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.
