►
From YouTube: Sigstore for Python Packaging: Next Steps for Adoption - William Woodruff, Trail of Bits
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Sigstore for Python Packaging: Next Steps for Adoption - William Woodruff, Trail of Bits
Sigstore is coming to the Python packaging ecosystem! For the past 9 months, engineers at Trail of Bits have worked with members and stakeholders within the Sigstore community to develop sigstore-python, a high-quality Python API and CLI for performing Sigstore-style signatures and verifications. Now comes the hard part: convincing members of Python's packaging ecosystem, among the largest and most critical, to adopt Sigstore into their package publishing and consumption workflows. This talk will perform a survey of Python packaging, and consider some of the ways in which Sigstore fits into the packaging user experience. Particular consideration will be given to two groups of packaging ecosystem users: "ordinary" users, who should benefit from baseline authenticity and integrity without having to substantially alter their workflows, and "proactive" users, who should be able to opt into *additional* security guarantees (such as verification against TUF-attested claims) both when packaging and consuming others' packages.
A
So
without
further
Ado
yeah,
my
name
is
William.
I
am
a
senior
security
engineer
at
a
company
called
trail
of
bits.
Some
of
you
may
know
us
for
those
of
you
who
don't
we're
a
mid-sized
cyber
security
company.
In
my
mind,
I
think
this
is
a
small
number.
Now
we're
actually
kind
of
big.
We
do
a
whole
bunch
of
different
things,
but
the
things
that
I'm
involved
with
are
primarily
open
source
work
in
the
package
management.
A
We
do
all
kinds
of
things
in
the
program:
analysis,
research,
space
too,
and
of
course
this
is
my
call
to
say
we're
also
hiring.
So
please
join
us
if
you
are
interested
we're
pretty
easy
to
find
online
yeah,
so
just
to
sort
of
set
an
agenda
for
today,
I'm
going
to
sort
of
do
because
this
is
a
six-door
crowd,
not
a
python
direct
crowd,
I'm
going
to
do
a
quick
overview
of
the
history
of
python
packaging
and
what
it
looks
like
and
why
it
is
the
way
it
is.
A
A
Unless
we
care
a
lot
about
adoption
and
the
hard
truth
is
that,
in
order
to
drive
adoption,
you
have
to
convince
engineers
and
Engineers
most
of
them
at
least
the
ones
who
aren't
specifically
tasked
with
it,
do
not
care
about
those
things
unless
they
directly
relate
to
their
job
duties,
and
it's
actually
not
their
job
too.
Their
job
is
to
achieve
the
things
they're
told
to
do
so.
A
It
is
therefore
our
job
to
make
security
as
easy
and
as
frictionless
as
possible
so
that
it
gets
out
of
their
way,
so
they
can
do
their
job
and
sort
of
everything
keeps
moving.
If
we
don't
do
this,
they
will
not
use
what
we
give
them.
They
also
present
us
for
it
and
they
won't
misuse
whenever
we
give
them.
A
So
you
know
this
is
we're
all
sort
of,
like
you
know,
pernicious
Little
Creatures
to
them
we're
getting
their
way,
and
this
applies,
of
course,
doubly
for
open
source,
because
you
know
a
lot
of
us
are
doing
open
source
and
we're
paid
for
it.
But
for
every
one
of
us
there's
people
who
are
doing
it
for
free
because
they're
they
believe
in
it.
So
you
know
we
need
to
stay
out
of
their
way
and
make
their
lives
better,
not
worse,
yeah.
A
So
as
part
of
that,
I
want
to
do
like
a
brief
history.
It's
actually
before
before
I
do
this.
Who,
in
this
room,
is
programmed
in
Python?
Okay,
probably
pretty
much
everybody?
How
many
of
you
use
pep,
pretty
much
everybody
programs
to
python
cool?
Okay,
so
you
probably
know
a
lot
of
this
already,
but
I'll
go
through
it
pretty
fast,
so
that
we're
all
on
the
same
page
yeah.
A
So
the
reason
I
bring
this
up
is
because
python
is
one
of
the
biggest
programming
communities
in
the
world.
It's
one
of
the
oldest
for
sort
of
like
a
modern
programming
language
and
as
a
result
of
that,
there's
a
lot
of
embedded
history.
Packaging
state
that
fundamentally
cannot
be
changed.
If
you
change
these
things,
you
angry
engineers
and,
like
we
just
said,
if
you're
angry
with
the
engineers,
they
don't
do
anything.
So
you
know
way
back
in
2000.
A
This
thing
called
Disney
tools
was
added
to
python
1.6.1,
that's
a
version
of
python!
It's
sold
that
it's
before
the
version
that
took
us
forever
to
deprecate
we're
still
using
this
two
tools.
As
far
as
I
can
tell
most
of
you
probably
have
some
piece
of
code
in
your
code
base
that,
instead
of
using
setup
tools,
it's
using
distributables,
so
it's
still
there.
This
thing
that
we
added
you
know
drinking
era
ago,
the
year
after
that
we
standardized
the
very
first
version
of
What's
called
the
python
packaging
metadata.
A
This
is
still
used.
We
have
newer
versions,
but
Python's
tools
will
happily
confirm,
consume
metadata
1.0.
Shortly
after
that
the
First
Central
packaging
index
was
established
and
the
word
index
there
is
really
key,
because
for
a
very
long
time,
Pi
Pi
was
not
a
vital
store,
it
was
an
index
and
what
that
means
is
that
it
didn't.
There
were
no
distributions
on
Pipi.
There
was
a
link
to
a
URL.
A
There
was
a
URL
that
pointed
to
another
server
and
you
would
navigate
as
a
human
being
to
that
server,
and
maybe
there
would
be
a
file
there
that
you
could
download.
So
this
should
tell
you
something
about
the
cattle
Python's
packaging
was
originally
organized
and
distributed.
There
was
no
like
automated
way
to
do
any
of
this.
A
You,
as
the
application
developer,
would
go
around
the
internet
sort
of
like
picking
like
picking
cherries
from
various
websites,
hoping
they
were
online
at
the
right
time
and
then
install
them
manually
and
then
the
after
that.
The
thing
that
we
now
call
Pipi
was
established.
That
was
still
just
this
bear
index.
No,
no
file
hosting
just
references
to
other
servers
with
that
came
out
of
data
1.1,
which
enhanced
my
data
just
a
little
bit.
Add
some
click
dependencies
you're
after
that
easy
install.
A
Some
of
you
have
possibly
used
this.
This
is
like
the
the
predecessor
to
pip
easy
install
also
comes
with
eggs,
which
are
the
predecessor
to
Wheels.
Both
of
these
are
more
or
less
long
gone.
I
think
you
can
still
use
Easy
install
with
the
lasers
python,
which
again
should
tell
you
something.
I
mean
this
is
not
you
shouldn't
be
using
it,
but
you
can
and
effort
is
put
into
supporting
it.
A
You
know
moving
on
a
few
years
ago,
Monday
to
1.2
and
then
critically
in
2008
we
get
PIP,
which
you
know
by
the
show
of
hands.
Just
earlier
many
of
you,
the
majority
of
you
have
used
and
again
I
should
say
something
that
you
know
14
years
ago.
The
tool
that
you
were
all
using
today
was
created,
so
that
was
that
was
like
sort
of
the
the
prehistory
of
python
packaging.
I
would
say
the
modern
era
roughly
begins
around
2012..
A
A
This
I'll
talk
a
little
bit
more
about.
What's.
This
enables,
but
basically
it'll
enable
a
lot
of
the
things
that
we
now
can
do,
with
with
sing
store
and
with
other
tools.
A
few
years
later
we
get
the
current
Pi
Pi
repository
API,
so
the
thing
that
pip
actually
uses
when
you
do
pip
install
before
that
it
was
completely
uncenteredized.
It
would
just
sort
of
like
hope
and
pray
that
the
URL
you
hit
resembled
a
Pipi
index,
so
you
know
seven
years
ago.
A
The
thing
that
we
all
assumed
just
worked
was
actually
standardized
two
years
after
that
we
get
metadata
2.1,
which
I
believe
is
the
current
metadata
standard
unless
they
just
released
a
new
one
which
I
believe
they
were
working
on
2018
the
modern
Pipi
backend
was
deployed
before
this.
It
was
a
code
base
that
sort
of
grown
up
organically
from
the
2003
code
base.
A
This
is
the
one
that
is
currently
in
use
and
I'm
a
big
fan
of
it
and
finally,
like
more
recent
history,
pep
458,
a
lot
of
people
in
this
room
are
very
familiar
with
four
five.
Eight,
a
lot
of
you
worked
on
it.
This
is
the
signed
repository
metadata
pet.
It's
specifically
tailored
around
tough.
It
was
accepted.
There
were
some
efforts
to
implement
it
that
are
still
ongoing.
A
A
So
you
know
what
15
years
after
no
10
years
after
it's
still
it's
a
very
large
there's,
a
minority
but
a
very
large
number
of
downloads
that
are
not
using
a
modern
distribution
format
and
then
also
pip
has
a
new
dependency
resolver
and
then
finally
we're
here.
So
you
know
so
it's
been
going
on
for
a
long
time
and
all
of
this
has
been
has
been
moving
in
sort
of
like
a
glacial
but
accelerating
Pace.
A
In
order
to
maintain
this
compatibility
with
this
massive
body
of
code,
that
cannot
be
moved
forward
without
a
great
deal
of
pain,
yeah.
So
on
the
side,
car
of
all
of
that
there's
a
question
of
like
package
security.
We
historically
or
not.
We
python,
python
pack
and
index
was
one
of
the
earliest
ever
made.
Security
was
sort
of
like
a
non-thought,
wasn't
something
that
anybody
was
even
thinking
about.
A
So
these
things,
these
three,
these
three
properties
of
authority,
integrity
and
authenticity,
were
just
not
concerns.
Originally,
you
know
just
to
rehash
for
everybody
here.
You
know,
Authority
is
users
or
identities
can
only
publish
packages
that
they
control
Integrity.
You
know
you
get
the
thing
that
you
asked
for
and
authenticity
is.
It
is
what
it
says
it
is.
So
that's
it's
not
just
unmodified,
but
it
was
actually.
It
was
actually
created
by
the
entity
that
had
the
right
to
create
it.
A
Yeah.
None
of
these
things
was
a
priority
and
we'll
see
sort
of
how
python
provided
them
originally.
So
this
is
actually
the
best
one.
Authority
was
something
that
was
pretty
much
baked
into
pipef
in
the
beginning,
because
we
had
these
user
accounts
that
could
upload
earlier
first
metadata,
but
then
actual
distributions
for
packages.
A
Historically,
the
only
way
to
off
to
Pi
Pi
was
usernames
and
passwords,
which
led
to
a
really
common
practice.
When
CI
became
more
common,
if
people
just
dumping
their
passwords
into
GitHub
and
gitlab
and
etcis,
and
then
usually
not
getting
leaked
but
sometimes
getting
leaked,
so
that
was
that
was
pretty
bad.
In
2020
19
we
developed
two-factor
off
on
pipe
pi
to
discourage
that
and
I.
Think
since
then
the
uptick
has
been
pretty
good,
so
I
would
say
here
the
status
quo.
A
A
You
know
we're
using
modern
two-factor,
it's
totp
and
web
often
nothing
crazy.
Yeah.
On
the
Integrity
side,
like
I
said,
IPI
was
historically
an
HTTP
index.
You
referenced
files
will
restore
an
HTTP
or
even
FTP
hosts.
That
means
you
know,
of
course,
no
transport,
Integrity
TLS
was
not
a
thing
and
it
was
a
thing,
but
it
was
not
a
common
thing
in
2001..
A
These
things
were
just
sort
of
like
trusted
blindly
over
the
network.
At
some
point,
I
don't
actually
know
when
https
was
added
to
IBI
providing
transport
Integrity.
But
of
course
that
requires
you
to
trust
the
host,
so
full
hosting
of
you
know.
Well,
it
doesn't
even
purchase
the
host.
You
know
you
still
have
this
transport
everybody
to
Pi,
but
then
you
you
go
out
to
the
HTTP
host
and
you
download
it
from
there.
A
So
your
individual
hosts
are
still
not
providing
it
necessarily
putting
everything
on
pipe
bi
fix
that
and
then
finally,
in
2016
we
added
hash
tracking
mode
to
pep,
so
you
could
actually
pre-declare
your
hashes
for
your
files
ahead
of
time.
Fetch
them
check
the
hashes
and
if
they
didn't,
and
if
not
all
your
files
were
hashed,
it
would
fail.
So
that
provides
like
strong
Integrity.
A
It's
not
great,
because
now
you
have
this
like
terrible
ux
of
hashes
everywhere,
but
it's
better
than
nothing
and
then
Google
distributions
improve
this
also
a
little
bit
by
adding
profile
hashes
in
like
this
metadata
record
file.
So
here
the
status
quo
is
it's
a
close
to
other
packs
managers,
but
it's
kind
of
hard
to
use.
It's
not.
A
It's
not
really
easy
to
use,
as
like
package
managers
like
the
node.js
or
rust
ecosystems,
where
this
is
all
done
by
default
for
you
in
in
the
packaging
metadata
file,
you
have
to
do
it
yourself,
which
is
kind
of
annoying
I,
mean
here's
an
example
of
what
that
sort
of
hash
looks
like
inside
of
the
record
file.
You
can
see
it's.
You
would
never
interact
with
this
directly,
but
it's
it's
just
there
yeah
and
then
we
get
to
authenticity
which
is
sort
of
a
key
thing
in
the
in
the
six
door.
A
Ecosystem
I,
think
pipi's
historical
approach
to
authenticity
could
be
could
be
characterized
as
like
Maybe.
You
can
do
it
if
you
want
so
so
optionally
for
for
years,
I
don't
even
know
when
this
began.
Papi
has
optionally
supported
pgp
signatures
on
distributions.
So
when
you
uploaded
a
distribution,
you
could
also
upload
a
distributionname.asc
for
the
signature
file.
Pipei
would
accept
it
render
it
alongside
and
then
someone
could
optionally
download
that
and
verify
it.
A
That's
that's
not
a
rhetorical
question.
Why
do
you
trust
that
signature?
You
know
anybody
can
sign
for
a
package.
Anybody
can
upload
it.
Podcast
maintainers
could
just
put
their
own
signature
there.
You
know
you
have
to
have
some
kind
of
web
of
trust
or
other
trusted
setup.
Global
trust
doesn't
really
work
anymore
since
the
the
whole
spamming
thing
in
2019
yeah.
So
that
really
wasn't
ideal.
It
turns
out
that
pretty
much
nobody
used
it.
A
So
you
can
still
upload
pgp
signatures
Pipi,
but
they're,
not
in
the
UI
anymore,
because
they're
functionally
useless,
stranger
and
sort
of
like
a
this
is
like
a
weird
Vestige
of
Python
history.
I,
don't
think
anybody
else
knows
about
this.
We
also
have
optional
support
for
Joe's
style
and
pkcs7
style
signatures.
As
far
as
I
can
tell
there's
only
one
package
ever
that's
been
uploaded
to
Pi
Pi
that
uses
these,
so
so
people
don't
even
know
this
exists.
A
I
found
this
out
while
doing
research
for
these
slides
same
problem
with
PTP.
Why
would
you
use
this
I?
Also
pip
I
think
someone
corporate
created
an
issue
on
the
PIP
like
issue
tracker
and
they
were
like.
How
did
you
find
us
out
close?
We
won't
ever
support
this,
so
you
know
you
could
verify.
Verification
is
clearly
option.
I'll
put
this
back,
you
could
use
these
at
your
own
risk.
I
guess
so.
Yeah.
A
A
So
what
does
Six
Tour
do
for
python
packaging?
How
does
it
get?
How
does
it
improve
all
three
of
these
properties,
so
I
think
the
way
that
I
think
about
it
at
least,
is
the
biggest
thing
that
six
or
does
for
python
packaging?
Is
it
fundamentally
solves
a
lot
of
the
ux
problems
that
happen
with
code
signing
while
simultaneously
preserving
the
best
properties
of
code
cyanine?
A
So
you
know
the
problem
like
we
said
with
with
pgp,
and
these
pdcs7
or
Joe
signatures
is
Key
Management.
You
have
to
hold
on
to
this
long-term,
very
sensitive
key,
which,
if
you
lose
or
disclose
by
accident,
you
have
to
rotate
and
then
you've
got
some
kind
of
rotations.
You
know
it
gets
very
complicated,
very
fast.
A
You
know
you
you,
as
a
packager
no
longer
have
to
do
that
with
sex
store
you
as
a
verifier,
as
a
consumer
no
longer
have
to
perform
curing
mate,
so
you
no
longer
have
to
prune
invalid
or
expired
keys
keys
that
are
catered
with.
Poor
crypto
systems,
like
you
know,
P2P,
you
can
just
create
a
RSA
256
key.
A
If
you
wanted
to
and
you
you
know,
you
don't
have
to
prune
that
out
now,
six
four
will
choose
the
right
ciphers
for
you,
six
door,
sort
of
on
the
same
topic
is,
is
in
agile.
You
know,
30
years
ago
we
thought
cryptographic.
Agility
was
a
really
good
thing.
It
turns
out.
We
were.
We
were
really
wrong
about
that
in
agility
is
sort
of
the
name
of
the
game.
Now
you
really
want
the
crypto
system
or
the
scheme
to
pick
the
best
ciphers
for
you
and
sixstore.
A
Does
that
six
door
does
not
let
you
pick
RSA
256,
it
does
not.
Let
you
pick
cast
five,
it
doesn't
let
you
pick
Blowfish
I,
don't
know,
and
then
finally,
sixer
signatures
are
rooted
to
a
public
identity,
I
think
increasingly
on
the
internet.
We
see
people
think
in
terms
of
identities
instead
of
in
Terms,
of
like
a
pgp
signature,
people
think
in
terms
of
like
their
GitHub
handle
or
their
the
the
email
metadata
it's
attached
to
the
package
and
so
bringing
the
cryptographic
promises
closer
to
that.
A
A
So
that's
that's
good
in
my
mind
and
then
sort
of
as
a
nice
side
effect
like
I
said:
I
mean
Authority
and
integrity
themselves.
Aren't
that
bad
right
now
in
IPI,
but
six
door
will
change
it
by
will
transitively
strengthen
these
properties,
because
once
you
get
authenticity,
you
also
get
Integrity
transitively.
You
have
strong.
You
have
strong
Integrity
via
cryptographic
signatures
you
could
Authority
by
having
this.
A
Oh
sorry,
this
is
a
separate
kind
of
authority
that
we're
getting
so
we're
planning
on
making
Pipi
its
own
openid
connect,
identity,
provider
and
So,
eventually
you'll
be
able
to
have
like
a
you
know,
username
separator
I
think
we
have
I
think
we
settle
an
exclamation
point
as
a
separator
for
non-mail
identities.
Can't
remember:
Pi
Pi
identifier
you'll
be
able
to
use
that
as
a
a
sign
identity
for
for
six
dollar
artifacts
I
mean,
like
I,
said
Integrity.
You
get
transitively
through
through
strong
authenticity
yeah.
A
So
that
brings
us
to
where
we
are
currently
So.
Currently,
you
find
people
reference
mention
it
throughout
the
other
slides.
We
have
this
reference:
python
implementation,
six-door
python,
one
of
the
cool
things
I
think
this
is
actually
I
forgot
to
update
this,
but
as
of
yesterday,
it's
it's
signed
for
the
latest
3.11
release
of
C
python,
so
this
is
not
related
to
stock
python
packaging
at
all.
A
A
We
also
have
ambient
credential
support
some
that
we
stole
from
from
cosine.
We
have
support
for
things
like
GitHub
actions,
Google
Cloud
build
et
cetera.
We
will
detect
if
you're
in
that
environment
and
we
will
pull
the
open
ID
connect
credential
from
that
environment,
so
that
you
don't
even
have
to
think
about
signing
it'll.
Just
do
it
automatically
I
think
that's
pretty
cool
and
we
actually
use
that
in
this
GitHub
actions
to
explore
python
package.
A
We
automatically
sign
using
github's,
open,
adconnect
and
six-door
dog
foods
is
internally
on
our
CI
every
day
and
then,
finally,
because
via
this
package,
we
can
automatically
publish
signing
artifacts
to
GitHub
releases,
and
you
know
here's
some
screenshots
showing
that.
So
this
is
like
a
latest
release.
You
know
you
see.
Each
distribution
has
a
second
assert
yeah,
so
that
brings
us
to
where
we
want
to
be
so
right
now
we
can
sign
up
verify
things
with
64
python.
A
We
want
those
sign
artifacts
to
actually
be
published
to
the
index
that
python
package
users
use,
which
is,
of
course
Pi
Pi.
They
have
to
be
published
alongside
distributions
and
then
eventually
once
they're
on
there.
There
needs
to
be
cross-checked
via
inclusion
in
a
tough
repository
per
up
at
458.,
so
to
support
this
Pipi
has
to
undergo
some
changes
right
now.
Pipi
will
reject
any
file
that
does
not
end
with
a
few
supported
suffixes
for
distributions
and
for
pgp
signatures,
so
we
needed
to
support.sig.sert
or
alternatively,
once
six
store.
A
Bundles
are
fully
standardized,
whatever
I
believe
that
six
door
was
the
suffix
that
was
chosen.
That
will
become
the
supported
topics
that
will
have
Papi
accepts
and
then
with
any
luck.
Pep
694,
which
is
the
upload
API
2.0
I,
think,
is
what
they're
calling
it
we'll
enable
this
by
having
us
attach
all
this
to
the
like:
a
metadata
blob
on
the
upload
and
so
find
it'd
be
a
separate
file,
so
that'll
simplify
things
nicely
yeah
and
then
once
it's
on
pipei,
it
actually
becomes
really
easy
to
deliver
this
to
users.
A
Pip
can
simply
just
download
it
with
the
distribution.
If
it's
available,
however,
this
again
will
require
a
little
bit
more
work
because
simple
index
is
is
frozen,
so
pep
503
has
to
be
superseded
by
pep691,
which
is
a
new
index
standard
for
the
API,
and
once
it
begins
to
consume
that
new
index,
then
we'll
be
able
to
deliver
these
files
to
users
yeah,
and
that
brings
me
to
sort
of
the
next
thing,
which
is
a
server
side.
A
Isn't
enough,
so
you
know
it's
one
thing
to
have
these
signing
artifacts
on
on
Pipi
and
at
pipei
I
do
a
little
bit
of
verification
with
them.
We
also
want
end
users,
people
who
are
doing
pip,
install
X
or
pip,
install
Dash,
R
requirements.txt
to
be
able
to
verify
these
materials
themselves
right.
They
shouldn't
be
dependent
on
us
to
do
it.
So
there's
a
couple
challenges
there.
A
One
one
is
that
pip
is
the
universal
python
package
installer,
which
means
that
it
runs
everywhere,
which
in
turn
means
that
they
can't
have
any
sort
of
native
dependencies
which
six
door
python
is
full
of
because
it
uses
openssl
and
some
Rust
builds
under
the
hood.
So
we
have
to
think
a
little
bit
about
how
we're
going
to
do
that,
and
so
that's
all
that's
on
the
road
map
to
think
about.
A
But
the
key
thing
here
is
then:
this
goes
back
to
what
I
was
saying
earlier
about
staying
out
of
Engineers
ways.
Users
should
not
have
to
be
aware
that
anything
anything
has
changed
whatsoever
about
their
process.
This
is
a
personal
goal
of
mine
is
PIP.
Install
requests
should
not
look
any
different
unless
something
fails,
unless
an
Integrity
or
authenticity
violation
has
has
occurred.
A
If
it
does
change,
users
will
reject
it.
Based
on
on
the
history
of
python,
Packaging
and
and
previous
failures
to
use,
signing
materials
and
pylon
Packaging
and
then
finally,
you
know
the
bigger
picture
is
that
six
door
needs
to
fit
into
the
larger
sign-in
and
high
Assurance
constellation
for
all
packaging
ecosystems.
A
We
really
want
our
efforts
here
to
be
a
sort
of
litmus
test
for
things
like
npm
for
cargo
for
sorry
for
crates,
for
you
name
it
even
we
want
them
to
be
able
to
take
from
our
our
mistakes
on
the
things
that
we
succeed
on
and
doing
better.
So
what
we
need
to
get
there,
so
it's
it's!
You
know,
there's
sort
of
two
big
classes
of
things
that
I
identify
as
things
we
need.
A
One
is
sort
of
like
General
ux
thought
that
needs
to
go
more
into
six
door.
It's
one
thing
to
verify
signatures
and
it's
entirely
another
thing
to
trust
identities.
People
have
many
of
you
have
spoken
about
this
during
during
your
talks,
six
doors
conceptually
much
much
better
than
blind
verification,
but
it
seems
to
be
practically
better
than
that.
It
needs
to
be
much
more
than
just
six
door
verify
in
these
materials,
and
these
actually
have
some
way
of
communicating
to
users
concisely
that
they
should
trust
this
identity.
A
A
I
have
there
about
how
we
can
make
this
better
or
how
we
can
how
we
can
achieve
this
specifically
Pi
Pi
and
the
packages
themselves
have
tons
of
metadata
in
them
that
we
could
use
for
cross-checking,
and
so
this
we
could
potentially
use
to
avoid
bugging
users.
Basically,
with
with
with
a
verification
information,
we
can
just
sort
of
glean
it
from
the
information
they
already
give
us
and
do
things
like
you
know,
a
package
maintainer,
you
know
it's
on
Pi.
A
Can
we
can
we
cross-check
that
against
the
email
identity
in
six
door,
the
repository
URL?
That's
in
that's
in
the
package
metadata.
Can
we
cross-check
that
against
packages
that
are
published
using
oidc
or
via
GitHub,
API
token
Exchange
and
then
longer
term,
we
want
users
to
be
able
to
configure
machine,
readable
verification
policies,
so
they
can
say
I
trust
these
three
maintainers
at
least
two
of
them
have
to
sign
for
the
package.
A
You
know
that
kind
of
complex
policy
needs
to
be
consumable
and
committable
somewhere
public,
so
you
can
verify
the
policy
does
not
change,
except
for
when
you
expect
to
change
and
our
thought
there
was
that
will
fit
in
nicely
with
tough
and
then
the
other
big
sort
of
fork.
There
is
threat
modeling,
you
know,
we
all
know.
Six
door
is
conceptually
pretty
complex.
The
core
of
it
is
simple,
but
as
you
begin
to
think
about
what
verification
means,
what
signing
actually
means?
A
You
quickly
splinter
out
into
different
edge
cases
where
you
know
you
trust
the
email
identity,
but
you
don't
trust
the
open.
You
don't
trust
the
IDP.
You
trust
the
IDP,
but
maybe
it
goes
down.
Sometimes
you
trust.
You
know
you
probably
trust
the
ca,
because
we're
all
trusting
full
sales,
it's
part
of
what
we're
building,
but
a
user
shouldn't,
have
to
know
any
of
that.
A
user
should
just
be
able
to
say
I
trust
it
because
X,
Y
and
Z.
A
These
are
properties,
I
want
to
get
out
of
it
and
if
I
violate
one
of
those
I
know
what
happens.
They
shouldn't
have
to
understand
these
rfcs
that
build
up
that
that
that
sticks
are
built
on
top
of
they
shouldn't
have
to
understand,
x509v3
or
or
the
actual
CT
scheme.
It's
understand
what
they're
getting
out
of
it
and,
of
course
they
also
shouldn't
have
to
understand
pki
or
these
ephemeral
keys
that
we
use
or
for
keyless
signing
or
any
of
that
sort
of
thing
to
benefit
from
six
door.