Re: Minutes for Directors Meeting of May 5th, 2007



[ 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]