Re: GPG public keys

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 09, 2015 at 05:43:36PM -0500, Jeff King wrote:
> On Wed, Dec 09, 2015 at 02:24:17PM -0800, Stefan Beller wrote:
> 
> > On Wed, Dec 9, 2015 at 2:04 PM, Jeff King <peff@xxxxxxxx> wrote:
> > >
> > > Of course you can't just fetch the v1.7.1.4 tag _now_, because the same
> > > person impersonating the most recent tag could also be impersonating
> > > (and back-dating) the older tags. But you could fetch it now, store it
> > > somewhere trusted (e.g., on your laptop), and wait two weeks. If you
> > > find no public outcry over hacked git, then it is probably OK to assume
> > > that is the real key.
> > >
> > 
> > With all of us pointing out 96AFE6CB being the right hash, you may or may not
> > trust the list enough to also trust the key now.
> 
> Who's to assume that I actually checked that 96AFE6CB is right? ;)
> 
> Actually, I don't typically verify Junio's tag signatures. I fetch and
> run "make" daily, far more often than he signs, so I would have been
> p0wned long ago.

It might also be worthwhile to check that the signatures on kernel.org
match the key in the repo.  kernel.org autosigns the tarballs as well,
so presumably that key matches what kernel.org has on file for Junio.

It may also be less important that the key really belongs to a human
named Junio C Hamano than that the same key consistently signs tags and
tarballs.  I can't personally vouch for the human behind the signatures,
but when building git from tarballs, I do check that the same key signed
them.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]