►
From YouTube: Trust But Verify - Git Merge 2017
Description
Thordur Bjornsson, a software developer at Yubico, has over a decade of experience hacking on databases, protocols, storage, and open source operating systems. His talk will cover the details on how to cryptographically sign your work; from PGP fundamentals and best practices, what gets signed and how to verify those signatures, to possible impacts, and benefits to your workflow. He'll also take a look at GitHub’s interface changes from earlier this year that added visual cues to highlight verification status of commits and tags.
About GitMerge
Git Merge is the pre-eminent Git-focused conference: a full-day offering technical content and user case studies, plus a day of workshops for Git users of all levels. Git Merge is dedicated to amplifying new voices in the Git community and to showcasing the most thought-provoking projects from contributors, maintainers and community managers around the world. Find out more at git-merge.com
A
So,
like
I
said,
I'm
going
to
be
talking
about
trust
and
verification
of
kid
comics
and
signatures.
So
the
problem
I
want
to
explore
with
you
today
is
how
to
attest
to
both
the
changes
and
the
state
of
the
repositories
that
we
work
with
every
day,
both
as
maintain
errs
and
as
end-users
and
I'll
start
with
going
over
a
little
bit.
The
moderate
motivation
and.
A
The
motivation
for
doing
this
kind
of
work
and
what
it
actually
brings
to
the
table,
then
I'll
discuss
the
solutions
and
some
of
the
practical
problems
associated
with
signatures
and
signature
verification.
Then
we'll
go
over
how
to
actually
sign
and
verify
work
with
git
and
n
dawns
on
workflow
considerations.
A
Now
the
problem
we
are
essentially
addressing
is
one
of
supply
chain
integrity.
It's
the
repository
that
I'm
working
with
the
genuine
article
and
how
can
I
actually
attest
to
that
and
for
those
purposes
we
have
a
number
of
different
things,
and
yet
we
can
verify
the
individual
comments.
We
can
verify,
merges
attacks
or
release
it
or
even
pushes
to
remote
the
solution
that
we
our
work
looking
for
are
digital
digital
signatures
for
signatures
for
short
and
like
many
things
in
IT,
takes
back
to
the
late
70s
and
so
on.
The
excuse
me.
A
The
way
that
these
schemes
work
is
that
they
play
on
public
key
algorithms
and
if
we
do
a
little
recap
of
them,
public,
key
cryptography
or
asymmetrical
cryptography.
Our
outer
rhythms
that
work
on
a
pair
of
keys.
You
have
a
private
key
that
you
keep
private
and
an
Associated
public
key
that
you
disseminate
to
interested
parties.
A
I,
don't
remember
when
but
ended
up
being
codified
in
an
RFC
which
defines
the
supported
message:
formats,
the
packets
and
the
methods
for
like
computing
signatures
and
verifying
them.
The
most
widespread
implementation
of
p2p
today
is
with
new
privacy
guard
or
GPG
which,
depending
on
your
outlook,
is
either
a
kitchen
sink
or
a
veritable
Swiss
Army
knife.
It
unfortunately
has
gotten
a
little
bit
of
a
bad
reputation
over
the
years,
especially
in
terms
of
usability.
A
lot
of
that
is
actually
intrinsic
to
PGP
like
we
will
see.
A
There
are
other
implementations
possible
because
you
can
graph
get
almost
indefinitely
with
modules
or
even
in
poor,
as
we've
seen
before
here,
but
it's
out
of
scope
for
this
talk,
so
we
will
stick
to
gbg
central
to
PGP
and
gbg.
Is
this
idea
of
a
web
of
trust
and
the
reason
why
we
need
to
consider
this
is
that
to
be
able
to
do
any
kind
of
verification
operations?
A
Essentially,
PGP
users
would
need
up
physically
at
key
signing
parties
where
they
would
verify
each
other's
identities
and
find
each
other's
public
keys,
thereby
providing
a
binding
between
the
public
key
and
a
real
identity.
It
turns
out
that
this
is
like
the
Achilles
heel
of
PGP,
because
this
method
of
scaling
in
both
communications
and
and
other
operations
doesn't
really
work.
When
we
start
to
talk
about,
you
know,
parties
and
the
number
of
millions,
if
not
even
billions.
A
Today,
however,
there
is
no
reason
to
throw
the
baby
out
with
the
bathwater
in
a
more
constrained
operations,
like
only
for
code
signing
the
web
of
trust,
especially
coupled
with
the
new
trust
model,
while
new
it
was
introduced,
I
think
in
late
2015
and
gbg,
a
first
model
called
tofu,
which
is
essentially
crust
on
first
use,
something
that
you
might
be
familiar
with
from
SS
aging
into
new
hosts.
You
know
the
SSH
client
asks
you
to
verify
a
fingerprint.
A
You
say
yes
and
after
that
point
in
time,
you
kind
of
trust
that
fingerprint
forever
exact
same
principle
here.
It
does
provide
a
much
weaker
security
guarantee,
but
it
can
be
coupled
with
PGP,
N
and
key
signing
to
give
you
a
more
robust
Network
which
isn't
practically
needed,
because
when
verifying
signatures,
we
don't
have
this
many-to-many
relationship.
We
only
really
care
that
the
code
we
are
using
is
coming
from
someone.
We
have
a
relationship
with
and
it
doesn't
even
need
to
be
a
personal
relationship.
A
Now
I
could
spend
a
lot
of
time
discussing
algorithm
choice
like
should
you
be
using
RSA
keys
of
size,
2048
4096,
or
should
you
be
using
electric
curve,
algorithms,
which
one
should
you
be
using
and
so
on,
which
is
a
very
fun
discussion
to
have
over
beers?
So
let's
suffice
it
to
say
that
the
defaults
today
in
gbg
are
pretty
good
and
will
remain
pretty
secure
through
the
next
10
15
years.
However,
there
is
one
thing
that
I
do
want
to
talk
about,
and
that
is
expiry
time.
A
One
of
the
biggest
problems
we
have
when
maintaining
these
repress
relationship
is
the
fact
that
if
you
have
a
private
key
and
it
does
get
compromised-
and
you
have
to
revoke
it
that
operation
for
you,
so
the
people
that
have
a
relationship
with
you
is
an
online
operation.
They
need
to
be
made
aware
of
the
revocation
and
this
one
times
falls
through
the
cracks.
A
So
when
you,
when
keys,
are
created
with
very
long
expiry
times,
sometimes
in
the
order
of
years
decades
or
even
infinite,
these
might
fall
through
the
cracks
so
short
expiry
times
less
than
a
year
less
than
six
months
or
even
better.
If
you're,
maintaining
a
software
project
tie
the
expiry
of
the
key
to
the
long-term
support
of
the
release.
This
also
has
the
added
benefit
of
perhaps
motivating
people
to
update
further,
using
the
same
key
for
everything
that
you
do
is
just
not
good
practice.
A
You
want
to
have
one
key
for
your
personal
use,
one
key
for
each
project
that
you
work
on.
It
does
add
a
little
bit
of
overhead,
especially
in
terms
of
you
know,
keeping
backups
of
them
and
keeping
those
backups
sales,
or
even
just
remembering,
maintaining
the
passwords
to
them.
But
compartmentalization
and
security
is
king
further
on
key
hiding
when
you
are
generating
a
key,
you
should
try
to
ideally
try
to
do
this
on
a
machine
that
is
not
exposed
to
the
wider
Internet.
A
Why,
for
example,
booting
a
linux
wipe
City
live
CD,
which
is
guaranteed
to
have
the
tooling
required,
or
you
can
even
take
it
further
and
using
Hardware
back
keys,
so-called
open
PGP,
smart
cards
or
USB
dongles,
some
of
them
support
generating
the
device
generating
the
key
on
the
device,
and
the
device
itself
may
be
engineered
in
such
a
way
that
the
private
key
material
cannot
be
physically
read
out
of
the
device.
So
all
signature
operations
and
everything
happens
on
the
device
providing
for
like
excellent
security.
A
Further,
there
are
implementation
of
these
devices
that
require
a
user
presence,
so
you
need
to
actually
physically
touch
the
device
to
get
it
to
do
anything,
and
you
know
you
might
want
to
also
consider
using
subkeys,
so
don't
use
your
master
key
for
signing.
The
reason
there
is
that
the
master
key
is
used
for
all
of
these
maintenance
operations,
such
as
signing
other
people's
kids,
extending
the
expiry
time
or
even
generating
other
key
or
generating
sub
keys.
A
So
with
these
small
details
out
of
the
way,
let's
look
at
you
know,
signing
and
actually
verifying
work
with
git
and
we'll
start
with
comments,
as
kind
of
the
basic
building
block
of
repository.
History
now
commits
our
point
in
time
snapshot
of
the
repository
that
you
are
working
in
not
actually
the
actual
changes,
and
if
we
take
a
look
at
a
commit
object,
we
see
that
it
references
a
tree.
A
So
the
tree
object
is
basically
the
thing
that
encodes
both
the
directory
structure
and
the
files
in
your
repository,
and
it
has
references
to
the
blobs
that
contain
the
actual
contents
and
so
on.
So,
along
with
this
header,
you
have
the
parent,
which
is
the
tree
state
before
your
commit.
If
any
like
the
root
commit
on
your
repositories
will
not
have
a
parent
along
with
author
and
committer
metadata
and
notice.
A
It
is
always
the
committer
that
is
making
signature,
not
actually
the
author
followed
by
a
blank
line
and
the
commit
message
now,
if
we
ask
it
to
actually
create
for
us
a
sign
comment,
we
see
that
it's
actually
not
a
word.
It
is
actually
not
doing
a
lot
of
this
work.
It's
shelling
out
to
gbg
to
actually
do
the
heavy
lifting
of
creating
the
signature
now,
if
this
were
actually
committing
real
changes
or
to
some
files,
creating
or
removing
them
adding
directories
or
so
on.
What
would
happen
under
the
hood?
A
Is
that
get
reports
all
of
these
changes
and
stores
them?
Then
it
builds
the
commit
object
after
having
done
that.
It
passes
it
down
to
gbg
by
a
standard
input
and
simply
asks
it
to
create
a
detached
signature
of
the
document,
which
is
a
mix
and
give
reads
and
then
adds
it
as
a
new
header
into
the
commit
object
before
putting
that
down
to
storage,
we
can
see
a
commit
object
that
we
just
created
is
identical
to
the
previous
one,
with
the
addition
of
this
single
gbg6
header.
A
Now
the
blob
that
you're
looking
at
there,
the
PGP
signature.
This
is
the
ASCII
armor
encoding
of
in
open
PGP
signature
packet,
as
defined
in
the
RFC
and
with
a
little
bit
of
copy-paste
work,
you
can
put
it
in
a
file
and
dump
its
contents
and
like
we
would
expect
for
something
to
guarantee
interoperability.
We
have
some
versioning
info
to
be
able
to
know
how
to
parse
the
packet.
We
have
the
signature
pipe,
the
algorithm
that
was
chosen
to
create
the
signature,
along
with
the
message
digest.
A
We
have
user
identity
that
created
the
signature
along
and
a
lot,
and
it's
key
and
a
few
other
miscellaneous
data
there
to
verify
a
comment
very,
very
simple.
But
again,
this
presupposes
that
you
have
a
public
feeling
containing
the
public
key
of
whoever
made
that
signature
and
that
and
for
it
to
actually
be
valuable
for
you.
A
Now,
looking
at
the
verification
itself,
we
see
that
we
can
ask
it
to
actually
output
the
comment
that
it's
asking
us
to
verify
and
we
see
it's
the
same
commit
object
with
the
signature
removed,
so
it
has
to
reconstruct
the
actual
commit
object.
This
is
just
passed
down
to
gbg.
That
then
calculates
the
signature
and
emits
some
output
which
get
actually
dumped
on
you
completely
verbatim.
A
So
if
you
have
configuration
in
gbg
to
either
highlight
or
call
out
fingerprints
or
use
longer
key
ideas-
and
such
this
will
all
be
available
to
you
by
a
bit
further
there's
a
I
don't
know
a
second
type
of
commits,
so
called
merges
and
I
mean
they
are
basically
just
like
comments.
The
only
real
difference
is
that
they
record
any
multiple
parents.
A
I
would
say
that
signing
individual
comments
does
have
value,
and
we
will
discuss
that
a
little
bit
later,
but
merges
are
a
little
bit
more
interesting
from
the
perspective
of
accepting
outside
contributing
contribute
contributions
to
your
project,
and
there
is
one
thing
to
keep
an
eye
on
there
if
you're
doing
so-called
fast-forward
merges
where
you're
simply
basing
the
brands.
On
top
of
yours,
it
will
not
create
a
merge
comment,
which
means
that
you
cannot
really
sign
the
resulting
merge
in
a
way
that
allows
your
users
to
attest
that.
A
This
is
something
that
you
as
a
maintainer.
It
does
maybe
then
interfere
with
workflows
that
prefer
having
a
linear,
rebased
history,
but
I
think
it's
a
I.
Think
it's
a
valuable
trade
off
to
do
that.
Further,
when
doing
merges,
you
can
ask
it
to
verify
the
signature
of
all
of
the
commits
you're
about
to
merge
and
if
you
decide
on
doing
non
fast-forward
merges.
A
Moving
on,
we
have
tags
as
well,
it
has
the
concept
of
two
types
of
tags.
There
are
the
lightweight
tags,
which
are
just
references
to
other
objects
in
the
repository
and
they
are
not
stored
as
first-class
key
objects
and
therefore
cannot
be
signed.
However,
annotated
file
and
notated
tags
can
be,
and
they
are
first-class
data
objects
and
a
little
bit
more
useful.
A
There
is
a
little
bit
of
a
difference
in
the
way
that
they
are
stored.
The
signature
is
not
stored
as
an
additional
header;
it
is
appended
to
the
document
and
as
far
as
I
could
tell
from
looking
at
the
get
history
of
get,
this
is
just
a
development
decision
and
realistically
it
has
no
end
on
how
you
do
the
verification
or
work
with
it
at
all.
A
A
There
is
a
third
thing
that
you
can't
sign,
which
unfortunately,
is
not
widely
deployed
and
that
pushes
or
push
certificates
and
get
parlons.
Now
with
tags
and
comments,
you
can
attest
to
the
authenticity
and
integrity
of
those
two
things,
but
they
tell
you
nothing
about
where
they
are
supposed
to
be
in
the
history
of
a
particular
branch,
so
say
that
I
push
some
some
branch,
why
there
is
no
ways
for
either
the
remote
itself
or
even
later,
users
to
know
that
I
wanted
a
particular
comment
to
be
at
the
tip
of
that
branch.
A
Unfortunately,
this
does
require
some
server
support
and
extra
configuration
the
biggest
one
being
that
you
need
to
share
unknowns
to
prevent
replay
attacks,
which
is
why
you
don't
see
it
on
the
free
open-source
hosting
providers.
It's
a
very
cool
feature,
but
to
be
able
to
talk
a
little
bit
about
workflow
considerations,
I'm
going
to
skip
and
skip
over
them
a
bit.
A
That
is
more
easy
to
compromise,
so
we
kind
of
devalue,
maybe
the
the
value
of
the
signatures
in
there.
However,
merge
commits
are
a
little
bit
more
interesting,
but
in
this
case
the
end
user
is
probably
not
very
interested
in
the
origin
of
the
changes
I
mean
from
from
the
software
perspective.
Yes,
maybe,
but
in
terms
of
being
able
to
attest
to
the
state.
A
While
he
does
have
a
trust
relationship
with
you,
so
it
kind
of
seems
that
tags
are
it
and
I
cannot
believe
they
are
releases
are,
from
the
user
point
of
view,
the
most
valuable
thing
I'm
much
more
likely
to
be
either
building
from
deploying
or
vendor.
In
you
know,
your
point
releases
rather
than
whatever
is
going
on
in
master.
A
It
also
does
have
the
lowest
overhead
for
contributors
as
they
don't
need
to
worry
about
signing
or
establishing
trust
relationship
and
all
of
these
things-
and
you
would
kind
of
hope
that
during
code
review,
you
would
catch
any
malicious
activity
there.
So
we
can
I
don't
need
to.
We
can
kind
of
define
that
problem
away
again.
It's
also
a
little
bit
of
a
lower
overhead
for
the
maintainer.
They
don't,
conversely,
have
to
establish
these
trust
relationship.
We'll
worry
about
the
signatures
there.
They
just
need
to
make
sure
that
they
are
signing
the
mergers.
A
This
is
still
compatible
with
most
of
that
workflows,
you
have
Bearden
gitlab,
github,
Atlassian,
slash
and
so
on,
because
the
merges
the
pull
requests
to
get
closed
at
the
time
you
merge
the
branches
having
the
merged
signed
by
the
maintainer
x'
and
having
their
public
keys
available
in
much
the
same
way
as
we
have
the
public
keys
for
the
project
and
kind
of
define
that
as
internal
integrity
of
the
project.
So
it
becomes
easier
to
tag
the
releases.
A
So
so
to
end
this,
if
you
just
sign
one
thing
find
tax:
when
you
publish
your
public
key
push
it
to
the
key
servers
and
make
sure
to
LIKE.
Put
your
fingerprint
everywhere.
Have
some
luring
a
repository,
a
list
of
doing
cross-checking.
You
know,
go
to
key
Bay's
I.
Have
my
public
key!
There
I
treated
my
I
tweeted,
my
key
there
I
have
it
on
my
website.
I!
Have
it
on
the
project
website,
even
put
it
in
the
repository
itself,
our
plan
for
rotation,
because
replication
mental
inevitably
happen
and
by
using
short
expiry
times.