Re: Multi-person sponsorship
On Tue, Feb 17, 2004 at 07:11:08PM +0100, Goswin von Brederlow wrote:
> > Prompted by a comment made by one of my potential sponsees, I've been
> > reworking my semi-automated sponsorship queue from a "helps me" thing to a
> > "could help lots of people" thing. The comment was along the lines of
> > "wouldn't it be cool if we could remove the SPOF of sponsors, and have a
> > group of people sponsoring packages".
> >
> > Well, I'm to the point now where I think that I can make that happen. What
> > I've got so far is an upload queue, a test autobuilder (to make sure that
> > the package at least builds cleanly before wasting a sponsor's time with
> > it), and the generation of a tarball containing the .dsc, everything that
> > the .dsc references, and the build log from the test build. All of that is
> > ticking along nicely, and I'd like to thank Lucas Wall and Juergen Strobel
> > for throwing their packages at the queue for the last few days while I
> > tweaked the bugs out of it.
>
> What kind of security do you have to prevent uploads of malicious
> sources?
If the .changes isn't signed by a key in the "uploaders" keyring, it gets
rejected. The exact criteria for who gets their key in hasn't been thought
about yet - so far, it's been people I intend to sponsor. I presume it'll
be something like that in the future, too.
> I hope you destroy the chroot after each build and unpack it anew.
Sing it loud, and sing it clear - "We love pbuilder! We love pbuilder!"
> Having a new-maintainer keyring, to which keys could get added by any
> AM after it has been verified, and checking the signature on the dsc
> files against it sounds good to. And the keyring would be usefull for
> other purposes too.
I hadn't thought about an NM keyring, but that has a certain amount of sense
to it. I'd like to not limit the sponsorship service to just people who are
in the NM queue, but even a "sponsee keyring" - perhaps separated by
NM/non-NM - would be of definite benefit. Knowing the trust path of the
maintainer of your software would be useful, even when they're not a DD.
> It would be nice if some uncommon archs could have a buildd for this
> so new maintainers are faced with protability right from the start.
I'm not likely to get an S/390 anytime soon (although donations are, of
course, more than welcome). <g> But I'm happy to put multiarch building
into the system if you'd be willing to run a buildd for it (I'm depressingly
single-arch these days).
> > The final step I'm planning on building into the system is a way for
> > sponsors to get packages out of this queue system I've built so they can
> > check them over and upload. The problem is, I'm not sure how to do this
> > optimally. My constraints are:
> >
> > * Must be quick and simple to use. Too much hassle will cause sponsors not to
> > use the system due to excessive pain.
>
> A mini-dinstall apt repository with limitd access. Accounts could be
> activated once by signed mail stating a user/pass pair.
Hmm, yes. What I've got at the moment is tarballs built from the
autobuilder output, with the .dsc, everything mentioned in there, and the
build log. My thought was that sponsors, when they wanted to get something
to sponsor, would download that tarball (everything you need in one easy
package). If you think it would be more helpful, I've already got a package
pool set up internally that I can easily convert for the purpose if needed.
> > * I'd like (but it's not an absolute requirement) to be able to track who
> > "claimed" each package for sponsorship, so sponsees can harass a particular
> > someone if the upload never gets done.
>
> Sponsoring could work just like the normal buildds. The sponsor sends
> a mail back to the buildd with the signature and the buildd does the
> uploading. There could be a simple webpage where DDs can claim
I'm wondering if that might be sailing a little close to the wind, though.
I'd prefer not to fiddle with the way things are done too much this early,
and "automating" uploads feels a little too much like it's ripe for abuse.
At least this way, since it's going to take the sponsor some time just to
build the package ready for sign+upload, hopefully they'll spend the extra
time looking for problems and maybe trying the package.
> packages for a limited time (say 24h default with a 1 week option)
> with a simple click. The webpage could double at showing whats
> available for sponsoring too.
This isn't a bad idea. I might have to get a little funky with my
mod_rewrite skills (pitiful as they are) and get something going so I can do
some reference-counting (and general funky stuff).
> > * Minimal manual intervention required on the administration side of things.
> > Preferably no need for setup of accounts beyond that provided by a GPG
> > public key.
>
> A mail wrapper could check against the debian keyring and activate
> accounts fully automatic then.
So I still have to write my MIME-aware mail checker? Bummer. <grin>
> > * Once selected by a sponsor, a package for sponsorship is taken "off the
> > market" for others, but can be reinstated later if the original downloader
> > can't upload, but the package shouldn't be rejected.
>
> Unless its rejected by the sponsor (with an explaination) or a newer
> version is uploaded. I think if the sponsor finds problems with a
> package it shouldn't go back just because some time passed. Packages
> should automatically come pack when no action is taken by the sponsor
> though.
That was one of the things that was bugging me. Once a sponsor has taken
the package, what should the on-going action be? Wait until the sponsor
says something like "No, I don't have time to upload this, better let
someone else do it", or "I am rejecting this package". You obviously like
for option 2.
> I think an apt repository for the build packages would be easiest to
> quickly test packages. Access should be limited (account creation by
> signed mails) and the pin setup like experimental to prevent
> accidentaly installing debs from there.
Hmm, that could be nice. Do you know if apt can handle HTTP Authentication
(not HTTP Proxies, I know it can do that). No mention in the manpage from a
cursory search.
> You could track who downloads each deb and show a counter on a
> overview page. That could be used as an intrest indicator. ("Yes, 2
> people have tried my package, lets see if one is willing to sponsor
> me"). Intrested sponsors could claim the package on that same page,
> which would remove the "needs sponsor" flag for a limited time.
That's a pretty cool idea. I think that something along those lines might
be a nice middle ground.
> Please do keep at this, if you can pull it off I think it will improve
> the sponsoring greatly.
Final question for you and everyone else - do we think it's worth trying to
get this onto a Debian machine at some stage (as in, do you think the
project proper should give it's support to this), or should it stay as a
DD-supported external service (like mentors.d.n)?
- Matt
Reply to: