Re: Mentors upload authentication
Stephen Gran, 2012-02-16 06:17:09 + : [...] Second, I think requiring all contributors on alioth to sign the DMUP is a very bad idea. We host some external project like SANE that have no reason to want to sign agreements about their usage of machines they'll never log in to. Even if we did think it was a good idea, account creation is entirely automatic and on demand - we have no way of ensuring people have read and agreed to something beyond adding a click through web page at creation time or something (ick!). Sorry I'm late, but FusionForge does provide a mechanism for restricting new accounts based on a I have read and agree to blah blah checkbox. But that only applies to account creation, not to existing accounts. Roland. -- Roland Mas Depuis 1977. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871up1h7kt@mirexpress.internal.placard.fr.eu.org
Re: Mentors upload authentication
]] Michael Gilbert In this case, I think it would be possible to use ssh public keys as that authentication. The process would be: This seems overly complex, why not just have the user put all those files in a well-known location on alioth (or some other host) and have the mentors code download and DTRT with that bunch of files. As for removing non-distributable files, that's not something we're going to entrust to another team, any such removal requests will go through admin@alioth. [...] 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. That a machine is not subject to agreement to the DMUP does not mean any other use of said machine is ok. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nukjip2@qurzaw.varnish-software.com
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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnyvd1njinyo2d2yfspdqc5yzraqrw3b8hd18y_fut...@mail.gmail.com
Re: Mentors upload authentication
This one time, at band camp, Michael Gilbert said: On Thu, Feb 16, 2012 at 1:17 AM, Stephen Gran wrote: This one time, at band camp, Michael Gilbert said: Based on discussion about making mentors official, one of the key requirements is contributor DMUP agreement and upload authentication. I think that there are two main problems with this idea: First, alioth, while having an infrastructure for ssh keys, doesn't know anything about gpg keyrings and signed packages and so on, so all of that work still has to be done (and this is the hard bit - distributing ssh public keys is easy). 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. Second, I think requiring all contributors on alioth to sign the DMUP is a very bad idea. Alioth is Debian machine, and its listed on http://db.debian.org/machines.cgi, which is linked from the DMUP (http://www.debian.org/devel/dmup). I don't really understand why alioth is so special that it deserves a free pass from the DMUP. It's a rather non-demanding agreement anyway. Just to be a bit more clear, of course DDs and DMs who've already agreed to the DMUP shouldn't have to do it again. 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. Yes, the 2 machines that make up the alioth service are in the normal debian ldap, as are several other non-DSA admin'ed machines (exodar, strauss, sumotsu, etc). You don't need to sign the DMUP to use those machines either, as far as I'm aware. Their presence in LDAP is an implementation detail of the system that exports accounts to the machines. We host some external project like SANE that have no reason to want to sign agreements about their usage of machines they'll never log in to. 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. Even if we did think it was a good idea, account creation is entirely automatic and on demand - we have no way of ensuring people have read and agreed to something beyond adding a click through web page at creation time or something (ick!). 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. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Mentors upload authentication
On Thu, Feb 16, 2012 at 1:17 AM, Stephen Gran wrote: This one time, at band camp, Michael Gilbert said: Based on discussion about making mentors official, one of the key requirements is contributor DMUP agreement and upload authentication. One thought I had recently was to move the file hosting functionality over to alioth, which already has the necessary authentication infrastructure. The process from a contributors perspective then would be something like: I think that there are two main problems with this idea: First, alioth, while having an infrastructure for ssh keys, doesn't know anything about gpg keyrings and signed packages and so on, so all of that work still has to be done (and this is the hard bit - distributing ssh public keys is easy). True, ssh pubkeys could be used as the authentication mechanism on mentors anyway. The issue is that mentor's isn't designed or intended to have users with full shell accounts. That's something much better served by a forge...like alioth. Also, ideally new contributors should be starting an alioth account anyway so they can start participating on teams. It would be nice if they only needed one account to participate in Debian (the alioth one). 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? Second, I think requiring all contributors on alioth to sign the DMUP is a very bad idea. Alioth is Debian machine, and its listed on http://db.debian.org/machines.cgi, which is linked from the DMUP (http://www.debian.org/devel/dmup). I don't really understand why alioth is so special that it deserves a free pass from the DMUP. It's a rather non-demanding agreement anyway. Just to be a bit more clear, of course DDs and DMs who've already agreed to the DMUP shouldn't have to do it again. We host some external project like SANE that have no reason to want to sign agreements about their usage of machines they'll never log in to. 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. Even if we did think it was a good idea, account creation is entirely automatic and on demand - we have no way of ensuring people have read and agreed to something beyond adding a click through web page at creation time or something (ick!). 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. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mn+ufqnn61a7fbkatxnd1+rcebbrwdnrw59mfy6lgl...@mail.gmail.com
Re: Mentors upload authentication
On Thu, Feb 16, 2012 at 7:53 PM, Michael Gilbert michael.s.gilb...@gmail.com wrote: On Thu, Feb 16, 2012 at 1:17 AM, Stephen Gran wrote: Even if we did think it was a good idea, account creation is entirely automatic and on demand - we have no way of ensuring people have read and agreed to something beyond adding a click through web page at creation time or something (ick!). 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. FYI, they actually require you to sign it before they will allow you to create a PPA (personal package archive) anyway. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajyzjmd-qxxqbtqmfut87dhsbsbuhdswsbm9i6opxxvs7by...@mail.gmail.com
Mentors upload authentication
Based on discussion about making mentors official, one of the key requirements is contributor DMUP agreement and upload authentication. One thought I had recently was to move the file hosting functionality over to alioth, which already has the necessary authentication infrastructure. The process from a contributors perspective then would be something like: 1. Contributor creates alioth account and signs DMUP (of course needs alioth to require DMUP signing requirement for -guest accounts first, which probably needs to be done there anyway) 2. Contributor [creates and] uploads public key to alioth 3. Contributor uploads their packages over ssh using public key auth, thus populating dirs like http://alioth.debian.org/~gilbert-guest. A dput.cf for this configuration looks something like this [unstable] fqdn = vasks.debian.org incoming = public_html/unstable progress_indicator = 2 method = scp allow_unsigned_uploads = 0 allowed_distributions = (.*) 4. debexpo scrapes and parses all packages found in -guest account dirs, then presents info on its pages mostly like it currently does 5. Contributor then sends sponsorship-requests mail with references to their packages on alioth. This makes debexpo/mentors itself quite a bit simpler, and reuses existing infrastructure. Both of which I think are good goals. Anyway, just a crazy idea I wanted to get out there. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mo9aphw-rtx8k9vjpcyyjx05-+y51zowvmmdz0vxvn...@mail.gmail.com
Re: Mentors upload authentication
I don't think that will work, since you need to be in a project to get SSH access to alioth: http://wiki.debian.org/Alioth/SSH#I.27m_unable_to_Connect_via_SSH.2C_... -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6FHL=4vgmub+ia7t+ckiggz8e9p+yhb0dxpjfdubu9...@mail.gmail.com
Re: Mentors upload authentication
On Wed, Feb 15, 2012 at 10:30 PM, Paul Wise wrote: I don't think that will work, since you need to be in a project to get SSH access to alioth: http://wiki.debian.org/Alioth/SSH#I.27m_unable_to_Connect_via_SSH.2C_... They could be made part of a new contributors project to start them out. Perhaps that would be temporary (a month max or something) with encouragement to get on a real project, and watched a bit more closely than other accounts to detect possibly malicious actions? Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNj+Oa9nQ3qAWZpWSwie+Y=e-e_ch60kkdemw4mhd1...@mail.gmail.com
Re: Mentors upload authentication
This one time, at band camp, Michael Gilbert said: Based on discussion about making mentors official, one of the key requirements is contributor DMUP agreement and upload authentication. One thought I had recently was to move the file hosting functionality over to alioth, which already has the necessary authentication infrastructure. The process from a contributors perspective then would be something like: I think that there are two main problems with this idea: First, alioth, while having an infrastructure for ssh keys, doesn't know anything about gpg keyrings and signed packages and so on, so all of that work still has to be done (and this is the hard bit - distributing ssh public keys is easy). Second, I think requiring all contributors on alioth to sign the DMUP is a very bad idea. We host some external project like SANE that have no reason to want to sign agreements about their usage of machines they'll never log in to. Even if we did think it was a good idea, account creation is entirely automatic and on demand - we have no way of ensuring people have read and agreed to something beyond adding a click through web page at creation time or something (ick!). So, I think this doesn't sound like a good fit to me, sorry. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
