►
Description
Presented by Andy Feller
In this workshop, participants learn how to secure Git commits using the new OpenSSH feature. This is an alternative to the traditional method of using GPG and maintaining keys which can be somewhat cumbersome.
About Git Merge:
Git Merge is dedicated to amplifying new voices in the Git community and showcasing the most thought-provoking projects from developers, maintainers, and teams around the world. Git Merge 2022 took place at Morgan Manufacturing in Chicago, IL on September 14th and 15th.
A
Hello,
Chicago
all
right
well
seriously.
I
really
do
appreciate
everybody.
You
know
hanging
around
it's
kind
of
a
long
day
being
the
last
here
so
I
know
you're,
like
you're
my
You're
My
People
by
staying
here.
So
there's
for
using
the
word,
simplify,
that's
a
very
long
title
but
I
believe
in
you
know,
microwaves,
microwave
refrigerators,
refrigerate,
and
this
is
simplifying
signing,
get
commits
and
tags
with
SSH
keys,
so
Andy
Feller
I
am
a
develop
engineer
with
my
compatriots
Preston
and
Bryant
over
at
GitHub
and
I'm
in
our
expert
services.
A
A
outcome.
Wise
right
was
really
trying
to
think
about
this
kind
of
a
workshop
of
like
what
would
you
hope
to
get
out
of
it.
So
when
you
left
today
that
you
actually
had
something
you
can
do
with
it,
and
so
it's
really
kind
of
three
things
right,
like
what's
kind
of
the
motivation
behind
signing
and
specifically
signing
with
SSH
keys,
you
know:
can
you
actually
get
some
hands-on
experience?
A
You
know
beyond
get
merge,
you
know.
What
might
you
consider
you
know
as
a
path
forward,
so
so
talk
about
the
motivation,
so
we
we
see
the
screenshot
here
and
once
again
you
know
this
is
this
is
something
that's
prevalent
in
all
of
get
like,
regardless
of
who
hosts
your
repositories,
what
you
sign
it
with
so
here's
a
screenshot
of
a
pull
request
that
I
created
and
you
might
kind
of
notice
that
this
isn't
me
like
whatsoever.
A
A
Here's
like
the
fingerprint,
and
so
this
should
be
like
really
kind
of
a
big
big
flag
of
like
maybe
you
shouldn't
actually
like
merge
this,
whereas
you
know
you
might
have
something
like
this,
which
is
kind
of
a
big
kind
of
a
green
box,
a
big
kind
of
a
check
mark
that
says:
hey
look!
Not
only
do
we
see
that
there's
a
signature
here,
but
we're
able
to
actually
verify
it
against.
You
know
signing
keys
that
this
individual
has
uploaded.
A
You
know
some
kind
of
you
know:
interaction
with
the
source
control
that
either
has
no
signature
or
has
a
signature
that
you
can't
verify
versus
verified,
which
is
there
is
a
signature,
and
it's
actually
been
able
to
be
verified
against
a
specific
list
of
people,
or
you
know,
individuals
or
apps
or
whatever,
that
you
can
cryptographically
verify
right
and
so
like
for
anybody.
Who's,
never
really
kind
of
delved
deep
into
get
just
just
a
little
bit
of
a
perspective
here.
A
A
You
know
out
of
the
gate,
and
so
that's
kind
of
where,
like
this,
this
last
line
here,
which
you
know
the
header
kind
of,
is
called
like
gpg
Sig,
but
we
kind
of
see
in
this
field
that
it's
actually
a
SSH
signature
kind
of
got
introduced
and
so
like
that
signature
is
really
like.
However,
you
sign
your
commits
and
whatnot
you
can
try
to
cryptographically
determine
whether
or
not
it's
actually
true
like
did
this
person
or
thing
actually
sign
it.
A
So
that's
really
kind
of
like
the
you
know,
like
the
main
motivation
and
as
you
can
kind
of
see,
there's
been
multiple
methods
of
signing,
commits
and
tags
and
whatnot.
You
know,
since
you
know,
2012,
you
know
back
in
get
1.79,
so
you
know
you
know.
Gpg
has
been
around
for
forever.
You
know
more
recently,
there's
the
x509
or
you
might
see
it.
It's
called
like
s
mime,
but
I.
A
Think
what
we
kind
of
saw
last
year
in
November
of
2021
was
a
lot
of
the
communities
saying
that
you
know
gbg
and
x509
kind
of
signature
was.
You
know,
there's
too
much
infrastructure
that
you
have
to
manage
it's
a
little
bit
more
complicated
and
it's
not
something
that
we're
actively
using
and
I'll
be
honest
like
I've.
Never
in
my
20-year
career
worked
at
a
place
that
required
me
to
actually
like
use
gpg
to
sign
and
Trust
everything,
and
so
you
know
the
community
was
saying
well
hey,
look
like
we're
using
SSH.
A
Connect
into
boxes
right
like
we're
using
it
throughout
our
infrastructure,
you
know
we
have
Cloud
infrastructure
and
we're
able
to
you
know
everybody's
using
SSH
key.
So
why
can
we
leverage,
what's
in
the
open,
SSH
library
to
actually
like
sign
content?
And
so
in
you
know,
get
2.?
You
know
34
in
November,
that's
when
support
for
SSH
signing
was
introduced.
A
So
once
again,
if
you've
kind
of
gone
to
the
github.com
get
merge
workshops,
there
should
be
a
number
of
repositories
and
one
of
them
is
called
simplifying
signing
with
SSH.
So
if
you
have
your
laptop
and
you're
interested
in
kind
of
following
along
you
certainly
couldn't
do
so.
I
also
want
to
kind
of
note
that
this
presentation
and
all
the
exercises
are
captured
in
a
repository
and
I
believe
that
afterward,
you
know
all
these
sessions
are
being
recorded,
they'll
be
uploaded,
so
you
know
you
certainly
can
follow
along
afterwards.
A
A
You
know,
specifically
the
gpg
format
config,
which
is
a
little
misleading,
but
trust
me
like
this
is
appropriate
an
option
you
may
have
not
seen,
which
is
your
signing
key
and
then.
Lastly,
the
this
is
a
concept
of
an
allowed
signers
file.
So
for
people
who
don't
know
the
ins
and
outs
of
open
SSH,
we'll
talk
about
in
a
second
well
actually
right
here
at
the
bottom
of
the
slide.
A
A
So
for
for
everybody,
who's
checked
out.
It's
Fallen,
along
with
our
repository
setting
up
to
the
workstation,
so
at
a
minimum,
get
2.34
or
newers
necessary
and
then
open,
SSH,
8.0
or
newer,
so
they're
for
anybody,
who's
never
installed
or
downloaded
get
for
any
operating
system.
There's
multiple
links!
If
you're
on
a
Mac
Brew
works
really
well
for
Windows.
You
could
download
the
MSI
and
install
it
the
the
the
get
bash
environment.
That's
set
up
with
the
the
windows.
Msi
actually
works
really
well.
A
It
includes
Vim
tree
and
a
number
of
other
Linux
utilities
you
might
use
if
you're
on
a
MacBook,
just
I
guess
there's
a
real
quick
aside.
Mac
comes
with
the
2.32
version
of
Apple
git,
and
so
you
want
to
be
very
intentionally
sure
that
you're
using
the
one
that's
installed
from
Homebrew
because
it
hasn't
been
updated
in
a
while.
A
A
Typically,
we
generally
recommend
like
the
newer,
the
Ed
255
19
Cipher,
which
is
you
know,
sufficiently
cryptographically
secure
versus
like
a
much
larger,
like
RSA
kind
of
a
cipher,
but
if
you're
on
an
older
system-
and
you
don't
have
support
for
the
the
ed25519,
you
certainly
can
use
a
more
40
96-bit
entropy.
You
know
RSA
key
if
you
really
want
to,
but
either
way
once
you
generate
a
key,
you
set
appropriate
for
permissions
for
it.
A
A
Great
question
I'm
going
to
over
repeat
just
to
make
sure
that
I'm
kind
of
following
along,
so
the
question
was
hey.
Look
if
I
have
an
SSH
key,
should
I
use
that
or
should
I
generate
a
new
one.
I
would
say
this
is
one
of
those
gray
areas
that
the
community
has.
You
know
different
opinions,
so
the
the
most
conservative
feedback
that
you'll
find
is
hey,
look
actually
generate
a
totally
separate
key
for
SSH
signing.
A
Then
you
use
for
traversing
your
your
Networks,
the
notion
being
that
you
know
if
one
of
them
is
compromised
and
you
have
to
kind
of
kill
it
or
regenerate
it.
You're
all
you're
minimizing
the
kind
of
impact
of
either
signing
artifacts
or
getting
around
your
network,
whereas
if
you're
using
the
same
one
for
both
like
you,
might
be
more
sufficiently
impact
like
just
just
a
broader
impact,
So
yeah.
Thank
you
Martin!
That's
that's
a
great
question
and
in
my
case
here,
I
actually
probably
did
a
little
bit
of
both.
A
Disclaimer,
so
this
Workshop
is
an
introduction
right.
This
is
a
very
deep
and
a
very
broad
topic
and
just
to
make
it
easier
for
people
with
getting
into
signing
with
the
SSH
Keys.
You
know
this
is
having
you
set
up
the
SSH
agent
and
adding
your
private
key
to
that,
even
though
there
might
be
kind
of
some
more
optimal
methods,
especially
if
you
use
other
kinds
of
tools
like
one
password
and
whatnot.
A
Lastly,
just
kind
of
closing
the
loop
here
on
the
this
just
workstation
setup:
all
these
instructions
are
working
on
a
local
repository
that
you
don't
have
to
upload.
You
can
do
it
locally.
You
don't
need
a
network
connection
to
do
it,
so
you
could
throw
it
away.
You
can
keep
it.
You
can
shellack
it.
You
know,
put
it
on
the
fridge
with
a
gold
star.
A
You
know,
send
me
pics
whatever
you
do,
but
the
last
thing
here
really
is
you
know
once
you
get
SSH
key
set
up
once
you
have
your
SSH
set
up
and
the
key
added
to
it
like
these
are
really
the
three
critical
configuration
options
for
a
particular
repository
to
do.
Ssh
signing
and
just
if
you're
brand
new
to
this
I
would
say:
don't
don't
do
the
global
version
of
these
config
commands.
You
definitely
want
to
very
intentionally
know
when
you
want
to
adopt
this
globally.
A
A
So
this
is
really
where
we're
actually
going
to
like
okay.
So
hopefully
at
this
point
you
have
an
SSH
key
agents
running,
you
should
be
capable
of
doing,
commits
and
verifying
them.
This
is
really
going
to
be
the
test
of
it
and,
as
you
can
kind
of
see
right
at
a
high
level,
none
of
the
there's
very
few
commands
that
should
be
completely
new
there's.
A
Maybe
one
of
them
here
that
you've
never
seen,
but
everything
else
for
people
who've
been
fairly
familiar
with
Git
is
the
same
commands
that
you're
used
to
maybe
with
some
additional
Flags,
and
that's
specifically,
the
dash
capital,
S
capital,
S
on
Commit,
the
Show
signature
on
log
and
some
new
kind
of
commence,
and
so
for
this
and
the
remaining
slides.
We
have
an
illustration
of
the
actual
git
repository
that
you'll
be
creating
in
the
end
state,
for
that
particular
exercise.
A
A
So
I
love
copy
and
paste.
It
really
helps
when
you
do
operational
troubleshooting
at
2
A.M
on
your
kitchen
floor,
and
so
you
know
this
exercise
kind
of
walks
through
in
generating
a
very
straightforward.
Read
me
file,
it's
very
copy
and
pasteable,
but
you
know
once
again
like
for
people
who
who
are
fairly
familiar
with
Git
You
know.
A
What
should
stand
out
here
is
that
when
you're
doing
signing,
whether
it's
gpg,
x509
or
SSH,
is
this
capital
S
option
and
I'm
I'm
harping
on
this,
because
the
lowercase
s
is
for
kind
of
a
complementary
capability
of
get
called
sign
off.
So
signing
is
for
the
authenticity.
Authenticity
of
the
committer
sign
off
is
for
the
committee
to
say
that
I
am
allowed
to
commit
this.
You
know
based
on
you,
know,
terms
and
conditions
and
whatnot.
So
two
very
important
things.
A
A
So
you
know
if
you
kind
of
get
something
like
this
here,
where
you
see
the
you
know
that
root
commit
file,
change,
everything's
created
great,
you
know
you
set
everything
up
perfectly
and
you
have
no
problems
for
the
rest
of
this
exercise.
But
if
you
see
something
like
the
second
message
here,
which
is
completely
cryptic,
you
possibly
have
you
know
a
problem
with
one
of
these
three
things:
SSH
agent
was
stopped.
A
A
So
hopefully,
everything
kind
of
ran
quickly
ran
well,
there's
no
problems,
it
looks
like
get
like
you're
used
to
using,
and
this
is
really
kind
of
where
the
first
brand
new
command-
you
probably
never
use,
comes
into
play
and
that's
verify
commit,
and
so
in
this
case
here
we're
going
to
look
at
like
the
the
last
commit
on
the
branch
and
what
you
should
kind
of
start.
Seeing
here
is
this
notion
of
this
good
get
signature
for
this
principle
right.
A
Additionally,
right,
so
that's
how
you
can
look
at
a
specific
commit
and
actually
verify
that
it's
good,
but
if
you
want
to
look
at
the
entire
history
of
the
repository
there's
an
additional
flag,
you
capacity
to
get
log
call
get
Show
signature
and
once
again,
if
everything
looks
you
know
completely
set
up
correctly,
you
should
see
that
good
get
signature,
blah
blah,
blah
blah
and
there's.
You
know,
there's
a
handful
of
possible
other
kinds
of
results
that
you
could
get
depending
upon.
A
You
know
any
kind
of
issues
with
setup,
so
the
middle
one
there
yep
once
again,
if
you
didn't
run
the
proper
git
config
options
there
for
the
Repository,
all
of
these
I
ran
into
testing
both
on
Windows
and
Mac.
So
this
is
this
is
my
own
kind
of
life
here,
you're
living
here
but
Additionally.
You
know
the
second
one
here.
A
A
A
And
all
these
exercises,
you
know
all
these
additional
Flags
like
it,
it's
nice
to
know
them,
but
like
as
a
person
I,
don't
do
everything
the
same
way,
each
and
every
time
like
that's
just
reality.
If
you're
like
me,
you
might
choose
to
use
something
like
some
of
these
additional
big
options
to
enable
them
by
default.
So
you
can
use
your
standard
git
commit
commands
your
standard,
git
log
commands
and
have
it
do
signing
for
you
automatically
and
to
show
you
lawn
signatures
for
you
automatically.
A
So
if
you
have
a
repository
that
you've
chosen
to
adopt
signing,
this
could
cut
down
on
some
of
the
errors
that
people
you
know,
don't
remember
all
those
additional
commands
to
do
it
right
every
single
time.
So,
if
you
choose
to
do
signing,
I,
certainly
recommend
looking
at
some
of
these
additional
configs,
and
so
once
again
by
the
end
of
this,
you
should
have
a
repository
with
a
single
commit
that
head
is
pointed
to
so
nothing
terribly
exciting.
B
A
Okay,
all
right
now
we're
going
to
get
slightly
more
complicated
talking
about
merges.
So
if
it
commits
the
very
first
thing
that
people
do
after
they
have
a
repository,
branching
and
merging
is
the
next
once
again,
there's
actually
going
to
be
no
new
commands
just
kind
of
additional
Flags
in
a
potentially
optional
configuration.
A
If
you
want
to
make
your
life
easier.
But
what
you?
What
you
see
here,
is
that
we're
going
to
actually
open
up
a
feature
branch,
we're
gonna,
get
some
of
those
commits
actually
ready
there
and
then
before
merging
it,
in
we're
going
to
make
some
changes
back
in
the
default
Branch
before
ultimately
merging
that
in
so
nothing
terribly
unusual
or
complicated.
A
So
the
the
option
that
we're
going
to
use
here
is
called
verify
signatures
and
this
could
be
potentially
misleading.
So
when
I
first
read
this,
you
know
my
thought
was
okay.
You
know,
I
have
I'm
on
this
Branch
I'm
going
to
merge
this
other
Branch
into
it,
and
I
want
to
actually
make
sure
that
everything
is
signed.
Well,
as
it
turns
out
get
merged
with
a
verify.
Signature
only
looks
at
the
tip
of
each
branch
to
make
sure
that
the
tips
are
sight.
A
So
hopefully
you
have
a
feature
Branch,
you
have
a
brand
new
commit,
there's
no
particular
problems,
and
this
this
is
a
little
contrived.
So
this
is
a
little
contrived
for
this
exercise
here,
but
before
merging
it
in,
we
want
I
wanted
to
try
to
simulate
some
other
kind
of
merge
getting
merged
back
into
the
default
branch,
but
instead
we're
just
creating
it
here,
and
in
this
case
here,
it's
just
updating
the
readme
of
hey,
look
like
you're
going
to
have
an
app
called
hello
world.
A
It's
going
to
be
amazing,
it's
going
to
change
everything
in
your
life
and
it
did
for
me
and
so
in
committing
that
in
once
again,
you
know
we're
adding
it
we're
committing
it.
Maine
is
pointing
at
a
different
place
than
what
it
was
when
feature
was
created
and
so
in
merging
in
the
feature
Branch
back
in
once
again
in
having
get
set
up
correctly.
Having
SSH
agent
running
you
know,
committing
and
validating
work
correctly
verify
signatures.
What
it
will
do
is
in
looking
at
both
of
those
branches.
A
So
once
again,
you
know
some
possible
results
that
you
see.
You
know
the
good
case
is
hey.
Look.
This
commit
happened.
It's
been
merged
in
everything
is
great,
but
if
there's
an
issue
with
either
one
of
them
not
being
signed,
you
should
get
a
fatal,
and
it
should
tell
you
very
clearly.
This
doesn't
have
a
signature
and
once
again,
a
bit
misleading
this
asking
for
a
gpg
signature
when
we're
doing
SSH
signatures.
A
Maybe
that's
an
opportunity
for,
like
the
the
next
release
of
get
to
kind
of
clarify
that,
but
hopefully
right
yeah
everything's
that
I've
been
working.
Then,
when
you're
after
you
merge
you're
looking
at
the
log
results
here,
you
know
you
should
see
that
entire
history
of
making
a
branch
making
a
commit
signing
it
all
along
the
way
and
every
single
commit
being
signed
and
trusted
and
verified.
A
A
A
A
A
A
A
I
think
it's
it.
It
is
basically
saying
that,
out
of
all
the
keys
that
you
trust
and
all
the
ways
that
you've
described,
who
or
what
might
have
done
that
signing
it
matches,
so
this
is
kind
of
where
we
I
guess
begin
to
talk
about
what
can
vendors
do
beyond
what
was
built
in
to
get
to
kind
of
further
on
so
yeah
all
right,
a
little
second,
you
know
what
we're
just
going
to
pair
this
up
to
my
phone
here,
real
quick.
A
A
But
I
love,
it
absolutely
love
it
all
right.
So
we
talked
about,
we
talked
about
commits
we
talk
about
merges,
you
have
a
laptop
set
up
like
this
is
like
the
easiest
section
ever
and
it's
tags
right
so,
but
something
that's
kind
of
interesting.
That
I
chose
this
as
a
topic,
because
it
wasn't
something
that
I
was
like
comfortable
with.
A
You
know,
having
gotten
into
trouble
with
security
stuff
over
the
years,
I
was
like
hey
I'd
like
to
learn
about
something,
and
once
again
you
know,
gpg
was
always
too
hard
for
me,
and
so
one
of
the
other
things
I
learned
through
this
is
that
there's
actually
two
kinds
of
tags
right.
So
most
of
the
tags
that
we
use
on
a
day-to-day
basis
are
what
called
a
lightweight
tag,
which
is
basically
just
a
reference
to
a
particular
commit.
So
it's
not
super
expensive.
It's
not
super.
A
You
know
involved,
but
when
we
talk
about
signing
tags,
you
have
this
notion
of
an
annotated
tag
which
is
more
akin
to
actually
commits
so
there's
a
lot
more
metadata.
That's
actually
captured
there,
including
you
know,
author
tagger,
whatever,
but
a
little
bit
of
trivia.
There's
multiple
kinds
of
tags.
A
And
so,
like
the
other
commands
that
we've
been
running,
there's
nothing
really
new
here,
except
for
the
fact
that
there's
an
additional
flag
to
the
tag
command
and,
unfortunately,
you
know
for
for
commit
it's
a
capital
S.
Unfortunately,
for
tag,
it's
a
lowercase
s,
but
if
everything
is
working
well,
it
looks
like
all
of
your
other
kind
of
get
tagging
kind
of
commands
and.
A
If
you
did
everything
right,
it
doesn't
say
anything:
if
you
did
it
wrong,
you
can
get
messages
like
this
right.
You
can't
find
gbg
fail
to
sign
it
and
once
again
it
all
goes
back
to
that
first
exercise
of
is
essay
agent
running
is
your
key
added.
Is
your
allowed
signers
file
set
up
correctly
and
all
those
configs
are
there?
A
A
Lastly,
if
if
you're
choosing
to
do
SSH
signing-
and
you
want
to
make
sure
that
you're
always
signing
everything,
I-
definitely
encourage
setting
config
options,
so
it
happens
by
default,
very
easy,
and
so,
by
the
end
of
this,
you
know
not
much
more
complication.
From
the
last
step,
we
have
a
tag
that
points
to
the
same,
commit
as
head.
A
Oh
great,
it's
actually
keeping
track
all
right
last
exercise.
Let
me
talk
about
the
other
fun
stuff,
so
we
talked
about
if
you
initially
sign,
commits,
merges
and
tags
what
happens
if
somebody
doesn't
configure
it
or
you're
choosing
to
adopt
signing
for
an
existing
project,
and
this
is
really
where
you
have
to
kind
of
get
into
either
amending
commits
or
nested
tags
is,
is
what's
actually
happening
under
the
covers
in
that
second
command
there,
and
so
this
exercise
really
just
kind
of
creates
like
a
new
commit
and
tries
to
tag
it.
A
Liking
things
like
hello
world
who
doesn't
like
fubar
so
just
to
kind
of
preface
or
get
this
new
tag
set
up.
We
just
kind
of
create
like
a
new
little
script,
called
Foo
tells
you
it's
bar
and
a
little
bit
of
an
update
to
the
readme
file
once
again
it
to
so
what's
specifically
going
on
here,
because
we're
trying
to
set
up
that
case
where
somebody
commits
something
that's
not
signed.
A
This
is
very
explicitly
saying,
like
don't
sign
this
once
again,
a
little
bit
of
a
misnomer
that
says
no
gpg
signed,
even
though
we're
using
SSH
signatures,
but
like
once,
you
do
the
commit.
If
you
look
at
the
log,
you'll
see
that
there's
no
signature
shown
there,
you
know
no
good
get
signature
and
so
fixing.
It
is
basically
doing
the
get
commit
amend
in
this
case
here.
A
This
is
this
is
not
where
I
am
an
expert,
so
I'll
apologize.
There
is
a
way
to
kind
of
rebase
an
entire
Branch
to
resign.
The
whole
branch
and
that's
kind
of
where
you'll
do
this
rebates.
With
the
exec
of
that
same,
get
commit,
amend,
and
in
this
case
here
you
might
pick
your
default
Branch
or
feature
Branch
or
whatever,
but
that'll
at
least
allow
you
to
go
through
the
whole
thing
to
resign.
All
of
it.
A
So
let's
do
parts
of
this
kind
of
exercise
right,
so
we
created
commit,
we
didn't
sign
it,
we
resigned
it
I'm,
not
sure
if
re-signed
is
the
correct
verb,
but
we'll
go
with
it
and
we'll
do
the
same
thing
with
tax
right.
You
know
very
similar,
you
know
get
tagged
with
Dash
Dash
and
then
sign
we're
essentially
setting
up
a
new
tag
without
it.
So
this
will
be
a
lightweight
looking
at
the
information
there
and
we'll
actually
see
an
error
here
that
there's
like
no
signatures
set
up.
A
A
A
It
looks
like
a
git
tag,
command
you're
using
the
same
name
for
both,
but
you
also
have
to
force
it
and
then
we're
also
making
sure
to
sign
it,
and
so
there's
a
little
bit
of
warning.
Disclaimer
that
comes
up
of
saying:
hey,
you're,
pushing
a
nested
tag,
and
that's
okay,
because
like
under
the
covers,
what
we'll
see
is
you
know
the
tag
will
get
updated,
we'll
see
the
signature
there.
A
All
that
being
said,
you
know,
if
you're
choosing
to
to
sign,
commits
and
tags
and
merges
and
pushes
there's
there's
more
okay.
This
is
the
way
that
you
can
like
fix
the
oopses,
and
the
reason
why
you
want
to
you
have
to
fix.
The
oops
is
especially
with
things
like
merge
and
push.
If
you're
saying
things
have
to
be
signed
to
people
aren't
signing
them.
It
basically
stops
the
world
so
going
back
through
and
like
fixing.
A
All
those
things
to
get
everything
back
on
track
is
a
little
bit
of
a
pain,
which
is
why
all
those
get
big
options
for
turning
on
by
default
are
really
recommended,
but
you
know
being
the
last
kind
of
exercise
you
know.
Hopefully
you
have
a
git
repository
that
looks
like
this.
You
know
handful
of
commits
a
handful
of
tags,
a
branch,
but
it
kind
of
gives
you
at
least
a
little
bit
of
a
taste
of
what
like
signing
content
and
get
kind
of
looks
like
behind
it
all
right.
A
A
If
you
just
look
at
the
support
edit
to
get
you
know,
typically
SSH
keys
aren't,
captured
and
distributed
so
they're
freely
available
as
a
web
of
trust,
so
they're
not
distributed
they're,
not
discoverable,
and
there's
no
concept
of
a
revocation
strategy.
So
if
a
key
gets
compromised,
what
do
you
do
about
it?
A
The
other
thing
is
once
again:
this
is
kind
of
where
we
need
vendors,
whoever
they
are
and
how
they
are
going
to
support.
This
feature
will
vary.
Naturally,
you
know,
GitHub,
probably,
is
the
only
one
with
support
out
currently
so
having
things
like
apis
for
fetching,
sign-in
Keys
having
things
like
Vigilant
mode
to
make
sure
people
are
signing
stuff
or
enforcing
signing
will
be
important,
but
it'll
all
depend
upon
what
your
vendor
comes
out
with
last
two
things
on
an
adoption
Plan
before
we
dovetail
them
to
Beyond
is
so.
A
If
you're,
in
a
situation
where
your
vendor
doesn't
have
support,
you
know,
one
thing
that
you
could
consider
doing
is
actually
committing
the
allowed,
signers,
faulty
or
repository
and
then
having
the
developers
that
work
on
it
to
use
it
in
their
configuration
as
the
trust
file.
So
you
know
worst
case
scenario.
If
you're
kind
of
interested
in
playing
with
it,
it's
obviously
an
option
that
you
can
follow,
and
then,
lastly,
so
this
is
actually
from
the
pro
get
SCM
book
right,
which
is,
everyone
must
sign.
A
All
good
all
good,
but
everybody
has
to
decide
if
you're
choosing
to
do
this,
because
you
know
one
unsigned
commit
kind
of
breaks
the
process,
because
this
concept
of
everything
is
being
signed
because
authenticity
matters.
So
it's
not
something
that
you
just
adopt
you
know
at
a
whim
is
something
you
have
a
conversation
about
and
you
understand
the
trade-offs
and
you
choose
to
adopt
it,
and
you
start
small
and
you
go
from
there
because
unverified
will
break
everything.
A
A
And
some
of
this
is
like
personal
opinion.
You
know
it's
not
an
opinion,
a
GitHub
or
anybody's,
it's
just
a
personal
opinion,
but
a
couple
other
things
I
found
useful
in
putting
this
together.
I
thought
I
would
share.
So
the
only
public
project
I
could
find
that
did
interesting.
Things
with
verify
commits
was
actually
the
Bitcoin
project,
so
they
have
some
client-side
hooks
that
before
they're
actually
pushing
up
to
their
remote
store
and
we'll
actually
check
every
single
commit
to
see
whether
or
not
it's
signed
and
if
it's
trusted.
A
So
this
is
kind
of
like
an
early
kind
of
approach
before
vendors
supported
it
to
you
know
verify
that
everything
is
actually
signed
to
make
it
easier
for
the
contributors.
So
it's
kind
of
interesting,
maybe
something
that
can
be
adopted
flying
over
here
from
Raleigh
North
Carolina,
where
I
live.
One
of
the
pain
points
is
that
you
know
this
file.
This
allowed
signers
file
requires
you
know
public
key
signing
keys
from
everybody
that
you
want
to
trust.
A
So,
if
you're
on
GitHub-
and
you
want
all
the
keys
for
all
the
people
on
the
team
that
you're
on
here's
a
little
GitHub
CLI
extension
that
you
can
point
at
your
team
and
generate
like
the
the
allowed
signer
file
for
you.
So
hopefully
it
makes
it
pretty
easy
if
you're
working
with
the
team
and
then
once
again,
I
want
I
really
want
to
keep
I
really
want
to
say.
Thank
you
to
vendors
for
trying
to
support
this
feature
for
users
right
once
again,
you
know
adding
it
to
get.
A
It
was
only
the
first
step.
We
really
need
vendors
to
support
it.
So,
hopefully
you
know
again:
Get
Loud,
bitbucket
they're
actively
working
on
it.
Hopefully
you'll
start
seeing
it
soon.
If
that's
something
you
need
and
then
lastly,
so
recently
one
password
right,
so
if
you're
using
them
for
like
holding
passwords
or
things
like
Keys,
they
recently
like
released
support
for
this.
So
you
know,
hopefully,
as
like
other
vendors,
really
support
for
that.
If
this
is
something
that
you
use,
you
want
is
a
really
easy
way
to
keep
your
keys
secure.
A
This
might
be
something
that
you're
interested
in.
So
obviously
you
know
the
community
as
a
whole
is
is
working
to
improve
the
story
behind
this.
To
you
know,
let
you
get
back
to
focusing
on
what
you
do
with
a
greater
sense
of
trust
and
once
again
take
all
it
with
a
grain
of
salt.
This
is
just
kind
of
like
me
personally,
a
professional
opinion,
but
yeah.
Thank
you
all
for
staying.
This
is
the
last
session
of
the
day.
You
know,
thank
you
for
the
staff
for
setting
things
up.
A
I
definitely
appreciate
the
opportunity
for
being
out
here
and
your
time,
and
attention
and
I
also
want
to
thank
a
handful
of
people.
I'm
not
going
to
read
you
all
their
names,
but
these
are
all
individuals
who
reviewed
gave
feedback.
You
know
worked
behind
the
scenes
and
helping
me,
you
know,
vet
this
content,
so
you
know
a
lot
of
people
behind
all
this
and
so
q.
A
anybody
would
like
to
ask
more
questions
and
we're
also
going
to
be
hanging
out
after
this.
C
A
So
when
you
work
at
a
company
of
a
hundred
two
hundred
a
thousand
ten
thousand
people
like
how
do
you
manage
this
at
scale
right
like?
Where
does
that
actually
sit
and
that's
kind
of
where
I
think
you'll
start
seeing
things
like
what
GitHub
calls
Vigilant
mode
or
other
features
at
that
level
with
like
this
is
something
you
should
ask
your
vendors
for
like
having
to
hear
your
voice
of
we're
interested
in
this.
We
actually
need
you
to
do
the
heavy
lifting
right.
A
That's
why
we're
your
customers
and
you're
starting
to
see
that
at
GitHub
with
what
we
call
Vigilant
mode
but
I,
think
I
think
there's
more
kind
of
run
room
to
kind
of
deal
with
things
like,
revocation
and
whatnot.
That
you
know
like
talking
to
your
vendor
of
saying
like
this-
is
a
value
to
us
like
make
it
happen,
is
probably
what
you're
going
to
see
So
my
answer
is
your
vendor
should
definitely
sell
it
for
you.
A
Gotcha
so
I
would
say
that
might
be
policy
Set,
Beyond
individuals
right
either
at
so,
let's
play
around
with
speaking
GitHub
Enterprise
terms.
So
maybe
that's
something
that
you
said
at
the
repository,
the
organization
or
an
Enterprise
level
I
think
like
if
you're
not
already
signing.
You
probably
want
to
be
very
intentional
with
what
your
rollout
strategy
is
right.
A
What's
on
the
roadmap,
to
say
you
know
the
terms
and
conditions
of
what's
currently
out
there,
because
this
got
released
what
two
weeks
ago,
three
weeks
ago,
but
I
think
I
think
it's
dog
feedback
right,
like
as
administrators
as
people
who
are
enabling
business
concerns.
How
do
we
make
this
easy
yeah?
That's
why
I'd
say.
A
E
Seven,
oh
thank
you
Derek
stolly's
here
tomorrow,
I
mean
we
can
check
on
with
him.
On
that
question,
then
I
know
we
were
having
a
discussion
about
it
being
in
the
on
the
get
DL,
there's
a
discussion
about
being
on
the
next
kind
of
major
version
of
git,
and
if
it
should
be
on
three
you
know
so,
let's
talk
about
it
tomorrow.
I
think
it's
a
great
question
to
bring
up
there.