W. Trevor King: > On Sun, Sep 14, 2014 at 05:40:30PM +0200, Michał Górny wrote: >> Dnia 2014-09-15, o godz. 03:15:14 Kent Fredric napisał(a): >>> Only downside there is the way github pull reqs work is if the >>> final SHA1's that hit tree don't match, the pull req doesn't >>> close. >>> >>> Solutions: >>> >>> - A) Have somebody tasked with reaping old pull reqs with >>> permissions granted. ( Uck ) >>> - B) Always use a merge of some kind to mark the pull req as dead >>> ( for instance, an "ours" merge to mark the branch as deprecated ) >>> >>> Both of those options are kinda ugly. >> >> If you merge a pull request, I suggest doing a proper 'git merge -S' >> anyway to get a developer signature on top of all the changes. > > Some previous package-tree-in-Git efforts suggested that only > Gentoo-dev signatures were acceptable, and that those signatures would > be required on every commit (not just the first-parent line) [1,2]. I > don't see the point of that, so long as Gentoo devs are signing the > first-parent line, but if folks still want Gentoo-dev signatures on > every commit the ‘git merge -S’ approach will not work for closing > PRs. > > Cheers, > Trevor > > [1]: http://article.gmane.org/gmane.linux.gentoo.devel/77572 > id:cagfcs_manfikevtj3cmcq1of-uqavebe2r1okykygwc5vom...@mail.gmail.com > [2]: https://bugs.gentoo.org/show_bug.cgi?id=502060#c0 >
Yes, there is a possible attack vector mentioned in this comment https://bugs.gentoo.org/show_bug.cgi?id=502060#c16 So we'd basically end up using either "git cherry-pick" or "git am" for "pulling" user stuff, so that we also sign the blobs. Regular merges would still be possible for developer pull requests, but that's probably not the primary use case anyway.
