Bruno Haible via Gnulib discussion list <[email protected]> writes: > Why should we mention this? The Gnulib repository doesn't use signed commits. > > And IMO it doesn't need to. Last time we discussed this, IIRC Simon noted > that enforcing signed commits hampers development by causing hassles to > the developers.
I know that sourceware is beginning to encourage signed commits [1]. See this part of a message on [email protected]: Signed-commit census report. Each quarter we now publish how each project is doing with signed git commits and the percentage of users that sign their commits. I have seen similar mentions on [email protected], but unfortunately could not find any page explaining their rational. > (2) We accept contributions via patches sent over mailing lists. Signed > git commits wouldn't protect us against this attack. Yep, as far as I am aware there is no way to sign a patch sent via 'git send-email'. That would sign the patch sent to the list, and then a maintainer would have to sign the commit once they push it. One could sign an email with the patch as an attachment, if the mailing list etiquette allows attachments like Gnulib does. For others, you would have to do: $ cat 0001-format-patch-output.patch | xclip -selection clipboard Then the author could copy the patch into their mail client and sign it. But this defeats the purpose of 'git send-email', which is to avoid mail clients which commonly mangle patches [2]. > (3) We rely on savannah being trusted infrastructure. I don't think it > makes sense to treat savannah like an untrustworthy hoster. Agreed. > In summary, signed commits would not be worth the hassles it causes. I agree, at least at the current moment. Collin [1] https://inbox.sourceware.org/overseers/[email protected]/ [2] https://www.kernel.org/doc/html/latest/process/email-clients.html
