> We use signed commits at $work and when you enable that it will fail to rebase in the GH UI because it can't do so without destroying signatures and it only wants to sign squashes and merge commits (and commits authored in GH UI). Which is what led me to kick this discussion into motion. 🤷♂️
Right this is true, the signature will be destroyed when it gets merged into main but you can still verify that the PR just before it did get merged into main is verified which may be enough. Anyways as you said this is going around in circles, let's make another discussion for it if we still want to discuss it. On Tue, Nov 8, 2022 at 11:11 AM Jean-Luc Deprez <[email protected]> wrote: > Mhaha, now it's starting to go in circles. > > We use signed commits at $work and when you enable that it will fail to > rebase in the GH UI because it can't do so without destroying signatures > and it only wants to sign squashes and merge commits (and commits authored > in GH UI). Which is what led me to kick this discussion into motion. 🤷♂️ > > It also has a nasty bug btw. You can't set branch creation protection to > require commit signing or it will try to validate the whole Git log and you > only need a few thousand signed commits to have it time out. > > > > On Tue, Nov 8, 2022 at 11:00 AM Matthew Benedict de Detrich > <[email protected]> wrote: > > > On a similar note on this topic, it is actually possible to do even > > "precise verification" via Github but it's a different way of doing > things. > > Now that pekko's main branch is protected (see > > https://github.com/apache/incubator-pekko/pull/29) it's also possible to > > turn on GPG signature verification. What this means is that you > > cannot merge a PR into main unless all of the commits have been signed by > > the original creators of the commit. > > > > What this does is that it verifies that whenever code has been merged > into > > main, the state of the code beforehand (i.e. as a PR) has been signed by > > the author's of that PR. So while commits that get merged into main are > not > > verified, the code just before the merge is verified and since the branch > > is protected (i.e. no one can directly push to it) the argument could be > > made that even in extreme cases this is enough to prove authorship even > > down to the technical signature level. > > > > I would like to at some point turn on signature verification however it > > requires everyone to setup a key and submit their public key to github so > > it can possibly reduce collaboration. I would say such a move would need > a > > binding vote and its a discussion for another day. > > > > On Tue, Nov 8, 2022 at 10:33 AM Jean-Luc Deprez < > [email protected]> > > wrote: > > > > > For copyright entitlement attribution by author tag or Co-authored-by > tag > > > should suffice. (possibly augmented by a copyright line in the file > > > header). > > > > > > Committer identity (in Git by digital signatures) matters if you > require > > > 'an audit trail / forensic evidence'. So it only really starts > mattering > > > when in a dark place already, but that's how most deterrents work and > > > plenty of those in the world. > > > > > > (not an argument to start doing that, just a response to Justin) > > > > > > > > > On Tue, Nov 8, 2022 at 9:51 AM Matthew Benedict de Detrich > > > <[email protected]> wrote: > > > > > > > Right this I understand, when I said "precise" traceability I was > > talking > > > > about precise tracking via git commit's which is not necessarily the > > same > > > > thing as knowing who wrote which code (this was in context of github > > > > creating its own commits because we do a rebase via the github UI). > > With > > > > this example of Github UI, in such a case it's still very clear who > > wrote > > > > the code but it doesn't perfectly align with the "traditional git > way". > > > > > > > > On Tue, Nov 8, 2022 at 9:36 AM Justin Mclean < > [email protected] > > > > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > > Precise traceability of who wrote which exact portions code isn't > > of > > > > any > > > > > > critical importance in open source projects, authorship is. > > > > > > > > > > > > > > > IMO, who wrote the code determines who owns it (them or their > > > employer), > > > > > and that impacts how it can be licensed and if that can be > > contributed > > > to > > > > > an ASF project. This is critical, even if it rarely an issue. > > > > > > > > > > Kind Regards, > > > > > Justin > > > > > > > > > > > > > > > > -- > > > > > > > > Matthew de Detrich > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > *m:* +491603708037 > > > > > > > > *w:* aiven.io *e:* [email protected] > > > > > > > > > > > > > -- > > > > Matthew de Detrich > > > > *Aiven Deutschland GmbH* > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > *m:* +491603708037 > > > > *w:* aiven.io *e:* [email protected] > > > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* [email protected]
