Re: Mentors upload authentication
On Sat, Feb 18, 2012 at 5:27 AM, Stephen Gran wrote:
>> In terms of gpg public keys, the user could simply upload theirs to a
>> public_html alioth location, which would allow the mentors scraping
>> algorithms to pick that up. That process itself would be rather
>> simple, and could be documented in a set of wiki instructions. Why
>> are you thinking that's going to be hard?
>
> Most people go to a lot more trouble to make sure gpg signatures are
> valid and trustworthy than just downloading them from a random home
> directory on a machine where accounts are created on demand. I'm not
> sure what level of identification you're looking for here, but that
> seems so trivial to subvert it makes me think you'd be better off
> without it.
>
> I'm assuming that the backstory here is that ftpmaster want signed and
> identifiable uploads. I think this idea fails that test, myself.
Here is my interpretation: the back story is that ftpmaster needs a
record of users' agreement to not put non-distributable material on
debian machines. That means that users need to agree to the DMUP, and
when they upload material, it needs to be authenticated that it is
from the same person that signed that agreement. Hopefully I got that
right?
In this case, I think it would be possible to use ssh public keys as
that authentication. The process would be:
1. User signs and uploads the DMUP to alioth via web interface
2. User signs and uploads ssh public key to alioth via web interface
3. User uploads gpg public key to a public area in their alioth
account (or maybe web interface again)
4. User uploads packages to a public area in their account [note that
their gpg key is not checked in this step]
5. Mentors scrapes packages and gpg key info from alioth public space
(probably gathering file locations from a config file that users put
in their home dir)
6. Mentors flags (and sends an email about) improperly signed
packages based on the info it scraped from alioth
7. Mentors only presents properly signed packages to prospective sponsors
8. Flagged packages on alioth get reviewed by someone from team, and
removed if they're found non-distributable
> Just to be clear, alioth is not a regular debian.org machine. It isn't
> admined by the same team, accounts are not handled in the same way,
> and privileged groups on Debian machines have no special privilege on
> alioth machines.
I understand that, but I don't see how that has to do with the DMUP,
which is a usage policy intended for debian machines of which alioth
is one. Otherwise, it seems like it fine to misuse alioth in ways
that violate the DMUP, but not any other machine.
>> I don't think it would be that arduous for external contributors to
>> sign the DMUP as it's a rather non-demanding and sane document anyway.
>
> I do believe it will be arduous to go find all the people who currently
> use alioth who are not DDs and ask them to sign something in order to
> retain their access to a service they use.
You could "grandfather" existing users to avoid that.
>> You could change your process to do something like launchpad with
>> their code of conduct (i.e. contributors can/should gpg sign and
>> upload it). That is optional on launchpad, but I think it should be
>> required for the DMUP.
>
> To recap, I still don't think alioth is a good fit for this. I think
> you're trying to shoehorn something that works with launchpad onto an
> entirely different system, and it doesn't fit very well for a variety of
> reasons.
My inspiration for this process is not from launchpad at all. That
was just an example of how to avoid a mindless "click-through" DMUP
agreement process.
Best wishes,
Mike
Reply to: