Re: OpenPGP keys

[Bruno Haible]

Hi Simon,

Thanks for having answered my questions.

> > Ten years ago, PGP key signing parties were common. They are not common
> > any more. The prior knowledge summarization engine explains this with a
> > demise of the "web of trust" model (see attachment).

> x) Opponents of web-of-trust like to declare it as dead, but just
> because it hasn't took over the world doesn't mean it doesn't work.

Well, I'm not an "opponent" of the web of trust. I just notice that around
2010, there was a keysigning event at every GHM or other conference, and
since about 2015-2020 it's not a topic any more.

> x) I got your PGP key a couple of years ago and still have it locally
> ...
> x) It is better to get the PGP key from multiple places, which is one
> reason the announcements mention a couple of ways, since it is harder to
> pollute all of them at the same time.  I'm hoping people aren't only
> trusting Savannah PGP key distribution mechanism here.

I see. Indeed, if many developers would share their PGP key through
Savannah, the GNU keyring, GitHub, GitLab, their own home page, etc., it
would become harder for an attacker to introduce a spoofed one in all of these
places. OTOH, since these are not regular but ad-hoc distribution patterns,
it's hard to build a tool that fulfils the job of "given the name and
email address of a developer, give me their PGP key and a trust estimation".

> if I got your PGP
> key a couple of years ago and still have it locally, your newly made
> signature will verify against it.  I wouldn't fetch your key on every
> verification attempt.  It is only when keys are rotated that I need to
> make a new trust decisions.  If you continue to use your key for a
> couple of years, I will gain trust over time by seeing your continued
> use of that key.

Is this merely a theoretical consideration, or is it an actual practical
one? That is, is there someone (at Debian, or at some other distro) who
will check whether the GPG keys which signed the latest libunistring and
gettext releases are the same?

> I think the essential concern here is that we engineers are good at
> identifying problems with a solution (and admittedly there are many
> problems with PGP), and therefor end up dismissing a solution.
> Sometimes this is good (e.g., rejecting really bad solutions), sometimes
> this is bad (e.g., rejecting solutions with problems when there is no
> better alternative around).
> 
> If there are better suggestions to protect against supply-chain attacks,
> I'm all for discussing and implementing them.  We need more of these
> rather than less, and I believe we need multiple mechanisms.  PGP is
> easy to complain about, but using it provide some features we don't have
> otherwise, which is why I encourage use of it.  Minisign, signify, Git
> SSH signatures, age, X509/SMIME, Sigstore and Sigsum are other
> approaches worth considering.

OK, thanks for admitting that the solution you propose is not a perfect
one.

>From an engineering point-of-view, one tries to combine approaches that
mitigate the gaps of the other approaches and omit approaches that are
less effective. For example, cars are not built with 6 different types
of brakes, only with 2 (mechanical brakes and anti-lock braking systems).

In this case, I like the approach with the git bundles, since it does
not have an impact on how developers work. But it's unlikely that the
7 other approaches have the same absence of drawbacks.

Bruno

signature.asc
Description: This is a digitally signed message part.