zsh-workers
 help / color / Atom feed
* gpg key used to sign zsh tarball has no trusted signatures so how can I trust it?
       [not found] <1130466066.9798.1594417647695.ref@mail.yahoo.com>
@ 2020-07-10 21:47 ` vapnik spaknik
  2020-07-10 23:49   ` Daniel Shahaf
  0 siblings, 1 reply; 4+ messages in thread
From: vapnik spaknik @ 2020-07-10 21:47 UTC (permalink / raw)
  To: zsh-workers

Hi,
    the zsh tarballs available on sourceforge & zsh.org are signed by "dana@dana.is", but this key has no chain of trust associated with it, only self signatures. How do I know that "dana" is trustworthy, and hasn't hidden some malicious code in the tarball? I can see "dana@dana.is" listed in the ChangeLog, but that's not much reassurance (it could have been achieved with a simple search-replace).
Considering how fundamental and frequently used zsh is, I think it's very important that we can trust the tarball, don't you?
Here's a suggestion for some of the long term developers; why not contact each other by email and arrange a video conference to get to know each other a little bit, and sign each others public gpg keys?

Joe Bloggs.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: gpg key used to sign zsh tarball has no trusted signatures so how can I trust it?
  2020-07-10 21:47 ` gpg key used to sign zsh tarball has no trusted signatures so how can I trust it? vapnik spaknik
@ 2020-07-10 23:49   ` Daniel Shahaf
  2020-07-11  4:25     ` dana
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Shahaf @ 2020-07-10 23:49 UTC (permalink / raw)
  To: vapnik spaknik; +Cc: zsh-workers

vapnik spaknik wrote on Fri, 10 Jul 2020 21:47 +0000:
> Hi,
>     the zsh tarballs available on sourceforge & zsh.org are signed by "dana@dana.is", but this key has no chain of trust associated with it, only self signatures. How do I know that "dana" is trustworthy, and hasn't hidden some malicious code in the tarball? I can see "dana@dana.is" listed in the ChangeLog, but that's not much reassurance (it could have been achieved with a simple search-replace).

You can compare the git tag to the tarball.  They should be identical,
other than some generated files.

You can also look up the various distro packages of zsh.  Those
packages are signed, and the distro maintainers should have solved this
problem before building and signing their packages.

For example, from the Debian package's repository:

https://salsa.debian.org/debian/zsh/commit/14d262602341f1a2d69aa9149a331d047851ef55
>> I retrieved the key with `gpg --recv-keys 7CA7ECAAF06216B90F894146ACF8146CAE8CBBC4`,
>> where the hash value was obtained by pulling upstream's zsh-web.git over an SSH
>> remote and inspecting Arc/source.html in the resulting clone.

That's how Debian established trust in dana's key.  (It's worth noting
that I wrote that log message, and I'm the one who set up dana's
release manager's upload access, so I had additional, out-of-band
reasons to trust.)

I didn't actually sign that specific commit — in hindsight, that
wouldn't have been a bad idea — but it's contained in the subsequent
«debian/5.7.1-test-3-1» tag, which is PGP-signed by a WoT-connected
individual.

(And I'm not signing *this* email because it's past midnight and I
don't have the brainwidth to re-verify that fingerprint right now)

[Arc/source.html is public at
http://zsh.sourceforge.net/Arc/source.html, as is zsh-web.git via
https://sf.net/projects/zsh]

> Considering how fundamental and frequently used zsh is, I think it's very important that we can trust the tarball, don't you?

Sure.

Note that key pinning is a partial answer: now that dana has RM'd a
stable release, verifying the next release comes from the same key will
provide a non-trivial guarantee.

> Here's a suggestion for some of the long term developers; why not contact each other by email and arrange a video conference to get to know each other a little bit, and sign each others public gpg keys?

I suppose I could verify dana's identity using
https://www.rants.org/2009/11/instant-answer-protocol/ (real-time
questions/answers + verify push access) and sign her key on that basis,
but I don't know when she and I would both have time.

Agreed it'd be a good thing.  Thanks for raising this.

Cheers,

Daniel

P.S.  (I'm replying to emails out of order, so to those who sent me
offlist emails and haven't seen a reply yet, you're not forgotten :))

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: gpg key used to sign zsh tarball has no trusted signatures so how can I trust it?
  2020-07-10 23:49   ` Daniel Shahaf
@ 2020-07-11  4:25     ` dana
  2020-07-12 10:09       ` Daniel Shahaf
  0 siblings, 1 reply; 4+ messages in thread
From: dana @ 2020-07-11  4:25 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: vapnik spaknik, Zsh hackers list

On 10 Jul 2020, at 18:49, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Agreed it'd be a good thing.

Yeah. I meant to get it sorted before, there just wasn't a convenient
opportunity. I'm not very familiar with GPG trust etiquette, but if there's a
good way we can establish trust remotely the next time we're collaborating or
w/e that'd be OK with me

dana


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: gpg key used to sign zsh tarball has no trusted signatures so how can I trust it?
  2020-07-11  4:25     ` dana
@ 2020-07-12 10:09       ` Daniel Shahaf
  0 siblings, 0 replies; 4+ messages in thread
From: Daniel Shahaf @ 2020-07-12 10:09 UTC (permalink / raw)
  To: dana; +Cc: vapnik spaknik, Zsh hackers list

dana wrote on Fri, 10 Jul 2020 23:25 -0500:
> On 10 Jul 2020, at 18:49, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > Agreed it'd be a good thing.  
> 
> Yeah. I meant to get it sorted before, there just wasn't a convenient
> opportunity. I'm not very familiar with GPG trust etiquette, but if there's a
> good way we can establish trust remotely the next time we're collaborating or
> w/e that'd be OK with me

The general rule is that you should only sign somebody's public key if
you are *certain* that whoever controls the private key is indeed the
person whose name is on the key.

Some people say you should perform the verification in person against
a passport (or other government-issued photo id).

Other people argue that passports don't actually add much security,
since the average open source contributor is not able to identify
fake passports at a glance, and in any case verifying a passport
doesn't defend against state adversaries.

Before social distancing, verifying people's PGP keys at conferences
provided a social defence: to paraphrase Linus, many eyeballs make all
impersonators shallow.

In the end, the question is what would convince you that someone
who claims to be danielsh is in fact danielsh; and which people who are
already connected to the Web of Trust would be able to be convinced
that you are in fact the owner of the public key that bears your name.

Cheers,

Daniel
(https://m.xkcd.com/1121/)

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1130466066.9798.1594417647695.ref@mail.yahoo.com>
2020-07-10 21:47 ` gpg key used to sign zsh tarball has no trusted signatures so how can I trust it? vapnik spaknik
2020-07-10 23:49   ` Daniel Shahaf
2020-07-11  4:25     ` dana
2020-07-12 10:09       ` Daniel Shahaf

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git