Re: OpenPGP keys

[Simon Josefsson]

Bruno Haible via Gnulib discussion list <bug-gnulib@gnu.org> writes:

>> 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".

Yes, I think this is where technology meet the social world: trust
cannot be fully automated, or it becomes a central point of failure and
attracts abuse.  The social world rely on many different minor trust
mechanism, each of them fallable, that overall build up trust.  I don't
think we can solve this technically.

>> 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 don't think so, but I don't think cross-project checks are necessary:
it is fairly strong if your PGP key added to Debian's libunistring
package back in 2018 is able to verify a 2024 release.  The chances that
someone got your private key and made releases with it without you or
others noticing this is fairly low.  And there would be stored artifacts
that could be used as proofs here -- unlike HTTPS attacks which are much
harder to prove anything about one year after the HTTPS session ended.

>> 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.

Agreed.  Perhaps one measurement to decide on adding new ones should be
if they are incompatible with our existing PGP-based tarball work-flow.
If some scheme requires you to only use that scheme and no other scheme,
that's a serious problem.  Unfortunately Git signatures have that
property: it is really messy to use PGP and X509 and SSH signatures on
git tags in the same project.  This is a git wart: there is no reason a
git tag couldn't have both a PGP and S/MIME and a SSH signature on it.
I'm signing all of my git commits and tags with PGP, but if we would
enforce that, we are stuck with git's limits on this.

/Simon

signature.asc
Description: PGP signature