Re: Multi-person sponsorship
Matthew Palmer <mpalmer@debian.org> writes:
> 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.
That was what I had in mind, just everyone in the sponsoring group, or
any DD, should be able to add or remove keys.
Or accept any key signed by a DD or something that won#t be as hard as
becoming a DD itself.
> > 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.
Whatever the name. I was just reminded that a NM keyring would be
usefull for tracking the NMs packages and similar jobs. The AM checks
the signatures and ID. If there is NM keyring the AM adds the key to
you would have some security and someone directly responsible for
adding the key for each NM without being overworked.
> > 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).
I was more thinking along the line of having at least i386, ppc and
alpha or amd64. i386 (or ppc) should usually cover having the same
system the uploader had. ppc has different chars (and endianness i
think) and alpha/amd64 for a 64 bit arch. Shouldn't be hard to get
those.
> > > 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.
For signing the build log (sbuild includes the changes file) or the
changes file is needed. For testing or fetching source a repository is
easiest to install, at least thats what I came to for my own
packages.
> > > * 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.
Then a tar containing all files would probably be best. If they have
the debs on the harddisk anyway they probably try them. But you would
need multiple tar packages, one per arch or one big one (which would
be wastefull).
> > 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).
Put all changes files in one dir. A small cgi or php script can then
look for all *.changes and *.state files and generate a list of
available packages. If a sponsor takes the package (clicks at the
"take" or "take 1 week" button) you write the username and timestamp
when it will be given back into <package>.state. The cgi/php script
can use the username and timestamp to say who has a package and when
it will be given back or if its free to take (e.g. taken packages
would have the user and time instead of the buttons).
A cron job could remove changes and state files of uploaded packages
by comparing the main archives Sources files against the packages on
disk (a simple grep-dctrl call per package).
As long as there are just a bunch of packages (say <100) in the list
that should do just fine. For more packages the list should probably
be cached to save time.
I don't think you need to worry about a full database or reference
counting or such there.
> > > * 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>
Check the buildds mail watcher.
> > > * 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.
Actions could be:
Take: click at webpage
Accepted: upload entered the archive (automatic)
New Upload: newer source was uploaded (automatic)
Rejected: sponsor gave a failure reason (mail or web interface)
Give back: failure without reason could double for that
States could be:
_Free_
/| |\
/ \
timeout/give back \ new upload
take \
/ \
|/_ \
Taken --- reject ---> Failed
> > 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.
What if you set the proxy to the real repository? The proxy auth would
then be used there. Or is that crazy?
or just plain deb http://user:pass@host/?
The buildds do it somehow, ask someone from the buildd team about
it. Could be they just limit it to ip and ident.
> > 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
MfG
Goswin
Reply to: