►
From YouTube: SLSA Tooling Meeting (September 9, 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
As
folks
for
joining
feel
free
to
add
your
name
to
the
attendees
list
and.
A
All
right,
we
can
probably
get
started
as
folks
roll
in.
So
just
as
a
reminder,
this
meeting
is
being
recorded
and
will
be
uploaded
to
YouTube
shortly
after,
and
your
participation
in
this
meeting
is
an
agreement
to
abide
by
the
open
ssf
code
conduct
cool.
A
A
Here
is
also
the
what
we've
been
working
on
most
recently.
A
Okay,
before
we
get
started
with
the
agenda,
is
there
anybody
new
on
the
call
who
wants
to
introduce
themselves.
A
Okay,
so
this
is
my
first
time
attending
I
work
with
Sebastian
Anaconda.
My
name
is
Preston
Moore
I
do
application
system
security,
that
sort
of
stuff
and
we
are
trying
to
get
some.
It's
also
related
efforts
going,
and
here
we
are
trying
to.
A
A
All
right,
oh.
A
Hey
Isaac,
hey.
A
Yeah
just
posted
the
notes
in
there
okay,
so
we
can
kind
of
get
to
it.
So
there
was
a
couple
of
things
that
we
worked
on
last,
so
we
weren't-
we
didn't
have
a
meeting
last
week
because
of
the
long
weekend
a
lot
of
folks
were
were
out
for
the
long
weekend
here
in
the
U.S.
A
So
and
let
me
share
my
screen
in
a
second
here,
and
hopefully
it
does
not
cause
any
issues
because
I've
been
having
some
sort
of
weird
screen
sharing
issues.
Lately:
okay,.
A
And
okay,
it's
a
little
slow,
but
it's
okay.
So
what
we've
been
working
on
for
folks?
Who,
who
haven't
been
around
for
a
couple
of
weeks
or
or
who
are
new,
just
to
kind
of
give
the
quick
run
through?
Is
we
sort
of
categorized
a
bunch
of
tools
in
the
in
the
salsa
space
we
sort
of
looked
at
where
there
were
gaps
and
where
we
should
be
focusing
our
efforts
and
one
of
the
big
areas
we
wanted
to
focus?
Our
efforts
was
around
attestation,
distribution
and
Discovery.
A
So
you
know
we
have
there's
a
lot
of
things
that
are
currently
building
the
Providence
right,
whether
it's
some
of
the
salsa
GitHub
generator
work
or
or
some
of
the
other
tools
and
plugins
that
are
being
built
for
things
like
you
know,
like
tecton
and
tecton
chains
can
do
this
and
and
there's
ones
that
are
being
built
for
Jenkins
and
there's
ones
that
are
being
built
for
git
lab,
as
Aaron
had
demoed
last
week
at
the
the
the
salsa
community
meeting,
and
so
there's
a
bunch
of
stuff
on
that
end.
A
But,
but
when
it
comes
to
sort
of
stuff
like
okay
cool
well,
if
I
you
know
generate
this
salsa
attestation
for
a
python
package,
how
should
that
get
distributed
out
and
how
should
people
be
consuming
it,
that's
kind
of
still
a
bit
of
an
open
question,
and
so
we've
been
super
focused
on
at
least
this
group
has
been
very
focused
on
sort
of
defining
the
requirements
and
then
seeing
if
there
are,
you
know,
since
most
of
the
folks
on
this
call,
are
at
some
level
Hands-On
keyboard,
Engineers
or
or
have
some
input
into
other
groups
where
we
can
go
and
say:
okay,
great,
here's,
how
salsa
should
probably
do
it.
A
A
How
would
you
they
plan
to
just
since
they
have
that
RFC
that
says
that
they're
going
to
be
both
signing
their
packages
as
signing
the
output
of
their
packages,
as
well
as
also
generating
salsa
attestations
for
npm
packages,
and
so
how
would
that
get
distributed
and
like
they
have
an
API
scheme
and
whatever
and
and
we
want
to
kind
of
figure
out
as
well
as
as
they
are
beginning
to
build
some
of
that
stuff
out?
A
If
some
of
that
stuff
can
be
then
standardized
right,
so
that
just
assuming,
for
example,
like
if
most
folks
can
use
a
similar
pattern
to
what
they
are
doing
for,
let's
say
Maven
for
you
know
whatever
else,
then,
then
maybe
we
should.
We
should
also
use
the
same
sort
of
thing
or,
if
there's
reasons
why
we
need
to
be
different,
like
let's
make
sure
that
it's
clear
so
that
you
know
different
systems
that
are
trying
to
integrate
with
salsa
can
or
different
packaging
ecosystems
that
want
to
integrate
with
salsa.
A
A
There
is
one
particular
item
we
can
talk
about
a
little
later,
which
is
more
around
what
happens
when
folks
are
not
doing
the
the
maven
npm
oci
stuff
right
like
if
they're,
not
using
you
know
existing
patterns,
like
especially
the
oci1,
which
is
relatively
codified
at
this
point
and
we're
just
kind
of
figuring
out
some
of
the
details,
but
for
cases
where
you're
Distributing
files
like
in
the
salsa
GitHub
generator,
where
it's
Json
lines,
files
which
are
the
in
Toto,
the
recommended
in
total
practice,
is
to
use
something
called
Json
lines
and
distribute
it.
A
Just
that
distribute
it
that
way
cool.
So
that's
that
so
before
kind
of
moving
on
to
any
specific
items
is
there
anything
anybody
wanted
to
bring
up,
as
as
far
as
any
of
the
this
is
there
stuff
that
that
folks,
think
is
missing,
want
to
be
added.
A
Once
again,
this
is
just
you
know.
This
is
an
open
document.
So
if,
if
there's
things
in
here
like
if
folks
are
super
familiar
with,
for
example,
python
or
or
whatever-
and
they
know
how
they
want
this
to
start
to
work-
or
they
have
some
ideas
and
thoughts
on
it
feel
free
to
put
it
put
it
in
here
as
well,.
D
I
think
there's
one
thing
that
we
could,
that
we
could
promote
to
package
management
system.
Maintainers
is
that,
in
effect,
once
you've
got
a
saucer
attestation
for
an
artifact.
You've
also
effectively
got
a
digital
signature
for
it,
because
the
the
attestations
ACT
has
proxy
signatures
for
the
actual
artifacts.
So,
rather
than
having
to
go
through
the
process
of
building
your
own
signing
mechanism
for
artifacts
and
generate
social
attestations,
you
could
just
go
as
far
as
generating
the
attestations
and
then
have
the
signatures
by
default.
D
A
Yeah,
since
the
attestations
contain
you
know
stuff,
like
the
hashes,
it's
yeah
yeah
Aaron.
B
You
know
you
almost
don't
have
to
spend
the
the
compute
time
or
whatever
you
want
to
call
it
or
the
complexity
of
signing
the
artifact,
because
if
you
do
have
kind
of
station
pointing
to
or
the
hash
of
the
thing
the
artifact,
then
you
know
that's
as
good
as
gold
in
a
way
as
well,
because
you
know
if,
unless
the
attestation's
been
tampered
with
very
that's
the
that's
the
one
thing,
but
if
we're
up
to
Source
level,
two
we're
really
up
to
cells
level.
A
Yeah
and
and
I
think
also,
if
you
like,
given
that
a
common
pattern
right
now
is
to,
if
you
are
signing
the
artifact
directly,
you
sign
the
artifact
and
the
attestation
pretty
much
at
the
same
time.
So
you
run
into
the
same
problem
like
if
you're,
if,
if
you're,
not
salsa
level,
two
three
or
whatever
and
you
are
that
key
is
potentially
you
know
being
used
for
other
things.
A
Anyway,
you
still
have
the
same
problem:
whether
or
not
you're
signing
the
attestation
or
signing
the
artifact
directly,
so
I
think
it's
it's.
You
know,
there's
there's
I
can't
think
of
a
point
where
somehow
signing
the
artifact.
It
would
be
more
secure
than
just
signing
the
attestation,
any
you
know
or
doing
both
or
whatever,
but
yeah
that
makes
sense.
A
Okay,
cool
yeah,
so
that
that
makes
sense
to
me.
I
I
agree
with
that.
E
C
I
have
a
couple
of
questions
actually,
the
first
of
which
is
having
given
six
stores
in
the
open,
SSS
family.
To
what
extent
do
we
have
a
bias
towards
six
stores
and
the
suicide
store
tool
chain
as
part
of
the
solution?
Here,
it's
the
first
part
and
then
the
second
part
I
was
wondering
was
was
just
around
I
mean
we're
talking
about
attestations
being
so
far.
The
tooling
that
we
have
generates
provenance
and
the
provenance
itself
doesn't
make
any
Claim
about
the
social
level
of
an
artifact.
C
But
if
you
want
to
make
a
claim
that
it's
also
a
level
of
artifact
to
produce
a
VSA
and
it
could
be
a
different
entity
producing
the
VSA
than
actually
does
the
build
and
produces
the
Providence,
and
so
when
we're
talking
about
you
know
signing
out
of
station.
Are
we
talking
about
the
provenance
which
is
the
tooling
we
have
today
to
generate
inside
Providence?
Or
are
we
talking
about
a
separate
process
which
generates
the
BSA
and
actually
makes
an
attestation
about
salsa
levels,
specifically.
A
Yeah
so
I
think
right
now
we're
talking
mostly
about
the
actual
provenance
attestations
whoops,
because
because
so
for
folks,
who
who
are
not
super
familiar
like
some
of
the
other
stuff
that's
being
discussed,
is
how
will
people
be
essentially
making
assertions
that
a
particular
build
system
or
whatever
is
salsa
level
three
compliant?
And
then
you
can
go
back
and
say
great
all
these
attestations,
which
use
this
Builder
at
this
time
or
whatever
can
go
and
say
yep.
We
believe
you
know
if
we
trust
that
auditor
conformance
whatever.
A
D
Yeah
I
think
there's
a
couple
of
points
here
in
that,
firstly,
I
think,
even
though
the
attestations
themselves
don't
make
any
explicit
mention
of
which
salsa
level
they
they
think
the
artifact
was
built.
You
can
infer
that
because
all
the
data
you
need
to
check
against,
which
is
also
level
it
was
built
against,
is
in
the
attestation
so
like
whether
the
whether
it's
reproducible,
whether
it's,
whether
a
dependencies
are
complete
and
all
those
things
are
actually
part
of
the
attestation.
C
D
Ultimately,
there's
a
route
of
trust
somewhere
and
you
you
know
you
have
to
trust
either
an
organization
or
a
person
to
have
done
what
they
say
they
did.
There's
you
know
at
some
point.
The
the
whole
tree
has
to
kind
of
have
a
root.
So
yeah,
yes,
yes,
you
do
have
to
trust
the
Builder.
But
then
you
know
okay.
Well,
then,
you
can
kind
of
devolve
trust.
D
You
can
put
into
put
into
your
kind
of
tree
of
trust
the
people
who
generated
the
Builder
and
then
perhaps
you
can
check
a
VSA
against
that,
but
ultimately,
somewhere
along
the
line,
you're
trusting
something.
E
Yeah,
so
so,
when
we
consider
you
know
the
attestations
and
and
and
the
respective
levels,
you're
not
trusting
the
Builder
or
or
trust
in
the
organization,
your
trust
in
the
process,
so
this
process
should
be
clear
when
you're
attesting
to
something
you're
attesting
to
the
level
at
which,
especially
when
you're
considering
levels
in
in
that
and
I
would
use
the
term
maturity
levels.
E
When
you're
assigning
a
attestation
you're
attesting
to
the
level
at
which
it
was,
it
was
built
that
I
mean
and
I
mean
that
there's
no
there's
in
that
attestation,
you
should.
You
should
clearly
have
all
of
the
requirements
of
that
level
per
the
process
in
place
to
get
to
that
level.
So
you're,
not
trusting
an
organization
or
trusting
a
builder
you're,
trusting
a
process
and
then
you're
attesting
now.
E
The
only
other
instance
of
this
is
when
you're
doing
a
third
party
attestation,
where
now
you're,
relying
on
The
credibility
of
the
third
party
organization,
completely
infestation,
but
then
there's
evidence
involved.
So
what
is
the
evidence
sect
that
suggests
that
you've
met
the
requirements
at
each
respective
level
per
the
attestation?
A
Yeah
I
I
think
it
does
I.
Think
one
of
the
big
concerns
with
with
salsa
is
is
because
a
lot
of
these
things
are
just
being
claimed
right
and
anybody
can
sort
of
claim
anybody
can
sort
of
claim.
Any
sort
of
evidence
in
there
right,
like
I,
can
falsify
a
bunch
of
different
evidence.
A
So
so
a
lot
of
it's
going
to
come
down
to
who
you
know
the
process
itself
is,
is
hey
that's
great
like,
but
if,
if
individual
elements
of
that
process
can
lie-
and
you
know,
falsify
the
evidence
and
some
some
capacity,
we
need
to
also
have
some
level
of
you
know-
do
I
trust
the
party
that
is
making
the
claim
in
the
first
place
right.
Are
they
generally
trustworthy?
You
know,
are
they
a
major
company
with
a
lot
to
lose
by
lying?
To
me.
A
Or
you
know,
and
things
like
that
as
well,
I
think
is-
is
kind
of
really
important
there
and
that's
kind
of
where
I
think
some
of
the
stuff
that
Sean
was
talking
about
with
like
the
VSA
is
like
hey.
Would
somebody
come
in
and
sort
of
assert
that,
like
no
I
checked
up
on
I
I,
you
know
the
process
itself
is
fine,
but
are
all
the
components
that
this
this
third
party
is
using
for
that
process?
Do
we
generally
trust
those
things
that
they're
doing
the
right
stuff.
E
Well,
that,
well
that
that's
that's
where
the
automation
comes
into
place
and
they
I
I
and
I
and
I'll
go
back
to
it.
I
mean
because
I
I
don't
necessarily
disagree,
but
but
what
I'll
add
to
that
is
if
it
comes
down
to
me
having
to
trust
an
organization
or
trust
an
individual
I'm
going
to
say
every
which
way
from
Sunday.
E
Neither
show
me
the
process
in
place,
that's
being
used,
let's
find
the
holes
and
the
gaps
there
that
can
be
filled
in
order
for
me
to
have
to
be
assured
about
whatever
process
or
whatever
evidence
that's
being
collected.
Or
what
have
you
I
mean?
We
did
there's
a
there's.
There's
a
there
are
things
that
we
can
put
in
place
to
make
sure
that
falsification
of
evidence
doesn't
occur.
There
can
be
a
chain
of
custody
that
occurs
right
so
show
me
where
the
evidence
was
generated.
Show
me
where
it
was
stored.
E
Show
me
who
signed
it
being
stored.
Give
me
the
downline
trace
of
all
of
this
evidence.
Give
me
the
downline
trace
of
this
attestation,
so
that
I
can
be
assured
that
there
were
no
gaps
involved
and
we
can
clean
those
gaps
up.
That's
just
about
patience
and
that's
just
about
due
diligence
at
that
point.
C
C
Sure
I
quite
agree
with
that
as
a
viable
proposition.
For
instance,
we
have
GitHub
actions
as
a
you
know,
as
a
cicd
system
today,
generating
salsa,
Providence
and
part
of
you
know
part
of
saying
this.
This
artifact
is
all
level
two
or
let's
go
it's
also
level
three.
C
They
say
that
these
builds
were
done
in
an
isolated
way
and
hermetically
right
and
so
we're
we're,
and
unless
we're
saying
people
need
to
go
in
and
audit
the
internal
architecture
of
how
GitHub
is
doing
its
builds
and
there's
no
possible
contamination
between
build
processes
or
one
building,
a
subsequent,
build
or
so
on,
like
that,
that's
part
of
the
attestation,
and
so
what
you
describe
is
hey.
We
need
to
go
in
and
do
a
review
with
GitHub
and
look
at
the
details
of
their
internal
architecture
and
make
sure
there's
no
possibility
of
contamination
between
builds.
C
In
theory
sure
we
could
show
up
with
like
KPMG
or
Accenture
and
go
into
an
alternative,
GitHub
I,
don't
think
github's
going
to
be
open
to
that
and
I
don't
think
get
scale
is
a
viable
proposition,
and
so
at
some
point
we
have
to
trust
when
GitHub
says
we've
architected,
you
know
our
workflows
into
GitHub
by
actions
build
system
as
such
that
these
reusable
workflows
here
are
operate
in
this
way
right
I
mean
when
you
say
show
me
the
evidence.
E
So
I
mean
you
can't
you
kind
of
hit
the
nail
on
the
head
there,
where
you
talked
about
an
audit
sure
what
what
I
mean
and
I'm
not
talking
about
something
that
isn't
difficult,
I'm,
not
talking
about
something
that
isn't
hard
I'm,
not
talking
about
something
that
isn't
you
know
a
bit
far-reaching
when
I'm
talking
about
is
something
that
that
we
should
probably
think
about,
because
GitHub
is
not
infallible,
not
nor
is
any
organization
when
it
comes
when
it
comes
to
their
processes
in
place
right.
E
C
A
E
A
I
can
still
understand
you
if,
for
some
reason
there's,
but
just
so,
you
know
and.
A
Let's,
let's
give
it
a
couple
of
minutes
and
then
we
can
kind
of
move
on
to
the
next
topic,
but
yeah
no
Isaac.
We
should
sort
of
show
those
off.
C
So
let's
see.
A
A
E
C
So
we
have
I
mean
we
have
we
have
here
right.
You
know,
we've
got
various
consumers
with
admissions
policy
for
the
artifacts
that
they
rely
on
and
in
some
cases
in
this
diagram
we've
got
GitHub
saying
hey.
You
know,
I
built
this
artifact
of
cells
level.
Three,
you
know
actually
this
this
Allied,
the
the
question
about
the
VSA,
because
it's
the
VSA
and
all
the
Providence
that
makes
that
claim.
C
But
let's
say
GitHub
says
you
know,
hey
my
business
provenance
is
is
conforming.
It's
also
level
three.
The
field
was
hermetic,
it
was
isolated
and.
C
Various
trust
policies
here
so
consumer
a
is
saying
sure
if
it
says
anything
that
says
assault
level.
Three
is
fine
with
me:
consume
a
b:
it's
like
yeah,
I'm,
only
trust
organization
from
builders
that
I
control,
I'm,
not
trusting
this
consumer
C
has
trust
in
GitHub.
Consumer
D
has
trust
in
GitHub,
but
only
a
consults
level.
Two
so
they're
not
relieving
their
GitHub.
It's
actually
producing
isolated,
builds
in
this
case,
so
we
have
yes
in
this
case.
C
This
is
a
route
of
trust
in
GitHub
and
some
of
the
consumers
trust
here
having
some
don't
in
terms
of
the
the
auditing
picture.
It
might
look
more
like
this.
Where
hey
we've
got
I
began,
making
the
same
statement.
We've
got
an
independent
auditor,
trailer
bits,
it's
just
illustrative
here
and
don't
anchor
on
that,
and
we've
got
the
open
ssf,
who
was
blessed
Sunset
of
Auditors
to
go
and
do
Audits
and
qualify
Builders
at
certain
salsa
levels,
and
so
salt
consumer
B
in
this
case
is
again
like
it's.
C
It's
a
no
on
this
because
it
still
doesn't
trust
its
own
Builders.
Consumers
see
trust
the
open,
ssf
and
Via
delegation
of
that
trust.
By
Trader
bits
in
the
order
system
amidst
the
artifact
and
then
the
third
slide
I
have
here
is
coming
back
to
python.
We
have
a
trust
boundary
which
which
we
could
actually
put
up
around
IPI
here.
Where
you
know
GitHub
is,
is
making
this
a
statement,
a
claim
about
the
artifact
that
it's
built
using
GitHub
actions
using
the
reusable
workflow,
and
so
it's
conform
itself
level.
C
Three,
it's
actually
Pi
Pi
in
this
case
that
is
establishing
the
Upstream
trust.
It's
trusting
to
have
actions
builds
to
be
conformed
to
level
three
and
then
Pi
Pi
itself
is
signing
the
VSA,
which
it
then
transmits,
Downstream
and
so
with
Pipi
is
a
very
useful
trust
boundary
here
that
consumers,
a
b
and
c
all
dressed
implicitly
in
Pipi
they're,
already
using
pip,
install
they're
already
trusting
in
this.
As
a
you
know,
distribution
mechanism
for
pythons
and
packages,
but
python.
None
of
the
consumers
in
this
case
need
to
know
about
anything.
C
That's
Upstream
of
Pipi,
because
there's
this
trust
boundary
here,
but-
and
so
ultimately,
I
mean
a
couple
of
statements
here,
I
think.
Ultimately,
yes,
we
need
to
have
some
root
of
trust
in
in
these
schemes
here
at
some
point,
some
somebody
needs
to
trust,
GitHub
or
needs
to
trust
the
open
SSS
to
trust,
an
auditor,
the
audits
GitHub.
But
there's
there
is
a
there
is
an
anchor
of
trust
in
all
these
diagrams.
Something
I
think
is
that's
worth
exploring.
Is
what
does
a
trustless
implementation
of
this
look
like?
C
How
would
we
use
techniques
like
you
know,
like
those
behind
transparency.dev,
or
you
know,
architectures,
where
you
don't
have
to
have
trust
in
individual
entity?
You
actually
have
Witnesses
and
a
gossip
protocol
which
allows
you
to
not
have
single
anchors
of
trust
in
single
entities
or
organizations,
but
I
think
that
any
scheme
that
we
can
imagine
short
of
that
has
a
root
of
trust
in
an
entity
whether
that
be
an
auditor
or
GitHub,
or
you
know
the
open
ssf
who
blesses
Auditors
and
so
on
and
I.
Think
that
there
are.
C
C
Me
in
that
front
door
to
do
that,
and
so
as
a
practical
matter,
I'm
Jay
I
hear
your
point
about
yeah.
It's
not
easy.
My
argument
is:
it's
not
actually
Beyond,
not
easy.
It's
it's
not
pragmatic
at
scale
and
so
I,
don't
think
it's
I,
don't
think
we
can
pursue
the
idea
that
anyone
who
wants
to
trust
a
salsa
level,
three
artifact
coming
from
GitHub
actions,
has
to
go
in
order
to
get
a
building.
C
E
To
oh,
no,
these
slide,
these
slides
are
fantastic
and
I.
Think
and
I
think
my
my
well,
my
point
was
was
right
at
the
person's
trail
of
bits,
right
that
that
is
the
third
party
organization
that
was
that
was
assigned
to
audit
the
attestation
right
for
the
attestation
they're
trusted
by
got.
C
E
E
What
I'm
saying
is
the
card,
maybe
next
to
Impossible
at
this
point,
but
at
some
point,
if
we
have
another
instance
where
GitHub
comes
up
on
some
type
of
article
or
some
type
of
blog
as
having
been
breached
in
some
way
shape
or
form,
maybe
we
should
be
able
to
audit
their
processes.
Not
necessarily
are
they
that
something
like
the
build
itself,
but
are
the
processes
by
which
those
bills
occur?.
C
Think
in
that
case,
actually
we
have
another
use
case
to
explore,
which
is
if
GitHub
is
breached.
What
do
we
do
middle
stations
it's
already
given
out
and
how
do
we
need
to
distrust
or
revoke
those
or
what
does
that
look
like
as
an
overall
likely
cycle
event,
so
I
think
that's
that's
worth
recording
and
putting
opinion
is
something
we're
going
to
have
to
revisit
that.
You
know
what
happens
when
you
know
it
is
revealed
that
our
trust
in
end
of
the
acts
it's
actually
been
undermined.
C
That
could
go
for
the
auditor
too.
What
if
we,
you
know,
trust
and
trailer
bits
to
do.
The
order
turns
out
that
they
won't
really
do
any
audit.
They
were
going
down
the
pub
and
just
signing
off
right
and
then
exactly
so
at
some
point
we
need
to
figure
out.
You
know
what
is
the
revocation
scenario
look
like,
but
Michael
so
I
didn't
mean
to
monopolize
the
conversation.
Yeah
I'm
happy
to
share
the
side
slides
in
slack.
C
A
D
Briefly
then,
I
think
two
things
to
note
there
as
one
an
audit
is
only
a
snapshot
in
time,
and
so
it
doesn't
give
you
a
guarantee
that
anything
going
forward
is
still
is
still
valid
and
two
I
think
the
only
way
you
can
reasonably
perform.
This
audit
is
to
follow
the
kind
of
the
reproducer
to
reproducibility
requirement
of
salsa,
IV
and
actually
independently
reproduce
a
bill
yourself.
Yeah.
C
Where
I
think
we
end
up,
if
we
go
down
the
transparency
got
their
path
and
look
for
you
know
essentially
trustless
architectures.
Here
we
get
to
you,
know
suddenly
you're
looking
to
hey
I,
want
to
do
this,
build
across
these
six
Builders
here
and
compare
the
outputs
on
at
that
point.
If
they
all
agree,
I
might
have
some
trust
in
the
artifact
again
Mike.
Sorry
back
over
to
here.
A
Oh,
no,
no
yeah!
No!
No!
This
is
I,
think
still
useful
and
I
think
you
know
the
one
thing
this
kind
of
brought
up
is
something
to
maybe
bring
back
up
to
the
specification
and
positioning
groups
just
to
sort
of
really
highlight
that,
like
hey,
look
as
we
begin
to
start
to
think
about,
like
Distributing,
the
stuff
people
are
going
to
start
asking
those
questions
of
like
okay
cool.
How
do
I,
delegate
trust,
who
do
I
trust,
I.
A
Think
Jay
still
brought
up
a
very
good
point,
which
is
like
as
much
as
we
can.
If,
if
you
can
kind
of
say
the
there's
a
limited
like
you
know
it's
about
how
many
elements
of
that
process
do
you
need
to
audit
to
feel
confident
that
things
are
are
still
good?
The
the
smaller
that
that
scope
is
the
easier?
Those
audits
are
right.
You
know,
so
it's
like
kind
of
like
that
problem
of
you
know
and
I
know
it's
something
that
we're
we've
been
looking
with.
A
Some
of
the
tooling
is,
you
know,
hey
if
you're
you
know
it's,
it
kind
of
goes
to
the
non-falsifiable
yayada
requirements
which
are
like,
if
you're
using
keys
based
on
workload,
identities
and
stuff.
Like
that
they're
a
little
bit,
you
have
increased
confidence
compared
to
a
long-running
key
that
could
be
potentially
stolen
and
that
kind
of
thing
so
there's
definitely
some
elements
there
as
we're
kind
of
also
building
out
the
tooling
to
see
like.
A
Where
can
we
support
some
of
these
things,
like
even
stuff,
like
Hardware
root
of
trust,
because
that
also
helps
with
some
of
those
things
further
down
the
line
but
yeah
I
think
yeah.
A
It's
worth
putting
a
pin
into,
and
also
probably
worth,
bringing
back
up
to
the
specification
and
positioning
groups
to
kind
of
provide
some
of
that
guidance
so
that
when
they
have
finished
that
they
can
come
back,
you
know
we
can
kind
of
take
the
information
and
the
decisions
that
they
have
made
around
VSA
around
conformance
around
audit
and
those
things
and
saying:
okay,
great
now,
when
I
pull
down
when
I
pull
down
out
of
stations,
I
probably
also
want
to
pull
down.
A
If
I
haven't
already
some
element
of
you
know,
hey
this
person
signed
this
thing,
and
this
other
third
party
is
asserting
this
or
they
don't
have
a
third
party
assertion
so
I'm,
mostly
taking
them
a
little
bit
on
on
faith
at
some
level
right.
There's,
there's
stuff
there
that
I
think
when
it
comes
to
the
distribution
standpoint
we'll
have
to
kind
of
consider,
but
for
now
I
think
we
can
think
a
little
bit
more
about
just
purely
stuff,
like
the
actual
attestations
themselves,
the
Providence
attestations
themselves
and
so
I'd
be
curious.
A
Like
have
folks
given
I
know,
you
know,
Sean
you've
been
doing
some
stuff
regarding
the
you
know
like
I
know,
python,
and,
and
that
kind
of
thing
do
other
folks
have
ideas
around
how
some
of
this
stuff
is
getting
done
with
python
or
how
you
you,
you
want
it
to
get
done
with
python.
A
In
this
case,
like
Distributing,
the
attestations.
B
So,
just
to
make
a
comment:
I
haven't
thought
specifically
about
python,
but
maybe
one
way
we
we
as
a
group,
can
think
about
this
type
of
thing.
Is
you
know,
thinking
about
ourselves
as
consumers?
How?
How
would
we
ideally
want
to
to
get
this
right
like
I?
Think
that's
the
best
way
to
think
about
it,
because
if,
if
the
consumer,
it's
easy
for
the
consumer,
then
you
know-
and
it's
and
it's
the
right
way
to
do
it
as
well.
I
think
that's
the
best
way.
A
C
That's
a
great
framing
and
I
think
for
me
in
a
way
I've
been
conceptualizing.
This
is
consumer
using
pip
install.
C
It
seems
to
me
that
I'm
either
in
my
environment
or
you
know
as
an
explicit
flag
to
to
pip,
there
should
be
some
policies
surrounding
pip
installs,
actually,
my
organization
most
of
the
policy,
if
I,
try
and
pip
install
something
that
isn't
a
salsa
level,
three,
it's
gonna
fail,
it'll,
give
me
a
warning,
and
so
hey
I
did
install
the
wireless
three
or
whatever
it
may
be,
and
it's
it's
pip
in
that
case,
that
is,
that
is
looking
at
the
VSA
and
so
the
diagram
I
showed
which
had
a
trust
boundary
and
it's
actually
Pi
Pi,
which
is
signing
a
VSA
and
I'm.
C
Providing
you
know,
there's
some
some
assertion
that
this
particular
package
is
I,
always
built
at
Salsa
level.
Three,
and
so,
when
I
pip
install
a
package,
it
says
great
you'll
put
your
local
policy
says
you
can
only
clip
installs
level,
three
or
above
so
that
works.
You
know
for
other
packages.
C
Province
may
be
completely
missing.
In
that
case,
Pipi
does
not
sign
a
VSA
or
it
just
says
hey.
This
is
false
level.
A
C
And
the
PIP
install
fails
or
gives
me
a
warning
or
other,
but
I
think
looking
at
it
just
looking
at
it
from
the
consumer
perspective.
What's
the
what's
the
end
user
experience
here,
it
seems
to
me
that
building
this
functionality,
wherever
the
the
solster
attestation
is
discovered
and
verified
within
pip
itself
or
within
that
process
and
seems
to
me
super
low,
friction
and
super
align
for
all
the
usual.
We
want
to
expect.
A
There
was
a
few
folks
I
think
in
one
of
the
previous
meetings
who
had
said
yeah,
that's
probably
going
to
work
for
for
a
lot
of
the
the
common
packaging
ecosystems,
but
we
probably
also
want
to
still
sort
of
consider
like
some
out
of
band
potential
Solutions
as
well,
for
folks
who
and
and
then
also
think
about
stuff,
like
libraries
and
and
tooling,
to
help
those
tools
like
pip
npm
Maven,
to
adopt
that,
because
one
of
the
things
that
was
brought
up
is,
you
know,
there's
like
hundreds
and
hundreds
of
technically
package
packaging
tools
out
there
and
and
expecting
them
to
all.
A
Just
sort
of
natively.
Integrate
with
with
salsa
is
going
to
be
potentially
a
little
difficult,
but
we
can
probably
do
at
least
something
right.
We
can
probably
do
you
know
we
could
probably
hit
the
the
biggest
of
the
big
right
like
you
know,
pip
Maven
npm,
you
know
gems,
and
that
that
kind
of
thing,
but
I
think
the
things
that
that,
on
that
end
is
is,
is
how
do
we
do
that
from
the
perspective
of
also
like
keeping
something
like
that
cosine
verify.
A
What's
the
I'm
trying
to
think
of
give
me
a
couple
seconds,
I'll
I'll,
think
of
think
of
what
I
was
thinking
but
Sean
yeah.
D
No
I
was
thinking,
I
I
was
thinking.
We
should
take
a
look
back
at
the
comments
I
made
in
the
rough
notes
section
down
at
the
bottom
about
the
levels
of
integration
for
package
ecosystems,
because
there
are,
you
know,
potentially
hundreds
of
package
managers
that
that
you
could
be
using
and
any
organization
might
be
using
multiple
package
managers
for
multiple
things
and
they
might
have
a
policy
about
salsa,
but
not
all
of
their
package.
Managers
are
actually
going
to
be
able
to
to
deliver
that
for
them.
Natively,
so
I
think
there's.
D
You
know
there
is
scope
for
having
like
a
native
integration
where
pip
actually
does
the
source
of
verification
for
you
and
then
there's
a
scope
for
hybrid
systems.
D
Where
say,
for
example,
you
know
if,
in
a
native
system,
you'd
have
paper
and
Pipi,
so
Pipi
would
be
publishing,
vsas
and
attestations
and
then
pip
would
be
verifying
them
up
against
the
you
know
up
against
the
pipi,
then
you
could
have
a
hybrid
ecosystem
where
the
client
tooling,
could
optionally
use
a
third-party
service
to
get
the
attestations
for
the
artifacts
that
it
gets
via
its
regular
mechanism
and
then
there's
a
kind
of
a
completely
Standalone
integration.
D
Where
you
have
the
package
manager
just
continuing
to
continuing
to
do
its
own
thing,
but
then
you
can
go
to
a
you,
can
use
another
tool
to
go
to
a
third
party,
a
third-party
store
and
get
the
attestation
data.
For
those
honestly.
A
Yep
yeah
so
totally
agree
with
that.
Let
me
try
and
turn
my
video
back
on
see
if
my
PCS
okay
seems
to
be
okay
now
so
so
yeah
I,
I,
agree.
A
So
I
think
one
of
the
things
that
was
kind
of
brought
up
before
a
little
bit
and
to
kind
of
switch
topics
slightly
is
one
of
the
things
that
was
kind
of
talked
about
with,
like
I
know.
Technically,
salsa
can
use
whatever,
but
the
most
common
thing
it
uses
right
now
is
in
Toto
attestations
and
you
know,
there's
as
we
were
kind
of
kind
of
coming
together.
A
You
know
we're
trying
to
kind
of
see
what
how
we
can
kind
of
stand
around
standardize
around
also
Builder
specifications
as
well
and
and
some
of
those
things
that
you
know
the
output
of
of
some
of
the
details
can
also
be
standardized
so
that
the
individual
tools
now
can
be
able
to
do
some
of
that.
I
don't
want
to
say
policy
validation,
but
can
can
sort
of
parse
through
an
attestation
and
and
I'm
gonna
say
not
necessarily.
A
It
itself
make
those
decisions
but
be
able
to
either
call
out
to
other
things
or
whatever
have
those
decisions
get
done
in
some
good
way.
So
that's
stuff,
like
is
this
signed
by
the
right
party.
Looking
through
the
evidence,
does
the
evidence
make
sense
to
what
we
have
for
our
policy.
That
kind
of
thing
not
saying
that
pip
or
npm
itself
would
do
that.
A
A
That's
been
discussed
regarding
like
sort
of
Json
lines
right,
which
is
the
the
the
is
the
standard
in
in
Toto
on
how
to
sort
of
distribute
in
total
attestations
as
files,
and
some
of
that
is
kind
of
like
where
people
are
starting
to
say,
hey
is
that
a
reasonable
place
to
start
is
to
assume?
A
Let's
say
that
when
you
do
a
pip
install
or
whatever
that
you're
downloading
a
Json
lines
file
associated
with
it
or
something
like
that,
and
then
you
know
you
then
do
that
parsing
and
then
that
kind
of
says:
okay,
great,
if
you,
if
it
doesn't
have
native
pip
and
Pi
Pi
integration,
you
are
still
sort
of
able
to
kind
of
like
provide
some
sort
of
I'm
gonna,
say
identification,
Discovery
mechanism,
something
like
hey.
If
I
go
and
I
do
a
pip
install.
A
Is
there
something
common
like
some
common
identifiers
that
we
can
go
and
say
great?
This
is
these:
are
the
common
unique
identifiers
for
every
package
and
so
every
version
of
every
package?
And
then
we
can
go
and
say
great
here.
You
know:
okay,
I
know
similar
to
how
it's
being
done
right
now
in
oci,
before
the
the
newer
oci
changes
came
in
right,
I
have
a
hash
of
a
package
and
you
know
I'm
looking
for
a
file
called,
you
know,
hash
dot,
attestation
or
hash.salsa.
D
Yeah
I
think
I
liked
the
I
like
the
kind
of
unique
hash
reference
mechanic
over
potential
over
potentially,
you
know
Pearl
or
something
like
that,
because
we
have.
You
know
we
have
situations
where
we
might
have
the
same
python
package.
You
know
or
say
we're
talking
about
Nuka
giri
or
something
like
that,
and
in
Ruby
the
Link's,
an
underlying
C
library.
D
We
could
say
you
know
in
terms
of
pearl
we've
got.
You
know
it's
nokogiri,
it's
this
particular
version
of
Nokia,
this
particular
revision
or
whatever
for
this
particular
architecture.
But
what
that
doesn't
encapsulate
is
that
I've
linked
it
against
a
different
version
of
libxml2,
so
I
might
have
five
artifacts
that
match
that
Pearl,
but
but
are
completely
different
in
terms
of
their
operation
because
they
have
a
different
underlying
dependencies.
D
So
yeah
we
were,
we
yeah
we
I.
We
are
currently
using
kind
of
individual
artifact
IDs,
which
are
generated
as
Merkel
hashes
of
the
dependency
change
for
each
of
our
artifacts
and
that's
how
you
reference
kind
of
the
the
active
State
artifact
is
via
their
artifact
ID,
which
is
a
miracle
hash
so
that
we
know
you
know.
We've
got
kind
of
some
of
that
provenance
baked
in
and
each
individual
permutation
of
that
has
its
own
unique
artifact
ID.
B
Not
trying
to
go
down
a
rabbit
hole,
hopefully
I'm,
avoiding
that
saying
this
you
know,
there's
you
know
you
do
a
pip
install
and
somehow
pip
has
cosine
integrated
with
it
and
cosine
verifies
the
attestation
for
your.
You
know
python
package
you
just
installed,
but
maybe
the
basics
are
yeah.
It
has
a
valid
salsa
provenance
format.
B
But
you
know
what
security
do
you
really
get
from
that?
Because
a
malicious
actor
couldn't
generate
a
proper?
You
know
so
I'm
not
trying
to
go
on
the
Rev
hole,
but
right
maybe
there
is
another
and
I
think
like
you
were
kind
of
going
down
this
route
with
what
you
were
just
saying,
like
maybe
a
third
party
or
like
out
of
band
hey.
This
is
what
you
should
expect
to
see
to
validate
against
this
provenance.
That's
coming
in
I
think.
That's
definitely
like
something.
B
That's
interesting
because,
like
a
malicious
actor,
you
know
or
even
a
phishing
attack
can
occur
right.
They
can
generate
a
salsa
provenance
and
it
can
look
good
when
you
do
a
pip
install
and
it
verifies
is
that
it's
been
signed
right,
so
I
think
that's
an
interesting
factor
for
when
we're
talking
about
Distributing
and
like
for
this
type
of
thing
like
having
like
what.
What
should
you
expect
to
see
not
just
expecting
to
see
the
format.
But
what
should
it
actually
be?.
A
Right,
but
by
that,
do
you
mean
like
the
actual
metadata
in
the
attestation?
Sorry
I,
I,
yeah,
I
suppose,
like.
B
The
right
so,
like
you
know,
for
like
some
of
these,
even
like
type
of
squatting
type
attacks.
You
know
some
of
these
folks
are
trying
to
make
it
look
like
you
know.
Oh
I
just
installed
requests
from
python,
but
it's
actually
recursed
or
something
and
yeah.
It's
not
actually
coming
from
the
request.
You
know
built
GitHub
repository,
so
maybe
that's
the
third
party
or
like
the
third,
where
you
can
verify
that
this
is
actually
something
that
you
expected
to
see.
I.
D
B
D
Think
that's
definitely
an
element
of
graph
walking.
You
need
to
do
to
really
be
sure
that
what
you've
got
is
is
what
you
think
it
is
so
I
think,
there's
you
know.
Okay,
so
you
know
the
authors
can
actually
either
produce
an
attestation
or
a
signature
for
the
source
code
and
that's
great,
and
then
you
know
well.
This
also
will
allow
us
to
do
is
kind
of
generate
that
chain
of
custody
for
every
process
that
goes
between
the
source
code
and
the
bits.
D
You
know,
that's
that's
what
we
should
be
aiming
for
and
I
think
there's
a
there's,
an
interesting
thing
in
there
in
that.
Yes,
you
should
be
checking
the
signatures
at
every
at
every
point
and
you
should
be
walking
the
graph
all
the
way
back
in
order
to
work
out.
You
know
exactly
whether
the
provenance
is
accurate,
but
you
should
also
be
working
out.
Who's
allowed
the
sign
for
what
so
it's
you
know.
D
You
wouldn't
necessarily
expect
the
authors
to
be
able
to
sign
for
the
build
or
the
builders
to
be
able
to
sign
to
the
source
and
and
vice
versa.
So
there's
a
policy
element
there
that
you
need
to
be
able
to
find
out
who's
who's
who's
allowed
to
give
a
valid
signature
to
What
stages
in
in
the
process.
A
Yeah,
so
what
what
I'm
hearing
is
that
and
and
I
think
this
is
something
that
that's
interesting
and
to
be
clear,
like
we're
doing
some
similar
stuff
with
with
guac,
which
is
one
of
the
tools
that
we're
trying
to
build
with
Google
and
stuff,
like
that,
but
I
think
what
I'm
hearing
and
and
like
feel
free
to
to
disagree.
A
But
what
I'm
hearing
is
is
it
might
make
sense
for
us
to
as
a
group
to
maybe
start
a
POC
around
just
assuming
file
distribution
generically
do
some
of
those
initial
things
of
like
okay
cool?
How
do
we
verify
the
signatures?
How
do
we
do
some
basic
verification
and
then
start
to
dive
into
stuff
like
the
policy
and
whatever,
because,
like
I,
think
a
lot
of
those
things
are
going
to
be
hard
until
we
actually
have
a
reasonable
understanding
of?
How
will
people
probably
be
downloading?
A
This
probably
be
getting
it
like
whether
it's
in
PIP
directly,
whether
it's
out
of
band
or
whatever,
and
then
I
think
we
can
then
start
to
look
at
okay
cool
great.
Now,
let's
look
at
the
policy
elements
and
do
something
a
bit
more.
You
know
this
is
actually
something
that
we've
been
talking
about
in
a
couple
of
different
meetings
is
sort
of
the
difference
between
like
what
we've
been
calling
and
I.
A
A
If,
yes,
then
cool,
it
goes
to
the
sort
of
the
next
level,
and
then
it's
like
dive
into
the
actual
content
of
that
attestation
and
then
there's
probably
another
level
as
Sean
had
sort
of
mentioned
of
which
is
now,
let's
crawl,
the
graph
of
everything
that's
in
that
salsa
attestation
that
you
know
as
materials.
Now,
let's
go
back
and
say:
okay,
great
here's,
where
the
source
code
is
cool,
let
me
go
and
validate
that
it
has
a
valid
signature
that
that
signature
is.
A
You
know
the
the
the
actual
source
code
you
know
or
the
the
developer
signature
of
the
the
source
code
like
the
commit
itself
assigned
or
whatever
and
and
and
so
on,
and
then
you
know,
here's
a
security
scan
is,
is
it
signed
by
the
security
scanning
key
or
certificate?
I
think
that's
I,
think
that's
kind
of,
and
you
know
feel
free
to
tell
me
about,
but
I
think
that
might
be
the
does.
A
B
Think
it's
a
good
path
like
I
was
trying
to
elude.
You
know
I'm
not
trying
to
get
us
to
jump
straight
to
that,
but
it's
just
something
to
think
about.
A
Oh
no
I
I
think
it's
still
super
valuable
I'm,
just
yeah
I'm,
just
trying
to
think
of
like
the
Practical
yeah.
D
A
D
Know
if,
if
we
are
doing
that
at
the
very
least,
the
one
of
the
things
that
you
can
do
is
have
it
actually
Echo
to
the
user.
That
I
got
a
valid
signature
for
this
attestation
from
this
party
and
allow
them
to
kind
of
manually
make
that
decision.
Initially.
A
Cool,
so
on
that
end,
I,
don't
know
exactly
what
it
takes:
I
think
I'm.
Technically
an
admin
on
the
salsa
org
and
GitHub
I'll
I'll
double
check,
but
it
we
might
be
able
to
just
go
in
and
you
know
or
somebody
who
has
admin
can
go
in
and
create
maybe
a
repo
for
this
sort
of
tool.
A
I
am
ambivalent.
On
what
language
we
you
know
build
this
tool
in
you
know
I
personally,
I'm
no
go
I,
know
python
I
know
rust.
Those
are
the
three
main
ones
I
I'm
familiar
with,
but
I'm
down
to
sort
of.
Maybe
you
know
start
hacking
around
something
like
this
with
you
know,
I
think
we,
the
the
two
things
we'll
need
to
sort
of
answer
are
or
the
actually
the
precursor
thing
that
we'll
want
to
answer
is
generally.
How
is
how
are
we
expecting
these
things
to
be
stored?
A
Are
we
just
assuming
for
now
this
stuff
is
going
to
be
stored
as
files
coming
from
HTTP
endpoints,
you
know
and,
and
we
just
kind
of
go
in
and
and
you
know,
make
a
sort
of
our
request,
like
you
know,
hash,
Dot,
salsa
or
whatever
or
hash.att,
and
just
kind
of
saying,
hey,
let's
start
from
there
and
then
see
where
it
goes
or
do
folks
have
other
thoughts
around
that.
A
Cool
yeah
yeah
I
just
wanted
like
I'm,
not
you
know
like
if
somebody
had
said
actually
there's
a
you
know.
Somebody
has
written
up
a
really
cool,
FTP
sort
of
thing
like
okay.
Let's
do
that!
I'm
I'm!
You
know
ambivalent,
a
little
bit
there,
but
yeah.
If
HTTP,
just
you
know,
makes
the
most
sense.
We
can
probably
just
literally
you
know
say,
and
in
fact
actually
this
just
to
give
you
an
idea,
because
I've
done
this
in
some
of
the
Nyx
stuff.
A
Pull
up
my
repo
here
so
just
as
an
FYI,
this
was
one
of
the
things
I
had
done
for
the
kubernetes.
That
big
graph
thing
I
showed
off
a
couple
of
months
ago,
but
I
have
something
like
if
we
wanted
to
here's
like
1300
or
so
at
a
stations
that
all
sort
of
make
that
graph
that
we
could
just
sort
of
you
know
I
think
we
need
to
sign
them
and
turn
them
into
Json
lines
files,
but
we
can
yeah
whatever
like
there's.
Definitely
things
we
can
probably
do
here.
A
Even
maybe
I
wonder
we
could
probably
call
the
the
if
we
needed
to
without
even
running
anything.
We
can
probably
call
the
the
do
something
like
you
know,
store
it
in
GitHub
and
then
call
the
raw
and
just
say,
hey
great.
We
pulled
it
down
via
that.
We
could
probably
do
something
like
that
for
now
or
you
know,
but
but
but
we'll
get
to
that.
D
One
of
the
nice
things
about
files
is
that
it,
if
it's
just
kind
of,
if
you're
being
delivered
a
file
that
has
a
signature
on
it,
you
can
validate
that
signature.
If
it's
some
sort
of
arbitrary
query
about
the
data-
and
it
doesn't
actually
just
give
you
back
the
file,
it
gives
you
elements
of
the
file.
How
do
you
validate
your
signature
against
it?
D
A
Yeah,
and
so
so
in
this
case,
I'm
not
saying
like
literally
these
files,
it'll,
probably
be
the
literal
Json
lines,
files
with
the
signatures
included,
yeah
yep,
so
for
so
Sebastian,
so
I'm
actually
not
super
familiar
about
all
the
in
Toto
tools.
A
A
But
but
you
know,
there
are
certainly
Toyota
tools,
the
whole
process
of
policy
and
like
verify
things
against
it
and
stuff,
like
that,
oh
yeah,
yeah,
so
yeah,
I
figure,
we'll
it'll,
probably
be
either
some
combination
of
the
tools
or
the
in
total
libraries
we'll
just
be
using
directly
and
just
kind
of
doing
some
of
that
stuff
cool.
So
the
only
other
I
think
open
question
I
have
is
any
thoughts
on
what
language
this
tool
should
be
written
in.
A
That
that
seems
reasonable
to
me:
I
I,
most
Python's,
my
my
most
familiar
language.
So
that's
easy
for
me.
I
know
if
there
were
other
folks,
they'd
probably
be
saying,
go
right
now,
but
I'm,
okay
with
just
saying
you
know,
let's
use
Python
and
then
also
I,
believe.
Let
me
just
make
sure
there
is
the
Sig
store
python
library
now,
which
is
also
one
of
the
more
you
know
readily.
A
What's
the
word
up
to
date,
Sig
store
sort
of
implementations,
so
yeah
the
it
still
says.
It's
not
for
general
purpose
yet,
but
given
that
what
we're
doing
is
not
super.
A
Yeah,
let's
see
is
there,
do
they
have
well
we'll
have
to
we're
already
pretty
much
at
time,
but
we'll
we'll
look
a
little
bit
at
at
some
of
this
stuff,
because
it's
not
clear
if
Sig
store
the
python
Sig
store
verifies
stuff
like
salsa.
Yet
it
looks
like
it
verifies
signatures,
but
maybe
not
verifies
signatures
on
well.
I
mean
you
could
probably
verify
the
signature
on
an
attestation,
but
not
go
a
level
deeper
I,
don't
know
we'll
we'll
we'll
cross
that
bridge
when
we
get
to
it.
A
Any
other
questions
comments,
concerns
I
I,
once
I
kind
of
get
that
initial
thing
set
up
inside
of
the
the
the
repo
I
will
ping
it
in
the
the
slack
chat,
the
salsa
Dash,
tooling
slack
chat,
and
we
can
start
poking
around
with
it
sound
good.
B
A
So
if
I
will
probably
be
asking
some
questions
from
that
group
about
some
of
the
python
in
Toto
stuff,
so
everybody
have
a
good
have
a
good
weekend.
Cool.