Guido van Rossum wrote:
I hope we're correctly estimating the effort required to manage the server and the users. Managing users is especially important -- if a user is compromised (as has happened in the past for python.org users) the whole repository is compromised. Now this could happen to SF users too, but I'm not sure that we know all the tricks in the book to prevent attacks; SF has been doing this for years and that's an aspect of SF that I trust (I think I've heard that they have even modified their SSH server to be stricter).
There are three issues that I see: - management of access control. This is actually something that we do on SF as well; if the pydotorg admins get overloaded, I'm sure the current projects/python admins would be willing to help there. - assignment of passwords. This I don't like about the current pydotorg setup - there should be a way to chose your own password; perhaps without involving an administrator. I could imagine a web form for password change, and administrator interaction in case of a lost password. - compromised passwords. The only tricky question then is: was the repository altered? Fortunately, for Subversion, there should be an easy way to tell: in fsfs, files never change (only new files are added). So we could generate md5sums of all files in the repository, and download these to an offsite place. If the md5sum of an immutable file changes, we were compromised (there are, of course, a few files that do change regularly). Of course, we also need regular backups of the entire data so we can restore them if they got compromised.