►
From YouTube: SLSA Meeting (September 15, 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
A
So
some
of
the
stuff
that
we
were
going
to
talk
about
regarding,
like
how
can
people
sort
of
assert
that
they
are
salsa
both
from
a
a
third
party,
has
audited
you
as
well
as
sort
of
a
self
assertion
that,
yes,
we
are
compliant
with
salsa,
but
she
is
going
to
be
out
today.
So
that's
going
to
be
probably
push
back
till
next
meeting.
Just
so
you
just
FYI
foreign.
A
A
All
right
we're
about
four
minutes
in
so
we
can
get
started
here.
So
just
as
a
reminder,
this
meeting
is
being
recorded
and
will
be
uploaded
to
YouTube
a
little
bit
after
this
meeting
ends,
and
also
your
participation
in
this
meeting
is
an
agreement
to
abide
by
the
open,
ssf
code
of
conduct.
A
Okay,
so
before
we
get
started
on
the
agenda,
is
there
anybody
who
is
new
to
this
meeting?
Who
wants
to
maybe
introduce
themselves.
A
A
Oh
okay,
so
we
can
get
into
the
agenda
so
I
know
before
maybe
we
go
into
the
updates.
I
know,
there's
a
couple
of
quick
notes
regarding
something's
the
the
the
Microsoft
sort
of
SSC
stuff.
A
I,
don't
know
who's
on
from
that
end
or
if
David
you're,
giving
an
update
on
that,
oh
I
see
Json
Jay.
Do
you
want
to
kind
of
give
just
a
little
intro
there.
C
C
That's
a
more
consumer
focused
framework
and
the
way
that
we've
been
pitching.
This
is
and
Bridge
and
in
parallel
with
salsa
I've
done
so
in
in
a
in
an
effort
to
not
bring
them
together.
C
Early
on
when
I've
had
these
conversations,
I've
always
said
you
know
taking
this
consumer
Focus
framework
and
then
you
know
maybe
bridging
it
with
a
more
producer,
focused
framework
but
now
I'm
being
extremely
specific,
because
I
see
with
the
bridge
I
see
where
the
parallel
is
and
I
really
do
feel
like
both
of
these
Frameworks
together
salsa
in
its
scope,
the
SSC
and
itsco
bridging
them
together,
working
on
them
in
parallel
working
on
them
in
the
open
and
both
being
members
of
the
openness
ssf
towards
standardization-
and
you
know,
David
David
wheeler
can
discuss
this
more
specifically
because
there's
a
pathway
but
the,
but
the
aspiration
is
to
have
both
of
these
documents.
C
Can
you
imagine
an
iso-1
and
dash
two
for
a
complete,
pure
supply
chain
framework?
That's
that's!
That's!
In
that's
internationally
recognized
within
the
industry,
so
that's
aspirational,
but
the
idea
to
bring
it
here
to
this
and,
of
course,
I've
been
in
these
meetings.
I
I
mean
I'm
active
in
them.
No,
this
meaning
the
positioning
tooling
and
specification
meanings
so
I'm
all
about
salsa
as
well,
because
I
see
the
potential
of
both
of
these
Frameworks
together.
The
idea
is
bring
it
in
have
discussion
here,
bring
the
discussion
to
the
specification.
C
C
They
both
balance
off
of
one
another
and
they
both
have
Bridges
to
one
another,
and
we
can
all
make
these
documents
collectively
successful,
so
so
that
so
yeah
I
I
would
love
to
further
the
discussion
here
as
a
as
a
as
a
height
in
the
agenda
item
for
one
of
these
meetings
on
the
bi-weekly
and
then,
of
course
bring
it
into
the
Sig
meetings
to
to
carry
on
discussions
there
on
how
these
can
be
positioned
together
and
how
they
can
be
worked
together.
Specification,
wise
and,
of
course,
two
of
them
wise.
B
B
C
Yeah,
absolutely
so
so,
when
we
consider-
and
this
is,
this
is
of
course,
high
level
talking,
I
usually
leave
the
the
detail
and
and
everything
regarding
it
to
to
Adrian
he's
not
he's
not
in
this
car.
Now
he
has
a
he's
a
conflict,
but
at
high
level,
when
we
consider
security
versus
compliance,
you
know
you,
you
have
compliance,
you
have
attestations.
C
You
have
potential
third
party
certification,
you
have
an
accreditation
situation,
a
potential
accreditation
body,
but
then,
when
you
get
down
into
the
nuts
and
bolts
of
of
how
controls
are
applied
and
what
those
controls
are
versus
the
requirements
that
the
controls
need
to
to
to
to
to
fit
into
now
you're
thinking
about
how
do
we
take
what
we
want
to
do?
C
Supply
chain
security,
wise,
have
a
compliance
structure
but
then
have
that
that
security
framework
underneath
it
you
go
end
to
end
and
you
take
in
from
ingestion
which
is
consumer
focused
and
now
you're.
On
the
other
end,
the
built
end
on
the
producer
focus
and
you
take
these
two
Frameworks
and
work
towards
the
middle
right.
C
So
when
we
talk
about
bridging
when
I
refer
to
that
I
refer
to
that
and
say
there
are
gaps
in
salsa
that
we
talk
about
in
all
of
these
meetings
and
a
lot
of
the
conversation
that
we
have
around
these
gaps
are
actually
scope
creep
towards.
Salsa
is
originally
intended
for.
That's
because
we've
recognized
that
the
gaps
in
salsa
really
do
live
on
the
consumption
side
of
things.
C
If
we
take
this
SSC
framework
and
we
dissect
it
the
same
way,
we
find
the
same
gaps
and
the
gaps
that
we
find
on
that
really
do
live
on
the
producer
side
of
things
you
see
where
I'm
going
so
so
when
we
I
understand
what
the
gaps
are
and
we
realize
what
the
Deltas
are.
You
know
in
terms
of
filling
these
gaps,
we
can
clearly
see
where
one
can
complement
the
other
and
instead
of
us
working
on
them
separately,
and
these
are
not
incon.
These
are
not
these
don't
work
against
one
another.
C
A
Cool,
so
are
there
any
other
sort
of
questions
there
so
I
know
Jay
you've,
given
a
bunch
of
presentations
now
on
this,
and
and
actually
one
of
the
things
that
might
be
useful
is
because
I
don't
want
to
have
to
say
hey
next
time
we
do
this.
You
should
give
the
the
same
presentation
again.
A
We
should
probably
forward
folks
the
the
Youtube
video
of
of
one
of
the
previous
meetings
here,
but
I
know
we
we
wanted
to
kind
of
I
know
you
wanted
to
sort
of
bring
this
up
to
folks,
so
that
folks
sort
of
understand
where
this
is
going
as
well
as
also
you
know,
making
it
clear
here
right,
like
salsa,
has
a
specific
scope.
A
All
right
cool
so
moving
on
to
now.
Let
me
just
see
here
yeah
the
updates
on
from
the
the
the
sigs
here.
First
up
is
the
specification
Sig.
B
Hey
so
we
we
had
two
weeks
off
through
the
holiday,
but
we
we
met
last
week
or
this
week
the
we've
basically
agreed
to
the
high
level
kind
of
major
decisions
for
the
1.0
proposal.
B
I'll
say
right
now,
then
the
next
step
is
actually
to
write
up
the
actual
draft
and
get
that
reviewed
and
so
I
wouldn't
count
like
any
of
these
as
like
set
in
stone
per
se
like
we'll
see
what
it
actually
looks
like
in
a
draft
and
make
sure
it
looks
good
before
we
actually
ratify
it.
But
the
things
that
we
discussed
at
length
in
in
the
Sig
were
one
to
split
a
recap.
B
Two
three
four
there's
like
build
one,
two,
three
four
source
I,
don't
know
what
the
numbers
are
going
to
be
for
various
reasons
that
we
could
explain
or
you
could
read
in
the
doc
if
you
want
a
second
is
to
postpone
the
definition
of
salsa
IV,
which
is
now
salsa
build
level
four,
which
is
the
two-party
review
requirement
on
the
source,
side
and
hermetic
builds
I.
B
Think
that's
the
main
thing
on
the
build
side
postpone
the
definition
until
after
the
1.0
release,
because
there's
a
lot
of
questions
around
hermetic,
builds
and
and
so
we'll,
instead
of
blocking
1.0
on
that,
we'll
we'll
defer
it.
We'll
still
have
some
sort
of
note
that
says,
like
these
things
are
coming
down
the
road
for
a
future
level.
We
just
won't
set
it
in
stone
and
speaking
of
setting
in
stone.
B
B
We
could
like
tweak
it
and
I
had
like
small
requirements,
but
the
basic
thing
of
like
what
does
build
level
three
mean
will
stay
the
same
and
the
reason
is
because,
if
you
we
start
changing
it
between
versions,
it
gets
very
confused
and
when
two
people
are
talking
about
I'm
salsa
build
level
three
when
they're
not
actually
meaning
the
same
thing.
B
Yes,
you
could
conclude
version
numbers,
but
when
people
discuss
informally,
they
just
naturally
drop
the
version
numbers
because
it's
too
difficult
to
say,
build
level,
three
version
one,
and
so
it's
more
desirable
if
we
ever
have
to
do
a
major
refactoring,
where
the
gist
changes
we'll
just
use
a
different
name.
To
avoid
confusion.
B
The
another
major
change
is
to
add
a
requirement
around
documentation
of
evidence
of
security
claims,
and
this
is
a
replacement
for
the
the
common
requirements
right
now.
There's
this
undefined
set
of
common
requirements
at
the
bottom
that
are
kind
of
like
you
should
do
security
and
two-party
reviews.
B
But
that's
about
all
we
say
we'll
replace
that
to
a
set
of
guidelines
that
suggest
what
to
do
without
being
like
hard
checks
and
then
have
a
requirement
around
having
a
detailed
set
of
like
foreign
s
and
other
evidence
that
why
should
anyone
trust
that
you
actually
are
meeting
all
these
other
requirements
like?
How
do
you
know
that
builds
are
actually
isolated?
How
is
the
service
actually
designed
and
implemented
and
run
such
that?
We
know
that,
for
example,
employees
at
the
company
don't
have
access
to
tamper
with
it.
B
How
do
we
know
that
you
know
the
two
different
builds
are
properly
isolated
from
each
other
into
what
degree,
and
so
having
that
in
some
sort
of
structured
template
is,
we
believe,
is
like
the
a
compromise,
as
opposed
to
like
a
hard
check
of
like
a
bunch
of
check
boxes,
which
we
don't
think
are
really
realistic
to
cover
all
bases
and
in
the
final
main
decision
is
to
add.
B
We
need
a
better
term
for
this,
and
hopefully
we'll
figure
that
out
during
development
is
policy
or
verification
or
checks
or
whatever
we
call
it.
I
think
each
of
these
terms
has
a
problem,
because
different
people
have
a
different
idea
of
what
that
term
means,
and
so
I'm
being
really
hesitant
to
say
just
policy,
which
is
what
the
term
I've
always
used
for
that.
B
But
we
want
to
introduce
that
somehow
because,
like
as
we
had
a
presentation
earlier
from
Pizza,
it's
necessary
in
order
to
achieve
the
objectives
and
address
the
threats
in
salsa.
But
it's
not
exactly
clear
yet
how
to
work
it
into
the
specification.
Like
does
this
become
yet
another
line
item
in
the
requirements?
B
Is
it
like
an
orthogonal
property
instead
of
doing
that
as
part
of
the
working
group,
it
seems
like
it's
best
to
just
actually
put
it
in
a
draft,
see
what
it
looks
like
and
then
we
could
kind
of
review
it
from
there,
because
talking
about
any
abstract
I
think
is
too
difficult.
B
And
so
so,
the
next
step
is
to
take
these
ideas,
in
addition
to
like
the
list
in
GitHub
of
the
actual
things
that
we
want
to
address
and
the
requirements
and
then
just
start
iterating
on
that
make
a
draft
and
publish
a
draft
at
some
other
domain
or
some
other
URL.
B
So
that
way
people
can
start
to
to
view
what
the
draft
is
and
contribute
to
that,
and
then
the
the
proposed
plan
is
to
do
that
without
necessarily
code
review
of
every
single
commit
and
then
review
the
whole
thing
in
bulk,
because,
like
kind
of
individual
PR
changes,
don't
really
work
for
like
a
big
document
like
this,
we
might
then
split
it
up
into
manageable
chunks
to
review,
but
but
the
initial
development
will
be
able
to
view
like
a
kind
of
like
an
unpublished
draft.
B
That's
the
main
I
think
that's
the
main
piece
out
of
the
specification
am
I
missing
anything.
Anyone.
A
A
I
think
Imelda
is
at
least
she
had
mentioned
that
she
wasn't
feeling
very
well.
A
Yeah
I
can
talk
a
little
bit
towards
that
which
is
there
was
some
discussion
about
stuff
like
salsa
conformance,
and
you
know
what
sorts
of
things
can
folks
do
to
sort
of.
You
know
like
how
are
we
you
know
how
are
different
folks
going
to
be
providing
like
the
information
out
there.
A
There
was
some
discussion
about
sort
of
continuous
compliance
and,
and
that
sort
of
thing
the
other
stuff
was
how
will
how
will
claims
that
are
external
to
salsa
like,
for
example,
a
Vex
or
something
like
that?
How
will
everything
sort
of
refer
to
each
other
and
and
what
you
know
generally,
how
should
people
be
viewing
like
different
elements
of
like
hey
I
have
a
salsa
attestation.
A
There
is
talk
about
you
know,
maybe
setting
up
some
like
a
recurring
blog
or
you
know
articles
especially
something
like
and
I
know.
This
is
some
of
the
stuff
that
was
also
discussed
potentially
about
the
adoption
piece,
as
we
kind
of
drive
towards
adoption,
as
well
as
like
hey.
A
Can
we
start
having
regular
blog
articles,
maybe
even
weekly
blog
series
that
just
talks
about
stuff
like
how
to
implement
salsa
how
to
get
started
and-
and
you
know
that
sort
of
thing
and
and
drive
almost
like
from
a
marketing
perspective
as
well
of
like
hey,
if
there's
a
new
salsa
blog
article
every
week,
then
people
are
like
oh
okay,
cool.
It
stays
in
people's
minds.
A
A
If
it's
already
hitting
the
requirements
from
salsa,
they
can
see
that,
like,
oh
I'm,
actually
already
salsa
compliant
I
just
need
to
generate
salsa
provenance.
Now,
there's
stuff
on
that
end,
I
see
that
John
from
the
cncf
controls
group
is
on,
and
so
one
of
the
things
that's
also
been
brought
up
is
how
we
can
all
sort
of
better
collaborate.
A
The
one
big
problem
is
that
the
salsa
position,
the
salsa
positioning
meeting,
happens
to
be
at
the
same
time
as
the
cncf
security
tag
controls
meeting
is
so
we've
been
trying
to
figure
out,
maybe
some
out-of-band
stuff
on
that
front,
to
try
and
kind
of
you
know,
integrate
there
and
then
we're
also
looking
to
sort
of
work
with
some
of
the
other
groups
like
The,
the
s-bomb
groups
and
and
so
on,
on
how
we
can
better
sort
of
collaborate
and
make
sure
that
it's
clear,
you
know,
hey
here's,
the
salsa
scope,
here's
what
s-bombs
are
doing
and
and
make
sure
that
folks
better
understand
that,
because
I
know
one
of
the
big
things
that's
been
very,
very
confusing
for
folks
is
like:
where
does
salsa
start
and
end?
A
A
And
to
be
clear,
I
wasn't
here
last
week
for
the
salsa
positioning
meeting,
but
that
was
kind
of
from
the
last
few
weeks
and
having
the
conversations
a
few
out-of-band
conversations
with
Melba.
C
C
As
a
matter
of
fact,
you
know
we,
we
discussed
a
final
review
of
the
charter
as
well,
but
the
Oscar
stuff
was
was
huge
in
that
meeting,
also
making
sure
that
we're
we're
creating
a
salsa,
Json,
XML
definition
file
that
could
be
used
to
see
if
we
can't
use
that
kind
of
stuff
to
cross-reference,
whatever's,
going
on
and
and
uscal
and
I
believe,
there's
a
do-out
duog
on
that
to
see
if
they
have
an
SD,
an
ssdf
of
cow
file
or
plan
to
have
one
something
that
could
be
mapped,
something
that
could
be
mapped
one
way
or
the
other.
C
You
know
they
they
and
of
course
I'm
on
the
hook
for
for
some
development
type
stuff
right
so
that
we
had
development
build
and
then
you
know
going
into
further
about
publishing,
artifacts
and
then
continuous
compliance
with
the
outline
of
those
things
look
like,
but
that
that's
that
I
mean
that
was
the
toll
that
came
out.
I.
Think
that
came
out
of
that
meeting.
So
so
yeah
yeah
you're,
not
you're,
not
you're,
not
far
off.
It's
just
a
continuation
of
a
lot
of
stuff
that
we
discussed
as
well.
B
A
B
A
Right,
okay,
I
can
talk
about
tooling,
so
the
tooling
working
group
has
been
focused
on
So
based
on
you
know,
just
to
kind
of
give
a
little
bit
of
the
rundown.
You
know
we.
We
had
categorized
a
bunch
of
the
different
salsa
tools
where
they
are
at
this
point
in
time.
We
just
you
know
we
had
a
a
you
know.
We
got
consensus
that
generally
the
attrib
attestation,
distribution
and
Discovery
is
where
we
want
to
focus
most
of
our
efforts.
A
There's
a
ton
of
different
folks
who
are
building
tools
regarding
the
generation
of
attestations
right.
So,
in
fact,
actually
one
of
the
things
that's
probably
worthwhile
to
just
sort
of
bring
up,
and
it's
in
the
salsa
slack,
both
the
tooling
slack,
as
well
as
the
the
general
slack,
which
is
somebody
from
Samsung,
has
written
a
salsa
Jenkins
generator.
A
They
want
to
contribute
it
to
the
salsa
group.
I,
don't
know
exactly
how
we
want
to
handle
that,
as
you
know,
taking
that
on
or
whatever,
but
they
they
wanted
to.
They
brought
that
up.
A
I
think
that
also
and
I
want
to
put
a
pin
in
that
as
something
just
to
kind
of
highlight,
which
is
it
does
sound
like
there's
more
and
more
folks
who
are
in
sort
of
the
different
areas
of
Europe
and
Asia,
that
this
is
a
very
bad
time
for
them
that
are
starting
to
do
a
lot
of
stuff
on
the
salsa
end.
So
we
might
want
to
just
have
some
sort
of
discussion
about.
A
Should
we
also
have
a
some
sort
of
you
know,
other
time
zone
friendly
meeting,
something
just
to
kind
of
consider,
but
anyway,
for
the
the
tooling
pieces.
A
A
So
one
of
the
big
ones
is
so
oci,
so
oci
recently
merged
in
some
changes
to
the
distribution
and
image
spec.
That
allows
us
to
now
better
sort
of
have
actually
a
type
in
the
oci
Manifest,
where
you
can
say
something
like
this
is
a
salsa
type,
and
so
it
makes
it
very
easy
to
know
like
you
can
pretty
much
query
before
even
checking
the
attestation.
You
can
sort
of
make
a
query
like.
A
Does
this
image
have
an
attestation
in
the
oci
registry
correlated
with
it,
and
you
can
look
in
the
thing
and
say
well,
if
I
see
a
if
I
see
a
salsa
type,
then
I
know
it
exists,
and
then
you
can
then
check
it
and
so
on,
and
then
there's
stuff
around
like
something
called
the
refers
API
which
allows
us
to
potentially
say
this
attestation
potentially
refers
to
something
else
in
the
registry
and
there's
a
lot
of
interesting
work
on
that
end.
A
A
So
it
it
it
was
merged,
it
hasn't
been
officially
released
yet
so
so
it
is
going
to
be
released.
They
just
haven't
finished
the
release
yet
and
then
the
other
thing
is
once
the
spec
itself
is
released,
then
the
tools
themselves
have
to
implement
the
the
spec.
So
it
could
be
a
little
bit
of
time
before
that's
done,
but
it
helps
at
least
build
consensus
there
for
folks
who
are
not
super
familiar,
you
know.
A
The
thing
today
is
most
of
the
tools
today
that
are
pushing
out
to
oci
they're,
using
tools
like
they're
using
you
know,
things
like
sick
store
and
what
they're
doing
is
they
more
or
less
just
say,
I'm,
putting
a
blob
into
the
oci
registry,
and
that
blob
is
called
the
digest
of
the
thing.
It
refers
to
dot,
ATT
and
that's
kind
of
the
thing,
but
that
has
a
lot
of
issues
with
it
because
it
becomes
harder
to
kind
of
say
well.
A
Could
you
have
multiple
salsa
as
stations
that
point
to
the
same
thing
for,
for
example,
repeatable
or
reproducible
builds
not
really
and
it'll
lead
to
a
bunch
of
other
issues.
This
sort
of
helps
solve
a
lot
of
that.
It
also
helps
solve
the
thing
of
if
you,
if
you
sort
of
mirror
other,
you
know
if
you
mirror
other
images,
you
can
essentially
say:
okay
cool
when
I
mirror
this
image.
A
I
also
want
to
pull
down
all
of
these
other
things
that
are
associated
with
it,
and
let
you
kind
of
pull
all
of
that
into
your
local
registry
without
needing
to
know.
Okay,
I
need
to
see
if
there's
an
s-bomb.
If
there's
a
this,
if
there's
a
that,
all
of
that
sort
of
stuff
would
get
pulled
in.
So
that's
that's
some
stuff
that
we
are
sort
of
getting
prepared
for
separately.
A
We
had
a
couple
of
conversations
about
attestation
Discovery,
so
these
are
things
like:
hey,
as
folks
are,
are
looking
at
different
tools:
different
libraries,
different
pieces
of
software.
One
of
the
big
questions
is
before
I
even
download
this
piece
of
software.
Does
it
have
a
salsa
attestation
if
it
does
have
a
salsa
attestation,
does
its
dependencies
have
salsa
attestations
and
so
on?
A
So
there's
some
talk
about
you
know.
Eventually,
you
know
creating
databases
and
things
like
that.
That
can
store
at
least
additional
things
for
salsa
attestation
that
can
then
be
queried
so
that
people
can
kind
of
find
out.
Hey
has
somebody
like.
Has
a
third
party
made
a
salsa
attestation
about
this?
Even
if
the
you
know
primary
hasn't
right
things
like
that
and
that's
some
stuff,
that's
happening
in
the
open
source
space
with
guac,
which
I'm
working
on
and
some
of
the
other
folks
are
working
on.
A
But
it's
something
that
we
are
interested
in,
seeing
if
anybody
else
has
other
things
that
they're
potentially
working
on
on
you
know
hey.
How
are
people
thinking
about
you
know
now
that
we
have
all
these
salsa
attestations,
correlating
it
with
other
metadata,
like
s-bombs
and
so
on,
to
make
decisions
and
then,
finally,
one
of
the
other
big
things
that's
being
sort
of
talked
through
is
sort
of
General
protocols
for
or
processes
I
should
say
for
for
how
people
should
be
Distributing
salsa
attestations
when
it's
not
a
core
integration
into
the
tool.
A
So
as
an
example,
we
have
npm
python,
you
know
Pi
Pi,
you
know
ruby,
gems
and
so
on
and
and
some
of
those
tools
are
looking
to
integrate
stuff
like
Sig
store
and
similar
into
its
into
the
tools
themselves.
So
like
as
an
example,
you
know
one
of
the
things
that
could
happen
is
when
you
run
npm
install
it
can
go
and
say:
okay
check.
Is
there
a
salsa
attestation
if
there
is
a
salsa
attestation
associated
with
pull
it
down?
A
Yayada
now,
there's
a
lot
of
open
questions
about
maybe
building
some
patterns
for
how
generally
this
should
be
implemented
because
it
just
you
know,
from
a
a
just,
a
general
good
practices,
perspective
and
then
separately.
One
of
the
things
that
is
also
being
talked
about
is
for
folks
who
that
integration
is
not
a
not
necessarily
a
possibility
yet
are
there
things
that
people
can
do
that
are
like
common
practices
to
still
sort
of
pull
down
these
you
know
attestations.
A
So,
as
an
example,
salsa
attestations
are
often
if
they're
constructed
as
files
they're,
often
as
Json
lines,
because
that's
the
standard
in
in
Toto
and
Json
lines,
files
which
is
a
which
is
a
a
which
is
a
schema
type,
and
so
are
there.
You
know:
are
there
good
things
that
we
can
suggest?
As
the
salsa
team
saying
hey?
This
is
what
it
should
look
like
from
an
eight.
A
You
know
from
a
the
perspective
of
like
you
know,
let's
just
say,
for
example,
GitHub
right,
you
have
your
stuff,
you
have
your
release
in
GitHub
and
the
file
should
live
alongside
that
release,
or
maybe
it
is
packaged
in
the
tarball
or
whatever.
But
those
are
some
things
that
we
are
starting
to
sort
of
talk
through,
so
that
you
know
some
of
the
common
tooling,
that
is
out
of
band
from
the
actual
package
installation
right
for
things
that
either
don't
meet
an
actual
package
installation
like
hey.
A
This
is
just
a
tarball
release,
but
we
have
an
attestation
associated
with
that
tarball
release.
This
is
what
this
is,
how
you
would
check
it
and
have
some
general
tooling
for
that
as
well.
As
you
know,
helping
folks
out
who
are
building
tooling
to
say,
oh
here's,
some
general
ways
that
we
should
do
this
and
and
how
these
attestations
will
probably
be
published
and
be
associated
with
whatever
the
artifact
is
attesting.
A
So
that's
that's
the
the
what
we've
been
working
on
on
the
tooling
side.
A
A
B
A
Right,
well,
everybody
can
have
back
25
minutes
or
so
and
see
you
all
either
at
one
of
the
Sig
meetings
or
in
two
weeks.