►
From YouTube: Sigstore Community Meeting - June 7, 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,
thank
you,
hey
everyone!
Welcome
to
the
six
store
community
meeting,
tracy's
out
today,
so
I'll
be
leading
the
meeting
if
you
haven't
been
before
we'll
start
with
a
project
around
robin
just
discussing
the
ongoing
work
and
we'll
discuss
the
ga
effort
a
bit.
If
you
have
any
other
things
to
discuss,
please
add
those
to
the
agenda
in
aob
and
if
you're,
a
new
community
member,
we'll
have
a
little
bit
of
time
at
the
end
for
introductions.
A
Priya
might
be
out
okay,
I
will
circle
back
so.
B
I'm
feeling
sick.
Sorry,
I
can
do
that.
One
no
worries
yeah
and
carlos
successfully
did
a
shard
in
the
staging
environment
so
give
it
a
try,
seems
to
have
gone
pretty
smoothly
in
the
updated
playbook.
A
Fantastic
that
is
good
to
hear.
Do
you
know
for
any
issues?
Was
it
significant
enough
that
we'll
want
to
do
another
starting
to
exercise
whatever
the
fix
is,
or
was
it
a
minor
issue.
B
C
D
D
He
brought
it
up
because
we
are
quickly
and
hopefully
very
quickly,
approaching
a
ga
for
these
things
and
now
might
be
a
good
time
to
make
that
change
before
ga.
We
don't
have
to
have
a
full
design
discussion
about
what
change
and
how
and
whatever,
but
if
this
is
something
you
have
hit
and
are
annoyed
by.
Let's
use
that
anger
to
productively
change
this
thing
before
ga
or
if
we
think
we
need
to
do
this
after
ga,
that's
fine
too,
but
a
a
good,
clear
decision
would
be
useful.
D
That's
all
I
guess
probably
go.
Let's
either
talk
about
it
in
slack
or
in
that
issue
or
later
in
this
meeting.
If
we
want
to.
A
I'll
just
I'll
quickly,
chime
in
here
since
we've
brought
this
up
a
little
bit
in
some
ga
discussions.
I
think
we'll
couple
this
work
with
the
grpc
rewrite,
because
we
don't
want
to
make
any
breaking
changes.
I
think
to
the
existing
v1
api
before
ga.
The
question
is:
can
grpc
get
done
before
ga?
There
are
some
conversations
right
now
about
priorities.
A
This
is
a
pretty
large
feature
and
I
think
we
had
initially
discussed
that
we
wouldn't
include
grpc
in
the
ga
release,
I'll,
let
bob
or
dan
chime
in
if
they
have
any
more
thoughts
on
this.
But
that's
that's
kind
of
my
initial
feeling
for
this.
E
I
guess
I
didn't
realize
there
was
so
much
anger.
So
shame
on
shame
on
me.
I
guess
is
the
guy
that
wrote
the
code.
I
I.
C
C
E
G
D
I
think
if,
if
grpc
is
on
the
horizon
and
grpc
might
fix
it
on
the
horizon,
even
after
ga
and
would
fix
it,
I
think
that's
that
seems
fine
to
me,
I'm
not
in
a
in
a
huge
rush,
except
that
the
gate
on
ga
is
closing
and
then
any
change
is
harder
to
not
than
impossible
but
slower
and
harder
to
make.
If
grpc
is
the
answer
to
that,
then
that's
fine
and
I'll
wait
personally,
yeah!
That's
for
no
one,
but
me.
E
Defining
a
revamped
v2
version
of
the
api
in
general.
I
E
Both
http
protocol
support,
as
well
as
grpc,
so
we're
not
necessarily
saying
hey
we'd,
have
to
make
full-on
client
pulling
changes
over
to
that
stack
as
well.
It's
more
of
just
a
hey
we're
going
to
take
everything.
We've
learned
about
the
api
and
the
project.
You
know,
look
to
rebase
it
and
then
ultimately
rip
out
some
of
the
code
generation
that
we
have
based
on
the
open
api
spec
that
is
quite
bloated
and
not
optimal,
for
a
set
of
other
reasons.
E
E
D
That's
helpful
clarity,
thank
you
for
that
and
if,
if
a
v2
api
is
coming
I'll
rephrase,
if
a
v2
api
is
coming,
I'm
fine
to
wait
for
it
myself,
but
if
there
wasn't
and
the
gate
was
closing
on
ga,
I
think
we
would
want
to
rush
to
get
it
through.
In
any
case,
just
having
having
an
answer
to
the
question
is:
is
the
the
ask
because
it's
just
sort
of
that
issue
has
just
lingered
there
since
we
talked
about
it
a
couple
weeks
ago.
A
Awesome,
thanks
jason.
I
guess,
if
anyone
has
any
other
comments
on
this
feel
free
to
hop
onto
the
issue
and
continue
discussion
all
right.
Let's
continue
on
to
folsio.
G
C
Full
co
that
uses
grpc
and
exposes
an
http
endpoint,
so
I
mean
presumably
the
v1
api
is
going
to
be
available
in
ga
and
that's
fine.
But
do
we
have
a
deprecation
strategy
to
remove
all
this
code
and
say:
hey
clients
should
get
off
this
in
one
year
or
six
months
or.
C
I
mean
I
would
say
six
months
just
so
I
can
delete
all
that
code,
but
there
might
be
some
existing
policy
that
I'm
unaware
of
for.
A
So
we
we
do
need
to
come
up
with
an
exact
date.
We
have
roughly
said
a
year,
but
we
will
not
add
any
new
features
to
v1
to
encourage
folks
to
move
on
to
the
v2
api.
Hopefully
it
shouldn't
be
a
significant
change
once
again,
grpc
or
http
works
for
accessing
it.
If
you're
writing
a
client
I'd
recommend
just
using
the
v2
api,
that's
at
this
point
been
rolled
out
with
the
production
release
that
we
did
last
week.
So
that
is
usable
at
this
point.
A
We
mostly
wanted
to
keep
v1
around
not
to
break
anybody
who
was
currently
calling
it
and
that's
why
we'll
probably
roughly
say
a
year
after
ga.
But
I
agree
that
we
need
an
exact
date
in
place.
A
Alrighty,
oh
other
thing,
I'll
mention
for
pulsio.
This
morning
we
released
0.5,
which
includes
some
internal
code
cleanup
and
a
a
new
api
for
fetching
the
configuration
for
full
seo.
A
All
righty
any
updates
for
cosine.
B
1.9
got
released,
which
contains
the
important
tough
fixes.
So
I
think
you
should
be
getting
close
to
being
able
to
try
a
new,
tough
v3,
but
you
probably
know
better
than
I
do.
Hayden.
A
Yeah
that
I
think
we
should
still
be
able
to
use
the
the
v3
root
without
upgrading
to
cosine.
The
fixes
will
help
us
with
the
I
guess
now
we'll
call
the
v4
signing
which
asura
we
are
officer
and
myself-
and
I
believe
I
don't
know
if
anybody
else
is
working
on
this
too.
If
you're
interested
come
chat
with
us,
we're
working
through
a
few
issues
that
came
out
of
the
post-mortem
yeah.
C
C
Yeah,
the
cosine
side
of
things
is
done
with
the
1.9
fixes.
Now
now
there's
a
couple
of
cleanup
things
that
I
have
to
go
through
that
issue
and
make
sure
you're
done,
but
everything
else
is
on
the
route
signing
repo.
So
there
are
a
bunch
of
issues
on
the
route
signing
repo
that
we're
starting
to
take
care
of
these
days,
so
check
out
that
if
you
want
to
take
one
of
those.
D
A
D
Right,
yes,
there,
it
is
also,
I
assume
billy's
not
here.
He
would
have
said
something
right
now,
but
yeah
billy
wrote
a
blog
post
for
the
six
store
blog
that
she
watson.
B
A
That's
excusable
we'll
allow
that
all
righty,
so
somebody
said
delays
out.
Does
anyone
else
want
to
speak
on
the
policy
controller.
B
A
Awesome
cool
always
found
some
good
code
cleanup
all
right
java.
Patrick,
do
you
have
an
update.
H
Yeah
we
talked
about
this
a
couple
weeks
ago.
You
know
java
was
kind
of
trying
to
figure
out.
We
as
part
of
our
release
process
for
multi-module
builds.
You
can
have
quite
a
large
amount
of
artifacts
that
need
to
be
signed,
so
we
weren't
quite
sure.
If
that
was
gonna,
gonna
meet
recourse
expectations
and
like
load
capabilities,
we
got
some
information
from
jason
swank
from
even
central
about,
like
those
artifacts
sort
of
the
amount
of
published
artifacts,
be
hovering
around
250
000
a
week.
H
So
we
just
wanted
to
get
confirmation
that
that's
something
that
would
fit
and
by
the
sounds
of
it,
the
comments
I'm
seeing
that's
going
to
be
all
right.
H
B
Yeah,
this
is
a
lot
of
load
like
a
good
amount
like
a
doubling
or
a
tripling,
not
like
a
200x
or
a
2000x,
or
something
like
that.
That
would
scare
me.
I
think
we
chatted
offline
a
bit.
It's
not
like
you're,
going
to
hit
a
switch
and
just
slam
us
with
this
load
either
it's
you
know
it's
going
to
be
up
to
people
actually
slowly
converting.
So
if
we.
B
H
Yeah
one
thing
jason
swank
came
up
mentioned
when
we
were
talking
about
this
last
time,
is
that
he
was
more
concerned
about
the
verification
load
and
that
actually
kind
of
gave
us
some
insight
into
the
fact
that
the
cosign
tool
is
doing.
G
H
Offline
verifications
so
that
we've
kind
of
modified
our
design
so
that
we're
we're
going
to
be
storing
the
well,
we
think
we're
going
to
store
the
whole
bundle
with
the
artifact.
C
I
Yeah
I'll
read
it
to
that
point,
patrick,
I
think
the
six
store
project
itself
should
be
a
little
bit
more
deliberate
about
giving
advice
there.
I
know-
and
I
I
appreciate
you
being
you
know
one
of
the
guinea
pigs
along
with
a
bunch
of
the
other
intrepid
adventurers
who
are
who
are
struggling
through
this,
but
maybe
maybe,
as
sort
of
your
your
project
wraps
up.
I
We
can
do
sort
of
retrospective
and
and
try
to
codify
a
lot
of
these
things
that
you've
had
to
figure
out
the
hard
way
and
hopefully,
next
time,
it'll
be
a
little
bit
easier.
H
H
Want
us
to
be
sort
of
on
parity
with
the
other
languages
that
are
doing
integrations
here,
and
I
could.
H
Instance,
upgrading
updating
the
like
sign,
blob,
cosign
docs,
to
sort
of
give
people
an
indication
of
doing
that.
Yeah.
J
Like
one
thing
on
the
load,
would
it
be
possible
to
point
it
at
staging
just
to
see
how
the
stack
would
look
like
like
I
don't
know
how,
like
would
that
be
too
confusing
for
people
to
use
that
for
this?
But
it
would
be
a
good
way
to
like
ensure
that
we
could
handle
the
load
before
even
if
it's
to
ramp
up.
H
Yeah
priya
mentioned
the
same
thing
I
mean.
Let's
talk
about
it,
I
don't
really
know
how
you
can
make
that
work,
but,
for
instance,
maybe
if
we
do
the
the
mass
sort
of
signing,
we
could
try
that
out
on
staging
first
or
something
like
that.
Okay,.
B
J
If
it's
that
then
yeah
staging
would
probably
be
too
much
work
overhead
for
okay,.
C
F
Yeah
this
does
the
signing
flow
fail
open
if
six
store
is
down.
F
B
B
C
F
The
ability
to
fail
open
here,
because
it's
not
actually
released,
and
if
we
like
we're
in
the
process
of
going
through
upgrades-
and
we
saw
last
week,
we
had
you-
know
significant
issues
where
we
we
actually
generated
log
entries
for
a
period
if
people
are
actually
taking
a
dependency
on
this
in
a
any
kind
of
fold
closed
way,
then
it's
if
something
goes
wrong.
It's
really
good
incentive
for
them
to
just
turn
it
off
and
not
do
it
again.
G
I
can
surely
with
the
cover
this
experience
we
just
had.
We
had
another
dependency
on.
I
think
it
was
cosine
1.6
in
the
kubernetes
release
process
and
there
was
a
change
of
stream
in
six
store
and
it
ground
the
kubernetes
releases
to
a
hull,
because
we
hadn't
updated
the
documentation.
G
It's
so
bad
that
carlos
isn't
here,
because
he
he
was
the
actual
person
who
fixed
it
last
night
and
yeah,
we
have
to
adapt
and
we
are
improving
the
reliability
of
our
release
process,
just
to
make
sure
that
whenever
we
find
or
have
any
communication
problems
with
sixer,
we
can
still
run
the
releases.
And
but
yeah
I
mean
it's
a
cost
benefit
in
the
end.
F
A
K
K
So,
for
example,
in
the
ruby
proposal,
we
basically
get
to
the
point
where,
if
you
have
an
unsigned
gem,
we
make
it
very
difficult
for
you
to
install
it
just
to
really
place
pressure,
and
it's
imaginable
that
we
would
eventually
reach
a
stage
where
we
say
the
policy
is
now
that,
if
you
are
in
the
top
x
gems
downloaded
that
you
have
to
be
signed
just
as
we're
doing
with
mfa.
F
F
F
I
think
it's
a
question
for
the
the
ring
gear
like
like
how
comfortable
are
we
announcing
support
for
something
when
we're
not
ga
and
we're,
and
when
the
infrastructure
itself
isn't
stable,.
B
B
C
I
H
A
Can
can
we
slightly
mitigate
this
by
having
those
who
are
taking
dependencies?
Note
that,
like
these
features,
are
in
beta
still
that
we're
just
part
of
this
is
is
to
avoid
any
sort
of
reputational
damage
where
people
go.
Oh
six
store
falls
over
frequently,
I'm
gonna
never
come
back
to
the
sig
store
right.
If,
if
we're
saying
that
the
service
itself
is
effectively
in
beta
the
features
and
the
tooling
that's
using
six
store
should
probably
also
still
be
in
beta
until
we
come
out
of
beta
into
ga.
A
K
Should
we
carry
this
over
into
the
6.8
discussion?
That's
coming
up.
A
Yeah
anyone
yeah
we
can-
we
can
discuss
this
more
here,
also
note
that
we
have
a
weekly
meeting
on
ga,
where
that
can
be
another
opportunity
to
have
this
conversation.
A
All
right
dustin
did
you
have
some
updates
for
the
python
client.
C
Hey
howdy
folks,
yeah,
just
click
updates
on
the
python
client,
we
made
a
new
release
with
sct
embedded
scp
support.
That's
out
now,
there's
a
lot
of
discussion
happening.
We
want
to
provide
an
interface
for
verifying
emails
and
identities
together
or
potentially,
additional
extensions
insert
so
we're
kind
of
blocked
on
some
like
upstream
discussions
happening
cosine,
because
we
want
to
implement
something
similar
and
not
just
go
off
and
do
our
own
thing.
C
So
I
appreciate
it
folks
weighing
in
on
that,
and
we
have
a
plan
to
start
signing
the
see
python
releases
with
six
store,
starting
with
python
311.
So
I'm
actually
later
today
going
to
sit
down
with
the
release
manager
and
we're
going
to
sign.
F
C
Stuff,
so
that's
super
cool
and
I
appreciate
some
eyes.
Some
folks
have
already
reviewed
this,
but
sometimes
in
that
doc
as
well.
It's
just
sort
of
a
workflow
for
people
that
aren't
super
familiar
with
six
store
and
the
tools
using
the
python,
client
and
yeah
zach.
I
Hey
yeah
great
work
on
both
those
fronts,
sort
of
the
the
python
client
front
and
the
the
c
python
doc.
I'm
really
excited
to
see
that
that
rolling
out.
I
would,
I
guess,
urge
you
to
to
try
to
figure
out
what
an
action
on
the
notion
of
identity
that
you're
using
for
verifying
the
the
python
releases
is
independent
of
sig
store
coming
to.
Some
kind
of
you
know,
fixes
everything
conclusion
here
and
I'm
happy
to
discuss
with
you
offline.
I
If
you
want
to
brainstorm
on
on,
you
know
what
that
might
be,
what
a
safe
you
know,
sort
of
future-proof
approach
might
be.
So
I
would
urge
everyone
to
weigh
in
on
those
issues,
but
I
would
also
urge
the
python
folks
to
try
to
try
to
not
block
everything
and
they're,
mostly
related
to
me
stirring
the
pot
a
little
with
sort
of
my
my
takes
on
on
what
actually
is
the
notion
of
identity
that
we
are
attesting
to
in
six
store,
so
very
interesting
discussions,
but
but
yeah,
that's
that's.
C
H
C
The
cert
issuer-
and
we
just
want
to
figure
out
what
that
should
look
like
and
then
make
it
user
friendly,
so
cool
thanks.
A
Thanks
dustin
see,
if
folks
want
to
hop
on
to
these
issues
discussed
more
there.
I'm
definitely
a
fan
of
having
the
clients
all
be
in
sync.
In
terms
of
what
they're
offering
six
store
ga
kenny
did
you
want
to
give
an
update.
J
Yeah
so
last
week
we
did
our
cluster
migration
and
the
entire
production
environment
is
now
critified.
So
it's
like
we're
no
longer
yellowing
our
changes
into
production
of
some
random
box.
So
that's
great.
We
did
unfortunately
discover
some
issues
of
our
configurations
during
the
migration
process,
so
there
is
some
amount
of
cleanup
we
have
to
make
so
we're
looking
to
we're
in
the
process
of
doing
more
documentation
with
playbooks
and
making
our.
J
Infrastructure,
a
bit
more
robust
for
things
like
that,
but
yeah.
So
that's
the
quick
update,
we're
also
we're
still
on
fossil
f
zero
point
recall
0.5,
we're
waiting
for
a
couple
changes
for
the
sharding
as
well
as
what
not
to
come
out
so
we're
waiting
on
another
recoil
release
to
before
pushing
the
latest
version
of
recur
to
the
production.
J
Falcio
0.5
should
go
up
roughly
around
the
same
time.
Frame
of
that.
A
Awesome
thanks
for
the
update
did
anyone
else
have
anything
they
wanted
to
chime
in
on
ga.
J
The
I
think,
the
last,
the
ga
timeline,
I
think,
is
depending
on
the
attack
meeting
later
this
week
on
the
on.
What
exactly
do
we
want
ga
to
be
so?
The
timeline
is
still
roughly
in
the
air.
I
think
we're
still
hoping
for
a
initial,
like
pre-announcement
of
ga.
C
K
Yeah
I
I
sort
of
bulldozed
simon
out
of
the
way
earlier,
and
I
want
to
sort
of
build
those
back
in.
So
I
guess
one
question
is:
would
we
set
something
like
an
slo
target
that
we
have
to
meet
before
we
announce
ga.
A
Slo
is
expected
to
be
a
part
of
ga,
it's
I
I
would
say
it
is
best
practice
that
we
are
meeting
that
slo
for
some
time
before
we
officially
go
ga.
I
think
that
point
might
be
up
for
discussion
a
little
bit
since
that
would
definitely
postpone
ga
a
little
bit
and
we
have
to
discuss
how
long
we
want
to
confirm
that
we're
meeting
our
slo.
J
We
I'm
sorry,
I
added
a
link
to
the
actual
assault
dock
that
we
drafted
for
ga
it's.
You
could
take
a
look
and
add
comment
if
you
want
there.
Sorry,
simon.
F
Yeah,
I
was
just
gonna,
that's
on
slo,
you
know.
If
you
look
at
just
last
week.
You
know
we
lost,
however
many
hours
of
transparency
log
entries
because
of
an
issue
which
should
count
against
soy
right.
So
I
don't.
F
Entries
did
we.
They
were
recorded
with
the
wrong
issue
so
well.
A
There
were,
there
were
two
issues
right:
there
was
that
the
the
search
index
wasn't
available
for
some
time,
which
we
could
consider
a
temporary
loss,
but
I
think,
would
still
count
against
slo,
and
then
there
was
that
certain
certificates
were
issued
with
the
wrong
issuer
value
in
the
extension,
which
I
think
we'd
have
to
figure
out
how
to
count
that
against
the
slo.
F
F
F
Like
I
think,
I
think
the
goal
here
is
get
to
a
state
where
we
don't
just
have
the
slo
defined,
but
we
can
demonstrate
that
we
need
it
and
that
involves
getting
the
change
management
process
in
place
and
demonstrating
that
we
can.
We
can
go
through
regular
releases
at
some
cadence
for
some
amount
of
time
and
over
that
period
we
also
demonstrate
that
we
need
an
slo.
F
F
We've
we've
tried
to
make
a
couple
of
changes
and
we've
found
things
that
weren't
discovered
in
tests
and
we
found
things
that
weren't
discovered
in
staging.
They
just
went
to
production
and-
and-
and
you
know
we
were
surprised
so
like
those
kinds
of
issues
in
in
security
infrastructure
are
super
problematic.
F
And
there's
there's
a
good
amount
of
work
that
we
need
to
do
to
make
sure
that
we
can
reliably
release
this
thing
without
causing
those
kinds
of
problems
and
so
looping
back
to
the
original
discussion.
Again.
How
comfortable
are
we
announcing
how
you
go
and
do
this
to
our
users,
like
you
just
go
start
using
it
when
we
like
we're
in
a
state
where
we're
not
sure
whether
we're
going
to
go
ga
in
a
month
or
two
months
or
how
long
it's
going
to
take
to
to
sort
of
converge?
A
This
might
be
something
good
to
mull
over
to
and
maybe
bring
this
up
in
one
of
the
working
groups
that
involves
a
lot
of
the
community
members,
for
example,
potentially
around
the
securing
software
repositories
having
a
little
discussion
on
reliability.
A
J
Plus
went
to
everything
simon
said,
I
think
the
harder
part
in
the
open
source
community
is
finding
people
to
actually
do
the
work
to
raise
it
to
the
raise
the
bar
that
we
want,
because
it's
always
a
chicken
and
egg
problem.
It's
like
engineers.
We
want
to
make
it
perfect
and
then
well.
You
could
take
forever
to
make
the
perfect
thing,
but
you
don't
get
users.
J
So
it's
like
not
to
say
I
don't
like
I.
I
totally
believe
we
need
to
do
all
of
these
things,
but
then
I'm
always
worried
about
if
we
push
it
out
too
long
and
no
one
actually
wants
by
the
time
we're
actually
fully
ready
and
no
one
wants
to
use
this
by
then
because
there's
another
competitor,
then
all
our
efforts
for
not
so
it's
like,
I
think
it's
a
fine
balance
and
for
like,
especially
with
demonstrations,
it's
like
yes,
it
will
get
better.
J
It's
a
learning
process
and
the
hardest
part
is
getting
people
to
work
on
all
these
things
that
we
need
done
to
improve
things,
because,
whether
it's
writing
tests
having
on
call
none
of
this
are
glamorous
community
work
that
people
are
eager
to
volunteer
for.
Unfortunately,
so
unless
we
have
dedicated
resources
from
a
big
company
to
back
it
up,
I'm
just
worried
that
we
end
up
saying
the
bar
so
high
that
we
never
end
up
going.
J
Ga
like
and
like
even
internally
when
I
was
at
google,
it's
always
like
the
sres
and
engineers
always
wants
a
higher
bar
than
what
the
pms
and
managers
want.
So
I'm
just
I
just
not
to
say
we
shouldn't
do
it,
I'm
totally
on
the
side
of
doing
it.
J
I'm
just
trying
to
be
mindful
that
community,
open
source
projects
dies
all
the
time,
just
because
there's
a
lack
of
users,
and
so,
if
we
don't
encourage
people
to
use
it
because
we
don't
feel
it's
robust
enough,
it
ends
up
no
one's
using
it
and
they
someone
else
does
something
that
might
not
be
as
good,
but
they
are
still
pushing
harder
from
it.
And
again,
I
don't
think
the
strongest
technical
solution
always
wins.
K
Very
quickly,
just
something
simple
like
two
releases
or
two
months
or
something
like
that,
you
know
it
doesn't
have
to
be
a
super
long
time.
I
could
I
see
where
you're
coming
from
kenny,
but
I
I'm
not
as
concerned
about
getting
to
the
market
first.
I
think
there's
so
much
momentum
behind
six
store
at
the
moment,
but
I
appreciate
that
we
we
do
want
to
get
it
out.
Eventually,
we
don't
want
to
sit
on
it
forever.
K
So
I
think
a
reasonable
compromise
would
be
something
like
two
releases
are
successful
or
two
months
would
be
a
like
a
reasonable
stretch
to
to
let
us
say
and
and
if
you
know,
I
think,
we're
probably
thinking
about
timing,
an
announcement
for
the
oss,
the
open
source
summit-
that's
coming
up,
and
we
can
still
say
that
on
stage
we
can
say
we're
going.
Ga
you
know
by
this
date
before
everything's
met,
you
know
a
little
asterisk
in
the
tiny.
G
F
I
was
wondering
I
think,
proving
to
ourselves
that
we
can.
We
can
upgrade
this
thing
and
operate
for
some
period
of
time.
There's.
B
B
So
yeah
we're
not
significantly
worse
than
the
infrastructure
that
people
are
using
this.
Alongside
of,
I
guess
today,.
B
F
F
So
you
know
if
you
people
really
care
about
reliability
and
security
infrastructure
when
they
don't
have
it.
If
you,
if
you
don't
offer
it
and
and
things
go
bad,
that's
you
know,
you
lose
a
bunch
of
reputation.
If
you,
if
everything's
reliable,
then
they
don't
care.
A
I'll
just
say:
we've
got
a
ga
meeting
right
now
on
mondays,
and
we
could
consider
turning
this
into
a
larger
meeting
with
more
folks
involved.
If
there
is
some
interest
in
it
right
now,
it's
a
mix
right
now.
It's
primarily
about
the
details
around
things.
I'll
also
say
that
we're
planning
on
distributing
the
prioritization
list
once
that
is
finalized
and
discussed
more
with
the
tech,
so
definitely
would
like
input
from
clients
on
if
we've
got
the
right
priorities
going
forward.
A
All
right,
let's
continue
on
aob
zach.
Did
you
want
to
mention
the
skip
meeting.
I
I
also
posted
about
this
in
the
slack
so
so
feel
free
to
search
for
that
that
term
s-c-I-t-t
in
there
and
and
there
will
be
all
the
details.
But
there
is
an
ietf,
I
guess
working
group.
I
It
is
not
a
w
capital,
w
capital
g
working
group,
but
there
is
a
a
an
effort
within
the
ietf
to
do
some
things
like
have
transparency
logs,
that
track
components
of
a
supply
chain
and
also
make
some
does
some
reasoning
about
about
notions
of
identity
and
so
on,
and
if,
if
that
sounds
a
little
bit
familiar
to
six
stores,
because
they're
interested
in
a
very
fundamentally
similar
problem.
So
I
think
that's
that's
been
an
interesting
group.
I
I've
been
following
it
from
from
a
distance,
and
they
they
have
some
some
fun
ideas
over
there.
They
are
interested
in
doing
a
bath,
a
birds
of
a
feather
session
which
is
sort
of
an
ietf
term,
meaning
get
a
bunch
of
people
who
are
all
interested
in
the
same
problem
in
a
room
and
talk
about
that
problem
and
and
what
sort
of
solutions
might
might
look
like.
I
I
think
the
six
door
community
is
in
a
great
place
to
sort
of
come
and
productively
contribute
there
sort
of
talk
about
our
experience
and
and
actually
rolling
something
that
meets
many
of
these
goals
out
and
and
sort
of
decide
whether
you
know
we
can.
I
What
sort
of
the
long-term
path
for
that
group
might
look
like
so
yeah,
so
I'm
I'm
planning
to
personally
attend.
I
think
it's
it's
gonna
be
pretty
interesting.
If,
if
any
of
y'all
want
to
show
up
it's
open
to
everyone.
A
Awesome
thanks
zach
alrighty
any
other
aob.
A
Sweet
all
right
now
comes
the
part
about
introduction.
So
if
you're
new
to
the
community
feel
free
to
speak
up
totally
optional
and
say
hi,
I
guess
we'll
start
with
eric.
C
Hey
everybody,
I'm
eric
smalling
dave,
as
it
says,
I'm
with
sneak.
I
know
a
few
of
you
from
met
sovereign
villa
kubecon
and
from
other
similar
universes.
We've
worked
with
in
the
past
and
just
finally
got
off
my
butt
and
started
to
join
the
meeting.
A
A
A
Awesome
well
I'll
just
say
again:
if
you're
new
join
the
six
door,
dev
group
and
that'll
give
you
access
to
the
community
notes
and
the
calendar
invite
for
the
community
meetings.
Thank
you
everyone
for
coming
today,
ken!
Would
you
be
able
to
stop
the
recording.