►
From YouTube: Sigstore Community Meeting - May 31, 2022
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
welcome
everybody
to
this
last
six
store
community
meeting
of
may
2022
and
yeah.
We've
got
a
busy
as
ever
agenda,
including
joey
who's
joining
us,
especially
today,
to
talk
about
standards
a
little
later
in
the
call
so
quick
reminder
meeting
is
being
recorded.
A
I've
now
figured
out
how
to
get
those
all
uploaded
to
youtube,
so
you
should
be
able
to
check
out
the
playlist
with
the
recent
meetings
and
I've
dropped
the
link
in
as
well
for
the
last
community
meeting,
okay
and
with
that,
let's
get
into
the
project
round
robin
seeing
it
pretty
quiet,
which
means
folks
had
a
good
memorial
day
weekend.
B
I
actually
had
just
one
one
thing:
I
think
carlos
released
the
0.7
a
few
days
ago,
which
had
all
the
sharding
downtime
changes
that
we
have
made,
so
I
will
probably
be
trying
to
shard
staging
this
week.
C
No,
no
major
updates.
B
A
A
Folks,
please
take
a
look
at
the
the
draft
billy's
written
up
a
nice
post
about
git
signing,
so
any
feedback
welcome,
and
it
will
be
great
to
get
this
up
on
the
six
door
blog
this
week.
C
Real
quick,
I
want
to
jump
back
to
cosine,
just
a
small
mention.
I
know,
there's
a
some
conversation
on
getting
a
new
release
out.
I
think
we
had
two
changes
that
were
depending
on
I
just
got
in
last
week:
there's
going
to
be
a
new
privacy
statement
just
regarding
what
gets
added
to
logs.
That
will
now
require
explicit
consent
in
certain
flows
where
you're
in
a
terminal
where
there's
expected
to
be
an
active
user
presence.
C
So
this
won't
affect
any
sort
of
automation
and
it
can
be
skipped
with
a
new
global
y
or
yes
flag.
That's
been
added,
the
other
changes
are
around
the
tough
clients,
so
there
was
a
bug
that
we
found
from
the
route
signing
that's
actively
being
fixed
and
also
related
to
that.
There
are
some
end-to-end
test
failures
in
the
space
too,
that
we
are
working
through
and
those
should
hopefully
all
go
out
soonish,
which
is
a
bit
of
a
large
pr
that
we're
working
through
right
now
and
yeah.
B
A
Okay,
any
oh,
no,
we're
gonna
jump
back
to
esket,
see,
there's
no
news.
D
Yeah
we
have
some
folks,
starting
this
week,
a
chain
guard
who
might
hopefully
be
co-opted
into
contributing
so
that'll
be
nice.
A
Okay
over
to
six
doj,
a.
E
So
we're
ready
to
migrate
our
zonal
cluster
to
a
regional
cluster
which
unfortunately
requires
a
bit
of
downtime,
so
we're
aiming
for
this
downtime
to
either
be
wednesday
or
thursday.
We
haven't
quite
finalized
it.
Yet,
as
we
do
our
some
last
minute
due
diligence
of
confirming
everything,
but
hopefully.
C
E
Be
a
no-op
for
people
there.
C
A
Great,
and
do
you
have
anyone
here
from
the
tsc
to
speak
to
any
plans
or
thoughts
around
the
ga
date.
E
Yeah,
I
guess
I'm
I'm
the
only
one
here
so
yeah
the
quick
update
is
attack.
Meeting
last
week
we
discussed
kind
of
about
the
definition
for
ga,
as
well
as
the
desire
to
get
to
a
more
concrete
plan.
The
agreed
to
next
step
was
that
we
at
the
next
attack
meeting
at
june
9th
we
will
review
a
proposed
plan
of
what
it
would
take
to
get
to
a
99.9
slo
with
24x7
on-call
coverage.
E
That's
I
think
it's
a
it's
definitely
a
step
forward
from
where
we
are
today
of
a
you
know,
best
effort,
experimental,
flagged
service,
so
making
sure
that
we
truly
understand
all
the
different
dimensions
of
that
plan,
both
from
the
robustness
of
playbooks
to
how
confident
that
we
feel
that
the
rotation
schedule
is
workable
to
a
whole
slew
of
other
things.
E
We've
got
a
fair
bit
of
work
to
do
here
in
the
next
10
days
to
get
that
plan
ratified
and
signed
off
on.
But
that's
the
current
current
schedule
is
that
we
will
look
at
that
plan
and
hopefully
make
a
determination
in
terms
of
you
know,
sizing.
B
A
Okay,
moving
on
then
to
outreach
and
events
I
want
to
highlight
for
those
of
you
who
are
fresh
off
kubecon
and
everybody
else,
it's
straight
from
one
cubecon
to
the
other,
and
the
end
of
this
week
is
the
deadline
for
talks
for
kubecon,
so
highly
encourage
folks
to
put
in
any
talks
on
six
door
and
connected
to
cloud
native
and
the
relevant
projects.
There.
A
Okay
and
then
yeah
great
to
see
a
couple
of
great
recent
blog
posts.
So
I
wanted
to
highlight
those
here.
So
there's
a
six-door
blockchain.
This
is
transparency
log
by
luke
in
santiago
and
then
the
privacy
and
sig
stop
post
by
zach.
So
if
you
haven't
had
a
chance
to
check
those
out
and
do
feel
free
to
share.
A
Okay
on
to
any
other
business
and
first
up,
we
have
jerry
berson
here
from
the
legs
foundation
and
openness,
ssf
and
jira
is
going
to
help
us
kick
off
a
conversation
or
just
get
us
the
ball
rolling
on
how
we
might
be
thinking
about
standards
and
open
specifications.
A
So
jerry
I'm
going
to
hand
over
to
you
but
yeah
folks.
This
is
you're,
pretty
interactive,
you're,
just
all
kind
of
learning
and
figuring
out
things
together,
just
with
a
general
view
to,
as
we
have
more
and
more
language
clients
coming
in
for
python
and
java
and
rust.
How
do
we
start
thinking
about
not
just
having
standardized
apis
but
driving
those
to
a
future
where
they
can
be
a
formal
specification
or
an
open
standard?
A
F
See
a
new
window
because
I
made
some
I
made
some
slides,
which
are
basically
part
of
a
standard
deck,
but
I've
kind
of
updated
them
a
little
bit
for
y'all
you'll
see
the
screen,
hopefully,
okay,
okay,
so
my
first
thing
when
I
talk
about
standards
is
just
to
kind
of
do
a
quick
intro,
because
I
don't
want
to
assume
that
everyone
here
has
had
experience
working
with
the
standards
body
or
working
on
a
standards
project,
and
it
can
be
super
overwhelming
and
super
confusing
for
the
uninitiated.
F
So
we'll
keep
it
really
simple.
A
standard
is
just
a
super
fancy
way
of
saying
we
agree
on
something
and
you
can
have
different
levels
of
standardization
right.
You
can
have
what
we
often
consider
a
community
standard,
which
is
where
you
know
a
group
like
you
all,
have
gotten
together
and
said.
F
F
F
It's
kind
of
reached,
perhaps
a
level
of
adoption
or
a
level
of
saturation
in
a
given
and
area
that
it's
sort
of
like
the
de
facto
thing
for
like
react,
is
sort
of
a
de
facto
standard
for
front-end
web
development
frameworks
or
something
moving
up
from
that
you
might
see
or
get
involved
with
industry
standards
or
industry.
Standardization
projects
at
groups
like
the
w3c
or
ietf,
where
there's
a
level
of
agreement
and
there's
also
paperwork
behind
that
level
of
agreement
right.
F
So
this
is
where
you
start
to
see
rigor.
You
start
to
see
formal
process.
You
start
to
see
some
assurances
that
are
being
made,
because
that
level
of
agreement
is
reaching
an
even
broader
group
of
users
of
stakeholders
and
so
on
and
so
forth,
and
then
last
but
not
least
like
the
highest
level.
We
refer
to
as
the
jury,
standardization,
and
this
is
what
you
get
when
you
go
to
like
an
ieee
or
an
iec
or
iso
or
whatever.
F
This
is
where
they
they
want
to
see
evidence
of
quite
a
bit
of
agreement
so
that
they
can
start
to
by
they
I
mean,
like
national
governments
and
industries,
can
start
to
maybe
set
policy
about
or
around
the
consumption
of
the
standard,
or
maybe
it
makes
it
into
procurement
requirements
or
that
or
import
export
requirements.
F
That
kind
of
thing
so
the
bar
has
to
be
pretty
high,
and
so
standardization
is
just
a
fancy
way
of
saying
here's
how
we
reached
agreement
and
here's
the
proof
that
we,
the
burden
of
proof
that
we
have
to
reach
to
sort
of
evidence
that
will
be
of
agreement.
F
So
and
the
question
becomes
whether,
like
your
open
source
project,
should
go
for
that
level
of
standardization
and
and
what
you
might
need,
and
why
obviously
there's
a
lot
of
great
benefits
to
going
taking
on
a
specification
or
standardization
development
project.
It
can
really
help.
You
know
to
signal
a
level
of
maturity,
a
level
of
stability,
consumption
of
your
project
helps
you
expand
the
marketplace
for
that
and
you're
going
to
certainly
see
in
a
lot
of
industries
where
it's
easier
to
sort
of
get
people
to
adopt
the
project.
F
You
know
and
then
other
industries
like
financial
services
or
the
like,
or
maybe
more
highly
regulated.
They
want
more,
more
proof,
more
certainty,
more
guarantees
that
things
aren't
going
to
be
shifting
out
from
underneath
and
they
like
to
consume
more
standardized
projects.
And
so,
if
you
want
to
get
in
your
project
into
those
sorts
of
fields,
you're
probably
going
to
need
to
be
on
a
standardization
track.
F
What
do
you
need?
You
need
processes
that
are
documented
and
auditable.
Really,
what
this
comes
down
to
is
ensuring
that
there's
a
degree
of
rigor-
and
you
know,
auditability,
if
you
will
for
how
decisions
around
the
technology
were
made,
who
made
those
decisions
and
how
well
those
are
sort
of
backed
by
and
promises
of,
contribution
to
your
to
to
the
ip
right.
So
in
open
source,
we
tend
to
sort
of
just
think
about
the
copyright,
and
sometimes
we
think
about
the
trademark,
but
in
in
a
standards
project.
F
We're
we're
not
only
thinking
about
the
copyright
of
the
documents
that
we're
working
on
we're,
also
thinking
about
trademarks
as
they
might
be
used
for
conformance
or
appliance
needs.
We're
thinking
about
patents,
which
are
super
important
and
most
open
source
licenses,
are
very,
very
bad
at
conveying
a
patent
so
that
ipr
assurance
is
very
critical
for
a
standards
project.
You
need
a
really
well-written
specification
document,
and
you
also
really
want
to
have
a
vision
for
where
you're
going
like
beginning
with
the
end
in
mind
is
not
a
bad
idea.
F
If
you
think
that
eventually
you're
going
to
want
to
have
you
know,
maybe
some
you
know
conformance
program
or
compliance
program
of
some
sort.
If
you,
you
know,
think
eventually
you're
going
to
want
to
be
operating
in
with,
with
a
you
know,
high
degree
of
reliability
in
different
marketplaces
like
that,
might
indicate
that
you
need
higher
levels
of
standardization
and
so
and
beginning
to
operate
with
some
of
the
rigor
that
you're
going
to
need
to
reach
those
levels
is
not
a
bad
idea.
F
So
standard
is,
is
going
to
include
a
spec
document,
not
all
specs
or
standards.
A
spec
is
just
basically
a
type
of
recipe
document.
It's
not
effectively
like
the
cake
itself,
but
it's
going
to
tell
you
how
to
how
you
can
make
one.
F
They
tell
you
what
you
must
must
not
should
should
not
and
sometimes
may
do
in
order
to
make
the
cake.
If
you
will,
they
will
tell
you
what
parts
of
that
recipe
are
normative
versus
non-normative
is
an
open-faced
sandwich
a
sandwich.
That's
would
be
a
great
question
for
answer
and
respect
for
sandwiches.
F
Tell
you
what
other
specs
you
might
need
to
conform
to
as
a
dependency
of
your
spec
and
specs
also
help
make
it
a
lot
easier
to
implement
your
technology,
so
things
that
you
should
see
and
include,
and
these
documents
are
like
glossaries
and
making
sure
you
know
it's
easy
for
a
person
to
read
that
there's
clear,
conformance
criteria
that
where
something
may
need
to
be
bolstered
with
an
example,
you
have
notes-
maybe
not
not
an
excessive
amount
of
notes
but
you're
using
notes
and
things
like
that.
Also
what
status?
F
What's
the
status
of
this
particular
spec?
Is
it
a
draft?
Is
it
an
editor's
draft?
Is
it
you
know
a
committee
specification
and
is
it?
Is
it
actually
a
standard?
So
those
are
those
are
things
to
to
include
you
know
in
your
spec
template
specs
are
very
useful
for
open
source
projects.
F
F
They
help
signal
performance,
predictability
and
maturity,
etc,
and
obviously
big
reason
for
specification
is
to
drive
interoperability
with
today's
standards
makers.
What
we're
really,
what
most
of
them
many
of
them
are
looking
for
is
a
way
to
develop
standards
that
look
in
mirrors
and
feels
a
lot
more
like
the
way
that
open
source
developers
get
together
and
get
to
work
quickly
on
open
source
projects,
so
some
ways
in
which
these
two
things
are
often
being
sort
of
packaged
together
and
really
driving
a
lot
of
value.
F
You
see
in
like
documentation,
you
see
in
reference
implementations,
test,
suites
conformance
test,
suites
the
the
materials
around
the
spec
that
really
support
its
adoption.
Like
statements
of
use,
you
see
it
in
increasingly
in
the
and
the
actual
processes,
so
feedback
and
comment
disclosure
processes
which
are
common
in
in
a
standardization
process.
Moving
that
into
github
is
is
a
big
another
sort
of
way,
so
they
they
really
work
well
together
and
to
kind
of
drive
that
point
home
the
linux
foundation.
F
A
couple
of
years
ago,
combined
with
the
joint
development
foundation,
the
jdf
picked
that
that
group
up
to
help
expedite
this
process
and
sort
of
demonstrate
how
demonstrate
to
the
traditional
standards
people
how
open
source
can
be
leveraged.
Like
really
speed
this
up
so
standards
body
is
just
the
organization
that
provides
the
housing
for
the
governance
and
the
legal
and
the
finance
and
the
ip
and
all
of
that
sort
of
stuff.
F
That
might
you
know
and
come
to
bear
they
provide
that
governance
model
and
again,
because
for
a
lot
of
projects
that
want
to
hit
those
higher
levels
of
standardization,
those
governance
processes
have
to
be
much
more
baked.
F
They
might
they've
got
to
be
a
little
bit
more,
not
a
little
bit
more,
sometimes
a
lot
a
lot
a
bit
more
baked
than
they
often
are
in
in
our
kind
of
open
source
world,
where
we
kind
of
do
what
makes
sense
for
the
community
in
a
standardization
track
project,
you
generally
have
to
hit
a
standard
if
you
will
of
demonstrating
an
agreement.
F
So
the
jdf
provides
all
this
boilerplate
for
companies
to
get
together
and
make
make
commitments
to
collaborate
easily
easy
that
sort
of
spins
up
that
structure
really
fast,
because
the
the
boilerplate
legalese
is
provided
the
boilerplate
patent
and
copyright
and
trademark
agreements
are
provided
and
the
there's
a
standard
sort
of
pattern
for
the
government
governance
model.
Provided
in
order
to
again
help
the
project
take
their
their
collaboration
from
maybe
a
community
or
a
de
facto
standard
to
something
that
is
able
to
reach
iso
one
day.
F
So,
while
the
jdf
overhead
kind
of
does
that,
from
from
a
traditional
angle,
there's
also
been
quite
a
bit
of
interest
in
maybe
providing
this
same
type
of
training
wheels.
If
you
will
for
pre
pre-standardization
activities
to
get
to
the
formal
paths
with
with
less
friction,
so
without
necessarily
having
to
go
spin
up
a
a
legal
entity
at
the
outset.
F
What
can
a
project
do
to
start
its
start
down
the
path
of
standardization
as
it
figures
it
out,
and
that's
where
the
community
spec
comes
in
here
so
with
jdf,
they,
the
the
legal
team,
got
together
and
started
really
distilling
down.
What
the
base
templates
are.
What
the
base
process
needs
to
be
for
a
group
to
get
together
collaborate
on
a
specification
that
would
have
the
ability
to
one
day
be
an
iso
standard
when
it
grows
up
if
it
wants
to.
F
So
this
takes
into
account
the
licensing
concerns
that
you
are
going
to
need
to
interrogate
it
takes
into
consent
into
account
the
decision
making
and
processes
that
that
have
to
be
hit
and
and
all
those
kinds
of
formal
terms
and
things
that
are
necessary
for
for
for
formal
standardization
later
down
the
road.
F
F
Solutions
in
an
open
source
friendly
way
that
kind
of
thing,
so
it's
all
out
there
on
github,
and
this
is
basically
a
repo
of
how
the
how
to
kind
of
get
started
from
from
from
scratch.
F
We've
got
a
lot
of
information
in
this
repo
about
how
to
consume
and
use
the
community
spec
license,
which
is
a
license
specifically
for
open
source
projects
that
are
gonna
work
with
with
a
standard
component
of
some
kind.
So
you've
got
your
copyright.
You've
got
your
patent.
You've
got
your
trademark
covered
in
an
open
way.
F
You
have
the
scope
documents
that
you
need.
You
have
the
governance
processes
that
you
need.
F
Importantly,
when
you
look
at
the
a
a
standard
standardization
project,
you
really
do
have
to
have
a
process
for
making
sure
that
the
person
or
persons
who
are
contributing
material
into
that
document
have
agreed
to
the
the
the
terms
of
the
ipr
terms,
and
so
there's
some
suggestions
in
here
for
how
we
use
tools
like
ezcla,
to
to
assure
that
that
has
been
reached
and
there's
some
some
templates,
and
things
too,
which
are
helpful
to
take
a
look
at
because,
depending
on
where
you
want
to
take
your
specification
as
a
next
step,
you
will
have
to
fit.
F
Your
documents
will
have
to
fit
the
templates
for
those
organizations
which
can
be
kind
of
a
pain
in
the
ass.
If
I'm
being
honest
with
you,
so
recommend
that
you
take
a
look
at
that
that
spec
and
if
you
want
to
use
it,
this
is
beta
test.
But
that's
because
this
deck
was
from
2019,
it's
definitely
not
in
beta
anymore.
We
have
a
lot
of
projects
actually
that
are
using.
This
graphql
is
probably
the
one
that's
like
closest
to
this
group.
F
That's
that
they're
using
the
community
spec
to
standardize
graphql.
The
c2pa
is
a
group
that
is
doing.
F
Standards
to
prevent
malicious
digital,
fake
media
effectively
really
remarkable
as
an
example
here
that
group
started
in
march
of
2021
and
by
the
january
of
2022,
they
had
reached
version
1.0
of
a
spec
of
their
standard,
actually,
which
is
remarkably
fast,
and
they
did
that
starting
from
scratch.
It
was
it's
quite
quite
awesome.
Trust
over
ip
open
chain
and
spdx
are
examples
of
projects
within
the
jdf
portfolio
that
have
advanced
on
through
to
much
higher
levels
of
standard,
spdxs
and
iso
standard.
A
Gonna
describe
yeah,
I
think
graphql
is
the
one
I
had
seen
where
that
community
has
grown
really
fast
and
use
jdf
pretty
effectively
just
to
give
that
confidence
to
the
various
language
communities.
F
Yeah-
and
so
I
I
love-
I
know-
that's
that's
it
I'll
share
this
deck
with
you
guys,
I'm
gonna
stop
sharing
unless
anybody,
and
so
I
can
see
your
faces
and
see
the
chat.
F
Graphql
has
taken
a
sort
of
like
living
spec
model
which
a
lot
of
the
languages
are
doing
now,
thanks
to
html,
they
don't
have.
You
know
like
a
like
a
like
for
for
javascript.
It
is
another
example
where
there's
like
they
publish
on
a
yearly
cadence,
and
so
every
you
know,
jan
1,
that's
the
new
year
for
future
set
and
so
on
and
so
forth
for
for
graphql,
they're,
also
kind
of
on
a
time-bound
release,
cadence,
which
matches
what
many
open
source
projects
do.
F
So
that's
an
approach
that
you
can
take
and
you
can
start
to
use
and
and
sort
of
and
practice
what
to
grow
your
muscles
for
this
kind
of
kind
of
process,
but
anyway,
that
lots
of
rambling
any
what
questions
can
I
answer.
F
Probably
easiest
thing
to
do
in
terms
of
like
getting
started
again
would
be
like
taking
a
look
at
at
the
community
spec
repo
and
then
because
that
process
was
designed
to
work
with
open
source.
You
can
actually
start
your
standards
project
in
a
repo
on
your
sig
store.
Org
just
apply
the
community
spec
license
and
start,
and
you
already
have
some
of
the
structure
that
we'd
be
looking
for
right.
You
have
dan
luke
and
bob.
F
You
have
a
you,
have
a
tsc
or
tac
that
can
start
to
kind
of
to
be
that
that
main
bridge
that
we
look
for
in
the
in
our
in
our
jdf
projects,
there's
typically
a
a
technical
steering
committee
and
working
groups
or
tasks
task
forces.
That
may
be
tasked
with
specifying
certain
aspects
of
the
project,
but
those
report
up
to
the
the
the
tsc
which
is
very
similar
to
how
we
have
our
open
source
projects.
F
So
you
can
see
it's
like
not
that
far
off
from
what
you're
kind
of
already
doing,
the
objective
is
just
a
little
bit
different
because
you're
writing
a
recipe
and
the
sort
of
again
the
the
assurance
that
we're
looking
for
is
higher.
We
have
to
have
a
bit
more
rigor
around
documenting
decisions,
documenting
discussion,
documenting
who's
there,
what
they're
committing
to
and
that
that
sort
of
thing,
but
I
don't
think
it's
going
to
be
a
big
stretch
for
this
group
to
try.
A
Okay,
yeah
now
thanks
jerry
for
coming
in
and
giving
us
that
overview
and
those
pointers
yeah
now
I
know
for
open
source
folks.
This
is
sometimes
not
the
most
exciting
of
topics
but
yeah,
I
will
say
it's
pretty
incredible-
to
see
the
rate
at
which
six
store
has
been
growing
and
being
adopted.
So
I
think
it's
well
worth
talking
through
if
they
are
any
folks
on.
This
call
who
are
more
inclined
to
get
into
the
weeds
of
you
know
is
a
hot
dog.
A
A
sandwich
is
an
open
sub
sound
to
kind
of
yeah,
get
more
actively
involved
with
that
yeah.
I
think
just
let
us
know,
and
we
can,
as
we
start
to
think
through
next
steps,
that
might
be
a
a
working
group
or
something
but
yeah.
I
think
there's
just
a
lot
of
good
starting
points
to
look
at
for
now.
A
Okay,
so
thanks
again
any
questions
or
comments
before
we
move
on.
A
A
E
I
I
think
you
promoted
our
activities
last
week
and
yeah
we're
just
starting
to
collect
people.
You.
C
E
The
six
store
community
meeting
is,
after
this
meeting
at
12,
1,
30
eastern
and
we're
making
good
progress
on
the
client,
and
I
think
we're
gonna
do
a
release
sometime
this
week
and
jason
was
going
to
try
and
integrate
that
into
the
main
client,
we'll
see
how
that
goes
other
than
that
there's
not
much
else.
If
you're,
a
java,
developer
and
you're
interested,
please
hit
us
up
on
the
javascript
channel,
we'd
love
to
have
more
contributors.
A
D
Yeah,
that's
me:
I
will
go
ahead
and
present
another
week.
Another
kid
sign
demo.
E
D
Cool,
so
if
you
were
around
me
during
kubecon
eu,
you
probably
saw
me
hacking
away
at
this,
but
this
was
something
we've
we've
been
talking
about
since
the
beginning
of
git
sign,
which
is
how
can
we
start
sort
of
introducing
good
sign
into
sort
of
ci
cd
workload
workflows
and
in
particular,
using
things
like
github
actions
or
anything
that
sort
of
produces
oitc
credentials
to
basically
start
signing
commits
as
part
of
like
ci
flows?
So
this
is
what
this
does.
D
So
this
is
just
a
pretty
simple
kit
of
action,
and
what's
really
really
cool
about
this
is
that
you
basically
just
need
one
line
and
it
works
base
pretty
much
with
any
git
tool
that,
like
respects
a
user's
git
config,
so
there's
a
few
sort
of
scenarios
that
I
have
as
sort
of
examples.
So,
if
you
remember
the
demo
from
last
week
for
verifying
commits,
so
you
can
do
that,
pretty
simply
would
just
you
know,
install
the
tool,
get
verify
commit,
it
works.
D
So
an
example
here,
so
it
runs
as
part
of
the
action
verifies
the
commit.
You
know
you
get
that
green
check
mark
and
then
also
things
that
write
commits.
So
these
this
is
the
sort
of
the
more
interesting
bits.
How
can
we
sort
of
flip
this
into
other
tools
that
are
making
commits
think
depend
about
think
anything
that,
like
depend
about
ratchet
anything
like
that.
D
That
will
like
go
into
your
repo
and
say:
hey
like
hey
here's,
this
new
change
so
again,
pretty
simple:
you
just
need
to
set
the
permissions,
install
it
once
and
then
everything
else
is
completely
unmodified,
which
is
really
really
nice.
D
The
logs
aren't
that
interesting,
because
it's
basically
the
same
as
before,
but
we
do
get
this
nice
little
pr
and
you
can
see
it's
verified
six
store.dev
and
we
can
sort
of
go
and
inspect
the
certificates
and
see
what
I've
shown
before
you
know.
What's
next
about
the
code,
signing
search
is
that
it
actually
has
the
hey.
This
is
the
actual
git
of
actions,
job
that
ran
at
this
commit
for
this
pr
stuff,
like
that,
so
it's
really
really
nifty.
D
We
we
put
this
in
our
open
source
repo,
so
feel
free
to
try
it
out
david.
You
have
a
question.
G
Not
so
much
your
question,
but
my
standard
hobby
horse.
Whenever
can
you
hear
me
first
of
all,
okay
yeah,
whenever
you're
talking
about
signing
and
get
make
sure
you
repeatedly
over
and
over,
say
cryptographic,
signing
cryptographic
signing,
because
everyone
knows
what
signing
means.
It
means
adding
a
text
line
saying
signed
off
by
so
we
we
got
it.
We
got
to
make
this
clear,
otherwise
people
will
say
I
don't
need
a
tool
to
add
one
line
of
text
onto
my
connect
get
command.
I
can
just
reconfigure
my
tool
to
do
it
now.
G
G
B
Yes,
sorry,
I
had
a
a
child
to
attend.
To
my
end,
one
of
my
kids
walked
in
so
so
what's
the
ask
here.
D
G
B
B
B
B
A
Okay,
I
don't
see
any
other
hands
so
yeah.
No
thanks
really
great.
Do
we
have
any
other
business?
Wait
we
finish
off
with
the
introductions
for
anyone.
Who's
new
or
relatively
new
would
like
to
give
some
introductions,
but
just
before
we
get
into
that
section,
any
other
business.
B
Hey
yeah,
I'm
new,
I'm
just
getting
to
know
this
community
I'll
be
doing
some
work
with
six
store
and
podman,
and
also
I
want
to
incorporate
it
into
another
tool
that
I'm
working
on.
So
I'm
just
here
to
learn
and
hopefully
be
able
to
help.
A
Okay,
any
other.
You
folks.
E
Jarvis
yeah
hi
there
myself
and
I'm
someone
else
on
the
court
called
terrace,
we're
both
from
wise
we're
looking
to
try
and
start
using
six
store
more
internally
and
then
maybe
contribute
things
back.
If
we
find
cool
stuff
met,
some
of
you
folks
at
kubecon
eu
so
yeah,
it
looks
like
a
really
cool
product
and
want
to
see
how
it
goes.
A
Awesome
yeah,
no,
that's
great
and
yeah
really
glad
you
could
join
us,
definitely
keep
us
posted
and
if
you
ever
want
to
do
any
demos
yeah
more
than
welcome.
C
Hi
I've
bounced
in
between
a
lot
of
different
ossf
meetings.
I
don't
know
if
I've
introduced
myself
here.
My
name
is
jonathan
laichu,
I'm
an
open
source
security
researcher
and
I'm
the
first
ever
dan
kaminski
fellow.
So
yes,
I
don't
think
I've
introduced
myself
here
before,
though
so.
A
Anybody
else
and
yeah
for
existing
folks-
and
you
folks,
you
know,
do
feel
free
to
get
stuck
in
if
you've
you
should.
If
you
have
joined
the
mailing
list,
you'll
have
access
to
edit
the
minute
so
feel
free
to
put
things
on
the
agenda.
A
If
you'd
like
to
see
something
discussed
or
you'd
like
to
demo,
something
do
feel
free
or
you're
more
than
welcome
and
yeah.
If
you
have
questions
or
you
want
to
just
reach
out,
feel
free
to
reach
out
to
me.
If
you,
you
just
want
to
check
in
on
on
anything
before
going
ahead
and
doing
that,
but
yeah
otherwise
go
right
ahead.
A
B
Sorry,
sir
I'd
had
my
mic
off,
I
don't
know,
there's
some
public
holidays,
it's
the
queen's
marriage,
it's
like
a
platinum
they've
been
married
for
two
thousand
years
or
something
and
it's.
E
A
A
Okay,
unless
there's
anything
else
have
a
good
week,
the
recording
should
be
posted
by
tomorrow.
If
you
want
to
share
that,
but
otherwise
I
will
see
folks
next
week,
bye.