Re: [PULL 0/1] vmclock queue

[David Woodhouse]

On Thu, 2025-01-09 at 11:03 -0500, Stefan Hajnoczi wrote:
> On Thu, 9 Jan 2025 at 09:14, David Woodhouse <dwmw2@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 <dwmw2@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 <dwmw2@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. I did fight it a bit longer and managed to get it to export the
repository as 'dumb' https, where it just exposes the files. Which kind
of works, but apparently not for tags. And it seems that some things
are *both* in .git/packed_refs and .git/refs/ so even pulling from some
branches gave the wrong results.

I tried to get the git-http-request thing to coexist with gitweb, but I
really have exceeded the time budget for messing with Apache now! :)

smime.p7s
Description: S/MIME cryptographic signature