On Thu, 9 Jan 2025 at 09:14, David Woodhouse <dw...@infradead.org> wrote: > > On Thu, 2025-01-09 at 09:01 -0500, Stefan Hajnoczi wrote: > > On Thu, 9 Jan 2025 at 08:18, David Woodhouse <dw...@infradead.org> wrote: > > > > > > On Thu, 2025-01-09 at 07:52 -0500, Stefan Hajnoczi wrote: > > > > On Wed, 8 Jan 2025 at 06:11, David Woodhouse <dw...@infradead.org> > > > > wrote: > > > > > > > > > > > 2. Send pull requests with a GPG-signed tag (git tag --sign) and > > > > ensure that the repo URL in the email is https:// (the tooling rejects > > > > unencrypted http:// and git:// repo URLs). > > > > > > You mean *or* rather than *and* in that sentence, right? Because if > > > it's GPG-signed, then I can send it to you over carrier pigeon and you > > > can validate it; the transport is irrelevant. > > > > > > If you really did mean 'and'... is this a new bug in the tooling? Last > > > time I used Peter's make-pullreq script, it worked fine¹. > > > > You're right, both are not required together for security. I still ask > > for both because we historically had some submaintainers without GPG > > keys and didn't want them to use unencrypted git:// or http:// URLs. > > It's easier if everyone does both so I don't have to check whether > > we've followed the right process depending on their GPG key status. I > > think QEMU submaintainers have now fully transitioned to GPG keys, so > > we could probably drop the https:// requirement. > > > > If it's not too much trouble to use https:// then that would be easiest. > > I tried the 'Advanced Web Server Setup' from > https://git-scm.com/docs/gitweb : > > # make the front page an internal rewrite to the gitweb script > RewriteRule ^/$ /cgi-bin/gitweb.cgi > > # make access for "dumb clients" work > RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \ > /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT] > > But it seemed to break the gitweb access for URLs of the form > https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv > so for the *moment* I have reverted that and filed it in the 'too much > trouble' bucket. I will take another look at some point though.
That's fine, I'll update my script to accept git://. Thanks, Stefan
