Re: [Mailman-Developers] Signing commits with gpg
On Oct 24, 2017, at 16:52, Abhilash Raj <maxking@asynchronous.in> wrote:
Gitlab now supports verification of commit signatures and it would be awesome if we start signing commits. It is a relatively painless process and happens automatically with little configuration.
Very cool that GL has enabled this! Thanks for sending the recipe too. I definitely encourage folks (especially core devs) to start signing commits.
Cheers, -Barry
On 10/24/2017 02:18 PM, Barry Warsaw wrote:
On Oct 24, 2017, at 16:52, Abhilash Raj <maxking@asynchronous.in> wrote:
Gitlab now supports verification of commit signatures and it would be awesome if we start signing commits. It is a relatively painless process and happens automatically with little configuration.
Very cool that GL has enabled this! Thanks for sending the recipe too. I definitely encourage folks (especially core devs) to start signing commits.
I have set my .gitconfig to automatically sign commits (I already had my signingkey in the [user] section, but I didn't have [commit] gpgsign = true which I now do).
I remember looking into signing commits when we first switched from bzr to git because I was used to signing all commits. At that time, it seemed controversial. See, e.g., <http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-tp2582986p2583316.html> where linus argues that "Signing each commit is totally stupid." and that you should sign tags but not commits.
I don't know enough about the internals of this to have an opinion, and as I said I will be signing my commits going forward, and the post I link to is over 8 years old and things might have changed, but there it is for what it's worth.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Oct 24, 2017, at 18:56, Mark Sapiro <mark@msapiro.net> wrote:
I remember looking into signing commits when we first switched from bzr to git because I was used to signing all commits. At that time, it seemed controversial. See, e.g., <http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-tp2582986p2583316.html> where linus argues that "Signing each commit is totally stupid." and that you should sign tags but not commits.
I don't know enough about the internals of this to have an opinion, and as I said I will be signing my commits going forward, and the post I link to is over 8 years old and things might have changed, but there it is for what it's worth.
I’m not sure that any of the points Linus brings up in that thread have changed, but I’m also not sure how relevant they are to our workflow. It’s interesting enough that Gitlab is now showing the verified tag for signed commits, although TBH, I’m also not sure how much that buys us in practice. Still, it’s easy enough to experiment with, so let’s do it and see if it has any practical impact on us, either pro or con.
-Barry
I guess more important would be to sign the releases. At least archlinux likes to have signatures for source archives and often requests upstream projects to add this.
For me as a user it would be more interesting to have a verified release signed by one key that's static rather than a commit history that is signed by many different keys that I don't know. I guess the single commit signature is more relevant to other developers, so we know who actually committed something. However, if all commits to the master branches come from merge requests, you already use gitlabs verification. It's not as good as gpg signatures, but in the end you have to trust gitlab to a certain degree anyway...
Another thing that just came to mind: how does commit squashing work? You'll probably have to do that offline and not use gitlabs autosmashing...
I don't have anything against it and I can also rather easily start doing that. (I will have to have my keychain nearby, as I don't have my keys stored on my machines...)
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Oct 25, 2017, at 12:14, Simon Hanna <simon@hannaweb.eu> wrote:
I guess more important would be to sign the releases. At least archlinux likes to have signatures for source archives and often requests upstream projects to add this.
Definitely. I (try to remember to) sign both tags and releases for Core.
Another thing that just came to mind: how does commit squashing work? You'll probably have to do that offline and not use gitlabs autosmashing…
I would think that squash merges would destroy the record of any intermediate signed commits. Core doesn’t have a firm policy either way; sometimes I squash merge sometimes not. I’m philosophical opposed to squash merging, but git often really makes me want to do it anyway.
-Barry
On Wed 2017-10-25 18:14:23 +0200, Simon Hanna wrote:
For me as a user it would be more interesting to have a verified release signed by one key that's static rather than a commit history that is signed by many different keys that I don't know.
this is not an "either/or" thing. it's a "both, and!" thing. software provenance works at multiple levels, and for software that we care about, we should have a cryptographic path on as many of them as possible.
--dkg
Mark Sapiro writes:
where linus argues that "Signing each commit is totally stupid." and that you should sign tags but not commits.
I agree with Linus that signing all commits is probably unnecessary because of the SHA1 chain, but I disagree with signing only tags. I think that the theoretical sweet spot is signing merge commits (or branch head in case of a fast-forward) at push time.
But pragmatically that's too annoying (requires user decision AFAIK, easy to omit, etc), so autosigning every commit FTW IMHO.
Steve
participants (5)
-
Barry Warsaw -
Daniel Kahn Gillmor -
Mark Sapiro -
Simon Hanna -
Stephen J. Turnbull