►
From YouTube: Sigstore Community Meeting - May 10, 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
And
the
good
thing
to
know
is
if,
if
you're
late,
for
some
reason,
somebody
else
from
chain
guard
will
be
able
to
let
people
in
so
that's
what
happened
when
we
had
so
I
created
the
original
one
on
the
red
hat
and
other
folks
at
red
hat.
Could
let
folks
in
for
me
so.
A
Well,
let's
just
have
a
look
at
the
who
we
have.
A
Okay,
I'm
sure
bob
will
trickle
in
shortly
so
right,
we're
recording.
So
that's
good,
so
we're
going
to
kick
off
with
the
agenda
for
the
community
chair,
okay,
so
tracy
is
our
new
community
chair,
okay,
great
to
have
you.
Thank
you
so
much
for
your
service
tracy,
this
one
really
good
to
leave
it
in
a
capable
pair
of
hands
there,
and
so
what
we're
going
to
do?
A
B
You
are
happy
to
do
that.
While
I
get
used
to
all
the
admits,
I
have
to
hit
sure
but
yeah.
Thank
you
very
much
and
yeah.
It's
an
honor
to
be
doing
this
and
I'd
like
to
extend
a
huge
thank
you
to
luke
for
getting
the
meeting
to
yes,
so
so
well,
run
and
I
hope
to
keep
that
up
and
keep
growing
the
community
and
getting
it
bigger
and
better
and
yeah.
I
look
forward
to
working
with
you
all
in
this
new
capacity.
B
So
that
being
said,
let's
jump
into
the
agenda
items
and
the
project
round.
Robin
so
does
anyone
have
anything
for
riko.
C
C
C
The
only
like
risk
is
the
time
it
takes
for
old
pods
to
be
spun
down
by
the
recoil
deployment
and
new
ones
to
come
up,
because
the
old
pods
would
be
writing
to
the
old
shard
and
the
new
pods
will
be
writing
to
the
new
one
we're
getting
around
this
by
scaling
down
the
deployment
to
one
pod
before
we
actually
replace
it
and
start
the
new
deployment.
So
that
way
entries
even
if
they
are
added
to
the
old
log.
C
The
new
pod,
the
new
pod,
as
it
spins
up,
should
be
aware
of
those
new
entries
and
then
once
everything
is
running
smoothly.
We'll
re-increase
the
number
of
pods
up
to
three
yeah
luke.
A
A
Yeah,
so
I
was
discussing
this
with
lilly
and
my
my
thoughts
are.
A
I
think
this
could
be
possible
for
us
being
an
experimental
okay
with
what
we
should
try
and
do.
If
it's
possible,
we
should
look
for
a
time
period
where
activity
is
at
its
lowest
okay.
Now,
at
the
same
time,
I
don't
want
anybody
to
get
up
at
4am
to
to
do
that.
So
you
know
you
know
we
might
need
to
sort
of
look
at
what
sort
of
time
zone
that
plays
out
for
the
people
that
are
working
on
this.
The
other
thing
is
when
we
go
into
full
ga
production.
A
A
So
one
of
the
things
I
was
thinking
of
earlier,
we
could
even
do
something
like
we
could
have
like
a
shim,
something
like
redis,
which
possibly
it
can
pull
so
that
as
soon
as
that
port
is
available,
so
the
services
come
offline,
it
could
immediately
perhaps
cache
the
entries
into
redis
and
then,
when
the
new
shard
comes
up,
then
it
could
spoil
those
entries
to
inclusion
into
the
log
so
that
that's
probably
a
bit
of
a
hacky
approach,
but
I'm
just
thinking
something
along
those
lines
where
we
could
have
some
sort
of.
A
I
don't
know.
The
word
is
shim
or
intermediate
skew
system
that
just
somehow
will
cache
those
the
the
other
thing
as
well.
I
did
raise
an
issue
about
this.
Is
we
could
look
at
how
different
clients
can
handle
this
as
well?
So
if
it's
like
a
10
20,
second
timeout
and
clients
have
their
own
retry
mechanism
that's
possible,
but
we
should
definitely
shoot
for
getting
seamless.
I
think
how
do
we
do
that
as
yeah?
I
don't
know,
but
so
it'd
be
good
to
to
sketch
some
sort
of
proposal
out.
C
C
Including
like
this
redis
thing,
and
then
I
had
been
brainstorming
about
having
a
separate
api
endpoint
for
sharding.
That
would
help
do
the
switch
over
so
like.
Maybe
that
would
help
too.
These
are
not
things
that
would
be
immediate
and
we
don't
need
to
do
them
now,
but
it
would
be
like
a
good
place
for
discussion.
A
C
I
can
definitely
I
can
definitely
start
brainstorming
some
plans
for
a
more
seamless
issue
for
now.
I
think,
with
the
current
plan,
we're
probably
okay
for
this
first
round
of
starting
because
we're
only
going
to
be
starting
staging
and
I
don't
think
anyone's
really
using
it
anyway.
So
yeah
we
should
be
okay
there,
but
yeah
before
I
say
that's
a
good
call
before
we
announce
ga.
We
should
have
at
least
know
how
we
plan
on
sharding
production.
A
And
then
we
will
then
need
to
work
out
a
date,
a
date
for
ga.
C
A
Yeah,
so
I
think
bob
wanted
to
talk
about
that
on
attack.
I
can
hear
someone
sort
of.
A
B
Yeah
we
can
propose
some
dates
and
then,
if
the
the
tech
wants
to
take
those
into
consideration,
decide,
but
let's
come
back
to
that.
So
is
there
anything
else
on
shouting
or
shall
we
move
on
to
hayden's?
F
Yeah
there's
a
lot
more
details
on
this
issue,
but
the
high
level
summary
of
this
is
I've
been
thinking
a
bit
about
the
purpose
of
the
time,
stamping
authority
and
whether
it's
necessary
or
not,
and
I
think,
as
it's
currently
deployed
it
doesn't
really
add
anything
of
value.
The
original
purpose
of
the
time,
stamping
authority,
was
that
you
know
if
you
wanted
to
have.
If
you
didn't
want
to
trust
recourse
clock,
you
could
have
some
third
party
provide
a
signed,
timestamp
and
admit
that
to
the
log,
but.
A
F
Log,
the
trust
models,
the
exact
same
and
you're,
really
not
getting
any
benefit
out
of
the
timestamping
authority.
So,
since
we're
pre-ga,
I
think
it's
the
the
right
time
to
have
this
conversation
feel
free
to
chime.
In
on
the
issue,
we
have
a
couple
different
options:
there's
one
option
which
is
removing
it
entirely,
which
is
my
personal
preference.
The
other
options
are
splitting
this
off
from
recore
to
make
it
its
own
service
that
it
can
run
that
can
be
run.
F
If
we
go
with
this
approach,
there
is
some
more
work
that
we
need
to
do,
because
the
underlying
rfc
that
describes
how
to
create
signed
timestamps
is
a
bit
complex
and
we
have
a
few
places
where
we
are
not
conforming
to
that
rfc
right
now.
This
is
once
again
a
reason.
I
really
just
don't
want
to
keep
this
around.
F
There
are
many
existing
implementations
of
time-stamping
authorities
out
there.
I
think
we
should
be
pointing
folks
to
those
if
they
really
want
those
there's
other
options,
which
is
newer,
timestamping
protocols.
Ultimately,
unless
we
want
to
just
bring
down
the
log,
we
need
to
still
support
the
time,
stamping
type
in
recore,
but
you
know
there's
an
option
of
supporting
different
types
of
assigned
time
stamps.
So
well,
that
said,
feel
free
to
take
a
look.
You
know
the.
I
don't
know.
F
If
we'll
get
this
change
in
soon,
I
think
there's
some
more
conversation
to
be
had
I've
got
a
pr
out
to
remove
it
just
to
see
what
that'll
look
like,
but
we
don't
have
to
get
that
in
yet
until
we
have
a
bit
more
conversation.
D
I'll
have
to
reply
on
the
issue.
I
I
think
we
should
keep
it
somehow
if
we
want
to
split
it
off
from
recoil
or
something
that's
fine.
The
main
point
for
me,
when
we
put
it
in,
was
actually
just
compatibility
with
systems
that
require
those
like
science,
jars
assigned
to
get
commits
those
kind
of
things
with
xmim
and
then
because
we
log
those
automatically
to
record
it's
actually
like
a
much
better
system
than
the
existing
ones.
You'd
be
pointing
people
to.
F
Yeah,
I
I
think,
if
we
wanted
to,
it
would
probably
want
to
be
its
own
service.
I
mean
we
can
decide
if
it
lives
outside
of
recourse
code
base
entirely,
there's
a
little
bit
of
work.
That
needs
to
be
done,
and
I
we
can
continue
more
on
the
issue.
I
think
about
this.
G
Is
is
the
time
stepping
authority
the
thing
that
creates
the
rfc
3161
entries
in
the
log
or
is
doing
more
or
things
than
that?
Okay
yeah,
just
just
to
give
everyone
a
bit
of
context
there.
There
are
only
like
196
in
the
entire
log
and
we
create
maybe
like
four
or
five
per
week
at
this
point
just
to
get
context,
and
the
entire
log
has
like
over
two
million
entries
now.
So
just
in
terms
of
use
total
log,
it's
vanishingly
small.
D
G
Because
I
I
would
trust
I'm
I'm
talking
about
I'm
counting
the
entries,
not
the
api
endpoints,
I'm
not
sure
why
someone
will
be
smacking
the
api
and
not
creating
entries
but
yeah,
like
all
of
the
entries
that
exist,
there's
only
just
under
200
that
are
type
rfc3161.
G
F
Well,
I
can
go
back
and
take
a
look
at
the
metrics.
I
mean
that's
even
more
justification
that
there
really
is
not
much
use
for
this.
At
this
point,
I'm
curious
if
you
know
the
the
date
of
the
first
entry,
so.
G
F
B
H
Yeah
this
was,
I
think,
I
talked
about
this
a
week
or
two
ago.
This
was
feedback
from
pipi
folks
and
I
think
a
few
others
on
the
call
said
they
ran
into
this
as
well.
H
It
was
a
pitch
to
change
the
top
level
key
from
being
a
dynamic
uuid
key
to
just
having
a
static
structure.
That's
easy
to
parse.
I
think
luke,
you
plus
one.
This
bob
said
that
we
could
do
this
in
grpc
and
anyone
have
thoughts.
I
can
start
working
on
this.
If
people
want
to
do
it
and
start
coordinating
with
all
the
client
libraries.
G
H
D
E
G
Yeah,
having
written
like
two
parsers
for
this
log
now,
it's
always
annoying
because
you
have
to
iterate
the
keys
there's
only
ever
one
of
them,
then
you
take
the
key.
It's
just.
It
feels
awkward.
Every
time
a
new
structure
will
be
lovely.
A
Yes,
I
was
just
going
to
say:
I
think
the
main
thing
we
need
to
consider
is
unifying
change
with
the
clients
really.
So
I
guess
cosine
is
the
main
one
so
that
we
make
sure
that,
as
the
release
that
there's
some
sort
of
coordination
really
around
the
releases
so
that
yeah.
B
D
Is
this
something
we
can
address
with
an
accept
header?
If
you
accept
the
recore
response
version,
one
you
get
the
old
well,
who
knows
what
the
default
would
be,
but
if
you
say
in
your
request,
I
accept
record
response
version.
2,
we'll
give
you
this
new
good
one,
and
then
we
migrate
clients
to
use
that
and
at
some
point
turn
off
the
old
one.
A
A
F
This
is
one
reason
maybe
to
to
handle
this
with
grpc.
Potentially
this
was
kind
of
the
same
thing
we
did
with
full
seal
where
we
took
advantage
of
the
fact
that
we
were
gonna
switch
over
to
grpc,
which
also
has
an
http
compatibility
layer,
but
we
versioned
the
api.
That's
a
v2
api
now
and
we
fixed
a
couple
things
that
we
didn't
like
about
the
first
api.
G
We'll
see
you
exposes
both,
I
think
using
jrpc
gateway
or
something
like
that.
But
then
we
do
support
both
the
one
and
the
v2
api
at
the
moment
in
full
co,
and
then
I
guess
we'll
deprecate
p1.
E
That's
right,
I
can
it's
just
that
I
would
want
to
keep
a
rest
api
for
the
very
simple
reason
that
rubygems
doesn't
want
to
take
honesty
of
dependencies
and
grpc
is
a
beast
and
talking
a
little
bit
out
of
class.
It
doesn't
get
much
love
from
google
in
ruby
land.
A
Yeah
I
did
discuss
this
with
bob,
I'm
not
sure.
If
he's
on
the
corner,
he
agreed
that
we
would
run
both.
So
you
know
you
could
you
could
you
could
pull
up
record
and
decide
which
interface
type
you
want
to
run.
F
Yeah,
I
don't
there's,
there's
no
plans
to
remove
the
rest
ap.
I
think
a
discussion
would
be
around
when
we
remove
the
older
version
of
the
rest
api,
like
with
full
seo
our
our
plan,
for
example,
proposal
going
forward
is,
we
won't
add
any
new
features
to
the
older
rest
api
to
encourage
folks
to
move
the
new.
H
F
You
know
and
then
we'll
have
to
probably
we
can
choose
to
maintain
some
sort
of
rest
client
if
we
want
to
otherwise.
You
know
we
can
say
if
you
want
client
generation
use,
grpc.
D
So
so
the
new
grpc
api
has
a
rest
proxy,
so
it
it.
It
exposes
a
rest
api
and
I
think,
from
java
land
we're
going
to
use
grpc
just
because
the
client
generation
is
easier
and
I
don't
have
to
write
out
these
weird
requests,
but
they
should
both
be
available.
A
A
A
B
G
Option
here
is
that
if
there's
an
open
api
spec,
you
can
code
jen
off
that
if
it's
better
in
ruby,
I'm
not
sure
if
that's
a
thing,
but
that
might
be
another.
A
B
B
Okay
right,
it's
moving
on
to
full
co
nathan,
refactor.
G
Yeah
and
not
really
a
big
thing
here,
I
propose
some
refactoring
work
in
philisti
a
while
ago.
That's
happening
now,
thanks
so
much
hayden
for
a
million
reviews.
Basically,
this
should
make
it
quite
a
bit
easier
in
the
future
if
we
need
to
add
more
identity,
issuers
and
logic
around
sticking
things
in
certificates
from
an
identity
issuer.
So
if
that's.
A
B
Okay,
thanks
nate
go
sign
anyone
anything
on
cosine.
F
Because
oscar's-
not
here
I'll,
start
off
by
saying,
thank
you
to
asura,
who
has
been
doing
an
absolutely
fantastic
job
throughout
this.
So
we,
the
tough
route,
is
expiring
in
about
one
day,
so
we
have
been
going
through
the
process
of
getting
all
the
signatures
from
the
root
key
holders
that
has
been
completed
as
of
last
night.
F
So
thank
you
to
everybody
for
quickly
getting
signatures
in
there's
a
couple,
more
steps
that
we
need
to
run
through
to
generate
the
rest
of
the
signed
metadata,
that's
with
online
keys
and
then
a
final
commit
and
push
make
sure
everything
works,
so
that'll
be
by
end
of
day.
We
should
be
all
good.
There's
no
worries
about
needing
to
push
this
new
tough
route
to
cosine.
Yet
we
will
probably
once
this
is
in
make
an
update
to
cosine,
so
that
this
is
the
the
default
route,
but
yeah.
F
Been
going
well
so
far,
if
you
want
to
follow
along
there's
the
root
signing
repository
where
prs
have
been
coming
in.
B
Nice,
okay,
six
doji
a!
I
don't
know
if
we
have
any
more
down
time
discussion,
but
one
thing
raised
was
related
to
the
ga
announcement
timing
and
priya
you
still
around.
We
had
some
thoughts
about
that.
C
F
I
would
just
say:
maybe
we
do
this
kind
of
systematically.
I
think
we
need
to
kind
of
go
through
all
the
open
tasks
figure
out.
What's
left
figure
out,
if
there's
any
timing,
you
know
issues,
you
know
the,
I
think
recourse,
probably
the
area
where
there's
the
most
question
of
what
we
have
left
to
do
and
just
make
sure
that
we
give
ourselves
some
runway.
You
know
at
least
a
few
weeks
where
we
can
iron
out
any
bugs.
G
D
Removing
the
timestamp
for
all
things
that
we've
just
kind
of
came
up
with,
because
we've
kept
stretching
this
out,
so
I
feel
like
some
line
in
the
sand
is
going
to
be
good
to
work
backwards,
yeah
directions.
I
guess
like
there
was
an
original
list
of
items.
I
think
that
just
kind
of
kept
growing
rather
than
shrinking.
F
Are
there
any
things
we
want
to
do
with
the
api
before
we
make
this
change
or
before
we
switch
over
to
ga,
and
we
have
to
have
some
api
stability,
so
I
think
that
would
probably
be
something
for
you
know
future
api
versions
that
we
think
a
little
bit
more
about
both
of
those
and
for
what
it's
worth,
I
think,
like
the
productionization
stuff
has
come
along
very
nicely.
I
think
there's
not
too
much
left
around
there
that
we
have
to
do.
I
think
it's
just
this
discussion
around.
D
D
Yeah,
I
just
had
a
quick
question:
sorry
hi
everyone,
I'm
simon
kent,
I'm
new
to
the
ghost
team
at
google.
Is
there
a
scoping
document
for
ga
that,
like
what?
What's
in,
what's
in
scope
for
ga
and
what
we're
announcing
and
promising
what
it
goes
to
you?
Can
someone
link
that
in
the
dock?
D
I
Yeah,
I
think
we
heard
the
quick
tl
dr
is
we
had
one,
but
then
it's
like
we
did
find
more
and
more
things
that
it's
like.
Well,
let's
not
break
the
api
afterwards
after
gh.
Let's
do
it
all
before
and
then
that
list
just
kept
growing
so
somewhat.
I
A
Luke,
I
just
can
say
going
forward.
It
might
be
useful
to
implement
some
sort
of
feature
freeze
for
this
sort
of
stuff
and
I'll
look
at
what
we
can
do
there.
I
Plus
one
on
that
productionizing
new
features,
every
couple
of
weeks
was
not
one.
A
B
Great
and
yeah,
just
from
the
other
side
like
the
non-engineering
side,
I
think
that
there's
nice
benefits
of
doing
a
a
big
announcement
where
we
pull
together.
All
the
different
communities
do
a
coordinated
announcement
and
it
makes
it
much
more
for
celebration
if
you
can
tie
to
an
in-person
event.
That's
quite
nice,
because
you've
got
folks
on
the
ground
who
can
cheer
it
on
or
we
can
have
some
special
swag
or
something
which,
which
is
pretty
fun.
B
So
I
do
think
that
connecting
it
to
an
event
has
has
some
nice
benefits
for
just
amplifying
that
message,
and
maybe
it
sounds
if
you're
in
that
ballpark
anyway,
I
can
get
the
ball
rolling
on
working
with
the
open
ssf
to
draft
an
announcement,
and
we
can
start
collecting
folks
who
can
contribute
in
terms
of
like
quotes
and
things.
It's
always
nice
to
give
folks
a
heads
up
if
they
need
approvals
so
yeah
I
can.
F
So
maybe
in
this
monday's
ga
meeting
we
can
go
through
the
open
tasks
and
see
if
what
we
have
open
with
what
we
have
open
if
june
end
of
june
would
be
a
reasonable
date.
B
A
Yeah
I
can
cover
this
one,
because
this
was
I've
been
speaking
to
carlos
a
fair
amount
this
week,
and
at
the
moment
we
got,
I
think,
close
to
30
repos,
okay
and
they
all
require
management
and
carlos
was
finding
it
a
bit
sort
of
challenging
having
to
ask
people
that
had
admin
to
do
certain
things.
So
there's
a
lot
of
other
stuff.
We
hit
some
limits
around
team
management
and
just
lots
of
things
really
so
so
we
thought
it'd
probably
be
prudent
to
have.
A
It
doesn't
need
to
be
a
sort
of
something
that's
forever
ongoing,
but
some
sort
of
infrastructure
working
group
that
can
tackle
all
of
this.
So
carlos
is
happy
to
be
the
point
person
on
that
and
he's
put
together
a
proposal
there
and
there
is
actually
a
meeting.
Let
me
just
look
at
my
calendar
to
remind
myself.
A
In
in
helping
out
with
sixth
or
infra,
I
do
recommend
you
come
along.
This
is
everything
really
github
actions,
automations
structural
team
structures,
how
maintainers
are
on
boarded
and
off,
boarded
and
all
of
that
sort
of
stuff
really.
I
Yeah,
this
is
a
big
plus
one
because,
like
I
was
just
talking
to
carlos
of
releases
well
we'll
release.
First,
you
need
release
focio,
then
record,
then
the
cosine
hcli
and
then
you
need
the
helm
charts
and
then
it's
like
the
scaffolding.
If
you
want
to
bring
up
the
entire
thing,
so
it's
like,
even
if
you
actually
want
to
use
all
the
pieces,
there's
a
lot
of
releases
that
needs
to
happen
in
order
for
any
one
individual
piece
you
you
want.
A
Very
much
yeah
as
well,
and
I
mean
that
even
came
up
on
this
meeting,
this
idea
of
release
coordination
and
so
forth
so
yeah.
I
do
agree.
B
A
Yeah,
so
so,
as
discussed,
we're
opening
up
the
tsc
for
anybody
to
attend
and
the
first
one
will
be.
May
the
12th
11
et
again
it's
on
the
calendar,
the
community
calendar.
A
We
have
a
relatively
light
agenda,
you
should
find
the
agenda
on
the
calendar
entry
and,
but
I
do
take
a
look
generally
will
be.
So
this
is
the
main
community
meeting,
okay
and
it
will
stay
that
way.
The
tsc
is
more
for
project
approvals,
anything
related
to
governance
and
so
forth.
A
So
so
we
try
to
be
fairly
autonomous
around
how
community
operates
it's
just
where
some
sort
of
voting
decision
is
needed.
A
Okay,
so
next
week
we're
all
out
in
sunny
valencia
and
well,
some
of
us
are
sorry
those
that
aren't,
and
there
is
a
no
need
to
access
this.
Unless
you're
you're
going
there
is
a
spreadsheet
which
just
tracks
the
who's
covering
the
booth,
so
we're
going
to
have
a
sig
store.
I
should
have
backfilled
that,
with
the
information
that
we're
going
to
have
a
six
store
booth
at
kubecon
eu,
so
this
is
just
to
help
state
who's
going
to
cover
it
at
certain
times
and
so
forth.
A
Okay,
and
so,
if
you
are
going
and
you'd
like
to
come
along,
do
request
access
or
send
me
a
message
on
slack,
and
I
can
add
you,
okay,
if
you're
all
going
to
be
there
but
you're
busy
or
you
don't
feel
you
know,
you've
been
around,
seek
store
enough
to
be
able
to
help
on
the
booth.
Do
come
and
see
us
that'd
be
great
to
see
anybody.
B
Awesome
yeah
thanks
for
pulling
that
together,
luke
and
yeah
you
and
red
hat
and
making
it
happen.
It's
awesome.
B
J
Yeah
so
there's
been
talk
about
paul
and
co-signed
the
web
hook
out
into
its
own
repo,
went
through
the
tsc
and
got
some
comments
and
plus
ones
and
whatnots.
J
So
I'm
gonna
apologize
up
front
because
I'll
make
mistakes.
When
I
do
that,
so
I
will
not
even
start
that
work
until
after
kubecon,
but
I
also
wanted
to
go
ahead
and
get
more
visibility
into
it
and
also
if
there
are
folks
who
would
be
willing
to
help
with
any
of
that
work.
That'd
be
fantastic.
J
H
Yeah,
this
was
just
a
conversation
that
came
out
of
the
pipe.
I
folks
again,
I
don't
know
if
jocks,
if
you've
put
any
thought
into
what
kind
of
type
you'd
want
when
you
think
about
like
a
ruby
package,
but
the
conversation
was,
do
we
create
a
type
per
package
manager?
So
I
have
a
pipi
type,
a
ruby
gems
type,
or
do
we
abstract
that
all
into
a
generic
package
type
that
satisfies
most
of
everyone's
use
cases?
E
Yes,
I
I
have
long
felt
that
a
generic
package
I
think,
was
going
to
be
necessary
or
that
putting
in
a
different
way.
That
would
be
very
wasteful
if
everybody
came
up
with
their
own,
so
I'm
definitely
in
favor
of
that
I
haven't
given
much
thought
to
the
details
of
it.
E
I
also
foreshadowing
believe
that
we'll
get
to
the
point
where
we
have
a
great
many
different
things
that
are
going
to
be
generic
across
package
ecosystems
that
get
written
into
the
logs,
so
things
like
push
events,
yank
change
of
ownership,
enablement
to
say
no
but
of
mfa,
perhaps
like
a
bunch
of
security,
sensitive
things
that
we
want
logged
in
the
open
will
eventually
wind
up
there,
and
I
think
those
should
be
generic
as
well.
E
E
Oh
yes,
that
was
it
definitely
as
this
evolves
or
as
this
firms
up,
please
bring
it
to
the
securing
software
repos
working
group,
because
that's
where
all
the
repo
focus
hanging
out.
B
K
Hi
I've
been
trying
to
deploy
to
maven
central
all
morning.
I
don't
think
I've
quite
made
it,
but
I
almost
have
a
working
version
of
the
plug-in
deploying
everything
to
maven
central
intact.
K
K
First
revision
of
the
maven
goodies
bob
is
going
to
take
a
look
at
the
code
that
I
made
and
then
no
dire
rush,
but
maybe
sometime
in
the
next
couple
days
the
code
will
get
moved
over
to
sigstor
and
I'll
start
trying
to
wire
it
into
everybody's
projects.
B
A
Yeah
so
great
work
nice
to
have
you
here,
jason
and
if
you
like,
you
could
do
a
demo
on
the
community
meeting
sometime.
If
you
want
and.
K
Tomorrow,
at
the
open,
ssf
meeting
and
I'll
record
one
as
well,
oh.
A
K
Yeah
definitely
I
I've
chatted
with
apoo
and
patrick,
so
I
think
part
of
the
work
that
I
have.
I'm
gonna
try
and
wire
back
into
the
normal
client,
and
then
it
can
probably
be
a
couple
of
blog
entries.
I've
got
the
sig
store
scaffolding
working
locally,
an
oidc
client
working
locally
and
then
the
sort
of
mock
of
maven
central.
So
I
can
try
and
someone
could
actually
do
all
the
testing
themselves
if
they
wanted
to.
So
it's
probably
a
few
blog
entries.
E
A
E
A
A
We're
we're
yeah
six
store
are,
but
we
we
do
run
with
some
autonomy
around.
You
know
stuff,
that's
happening
in
six
store.
If
it's
something
that
we're
doing
in
conjunction
with
the
open
ssf,
then
that
would.
K
Be
the
case,
however,
we
want
to
do
it.
I
was
just
interested
like
a
couple
months
ago
just
trying
to
get
it
working
for
the
ecosystem,
and
then
I
synced
up
with
dan
and
I'm
going
to
do
it
on
behalf
of
chain
guard.
So,
however,
best
I'm
not
in
any
rush
to
like
push
anything
out.
So,
however,
people
and
people
probably
want
to
watch
the
demos
first
and,
however,
you
want
to
proceed
is
fine
with
me
sure.
J
If
you
want
to
amplify
the
attention
and
use
the
open
ssf
as
part
of
a
communications
distribution
channel
yeah,
then
it's
good
to
give
them
a
courtesy
heads
up,
because
that
way
you
know
the
project
benefits
because
it
gets
broader
distribution
and
the
open
ssf
feels
good
about
it,
because
it
doesn't
come
out
of
left
field
where
the
friction
occurs
is
when
people
do
things
that
you
know
closely
reference:
the
open,
ssf
and
the
association
with
it,
but
failed
to
give
them.
Yeah
causes
some
heartburn.
A
Yeah,
I
guess
my
my
point
was
totally
agree
with
that.
It's
just
the
open,
ssf
haven't
really
had
any
involvement
in
this,
so
sona
type
contacted
six
store
directly
and
the
works
got
underway.
It's
I
mean
we're
a
project
in
the
openness
itself,
but
right.
J
B
We
just
communicate
with
folks
and
yeah.
Some
of
it
is
good
to
get
folks
involved
early
and
some
is
good
to
let
folks
know
so.
They're
aware,
but
yeah
either
way
happy
to
shout
about
this
one
in
various
ways,
and
we
can
come
up
with
the
plan
around
that.
B
Okay,
just
a
little
conscious
of
time.
Let's
move
on
anyway,
super
excited
about
the
demo.
So
yeah
good
luck
with
that
and
looking
forward
to
to
seeing
it
in
some
form
or
the
other.
Let's
go
to
crossplane
sig
jesse.
J
Hi
yeah
I
this
is
my
second
time
attending
the
meeting.
So
thanks,
I'm
I'm
actually
here
on
behalf
of
autodesk,
but
I've
been
doing
work
with
the
crossplane
community
to
implement
their
config
package.
Signing
I
just
wanted
to.
Let
folks
know
that
we're
going
to
kick
off
a
special
interest
group
within
crossplane
in
regards
to
config
package
signing
and
the
first
project
that
we're
going
to
take
on
is
going
to
be
validation
of
cosine
signatures
within
cross
plane.
B
Awesome
yeah,
that's
amazing,
to
hear,
and
thanks
for
coming
over,
to
share
that
news
check,
go
ahead.
E
I'm
sick
of
hearing
you
too,
I'm
sorry.
Yes,
this
is
awesome
when
it's
convenient
for
you.
Could
you
also
join
us
in
the
securing
software
repost
group,
because
this
sounds
really
very
early
and
just
be
nice?
Absolutely.
J
Absolutely
I
wasn't
aware
of
it
I'm
still
new
to
this
community,
so
I
will.
I
will
certainly
dig
it
up
and
be
there
all
right.
That's.
D
Yeah
this
is
me
yeah,
so
this
is
just
a
follow-up
from
the
the
demo
I
gave
last
week
for
git
commit
signing
for
using
ephemeral,
fossil
certs.
So
I'd
really
like
to
move
this
into
the
six
door,
org.
So
there's
some
discussion
on
the
original
issue.
I
went
ahead
and
opened
a
tsc
issue,
but
yeah
if
people
want
a
plus
one
or
if
they
have
any
comments,
feedback
stuff
like
that
yeah
feel
free
to
leave
it
on
the
issue.
A
J
B
Okay,
so
going
back
to
the
agenda,
we've
come
to
the
point
we
do
introductions
so
kenny
was
that
before
introductions
here.
I
Yeah
sorry
got
a
quick,
really
silly
question.
I
was
trying
to
access
the
video
recording
from
last
week
and
I
get
access
to
please
request
access.
So
is
there
I'm
just
trying
to
figure
out
like
what
do
I
need
to
do?
I
click
on
the
video
link
from
last
week's
meeting
in
calendar
and
it's
saying
access
denied.
So
I'm
just
curious.
What
do
I
need
to
do
to
gain
access
to
it?.
A
Yeah,
I
think
this
is
probably
a
consequence
of
us.
We've
we've
migrated
the
the
hangouts
account
and
the
calendar
entry
has
been
recreated
by
tracy,
okay,
so,
where
I've
handed
over
the
community
meeting
to
tracy
the
videos
are
probably
is,
I
think,
something's
probably
got
confused,
because
both
red
hat
and
chain
guard
use
google
services,
okay
and
there's
some
sort
of
enterprise
access
control.
So
I
don't
really
know
what
I'm
talking
about
here,
but
I've
got
a
feeling.
A
D
A
I
I'm
trying
to
oh
so
the
recording
for
last
week
is
tied
to
last
week's
calendar
yeah
and
entry.
So
that's
where
I'm
trying
to
load
the
video
from.
B
B
Let's
take
a
look
and
I
do
have
access
to
youtube
as
well.
So
if
I
can
access
it
we'll
see
if
we
can
just
upload
it
and
you
can
find
it
on
youtube.
D
B
You're
not
sure
why
that's
an
issue,
though
okay
yeah
introduction,
so
this
is
the
part
where,
if
you're
new
or
relatively
new
or
you've
been
looking
at
a
few
meetings
and
want
to
introduce
yourself,
please
do
feel
welcome.
I
think
we
heard
from
simon
earlier
so
same
and
if
there's
anything
else,
you
want
to
add
please
chime
in
and
yeah
I'll
leave
a
brief
pause.
So
anyone
wants
into
yourself.
B
J
Yeah,
I
just
I,
I
think
that
I
introduced
myself
last
week,
but
if,
if
I
did
not
my
apologies,
I'm
jesse
sanford.
I
work
at
autodesk
as
a
senior
principal
software
engineer,
but
primarily
I'm
sitting
between
developer
enablement
and
security.
So
a
lot
of
what
I
do
is
in
regards
to
build
pipelines
and
securing
them,
and
so
cosign
got
on
my
radar
about
a
year
ago
and
we've
actually
started
to
do
some
implementations.
J
I
really
appreciate
all
the
work
you
guys
are
doing
it's
great
stuff
and
I'm
looking
forward
to
adding
it
into
crossplane.
B
Awesome
yeah
so
glad
you're
here
and
yeah
you're
already
up
and
running
updating
the
agenda
and
everything
and
demo
soon.
I
think.
J
Hey
I've
stopped
in
before,
but
I
don't
think
I've
ever
introduced
myself
for
those
that
haven't
crossed
paths
with
I'm
jeff
borick.
I've
worked
at
open
source
and
communities
at
ibm
for
over
a
decade
now
in
various
capacities,
going
all
the
way
back
to
the
early
days
of
docker
and
even
before
them,
and
I
just
want
to
congratulate
the
team
on
the
recent
news
about
six
door
and
google
networks.
So
it's
a
significant
milestone
and
I
think
it's
a
great
step
forward
so
congrats
to
everyone
around
the
table.
B
Awesome
yeah
thanks
very
much
and
yeah.
I
think
with
saying
that
was
a
really
big
announcement
and
there's
a
bit
of
scrambling
earlier
last
week
to
put
that
together.
But
it
was
really
nice
that
we
had
lots
of
different
community
members,
both
from
kubernetes
and
from
sig
star
contributing
to
the
announcement
and
it
actually
got
picked
up
by
like
at
least
three
different
press
outfits
wrote
articles
about
it.
B
B
Awesome:
okay,
we'll
just
leave
it
at
saying
yeah!
No
thanks!
Very
much
for
all
your
support
is
the
kickoff
chair
meeting,
I'm
looking
forward
to
the
next
set
of
meetings
and
yeah
also
open
to
meeting
folks.
If
anybody
wants
a
sync
up,
one
to
one.
Please
hit
me
up
on
slack
if
you've
got
any
ideas
about
the
community
meetings
and
things
you
want
to
see
more
for
things
you
want
to
see
less
of
or
just
any
other
feedback
you're
happy
to
chat
directly
with
folks.
So
don't
feel
shy.