►
From YouTube: Digital Identity WG 2020 (October 28, 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).
B
All
right
so
recording
just
started,
and
today
we
have
a
presentation
from
damien
on
ssh
signing
and
get
so
thanks
for
everybody
that
noticed
the
calendar,
change
and
stuff.
I
got
pinged
by
about
three
people
during
the
normal
time
today
asking
if
the
meeting
was
happening
or
not
so
somehow
some
people
missed
that
I'll
send
out
a
link
to
the
recording
after
you
want
to
get
started,
amy
sure.
Let
me
just
go.
A
A
E
A
F
D
F
C
A
Cool,
so
just
by
way
of
introduction,
I'm
a
tech
lead
manager
at
google
who's
done
some
work
in
open
source
supply
chain,
I'm
also
a
maintainer
of
open
ssh.
So
I'm
very
much
speaking
with
the
first
hat
on
today,
though,
the
work
that
the
work
that
I'm
talking
about
does
cut
across
both
to
some
extent.
A
So
this
is
a
talk
about
what
I'd
like
to
do
with
with
signing
in
git,
and
it's
really
centered
around
like
this
vision,
which
I
think
is
an
important
one
for
supply
training
supply
chain
attribute
attribution,
and
I
said
every
every
object
and
every
line
of
code
in
a
repository
can
be
attributed
back
to
its
author
and
ideally
from
something
that
can't
triply
be
stolen.
Like
a
hardware
route
of
trust.
A
I
think
this.
This
sets
the
stage
for
all
sorts
of
things
that
come
after
the
source
code
reaches
someone
who
depends
on
it,
and
I
think
it's
a
precondition
for
for
addressing
a
lot
of
the
the
problems
in
the
security
supply
chain
for
open
source
software.
A
Why,
at
a
broad
level,
cryptographic
signatures
prevent
tampering?
You
know
there's
caveats,
of
course,
around
the
life
cycle
of
keys,
etc,
but
having
having
signatures
is
generally
superior
to
not
having
signatures
or
things
being
equal
being
able
to
attribute
code
back
to
developers,
prevents
a
developer
impersonating
another,
and
you
know
pushing
changes
that
report
to
be
from
someone
who
who
they're
not
without
you
know,
being
able
to
be
detected
and
that
attribution
also
lets
us
draw
a
line
around
a
bad
actors
contributions.
A
So
when,
when
someone
turns
out
to
have
done
something
bad,
we
can
identify
to
you
know
the
extent
of
that
badness
and
and
cut
it
out
or
you
know,
take
remedial
action
or
you
know,
do
forensic
do
forensics
on
that.
I
think
also.
A
You
know
more
broadly
that
when,
when
in
the
in
a
world
where
developers
actions
are
attributable
back
to
them,
it
gives
them
a
bit
more
skin
in
the
game
and
raises
the
cost
for
a
persistent
attacker
for
to
create
an
identity
that
you
know
injects
malice
in
somewhere.
If
they
know
that
identity
is
going
to
be
burned
as
soon
as
that,
malice
is
discovered,
and
I
think
attribution
you
know,
attribution
is
a
key
element
to
you
know
being
able
to
to
get
to
that
state.
A
I
mentioned
the
hardware
roots
of
trust,
because
that
that's
an
element
that
deters
theft
of
keys
or
you
know,
prevents
theft
of
keys.
In
the
ideal
case,
if
a
key
can
be
stolen,
you
know
by
a
client-side
bug
on
a
developer's
workstation.
A
Then
you
know,
then
that
attribute
attribution
story
falls
apart
very
quickly,
and
you
know
that
that
sort
of
attack
occurs
with
some
regularity
built.
Putting
the
putting
the
key
into
a
hardware
route
of
trust
means
that
that
the
attacker
can
only
steal
use
of
the
key.
You
know
and
subject
to
all
the
caveats
of
of
being
able
to
do
that
that
you
know
they've
got
to
be
on
device
with
their
victim.
They've
got
to
be,
you
know,
get
there,
get
their
actions
hidden
from
the
victim
and
they're.
A
You
know
they're
only
as
trustworthy
as
the
source
code
that
that
they
take
as
input
so
improving
improving
that
trustworthiness
of
the
sources
has
ripple
on
a
ripple
on
effects
all
the
way
down
to
consumers,
and
that's
why?
I
think:
that's
why
I
think
getting
you
know
getting
the
trustworthiness
of
source
code.
Improved
is
is
important.
A
So,
what's
missing
now
one
of
the
you
know,
one
of
the
key
things
is
that
most
developers
don't
sign
their
code
in
their.
You
know
in
a
general
sense,
it's
relatively
common
to
sign
tags
and
releases
in
git
repositories,
but
not
so
much
to
sign
every
commit
and
even
rarer
to
use
the
push
signature
feature
in
git.
A
Now
I
I
attribute
this
in
in
some
part
to
the
difficulty
of
use
of
open
pgp.
It's
got
a
you
know,
there's
there's
been
multiple
papers
written
about
how
its
trust
model
is
difficult.
You
know
the
series
of
why
johnny
can't
encrypt
papers
by
elmer,
whitton
and
and
co.
A
There's
there's
no
there's
no
direct
linkage
of
gpg
identities
with
repository
identities
in
practice,
most
repositories
build
that
as
a
you
know
as
a
feature.
So,
for
example,
github
lets
you
register
pgp
keys
and
hardware
support
within
most
pgp
tools
requires
pkcs
11
tokens,
which
generally
require
in
turn
middleware
and
daemons
and
and
additional
configuration
as
well
as
being
relatively
expensive.
A
Another
another
thing
that's
missing.
Pardon
me
is
a
wider
life
cycle
story
around
signatures
within
git.
So,
if
I
excuse
me
when
I
clean
my
throat.
A
If
I,
if
I
take
a
contribution
by
rebasing
it
or
rolling
it
squashing
it
into
a
single,
commit
and
applying
it
to
my
tree,
then
any
signatures
on
on
the
the
objects
that
contributed
to
that
commit
are
lost.
So
these
operations
are
relatively
common
and
and
exist
for
good
reasons.
A
Not
everything
in
git
can
be
emerged.
For
example,
I
think
practically
so
a
story
around
preserving
signatures
across
those
mutations
is
is
another
thing.
That's
missing
at
the
moment.
A
My
my
proposal
here
is
teaching
git
about
ssh
signatures
and,
basically
making
it
a
peer
signing
method
to
open
pgp
signatures,
as
they
are
at
the
moment,
and
my
rationale
is:
is
this
that
ssh
is
basically
everywhere
you
get
if
you
install
a
general
purpose
computing
device,
you
have
the
open,
open,
ssh
and
its
client
tools
almost
certainly
installed
be
that
on
windows
mac,
certainly,
linux,
bsd,
etc.
A
The
trust
model
for
ssh
is
very
simple,
and
developers
are
very
familiar
with
it.
It's
flat,
it's
you
know,
comprehensible,
there's!
No,
you
know,
friends
of
friends,
type
explanations
that
need
to
happen
there.
A
Most
developers
already
interact
with
with
their
git
repositories
via
ssh,
so
there's
already
a
trust
relationship
there
they're
already
using
the
tools,
they're
already
familiar
with
the
tools
to
some
extent
and
consequently,
repository
hosts
already
maintain
user's
keys
at
their
end,
and
they
already
maintain
some
sort
of
mapping
from
those
keys
to
user
identities.
So
it
seems
to
me,
like
all
of
the
pieces
of
a
wider
identity
story,
are
already
in
place.
A
A
So
as
as
far
as
implementing
this
vision
of
of
making
ssh
signatures
capable
of
get
capable
of
using
ssh
for
signatures,
we've
taken
some
steps
and
there's
some
steps
left
to
take.
At
the
moment.
A
This
is
built
in
if
you're
familiar
with
the
open,
ssh
tools,
it's
built
into
ssh
keygen,
and
allows
signing
and
verification
of
messages
with
a
very
simple
trust
model
that
should
be
familiar
to
most
users
of
the
ssh
authorized
keys
like
file
that
maps
identities
to
to
keys,
and
it
supports
name
spacing
of
signatures.
A
A
Where
you,
you
know
you,
the
attacker
creates
an
ssh
server
that
gets
the
user
to
sign
something
that
looks
like
an
authentication
request,
but
is
actually
a
you
know,
git
commit
so
that
that's
those
sort
of
attacks
are
frustrated,
and
this
is
this
is
really
designed
to
be
as
familiar
to
ssh
users,
as
as
all
the
other
tools
you
know,
the
keys
are
just
ssh
keys.
You
can
stick
them
in
an
agent,
you
can
use
a
certificate,
you
can
stick
them
in
hardware
and
they
all
just
work
kind
of
as
normal.
A
In
in
this
case,
the
identity
is
a
a
utf-8
username,
which
is
basically
unconstrained
by
the
ssh
side
of
of
tools.
So
it
can
be,
it
could
be
a
user
at
the
main.
It
could
be
a
username,
it
could
be
a
you
know
anything.
Basically,
this
does
not
prescribe
a
particular
identity
model,
it's
just
it,
but
it
proves
it
provides
the
the
glue
by
which
you
can
build
a
system.
A
Getting
getting
hardware
back
to
keys
ubiquitous
is
another
challenge
like
like
gpg.
Openssh
has
supported
pk
sys11
tokens
for
over
10
years,
but
these
tokens
are
generally
comparatively
expensive.
I
think
they've
come
down
hugely
in
price
in
recent
years,
but
you
know
you're
still
looking
at
you
know,
50
bucks
per
token,
maybe
maybe
30
at
the
low
end
and
they're
they're
more
fiddly
to
set
up
you.
A
You
have
to
install
middleware
that
talks
to
the
cards
or
you
know
they
come
out
of
a
they
come
out
of
a
model
that
is
smart
card
based
and
inherits
a
lot
of
baggage.
From
that,
I
think
there's
some
simplification
in
progress,
but
it's
not
you
know
it's
incomplete
so
early
this
year,
open
ssh
added
support
for
fido,
slash,
u2f
keys,
which
is
a
you're
probably
familiar
with
it.
But
if
not
it's
a
authentication
model
that
was
designed
for
the
web.
A
That
uses
basically
splits
the
key
into
a
hardware
resident
part
and
a
part
that
lives
either
on
the
outside
the
key
and
combines
those
at
the
time
of
signature
to
to
derive
the
real
key
because
they
require
very
little
storage
on
device.
They
can
be
much
much
more.
They
can
be
much
cheaper
than
pkcs11
keys.
A
I
think
that
the
low
end
you
can
pick
up
a
phyto
token
for
less
than
10
us
dollars,
they're
quite
simple
to
use.
They
have
a
lightweight
specified,
usb
protocol
to
speak
to
them
that
doesn't
require
complicated
support
and
they
they
generally
configured
to
require
that
the
user
touched
or
tapped
them
once
per
signature
operation,
and
this
this
is
a
really
nice
feature
with
to
deter
theft
of
use,
attacks
against
the
user's
keys,
because
the
user
actually
has
to
physically
authorize
a
signature
under
most
circumstances.
A
So,
even
if
an
attacker
does
obtain
code
execution
on
their
victim's
machine,
they
have
to
you
know:
fish
fido
touch
events
to
to
get
them
to
do
to
authorize
things
within
ssh.
It
acts
just
like
any
other
key
type.
You
can
add
them
to
authorized
keys.
You
can
stick
them
in
an
agent.
You
can
afford
them.
You
can
authenticate
with
them.
You
can
even
use
them
as
host
keys.
A
Well,
the
next
now
we
move
from
the
stuff
that
we've
done
to
the
stuff
that
we
haven't
done,
the
stuff
that
we're
optimistically
yet
to
do,
and
that
is
generalizing
git's,
signing
interface,
git's
cryptography
code
is
I'd,
say
organically
built
around
the
expectation
of
talking
to
gpg
and
those
assumptions
run
fairly
fairly
deep.
A
There
was
a
last
year
there
was
a
an
internship
at
the
linux
foundation
that
started
to
to
pull
these
apart
and
really
abstract
the
signing
and
verification,
and
all
the
you
know,
some
of
the
identity
code
from
being
just
gpg,
centric
to
being
actually
pluggable.
A
So
I
think
the
the
motivating
case
was
a
system
called
hyperledger,
but
the
work
was
going
to
be
just
as
usable
by
us
or
by
anyone
else
who
needed
to
build
a
new
signing
interface
into
git,
unfortunately,
that
internship
finished
without
without
getting
that
work
getting
upstreamed,
but
I
think
you
know,
even
even
if
you're
not
interested
in
ssh
signatures
in
git.
I
think
this
is
important
work
because
it
it
facilitates
the
experimentation
and
and
and
also
cleaning
up
the
interfaces
within
git
for
for
other
other
cryptography.
A
A
Actually
getting
get
to
use
these
use
ssh
as
a
signer
is
is,
would
be
the
next
step
after
that.
F
A
A
A
I
think
look
I
I
I
think
any
any
competency
developer
could
could
could
do
this,
so
I
don't
think
it
comes
down
to
a
person,
but
the
right
person
means
less
funding,
and
you
know
someone
who's
got
to
come
in
come
into
it,
without
that,
prior
knowledge
would
take,
would
have
a
longer
ramp
up
time.
Of
course,.
B
A
The
from
my
understanding-
and
I
was
at
the
end
of
the
game
with
telephone
here-
yes
gavin-
I
believe
that
the
worker
didn't
land
because
they
ran
out
of
time.
Yeah.
Sorry,
sorry,
I
got
distracted.
What
was
your
question
again.
B
I
was
basically
the
same,
I
guess
as
gavin's.
There
wasn't
push
back
from
the
maintainers
or
anything
like
that.
It's
really
just
a
matter.
A
No,
we
think
with
with
caveats
they
I
think
they
were
fine
with
it.
I
think
you
know
for
my
conversations
with
with
some
of
the
git
maintainers
who
work
at
google.
They
are
very
receptive
to
any
sort
of
patches
that
improve
their
internals
subject
to
the
caveats
that
they're
thoroughly
tested,
etc,
etc,
which
you
know
good
good
stewardship
stuff.
There
was
no.
There
was
no
in
principle
pushback
to.
A
This
I'll
move
on
as
far
as
getting
ssh
to
actually
use
this,
that
writing
that
glue
is
quite
trivial.
We've
we've
designed
the
ssh
signature
support
around
the
needs
of
of
what
we
expect
it
to
use.
It
supports
the
operations,
including
some
of
the
more
esoteric
ones
like
checking
a
signature
validates
without
actually
tying
it
back
to
a
user
principle,
which
is
an
operation
that
git
does
at
some
points.
A
So
we've
done
our
best
to
anticipate
the
needs
of
of
a
pluggable
interface
within
ssh,
so
getting
that
getting
that
basic
glue
between
ssh
and
git
is
is
quite
simple.
There
is
a
wider
story
of
actually
making
it
usable
within
the
context
of
repositories
and
that
that's
really,
you
know
tying
up
the
identity.
Loop
of
you
know
an
identity,
who's
the
identities,
that's
signing
the
key
matching
that
to
an
identity.
In
the
repository
of
a
you
know,
a
trusted
pusher.
A
As
I
mentioned
previously,
git
servers
already
have
ssh
keys
for
for
user
accounts,
be
they
system
accounts,
or
you
know,
user
accounts
in
the
in
the
sense
of
github,
for
example,
so
that
that
information
already
exists
at
some
level.
It's
just
tying
that
all
up
and
making
it
making
it
usable
would
be
is
the
is
the
part
there.
A
There
are
some
questions
about
what
have
the
co-existence
of
signatures
if
someone
signs
a
a
commit
with
both
gpg
and
ssh,
then
that
that
seemed
to
be
okay,
when
we
were
looking
at
it
that
they,
both
just
they
just
both
text
strings
attached
to
the
to
the
object
that
was
being
signed,
and
it
seemed
that
that
git
would
deal
with
that.
But
you
know
we
have
to
be
sure,
because
you
know
we
do
need
these
things
to
co-exist.
There
are
active
use.
A
Cases
depend
on
gpg,
signatures
that
we
must
not
disrupt,
but
we
also
want
to
enable
new
stuff,
so
they
have
to
co-exist
a.
F
Quick
quick,
additional
question:
is
there
any
objection
to
including
the
key
the
public
keys
within
the
repo
itself
so
that
anybody
later
can
verify
you
know
who
signed
which.
A
I
don't
think
there's
any
any
security
reason
why
you
wouldn't
do
that.
I
believe
that
github,
for
example,
allows
you
to
query
the
ssh
key
of
any
user
identity
on
the
system,
regardless
of
authentication.
So
that
seems
to
be
a
you
know:
a
decision,
that's
that
they've
made
that
that
that's
not
the
case,
and
I
I
don't
see
a
problem
problem
with
that.
I
think
it's.
A
I
think
to
to
actually
to
achieve
this.
End-To-End
attribute
attribution
you.
You
really
need
to
be
able
to
do
that.
B
F
B
Like
allowed
pushers
or
allowed
committers
in
that.
F
Repository
or
something
I
really,
I
think
I
don't
think
necessarily
it's
for
security
access,
I'm
thinking
more
in
terms
of
being
able
to
verify
later
on
the
linux
kernel
developers,
for
example,
generally
don't
use,
they
don't
use
github,
they
don't
use,
get
lab
they're
using
email
and
then
the
question
is:
how
do
you
verify
later?
Well,
if
it's
in
the
repo,
then
there's
no
problem
finding
out
which
keys
apply
to
which
people.
A
So
they
are
to
you
know
if
you,
if
you,
if
you've
not
if
that
mapping
doesn't
explicitly
exist
within
a
repository,
you
still
see
the
purported
identity
and
the
key
that
was
used
to
sign.
But
you
know,
there's
no,
there's
no
trusted
repository
host,
saying
yes,
they
are,
they
are.
They
are
one
together,
but
you
can
you
could
you
know,
for
example,
attempt
to
you
know,
extract
that
in
retrospect,.
A
And
the
final
piece,
I
think,
is
a
wider
discussion
around
cryptography
and
git.
I
think
you
know
the
I've
mentioned
that
the
the
approach
to
cryptography
and
git
seems
fairly
organic.
You
know
around
okay,
this,
like
it
seems
like
the
the
operations
that
exist
have
been
structured
around
particular
needs
at
particular
points
in
time
like
we
need
to
be
able
to
sign
a
tag.
We
need
to
be
able
to
sign
a
commit,
but
I've
mentioned
before
some
of
these.
A
You
know
mutating
operations
that
will
will
destroy
signatures
and
and
verifiability
of
signatures,
and
you
know
coming
up
with
you
know,
patterns
and
workflows
that
preserve
the
you
know,
preserve
that
attribution
across
these
operations.
A
You
know,
for
example,
you
know
preserving
somehow
the
original
chain
of
commits
putting
that
in
a
place
where
people
can
get
to
it.
You
know
counter-signing
with
the
person's
key
or
the
repository
key.
When
those
commits
are
squashed
rebased,
you
know
rewritten
in
some
sense,
and
then
you
know
being
able
to
have
all
that
information
available
so
that
when
you
do
want
to
go
back
and
trace
things
back
to
their
original
source
that
that's
all
ready
to
go
now.
A
A
You
know
the
counter,
signing
and
preservation
of
commit
chains,
but
you
know
really
having
workflows
that
support
this
and
maintain
you
know
maintain.
The
attribution
is,
is
really
important
as
well,
and
that
would
look
very
different,
for
example,
for
a
self-hosted
repository
or
something
like
the
linux
kernel
to
you
know
a
gitlab
or
you
know
github
or
a
bitbucket.
A
You
know
they
can
have
their
own
resident
keys,
that
that
do
all
these
counter
signing
operations
and
it's
a
lot
easier
than
in
many
senses
than
than
individual
repositories
and
there's
a
you
know:
git
supports
multiple
signatures
types
as
push
signatures,
as
well
as
commit
signatures
and
push
signatures,
are
very
interesting
and
and
attest
to
different
things
than
signing
commits
and
in
some
ways
some
ways
are
more
useful,
but
they're
not
very
widely
used
and
not
well
surfaced
in
in
ui
at
the
moment.
A
So
you
know
coming
back
to
the
vision.
I
think
I
think
this
is
you
know
this
is
an
important
linkage
in
the
total
trust
chain
for
open
source
software.
You
know,
if
you
can,
if
you
can
trust
and
attribute
the
source
code,
then
then
a
lot
of
other
stuff
becomes
possible
down
the
stream
and
really
tying
this
up
as
tightly
as
possible.
A
You
know
enables
a
heap
of
heap
of
other
good
stuff
that
that
follows.
I
think,
ssh
keys
are
the
the
most
plausible
and
easy
path
forward.
For
the
reasons
I
outlined
of
you
know
already
being
deeply
embedded
in
the
ecosystem,
and
I
think
you
know
we've:
we've
got
most
of
the
pieces
ready
to
go
the
you
know,
and
the
next
steps
are
relatively
clear
and
and
straightforward
to
implement.
I
say
you
know
with
with
only
a
trace
of
hubris
and
that's
that's
that's
really.
A
It
yeah
I'm
of
course
happy
to
answer
more
questions
if
you
have
them
actually
I'll
stay
there
in
case
you
want
me
to
go
back
to.
B
I
don't
really
have
any
questions.
Thanks
for
the
explanation,
I
just
I'd
like
to
figure
out
what
it
would
take
to
dust
that
off
and
get
it
going
again.
A
Yeah
I've
I've
not
looked
I've.
I've,
I've,
I've
been
kind
of
busy
with
other
stuff
for
the
last
pandemic.
A
But
the
I
don't
think
I
don't
think
the
crypto
code
in
git
has
has
changed
too
much
in
the
you
know,
nine
months
since
someone
was
looking
at
it
and-
and
I
you
know
the
one
of
the
one
of
the
things
that
was
done
as
part
of
that
work
was
a
set
of
unit
tests
that
I
think
fleshed
out.
Gitz
testing,
and
I
think
that
was
that
part
of
the
work
is
important
and
could
be
can
certainly
be
reused.
F
I
I
haven't
been
as
directly
involved
in
the
development
of
get
recently,
but
if
I
recall
correctly,
there
are
some
changes
in
the
crypto
recently,
because
they're
trying
to
move
away
from
requiring
exclusively
on
their
variant
of
sha-1
they've
got
they've
got
a
shim
in
there.
So
it's
not
actually
sha-1.
F
It's
a
sha-1,
that's
tweaked,
but
there's
ongoing
work
to
move
beyond
sha-1
and
that
might
might
impact
that.
I
don't
know
what
you're
talking
about.
A
Yeah,
so
the
latest
release
of
git
does
support
repositories
that
use
sha-256
signature,
256
hashes
as
the
identifier
for
objects.
That
is
quite
as
far
as
I
can
tell
orthogonal
to
the
the
signing
and
verification
I
think
in
in
both
case.
Like
you
know,
the
signing
and
verification
code
doesn't
care
what
it's
signing
it.
Just
it's
just
a
bunch
of
bytes
so
that
that
shouldn't
you
know
that
that
certainly
an
important
improvement
with
the
you
know
show
one
being
you
know
on
its
way
out:
cryptographically
from
a
security.
B
Do
you
know
how
involved
the
mentor
was
and,
as
you
mentioned,
somebody's
name
looked
like
he's
at
the
linux
foundation?
Maybe
we
could
see
if
he's
willing
to
continue
mentoring.
If
we
can
find
someone
else,
there
was.
A
Some
talk
earlier
this
year
about
getting
someone
else,
but
then
pandemic.
So
I
don't.
I
don't
know
what
happened
with
that
and
again
I
was
I
kind
of
was
at
the
end
of
a
game
of
telephone
with
you
know
one
of
my
staff,
who
was
mostly
doing
this
work.
F
I
was
just
saying
I:
it
seems
to
me
that
we
can
at
least
you
know,
shoot
an
email.
I
don't
know
either
these
people,
I
I
know
how
to
type
an
email.
F
A
Yeah,
I
look
I
can
I
can
I
can
when,
when
kim
shares
the
slides,
I
can
actually
put
the
the
the
david
hughes
piece
email
in
the
in
the
notes.
A
C
F
A
G
Damien,
have
you
or
is
anyone
else
like
thinking
about
or
straw
manning,
what
team
management
for
this
might
look
like
more
generally,
because
that
that
seems
like
I'm
just
sort
of
imagining
all
of
this
existing,
and
that
seems
like
the
next
hard
problem.
A
Yeah,
the
I
mean
the
identity
management.
I
I
it
really.
It
really
depends
on
on
the
repository
post.
You
know,
I
think,
and
it
would
look
very
different
for
a
you
know:
a
commercially
hosted
repository
yeah,
guitar
lab,
etc.
So
then,
then,
the
linux
kernel
or
you
know
the
hinky
little
one.
I
keep
on
my
computer
at
home
yeah
for
for
a
simple
repository.
A
They
would
probably
use
the
the
ssh
allowed
sinus
format
very
directly,
which
is
just
you
know.
It
can
be
literally
as
simple
as
you
know,
user
username
key,
that's
it.
Basically,
it.
A
Looks
a
lot
like
a
an
authorized
keys
file.
You
know
something
which
is
you
know,
you
know
git
tiles
or
something
like
that
could
build
it
into
its
ui.
And
you
know
the
the
commercial
repository
hosts
have
got
whole
teams
that
could
build.
You
know
maybe.
E
A
That
I
could,
I
could
only
dream
of
yeah,
I
I
you
know.
I
think
that
it's
really
a
ui
question
of
you
know
how
how
to
surface
that?
How
to
you
know
make
it
make
it
comprehensible
for
users.
A
Yeah,
well,
I
I
think
the
by
by
virtue
of
the
ssh
signature
format,
including
the
key
as
part
of
the
signature,
if
you
trust
a
repo,
if
you're
getting
if
you're
you
know,
if
you're
checking
out
a
repository
from
another,
you
know
from
somewhere
else,
and
you
trust
that
repository
to
have
verified
that
in
the
past,
then
you
can
just
look
at
the.
You
know,
look
at
the
identity
of
the
commit
and
the
identity
of
the
key
that
signed
it
and
draw
and
infer
that
mapping.
F
Which
is
why
I
also
asked
about
why
not
be
able
to
store
this
within
a
repo,
because
you
know
for
folks
like
the
linux
kernel,
you
know
they
can
review
and
say
yes,
that
key
is
acceptable
or
no,
that
key
is
not
acceptable,
bring
it
in
and
then
in
the
future.
Anyone
can
check
those
keys,
even
the
historical
keys.
A
Yes,
yeah
and
that
and
that's
absolutely
possible,
you
know,
like
the
the
ssh,
like
the
format
that
we
implemented
in
open.
Ssh
is
literally
just
a
flat
text
file
and
yeah.
You
could,
if
you
don't
like
that
format,
it's
trivial
to
generate
from
from
a
format
that
you
do
like.
F
G
A
I
think
I
I
think
we
build
an
ability
to
revoke
keys
into
the
format,
if
not
that's
trivial,
to
add,
as
far
as
as
far
as
key
life
cycle
for
bear
keys.
A
That's
it's
up
to
whoever
maintains
the
list
of
trusted
keys
in
the
repository,
but
the
the
system
does
completely
support
certificates
which
do
have
built-in
life
cycles,
and
you
know
a
bunch
of
other
features
that
that
are
somewhat
relevant
and
they're
pretty
widely
used,
at
least
across
you
know
some
of
the
tech
companies.
I
think
google
uses
certificates.
A
I
think
facebook
uber
lyft
they
all
they
all
use
it
as
far
like
those
are
the
ones
I
know
of
and
those
you
know
that
that
has
the
has
the
sort
of
dual
benefits
of
providing.
You
know
explicit
life
cycle
limitations
and
also
providing
a
you
know,
a
reference
to
a
third
party
trust
group.
That
is
the
organizational
ca
key.
Exactly
how
that
would
unfold
within
git
is,
you
know,
probably
gonna.
A
You
know
going
being
able
to
go
back
and
verify
a
commit
that
was
made
in
the
past
with
the
key
that
is
no
longer
valid
and
being
able
to
discern
that
from
a
commit
that
was
made.
You
know
right
now
with
a
key.
That's
no
longer
valid,
but
simply
just
lied
about
the
date
that
it
was
committed,
and
you
know
that's,
that's!
That's
a
okay!
F
Damian,
I
put
my
email
address
in
there,
so
you
know
I
obviously
have
no.
I
have
no
grand
superpowers,
but
let's
see
what
we
can
do,
at
least
at
least
find
out
some
information
and
hopefully
maybe
make
some
progress.
Yes,.
B
F
F
No,
let
me
make
that
clear.
I
did
not
volunteer.
F
A
Interesting,
thank
you
all
for
your
time
and
I'll
I'll
get
the
slides
to
kim
with
and
feel
free
to.
Email
me
if
you've
got
any
more
questions,
cool.
A
I
think
I
think
once
once
some
of
the
us
comes
off
summertime,
it
gets
a
bit
easier.
G
A
C
Good
luck
doing
anything
next
week,
but
yes.
E
F
H
E
F
Yeah,
it's
just
base.
It's
really
that
I,
I
think
the
town
hall
hall
is
basically
its
real
goal
is
sure
enough,
so
that
people
have
a
clue.
What's
going
on
and
trying
to
encourage
people
to
join
me,
I
what
I
would
do
is,
I
would
start
with
the
developer,
the
digital
id
working
group
notes
and
just
try
to
pull
out
some
of
the
here's
who
you
talk
to
here's.
Some
of
the
key
points.