►
From YouTube: Digital Identity WG (September 2, 2020)
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
Clicked
the
button
awesome-
and
I
just
officially
started
this
recording,
so
this
will
be
uploaded
to
the
ossf
youtube
channel.
Sometime
later
today,.
B
B
B
B
All
righty,
so
I
just
moved
up
constantine.
He
had
he
had
offered
to
give
a
presentation
on
linux,
kernel,
developer,
identity,
stuff,
and
I
took
a
very
quick
look
at
his
slides
and
there's
some
really
good
content
in
there.
We
might
that
might
take
up
the
majority
of
the
time
this
meeting,
but
I
think
that's
fine.
If
we
have
a
good
discussion
around
it
and
learn
a
bit
about
that
process,
so
constantine,
do
you
want
to
kick
it
off.
C
Right
how
about
I
do
that,
while
everybody
else
does
something
else,
I
don't
want
to
hold
up.
F
B
B
C
B
Okay,
do
we
want
to
jump
okay?
How
much
time
do
you
think
you
need
to
talk
about
collaboration
with
the
cdf
security
thing.
D
Okay,
I
think
that
I
think
I'm
just
answering.
I
think
there
may
have
been
some
questions
that
came
up
last
time
and
so
yeah
and
I'm
just
on
point
to
to
provide
an
answer.
Does
anyone
remember
the
the
exact
question,
so
I
make
sure
I'm
I'm
I'm
giving
an
appropriate
answer.
B
A
D
She's
not
here
today,
okay,
sure
so
yeah,
so
the
cdf
security
sig
there
were.
There
are
two
things
that
are
kind
of
happening
there.
So
one
is
we're
using
the
that
sig
for
tracking
information
about
the
3ts
bomb
specifications
and
the
3ts.
D
D
D
We're
working
on
a
software
bill
of
materials
standard.
Some
of
the
people
in
this
column
might
be
involved
in
that
there
are
a
number
of
people
from
microsoft
anyway,
so
that
group
is
it's
being
run
out
of
the
omg,
but
we're
using
resources
from
the
cdf
security
sig.
So
we
have
a
a
github
and
google
docs
where
some
information
is
stored.
D
So
that's
one
thing:
that's
happening
in
the
cdf
security
sys.
There
was
a
separate
thing
that
I
got
started
earlier,
which
was
about
supply
chain
security,
but
that
really
hasn't
taken
off
and
that
aspect
I
would
like
to
merge
over
and
have
that
be
in
the
openness
instead.
D
G
H
I
can
give
an
update
there.
So
did
sp
did
raise
this
on
the
is
it
the
toc
or
the
tac.
There's
too
many
foundations,
yeah.
H
Okay-
and
they
said,
if
we
could
outline
the
new
scope
for
them,
okay,
then
we
would
take
it
back
and
they
would
then
review
that.
H
A
H
Is
just
put
together
a
simple
dock
just
to
outline
our
our
scope,
what
will
constitute
secure
supply
chain?
What
would
we
you
know?
What
will
we
focus
on
so
we
could
have
the
initial
focus
be
developer
identity
still,
you
know,
that'd
be
the
the
key
area
that
we
explore,
but
then
we
would
sort
of
say
we're
also
interested
in.
I
don't
know,
attestations
of
materials
or
capturing
metadata
and
whatever
else
we're
interested
in
doing
that's
great.
D
We
might
I
I
think
it's
worth
us
just
we've
got
another
topic
for
today.
So
that's
what
I'm
suggesting
isn't
for
today's
discussion,
but
I
think
in
a
in
a
future
meeting.
One
thing
I'd
like
to
explore
is:
maybe
we
we
do
want
a
separate
group
that
thinks
about
what
our
general
story
is
for
supply,
chain,
attestation
and
governance,
and
maybe
we
do
want
a
separate
group
that
just
deals
with
it
at
an
infrastructure
level.
D
So
you
know
here's
what
our
plan
is
across
the
various
teams,
because
developer
identity
is
one
aspect
that
will
want
to
build
on
that
infrastructure,
but
some
of
the
other
working
groups,
for
example
the
project
metrics
written
group-
I
I
think,
would
also
want
to
build.
On
top
of
that,
I
think
I
haven't
spoken
with
them
yet
so
so
we
we
have
options
to
explore
when
we,
when
we
get
back
to
looking
at
scope,.
B
That
was
good
all
right
and
that
yeah
that's
later
it's
on
the
agenda
constantine.
Are
you
ready
to
go.
C
C
All
right,
so
this
is
a
case
study,
I'm
not
claiming
that
this
is
how
it's
supposed
to
be
done.
This
is
just
kind
of
that's
the
way
how
we
do
it
and
I
will
go
into
what's
working,
what's
not
working
and
I
will
do
a
general
review
of
what
it
is.
So,
first
of
all,
before
we
go
into
this,
you
need
to
understand
how
the
linux
kernel
hierarchy,
works.
Right,
linus
accepts
full
requests
from
a
small
subset
of
subsystem
maintainers,
and
this
is
a
small
subset.
C
It's
not
if
you
look
at
the
maintainers
file
in
the
linux
kernel
you'll
see
like
thousands
of
entries
in
there
various
people,
but
but
only
about
maybe
50
maximum
people
send
pull
requests
directly
to
lena
stormels
right
most
of
them.
The
vast
majority
of
them
sound,
just
pull
requests,
they
don't
sell,
they
don't
send
patches
with
extremely
few
exceptions.
Andrew
morton
does
not
use
git
because
it's
too
new,
I
guess
so
he's
he
still
sends
patches
and
like
quilt
collections
to
him,
he's
the
only
one.
C
As
far
as
I
know,
that
still
does
that
everybody
else
sends
bull
requests
which
can
be
the
gp
signed.
The
reason
I
mentioned
this
so
top
tier
maintainers
who
send
the
request
to
linux.
They
themselves
have
sub
maintainers
or
they
may
not
have
some
maintainers.
Usually
they
do.
They
would
have
like
a
subset
of
files.
C
C
C
If
you
look
at
the
maintainers
file,
there
is
every
every
driver
has
a
subsystem
maintainer
and
which
is
which
explains
why
there's
so
many
entries
in
there
so
trust
bubbles
up
so
like
the
maintainer
who
receives
patches,
trusts
or
checks,
do
it's
up
to
them,
how
they
check
the
the
trust
for
the
every
every
previous
maintainer
and
blame
obviously
bubbles
down.
So
you
know
if
linus
receives
something
from
a
sub
maintainer,
he
just
blames
that
person
and
that
person
will
let
him
spread
the
blame
back
down
down
my
heart
keychain.
C
So
it's
not
a
secret
that
linux
kernel
uses
pgp
for
its
cryptographic,
station
and
developer
identity
and
the
reason
we
are
continuing.
We're
not
we're
not
planning
to
switch
away
from
this.
It's
probably
because
decentralized
trust
is
a
hard
problem,
and
linux
linux
development
is
a
very
decentralized
effort.
You
know
there
have
been
known
efforts
to
combat
any
sort
of
attempt
to
centralize
the
next
development.
It
is
still
happening
on
multiple
git
servers.
It's
still
on
multiple
mailing
lists.
C
There
is
strong
push
back
against
like
let's
just
move
it
to
github,
but
let's
just
move
it
to
git
lab.
Well,
let's
just
use
garrett
or
something
like
that.
That's
it's
an
ongoing
conversation,
there's
a
very
strong
strong-minded
and
willful
subset
of
high-level
maintainers
who
say
we'll
never
do
this,
because
linux
development
must
remain
decentralized
so
that
no
one
entity
can
claim
linux
development
happens
within
our
company,
even
if
it's
a
non-profit
like
a
linux
foundation.
So
linux
development
does
not
happen.
C
The
linux
foundation
just
to
clear
up
any
misconceptions
there.
We,
the
noise
foundation,
may
be
hiring
linus
or
greg
hartman
or
a
number
of
other
developers,
but
and
it
can
be
managing
kernel.org
but
current.org
is,
has
equal
weight
in
terms
of
where
git
repositories
are
stored.
C
So
there
is
no
linux
kernel.
Web
of
trust,
we'll
talk
about
the
web
of
trust,
but
this
is
class
understand
that
there
is
no
such
thing
as
the
linux
kernel
web
of
trust,
each
one
each
one
of
the
maintainers
has
their
own
web
of
trust
like
little
fiefdoms
of
trust
that
happening.
Even
I
mentioned
that
you
know.
C
Trust
goes
up
and
plain
bubbles
down,
so
it's
up
to
each
of
the
maintainers
to
maintain
their
own
web
of
trust,
and
not
many
of
them
use
actual
web
of
trust
in
terms
of
the
pgp
definition
of
it.
It
means
that
you
know.
If
you
sign
this
person's
key,
then
you
know
and
that
person
signs
this
person's
key.
Then
I
can
trust
this
person's
key,
because
he's
got
both
of
these
signatures.
Many
of
the
developers
do
not
care
about
this.
C
They
have
a
very
direct
relationship
which
can
be
described
as
the
trust
on
first
use.
I
will
talk
about
the
next
slide
and
linus
torvalds,
for
example,
is
one
of
those
people
so
a
few
years
ago,
lena
said,
if
you're
in
my
keyring,
I
trust
your
signature
right.
It
is
not
wrong.
It
sounds
wrong
when
you
think
about
it
like
on
top
of
it,
but
it
is
not
actually
wrong.
This
is
the
trust
and
first
use
approach.
This
is
ssh
style,
identity,
trust
in
the
first
time
using
station
system.
C
C
The
first
use
pgp
approach,
the
first
time
you
see
somebody's
key
you're,
seeing
that
this
assume
that
this
key
is
valid
and
next
time
you
receive
anything
signed
from
that
from
that
email
address
and
the
fingerprint
or
the
key
is
different,
then
the
pgp
will
say
well,
something
weird
is
going
on.
It
marks
both
both
of
the
versions
all
the
versions
of
the
key,
as
must
be
checked
manually
and
they'll,
refuse
to
say
this
is
valid
or
anything
like
that.
C
So
there
are
upsides
and
downsides
to
this.
The
upside
is
that
tofu
scales
better
and
is
much
easier
to
understand.
You
know
the
pgp
web
of
trust.
Almost
everybody
misunderstands
it,
and
even
I've
been
dealing
with
this
for
the
past
10
years
extremely
closely.
Every
now
and
again,
it
just
still
surprises
me,
because
I
think
something
should
be
working
and
it
actually
doesn't.
C
A
Can
I
ask
a
question
on
that
one:
real,
quick,
so
somebody's
identity
is
basically
the
tuple
of
their
email
address
and
their
pgp
key.
G
C
There's
pgp
classic,
then
there's
pgp,
you
know
with
with
delegated
trust,
there's
a
way
to
say
you
know,
trust
all
the
trust
delegations
of
this
person.
You
know
it's
it's
really
hard.
You
know
I
had.
I
tried
for
so
many
years
to
sort
of
have.
This
is
how
you
do
it
and,
like
I
said
every
now
and
again,
I
I
prove
myself
wrong
that
this
is
actually
not
how
you
do
it.
It's
got
logic
that
defeats
defeats
my
understanding
of
it.
C
So
this
is
just
to
highlight
that
tofu
trust
and
first
use
is,
is
a
valid
approach
to
this,
and
a
lot
of
developers
are
using
what
we
call
the
direct
trust
relationship.
You
know
you
if
I've
gotten
your
key
into
my
hearing.
I
I
believe
that
I
had
good
reasons
to
put
this
in
my
hearing.
Otherwise,
and
so
I
have
to
trust
it,
you
know
it
would
not
just
automatically
show
up
in
my
queueing,
you
know
I
have.
C
C
So
the
downside,
of
course,
is
that
it
is
easier
to
subvert
tofu
than
the
web
of
trust
right.
So
the
web
of
trust
supposedly
has
a
lot
of
precautions
built
in
that
it's
not
straightforward
to
just.
You
know,
trick
somebody
into
accepting
a
key
and
you're
and
you're
trying
to
support
the
entire
system.
You
know
if
you're,
if
you
know
that
somebody,
for
example,
just
joined
red
hat
and
it's
going
to
be
working
with
linux
kernel,
you
could
send
a
fake
patch
to
the
mailing
list,
saying
hi,
I'm
so-and-so
at
redhead.com.
C
C
It
will
be
a
different
key,
so
pgp
is
going
to
say
well,
something
is
weird,
but
this
is
like
a
way
to
disrupt
the
whole
process
and
maybe,
if
the,
if
the
actual
red
hat
developer,
never
signs
there
any
subsequent
patches,
then
there's
a
way
to
kind
of
trick
this
and
then
send
a
patch
anyway.
So
this
this
is
just
we're
getting
into
potential
abuses
of
this,
and
I
also
can
think
of
many
different
ways
of
supporting
the
actual
web
of
trust
too.
C
You
know
if
nobody's
seen
you
before
you
ask
to
sign
your
key
and
you
show
you
know
how
it's
done.
You
show
your
passport,
the
video
camera.
You
know
it's
impossible
to
tell
if
it's
been
just
printed
out
five
minutes
ago
or
if
it's
actual
document
so
there's
I
I
I
say
it's
easier
to
subvert
than
web
of
trust,
but
not
as
much
as
you
think.
G
Getting
ahead
of
the
whole
presentation,
but
is
there
any
way
that,
for
example,
wkd
can
come
into
play
and
I
will
mention
that
in
the
future?
Yes,
okay,.
C
Cool
yeah,
so
let
me
first
finish
this
other
cryptographic
platforms
using
tofu
is
signal
unless
you
do
the
actual
verification
of
fingerprints
which
is
problematic
because,
usually
when
you
talk
to
people
about
pgp,
they
say
oh
pgp.
No,
you
should
be
using
signal,
you
know,
but
but
this
problem
that
we're
trying
to
solve
is
not
actually
solved
by
signal
either.
C
No
signal
still
uses
trust
and
force
views,
and
you
still
have
to
have
other
mechanism
of
verifying
that
you're
talking
to
the
real
person
with
signal
right,
you
have
to
either
show
the
qr
code
mutually
when
you're
person
to
person
or
you
have
to
call
them
or
have
a
video
conference
and
do
the
same
thing.
So
this
is.
This
is
just
different
way
of
doing
the
same
thing
that
everybody
criticizes.
Pgp
is
doing
wrong,
so
mini-sign
and
signify
are
kind
of
newcomers
to
the
to
the
field.
C
If
you
don't
know
what
signify
is,
this
is
open.
Bsd,
looked
at
pgp
said
this
is
too
hard
we're
just
going
to
do
our
own
ecdsa
elliptic
curve
signatures
they're
very
short,
so
you
can
actually
just
just
paste
them
on
the
website,
and
this
is
also
like
trust
on
first
use
because
the
first
time
you
have
to
get
it
from
the
website
and
and
put
it
in
your
storage
somewhere,
and
then
you
can
trust
that
it
hasn't
been
changed.
But
there
are
other
problems
with
that
too.
C
Let
me
get
to
that
so,
but
there
is
a
kernel.org
web
of
trust
curing
it's
different
from
the
linux
kernel
keyring,
which
does
not
exist
the
colonel.org
web
of
trust
to
get
an
account
of
kernel.org.
We
require
that
your
key
is
signed
by
at
least
two
other
people
who
already
have
an
account
at
curl.org.
C
So
we
publish
the
pgp
keys
that
get
a
repository
where
all
the
keys
are
stored,
and
so,
if
you're,
a
new
person
who
is
just
coming
in
or
you're
going
to
be
a
maintainer
and
you
want
an
accountant.org,
you
can
actually
import
all
those
keys
and
so
you're
delegating
trust
to
me,
I'm
I'm
become
you're
like
the
trusted.
Introducer
we're
talking
in
the
certification
authority
lingual
here.
C
So
this
is
delegated
trust
scenario.
You
can
trace
each
key
to
the
storyboard,
so
you
you
can
sort
of
trust
that
I'm
doing
the
right
thing,
but
you
don't
have
to
you
can
always
verify
you
can
look
through
each
keys.
You
can
trace
the
signature
to
linux
doorbells
and
I
doubt
anybody
actually
does
this
because
I've
been
doing
this
for
a
while.
But
if
you
wanted
to,
I
provide
all
the
mechanisms
to
do
this.
So
usually
it's
not
blind
trust
into
me.
Anybody
can
verify
it.
C
C
G
Cool,
I
also
pasted
one-
that's
probably
similar
for
the
arch
linux
on
the
chat,
if
you're
curious,
to
see
that
one
as
well.
E
Yeah
I
copied
that,
by
the
way
into
our
meeting
notes,
because
I
believe
these
chats
all
disappear
when
we,
when
we
hang
up
all
right.
C
Thank
you
all
right.
Yes,
let
me
go
ahead.
The
honorable
mentions
the
key
servers.
Why
are
we
not
using
key
servers?
Key
servers
are
a
bit
of
a
rotting
mess
because
they've
been
written
by
everybody
uses
the
same
implementation
that
was
written
by
a
phd
student
as
their
phd
thesis
back
in
early
2000s,
and
it
was
written
in
e-lisp
that
nobody
really
understands
and
it
was
an
actual
phd
thesis
and
nobody
understands
how
it
actually
works
and
the
person
who's
written.
This
does
not
care
really
to
continue
maintaining
it.
C
It's
been
fixed
in
pgp,
but
this
is
considered
we're
considering
key
servers
as
really
untenable
they're,
not
that
all
the
replicating
what's
up
replicating
once
the
pgp,
the
pg
still
uses,
and
it's
also
the
design
is
gtbr
non-compliant.
There's
no
way
if
somebody
says
remove
my
data
from
this
key
server.
It's
already
been
replicated
everywhere
and
the
way
it
was
written
is
to
never
allow
any
sort
of
removals.
So
the
I'm,
whenever,
when
gdpr
first
showed
up
a
whole
bunch
of
key
servers
in
europe,
just
went
offline
and
there
was
a
big
destruction.
C
C
C
All
right,
so
the
trouble
that
I
have
the
biggest
trouble
I
have
is:
yes,
we
had
have
this
all
set
up,
but
you
know
how
do
we
educate
kernel
maintainers
that
this
is
available
and
they
should
be
using
this?
So
there's
a
maintainers
pgp
guide
document
known
as
kernel
documentation
that
it
covers
the
topics
like.
Why
do
you
want
to
use
pgp?
How
do
you
properly
secure
your
pgp
key,
where
to
get
other
people's
pgp
keys,
how
to
check
if
the
keys
are
valid
or
not?
You
know
how
to
find
an
imposter.
C
If
you
could,
you
know
what
and
when
to
sign
which
we'll
get
into
the
next
slide,
and
then
this
foundation
sponsors
pgp
hardware,
tokens
for
maintainers
so
like
if
we
had
an
agreement
with
nitro
key
saying
that
they
have
a
kernel.metrickey.com,
I
believe,
which
is
the
shop
front
end
where
the
developers
can
go
if
they
have
a
current
network
email
address
or
if
their
email
address
shows
up
in
the
maintainers
file.
C
They
get
a
free,
nitric
key
start
so
that
they
can
put
their
signature
encryption
keys
onto
into
the
hardware
token
and
removed
from
their
workstations.
It's
not.
B
C
No,
it's
shipped,
so
you
yeah,
you
trust
that
the
this
german
outfit
that
produces
these
does
not
you
know,
do
anything
nefarious.
You
know
you
always
have
to
trust
this
with
hardware
tokens
right.
It's.
G
C
G
C
So
ub
keys
are
proprietary
hardware,
proprietary
software,
everything
about
his
proprietary,
the
nitro
key
start
is
actually
a
good
nook
free
hardware,
the
coping
hardware
chip
that
was
actually
developed
by
fsf,
japan,
I
believe,
and
so
that
we
chose
specifically
because
all
the
software
in
it
is
open
source
and
all
the
hardware
is
all
the
specs
are
available.
C
If
you
trust
that
nitro
key
is
doing
the
right
job
with
it.
Of
course,
we
always
trust
the
manufacturer.
There's
no
way
to
get
out
of
this
okay.
So
what
gets
pgp
sign
right?
So
the
kernel
release
star
balls,
you
know
when,
when
you
go
to
download
the
current
release,
you
go
to
curl.org
and
you
click
on
the
latest
release.
You
take
no
guitar
dot
xz
file
and
you
can
download
the
detached
signature
to
it
and
that
detached
signature
is
actually
in
the
git
note
attached
to
to
the
actual
tag
the
git
tag.
C
It's
so
there's
a
little
wrapper
script
that
greg
hartman
runs
that
will
generate
d-type
signatures
and
put
them
into
git
itself.
So
the
upside
of
this
is
that,
if
you've
mirror
cloned
this
table
get
tree,
you
will
get
all
the
terrible
signatures
and
all
the
tags,
images
and
all
that
stuff.
So
man
lane
mainline
and
stable
git
tags
are
also
bgp
science.
C
These
are
all
these
are
all
signed
by
greg
because
he's
currently
the
person
who's
cutting
all
the
releases
and
also
the
main
line
stable,
mainline
kit
tags
are
assigned
by
the
storyboards.
All
the
tar
balls
are
signed
by
gregor
hartman
because
he's
the
person
who's
doing
all
the
stable
cardboard
releases.
Does
it
make
sense.
C
Okay,
so
pull
request
sent
to
linus
if
there
are
a
tag,
usually
what
people
said.
Please
pull
this
url
and
they
will
be
contained
a
tag.
There
is
a
most
of
them
contain
signatures
on
the
pgp
on
the
git
tags
themselves.
He
only
check
signatures
on
repositories
not
hosted
on
kernel.org
he's
wrong.
I've
talked
to
him
many
times
saying
you
should
not
be
trusting
me.
You
know
trust
trust.
The
developers
do
not
trust
the
infra.
He
is
winning
this
argument
because,
unfortunately,
yes
he's
wrong.
C
C
Yes,
he's
still
against
signing,
he
gets
still
against
signing
commits.
You
know
we
don't
we
don't
enforce
signing
of
commits,
which
is
kind
of
makes
sense.
So
if
you,
if
you
look
at
this
link
here
when
people
curl.org,
I
discuss
what
actually
goes
into
bgp
signature
and
commit.
So
when
you
have
a
pgp
signature
on
a
commit
that
proves
that
everything
below
that
you
know
in
the
history
is
automatically
bid
for
bid
verified.
You
know,
so.
C
H
G
I
also
don't
know
if
it's
worthwhile
mentioning
push
certificates
and
such
because
I
think
that's
the
next
level
of
problems
when
it
comes
to
git
metadata.
C
Right
signing
yeah,
I
wouldn't
touch
in
this
conversation-
the
push
certificates,
because
it's
it's
it's
esoteric,
knowledge
that
most
people
will
not
probably
find
very
useful
here,
but
I
I'm
in
agreement
with
you,
we're
actually
going
to
start
publishing
sort
of
an
audit
feed
of
all
of
the
pushes
to
all
the
repositories
as
a
public
inbox
so
that
you
know
you
can
go
back
and
and
then
we'll
start
publishing
the
birth
certificates
as
part
of
that,
but
we're
not
requiring
or
checking
that
it's
just
going
to
be
sort
of
an
audit
trail,
all
right
and
so
there's
in
addition
to
that,
there's
a
experimental
way
to
sign
patches
so
that
there's
patches
are
not
part
of
a
git
tree.
C
Obviously,
so
you
send
them
to
the
mailing
list
and
the
problem
exists
that
we,
nobody
actually
signs
them.
So
mailing
lists
are
sort
of
untrusted
by
the
day
of
nature.
So
there
is,
there
is
a
way
to
do
it.
Now.
It's
an
experimental
feature.
Extremely
few
people
use
it.
I'd
like
to
convince
more
people
to
start
using
it
it.
C
Actually,
it
does
not
modify
the
patch,
it
doesn't
detach
signatures
sent
to
a
different
mailing
list
and
it's
sort
of
a
collection
of
hashes
that
verifies
the
metadata
of
the
patch
sort
of
like
who
it's
from.
What's
the
subject
of
it,
also
the
message
on
it
commit
and
the
actual
the
code
that
is
in
the
commit
and
the
tool
that
I
wrote
for
this
is
called
b4.
This
is
for
working
with
patches
and
the
mailing
lists,
and
it
will
verify
if
this
data
is
available.
C
H
G
H
G
I
think
there
was
a
couple
of
question
marks
right
there,
but
I
think
it's
also
a
very
interesting
feature.
You
know,
if
that's
going
anywhere,
do
you
think
that
would
be
desirable
and
just
like
in
the
sense
of
like
b4
being
natively
supported
and
the
impact.
C
I'm
not
sure
yeah,
I'm
not
sure
about
natively
supporting
it.
The
trouble
with
with
this
strategy
is
has
been
pointed
out
to
me
by
multiple
maintainers
saying
that.
Well,
if
we
preserve
the
signature,
unfortunately,
when
when
a
series
is
sent
to
maintainer,
a
maintainer
was
almost
always
modified
in
one
way
or
the
other
like
they
will
add,
sign
off,
buys
they
will
add,
they
can
change.
Subject,
they
can
change.
You
know
my
new
things
about
the
the
structure
of
the
actual
code.
They
may
like
remove
spurious
semicolons
or
new
lines.
C
C
The
maintainers
will
have
to
not
make
any
of
those
changes
and
the
maintenance
life
actually
will
become
harder
because
they
would
have
to
say
you
know
you
have
a
new
line
here.
Please
resubmit,
and
this
would
be
too
much
back
and
forth.
It
is
much
quicker
and
easier
for
maintainers
just
to
say
you
know.
Well,
I'm
just
going
to
make
this
edit
right
now
and
since
it
does
not
change
the
logic
of
the
co
of
the
sign
off,
still
still
stands.
C
So
there's
that's
where
discussions
have
led
and
the
reason
we
haven't.
I
haven't
really
investigated.
Any
further
is
because
most
of
the
maintainers
for
the
linux
kernel
at
least
specifically
said
that
this
is
not
a
useful
feature
for
them
to
have
anything
like
that,
because
they
almost
always
modify
patches
either
the
code
or
the.
C
Metadata
of
the
commit,
because
the
date
would
be
different
like
and
the
sign
off,
buys
all
the
taglines
will
be
different,
so
that
yeah
of.
C
All
right
we're
coming
up
to
the
end,
so
is
this
whole
setup
working
right
this
this
I've
described
this,
so
it
is
up
to
each
maintainer
to
enforce
cryptographic
attestation,
we're
not
we're
not
enforcing
this.
I
mean
linus
enforces
this
for
pull
requests
to
receive
from
outside
of
pearl.org.
C
C
Sub-Maintainers,
as
far
as
I
know,
some
of
them
require
that
the
tags
are
signed,
or
some
of
them
are.
I
think,
like
one
of
them
is
requiring
the
patches
assigned
using
the
station
mechanism
that
I've
suggested,
but
it
is
very,
very
small,
subset
of
code,
that's
that's
being
processed
and
received,
and
I
can
attempt
to
gather
data
on
how
widely
it
is
used.
Like
the
entire
cryptographic
illustration
of
pull
requests.
C
For
example,
I
expect
the
results
will
be
extremely
disappointing,
which
is
why
I
haven't
yet
done
it
because
it
will
just
sort
of
wet
my
blanket.
So
I
don't
want
to
do
it.
I
want
to
pretend
that
this
is
actually
going
somewhere
and
to
point
out.
A
lot
of
my
data
is
actually
actively
pushed
back
against
sort
of
this
cryptographic
at
the
station
of
code
they
receive
and
their
argument
is
valid.
C
They
say
you
know,
we
must
assume
that
attackers
have
state
level
budgets
are
able
to
coerce
people
or
steal
pgp
keys
right,
so
they
they
can
go
and
steal
ptpk
from
a
hardware
device
or
from
a
from
a
laptop
or
just
coerce
a
developer
threaten
their
family.
You
know
give
them
big
bribes,
so
if
we
place
too
much
trust
into
cryptographic
signatures,
then
we
are
going
down
the
wrong
path,
all
the
code
that
I
several
maintenance
told
me
all.
The
code
must
be
taken
at
face
value
and
it
seems
to
be
malicious.
C
So,
regardless
of
any
prior
contributions
by
the
developer
or
any
kind
of
signatures
or
anything
on
it,
they
said
you
know
what
we
want
to
always
treat
the
code
as
it
was
sneaked
and
snuck
sneak
sneaked
in
by
by
a
malicious
party.
Obviously
this
doesn't
scale
all
the
way
up
right.
So
venus
cannot
possibly
go
through
the
entire
code,
which
is
why
he
does
rely
on
cryptographic
signatures
from
top
level.
Maintainers
yeah.
I
I
You
know
the
this
trust
web
exists
in
the
kernel,
but
that's
not
really
where
the
trust
lies
right.
The
trust
lies
in
the
review
process.
Right.
You
know
most
maintainers
the
code
they're
committing
didn't
come
from
them
for
the
most
part,
so
this
is
sort
of
the
final
firewall.
It's
not
the
primary
trust
mechanism.
C
Right
so
it's
really
which
which
one
is
harder
to
do
right
for
an
attacker.
Is
it
harder
to
steal
their
cryptographic
stuff,
or
is
it
harder
to
sneak
in
a
code
that
people
are
just
going
to
miss,
because
you
know
c
is
fairly
easy
to
obscure
so
missing
semicolon
there
and
suddenly
the
entire
logic
is
different
or
you
different,
follow
through
right,
they're
trying
to
address
this
in
the
code
itself.
But
I
mean
it's
a
valid
valid
observation
by
maintainers,
which
is
why
a
lot.
C
I
G
C
C
G
G
No,
no,
the
point
that
I'm
trying
to
make
is-
and
you
said
it
it's
it's
easy
to
office
kc
code
to
make
it
to
make
it
look
behind,
but
it
can
be
malicious.
I
think
the
the
brother
point
and
is
that
we
need
both.
G
We
probably
need
to
minimize
impact
of
a
merge
that
was
not
properly
reviewed
like
another
anecdote
is
hardly
it
was
merged
on
new
year's
eve
of
2012
or
something
like
that
where
everybody
was
either
a
hangover
or
really
wanted
to
go
out
celebrate
there
can
be
situations
like
this
and
I
think,
putting
handrails
or
guardrails
everywhere
is
like
something
we
should
strive
for
right.
C
Yeah,
I
agree
well
when
people
bring
up
this
argument
that
you
know
we
shouldn't
be
trusting
pgp,
I
said:
well,
there's
nothing
preventing
you
from
doing
both
right
have
a
sort
of
initial
level
of
check.
You
know
this
is
actually
failing
signature
or
this
is
actually
passive
signatures
give
it.
No,
you
know,
give
it
no
level
of
trust,
but
just
sort
of
a
way
to
cut
off
the
lazy
attacker
right.
You
know
you
haven't
even
done
your
homework,
so
I'm
not
even
going
to
pay
attention
to
you,
but
then
you,
then
you
review
the
code.
C
D
On
a
related
note,
I
just
dropped
a
link
into
the
chat.
I
just
yesterday
was
made
aware
of
a
hackathon
that,
where
someone
was
working
on
some
artificial
intelligence
to
see
if
the
code
that
someone
commits
recently
matches
other
commits
by
that
person
in
the
past,
so
that's
a
way
to
see
if
it
gets
at
the
you
know,
nation
state
or
someone
stealing
a
gpg
key
or
something.
G
Sure
so
metric
checker
for
patches,
yeah,
yeah,
interesting.
C
Yeah
we
should
be
aiming
to
make
the
life
of
attacker
more
complicated
right,
make
have
more
chicks,
have
more
things
they
have
to
defeat,
instead
of
just
you
know,
being
as
lazy
as
just
sending
a
fake
from
to
a
mailing
list
and
then
just
defeat
this
by
volume.
Instead
of
effort,
all
right
so
get
tags,
entire
ball
signatures
are
checked.
You
know
there
was
a
couple
of
times
when
the
back
end
process
didn't
do
the
right
thing
and
the
the
tarball
didn't
match
the
signatures
immediately.
C
E
C
Yeah
sure
I
believe
it's
already
an
attachment,
but
I'll
place,
the
the
actual
url
in
the
presentation.
It's
open
to
anybody
with
a
link
so
you'd
be
able
to
get
to
fabulous.
Thank
you
yeah.
I
think.
That's
it
yeah!
So
q,
a
you
know,
it's
pgp,
quantum
proof!
No
and
either
bitcoins.
You
fools
that's
my
usual
answer.
C
E
G
C
So
so
the
if
you
look,
I
think,
there's
a
link
provided
to
people
caroline
or
sort
of
my
let's
see
where
it
is
because
all
right,
you
you'll,
find
it
so
that
I
talk
about
you
know
when
we
sign
the
tags.
Does.
That
is
what
what
about
the
xiaowan
signatures,
which
I
want
hashes
that
right
there
that
the
git
uses,
and
it
is
actually
not
as
far
as
we
know,
it's
not
yet
possible
to
have
an
attack.
C
That's
been
that's
done
on
shawwan
and
then
have
it
succeed
in
git
because
of
the
precautions
that
get
already
put
in
place.
There
is
a
show
on
collision
detection,
for
example,
that
is
in
git
code
and
there's
it's
just
not
as
easy
to
do
it
in
kit,
as
opposed
to
like
to
padding
a
pdf
file.
This
is
this.
Is
this
is
harder
than
you
think,
but
yes,
there
is
work
and
get
to
move
away
from
xiaowan.
C
Unfortunately,
when
git
was
written,
this
was
kind
of
assumed
that
this
was
going
to
be
forever
and
which
was
the
wrong
assumption
in
the
first
place.
But
this
means
that
changing
it
would
require
sort
of
a
flag
day
for
repository
or
have
basically
two
repositories
existing
in
the
same,
at
the
same
time
where
every
one
one
sets
of
commits
is
used
using
one
hashes
with
the
other
one
using
chat,
56
or
any
other
hashing
mechanism
that
you
choose.
C
G
Yeah
yeah.
I
also
made
an
analysis
back
when
the
everything
came
out
and
with
the
quote
churn
happening
on
the
linux
kernel
by
the
time
you
collide
a
file
or
like
a
commit,
it
will
be
like
or
a
blob
to
to
be
exact.
It
will
likely
be
replaced
by
a
new
one
so
that
you're
back
to
zero.
You
will
be
able
to
replace
it.
I
have
some
graphs
around
if
anybody's
interested.
In
that
I
think
for
most
of
the
popular
repositories.
G
I
found
that
you
can
just
collide
a
readme
file
or
a
license,
which
is
it's
an
interesting
academic
attack,
but
nothing,
nothing
really
scary.
Just
yet
right.
C
Right
if
we
go
back
to
the
topic
sort
of
before
the
genitives
and
yeah
I
mean
I
can
talk
about
git
and
sha
and
pgp
like
a
lot
and
you'll,
be
asking
me
to
shut
up,
but
you
can
go
back
to
the
the
developer
identity.
Any
other
questions
about
that
specifically.
E
I
I
did
you
mentioned,
there's
a
url,
can
can
you
post
that
or
where,
where
is
that
yeah.
A
C
I
have
I
have
no,
I
mean
I
don't
check.
How
would
I
check
now?
How
would
I
know
that
I
got
somebody
or
not
right.
I.
C
A
C
I
guess
yeah
make
it
make
it
scary
to
even
try
right,
you
know,
make
it
well,
they
will
probably
almost
certainly
catch
it.
You
know,
that's
that's
how
I
at
least
try
to
do
it.
So
I
see
that
somebody
put
bases
out
of
the
hybrid
server
it
also
strips
third-party
signatures,
which
is
not
acceptable
for
us.
You
still
kind
of
basically
trust
the
administrators
of
that
server
that
they're
not
doing
anything
malicious.
We
are
trying
not
to
delegate
trust
to
infrastructure.
C
This
is
like
the
whole
ever
since
the
2011
kernel
org
break
in
the
mantra.
For
me
at
least
saying
you
know,
do
not
trust
intro
to
not.
They
have
trust,
is
in
developers
never
network
infrastructure.
So
anytime
there's
a
solution
that
says:
oh
here's
a
way
to
do
it,
but
you
have
to
trust
the
server
to
be
uncompromiseable.
Then
it
is
not
an
acceptable
solution
for
us.
C
So
key
rotation
or
expiration
extensions.
You
know
with
the
pgp
the
way
I
said,
if
you
added
a
new
key
or
if
you
extended
expiration
date
or
added
a
new
sub
key,
you
send
a
here.
There
is
there's
documentation,
saying
how
to
do
it.
They
just
send
an
email
to
the
mailing
list
with
the
key
export
and
then
I
process
it
and
they
make
my
judgment.
C
C
Yeah
I
haven't
in
my
10
year,
you
know
experience
doing
this.
I
haven't
seen
a
single
revocation
people
just
stop
using
the
key
they
which
is
not
what
you're
supposed
to
do.
But
you
know
almost
nobody
preserves
the
revocation
certificates
that
pgp
create.
You
know
create
on
key.
I
Generation
yeah,
I
think
the
only
other
thing
I
would
bring
up
is
that
that
that
the
method
of
of
having
your
your
key
off
by
two
people
with
keys
already,
is
sort
of
based
on
the
idea
that
people
see
each
other
at
conferences.
Given
the
world
right.
C
We
kind
of
relax
that
rule
saying
you
can
do
the
video
call,
and
I
always
stress
that
you
know
we're
not
trying
to
verify
your
government-issued
energy
right.
We
just
want
to
say
this
person
is
working
with
this
maintainer
and
this
maintainer
knows
them
as
joe
doe
right
and
then
you
know,
you're
signing
this
as
verifying
that
yeah.
C
I
believe
this
person
is
joe
doe,
because
when
I
talked
to
them
the
information
got
back,
confirmed
to
me
that
you
know
you
know
the
harry
potter
idea
of
you
know
what
was
in
my
in
my
tank
when
you
saw
me
two
years
ago,
when
you
entered
my
room,
it's
kind
of
same
idea,
sort
of
make
sure
that
this
person
is
who
they
say
they
are
without
relying
too
much
on
government
issued
empty
documents.
F
D
D
What
would
that
entail?
It
might
be
too
much
to
think
of
in
in
just
these
few
minutes,
but.
C
C
C
There's
a
way
to
do
this,
and
then
you
can
use
the
verification.
This
way,
sort
of
trust
get
use
github
as
your
key
server.
Basically
you
can
you
can
get
people's
keys
from
there.
Unfortunately,
everybody
has
misunderstanding
of
why
pgp
is
terrible.
The
gp
is
terrible
not
because
of
a
problem
with
pgp
itself.
It's
terrible
because
delegated
trust
is
terrible.
This
is
a
hard
problem
to
solve.
There's
no
easy
and
simple
solutions
to
this,
and
everybody
just
thinks
this
is
a
problem
with
pgp,
but
it
is
a
problem
with
any
mechanism
of
delegated
trust.
C
You
either
have
a
central
authority
that
you
delegate
this
all
to
like
the
cas
with
the
tls
world,
the
dns
sec
with
the
dns
sort
of
part.
These
are
two
major
ones
or
you
have
to
jump
through
hoops
that
everybody
misunderstands
and
everybody
says
wow.
This
is
so
hard.
Why
does
it
suck
so
much,
but
it
does
not.
It's
not
a
problem
with
tools.
It's
a
problem
with
the
problem
is
being
hard.
G
C
G
Will
add
that
the
gpg
like
cli
is
a
little
confusing
and
that
there's
no
like
blessed
yeah
library?
For
it
I
mean
that's.
C
A
A
All
right,
so
we
only
have
like
nine
minutes
left
I'll
just
cover
up
some
last
things.
I
guess
I
added
a.
I
found
this
presentation
really
helpful
again.
I
just
want
to
mention
I
added
a
list.
H
A
The
top
of
ideas
for
future
presentations.
If
anybody
wants
to
hear
a
similar
topic
from
another
project-
and
maybe
you
have
a
point
of
contact-
we
can
reach
out
to
add
that
up
there
and
we'll
go
ahead
and
try
to
schedule
them.
I
think
these
are
really
useful.
A
Somebody
from
the
chromium
team
at
google
mentioned
that
they'd
be
up
for
doing
something
like
this
on
how
they
manage
chromium,
which
is
different
kind
of
open
source
project.
Yes,
so
yeah
type
stuff
up
there
if
you're
interested
or
have
ideas,
we
did
case
follow-up
already
from
the
agenda.
A
A
I
think
the
next
step
once
things
slow
down
and
people
stop
adding
new
ones,
is
for
us
to
review
and
kind
of
categorize
and
prioritize
and
figure
out
which
ones
we
think
we
can
actually
improve
and
make
progress
on
in
this
working
group,
a
bunch
of
people
added
links
to
other
kind
of
collections
of
threats.
So
I
tried
to
merge
some
of
those
in
that
we
didn't
already
have
like
santiago,
has
a
big
list
of
them
in
a
cncf
security,
repo
of
actual
attacks
that
happened.
A
So
I
just
wanted
to
call
that
one
out
anything
else.
Anybody
else
wanted
to
cover
today.
D
Has
anyone
looked
at
how
this
effort
we're
doing
in
this
group
maps
to
the
work
that
was
done
in
the
there's
in
the
security
threats
group?
The
document
that
michael,
what's
his
last
name,
yeah.
A
A
I
think
the
difference
is
we're
not
trying
to
actually
come
up
with
and
publish
a
list
of
all
these
threats,
we're
just
trying
to
catalog
the
ones
that
we
want
to
tackle.
His
dock
was
kind
of
identifying
threats
across
all
like
a
whole
bunch
of
different
threats
across
open
source
projects.
Just
to
make
people
aware.
A
Right
yeah,
there
were
a
couple
other
things
like
that
that
we
found
here
list
of
these
david
had
a
bunch
in
his
course
two
that
I
reviewed
and
merged.
A
B
No,
I
think
I
think
you
covered
it.
I
think
we
yeah
we
can
save
the
scope
discussion
for
next
time
or
maybe
just
split
up
into
a
small
subgroup
and
work
on
that
doc,
for
the
talk
together
seems
like
a
good
plan
to
me
for
those
interested
yeah.
That's
it
from
my
side,
any.
E
Get
is
the
lead
for
this
working
group
dan
or
I
don't
my
pa
or
kim
or
my
apologies.
If
I
don't
know,
I'm
trying
to
still
trying
to
figure
out
who's
here.
B
Yeah
I
mean
we
have
a
facilitator
section
at
the
top
right
now,
which
is
dan,
and
I
and
just
tag
teaming.
You
know
for
people
that
are
also
interested
in
facilitating
the
meetings.
That's
great.
We
want
to
be
leads
open,
open
to
everyone
david.
I
think
you're
volunteering
so
feel
free
to
add
your
name
at
the
top
up.
There.
B
Yeah,
I
think
yeah,
I'm
not
sure
I
think
you
know
we're
just
getting
off
the
ground
now
so
once
we
get
to
sort
of
that
threat
document
and
figure
out
what
we're
going
to
tackle
first-
and
you
know,
I
think
the
meetings
might
change
slightly
to
be
more.
You
know
about
actual
work,
that's
being
done
as
opposed
to
trying
to
learn
how
scary
the
world
is.