[ If it is regarding some technical detail, please follow up to gnome-infrastructure (reply-to set to that). ]
On Tue, Jun 03, 2008 at 11:46:04PM -0700, Luis Villa wrote: > * Accounts team > ACTION: vincent to ask around who can extend/develop mango to > automate accounts creation I'd really love if someone could add any of the following to Mango: * Usability of new accounts process * General cleanup of the code (lots of classes look the same) * Some sort of *secure* ACL design: * Allowing maintainers to add/remove maintainers for *only* the modules they are a maintainer of * Allowing people from the foundation membership committee to edit parts of a user (@gnome.org email alias and the foundation fields + group) * Allowing users to edit their details * Addition of GPG keys, use this for login? * Use SSH public key data for verification / login? * Moving foundation info to LDAP * General LDAP advice (see email in gnome-infrastructure) * Requesting additional permissions by people with an LDAP account. More detail: Usability of new accounts process It just shows the group name when someone requests access. For SVN it is still called 'gnomecvs'. There should be descriptions for this. Further the annoyance of assigning maintainers, getting/resetting passwords (move to GPG for login?). Also, the login page should check if the user is a maintainer/l10n coordinator. If so, it should say there aren't any requests. Requesting additional permissions Currently people can request a new account, and that process is theoretically ok. If they already have an account, then they might want some new permission. E.g. 'gnomeweb' group (user used for most web sites). Secure ACL: Basically I want different levels of access, somewhat configurable and not too hard coded. For a user I can think of: * sysadmin can do anything * accounts people are more limited (cannot assign new accounts people) * membership committee members can edit just foundation stuff, plus some fields have to be hidden (note that the XML is transformed into HTML by the client, so doesn't involve just changing the XSLT). * user themselves. I don't trust password Allowing maintainers to add/remove other maintainers Only for the modules they are currently maintainer of. This is different from developer status (which is not recorded/stored). This would remove the need for ugly MAINTAINERS file parsing (or the whole file altogether). Don't know what solution to follow for a new module. Emailing accounts@ would work, but perhaps nasty (the idea is that you can create repos without needing to email people). Perhaps hacky script that checks for new SVN modules daily and assigns maintainer status to the first committer (other than 'root' or 'gnomecvs'). Allowing users to edit their details I don't want that SSH keys can be changed with just a password. Or the email address (we currently assume the email address is secure). Because it is a manual process now, the security requirements are currently less than what is needed in future. This as a system cannot determine if a request is strange. This is why I need it to be secure (not about not trusting people with a GNOME account, it is the possibility of their details being changed by people other than them.. insecure browsers, stored/sniffed passwords, stolen laptops, etc). Addition of GPG keys No idea how to handle these. Personally, I'd rather store the whole GPG public data in LDAP and then use that key when encrypting. This ignores the whole web of trust, etc. However, it seems it is hard to do something like that. GPG seems to want a recipient instead of just passing in a public key. Also not sure how to handle the initial adding of GPG keys. Using SSH public key data Using the data in SSH public keys, it should be possible to encrypt something that only can be decrypted with the SSH private key. Or the other way around. Not exactly sure how feasible this is. Python-paramiko has some 'sign' stuff. Unfortunately Mango is in PHP. Plus this might be annoying for Windows users. Moving foundattion info to LDAP Not sure about LDAP structure, etc. My plans are in Bugzilla: http://bugzilla.gnome.org/buglist.cgi?product=sysadmin&bug_status=NEW,REOPENED,ASSIGNED,UNCONFIRMED&component=mango -- Regards, Olav _______________________________________________ foundation-list mailing list foundation-list@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-list