Mark H Weaver <m...@netris.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> What you suggest would be perfect but, if I understand it correctly, >> it’s far from reality. > > What exactly is far from reality? I did not speak about what _is_, but > rather about what we _should_ do to improve things.
Sorry, that was poorly worded. What I meant to say is that the practices of upstream developers are on average far more “sloppy” than we, as downstream, would end up setting up. A particular problem I see, is that we would end up maintaining a list of authorized fingerprints when 90% of upstream developers do not actually provide that information. This is not to say we shouldn’t try. Rather, what I’m saying is that we should make sure we don’t over-engineer a solution whose benefits would, in effect, be significantly limited by what upstream actually does. [...] > It seems to me that you're rejecting this proposal because you see that > it's not yet practical to do the job perfectly. I’m not rejecting the proposal. My main concern is the implementation of the proposal; I think it’s easy to over-engineer it, or end up with something that doesn’t scale, or provides wrong assurance. > In my view, it is enough that it would be a significant improvement > over what we have now. In my first message in this thread, I listed > the following benefits: > > I wrote: >> * If the packager downloaded a key belonging to a man-in-the-middle >> (quite possible given that we rarely have a validated chain of trust >> to the developer), then that bad key will be stored in our git repo >> for all to see, allowing someone to notice that it's the wrong key. I agree that’s an improvement, because it provides an audit trail. In practice it may still be hard to determine whether this is the “wrong” key, because only upstream can tell. >> * When the package is later updated, it will not be possible for a new >> man-in-the-middle attack to be made on us. If a new signing key is >> used, we cannot fail to notice it. It will raise a red flag and we >> can investigate. Agreed. >> * It would strongly encourage packagers to do these checks, and make it >> obvious to reviewers or users when the packager failed to do so. It >> would also make it easy to find unsigned packages, so that we can >> encourage upstream to start signing the packages, at least for the >> most important ones. Agreed. > Do you disagree that my proposal would have these benefits? No! So, how do we do this? :-) Something like <http://git.savannah.gnu.org/cgit/guix.git/tree/TODO?id=3476ded934dc0beab1801d7fcdcc37b5c17bbf01#n52>, where the signature fields are optional? Do we force signature checks as part of the derivation builds, or do we make it off-line (say, in ‘guix lint’), or both? How do we handle projects that maintain a list of authorized public keys, like GNU, Tor, and kernel.org? Thanks, Ludo’.
