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

Re: [tor-bugs] #3158 [Company]: Need a clearer policy about who gets ldap accounts



#3158: Need a clearer policy about who gets ldap accounts
---------------------+------------------------------------------------------
 Reporter:  arma     |          Owner:  phobos
     Type:  defect   |         Status:  new   
 Priority:  normal   |      Milestone:        
Component:  Company  |        Version:        
 Keywords:           |         Parent:        
   Points:           |   Actualpoints:        
---------------------+------------------------------------------------------

Comment(by rransom):

 I've thought about this some more, and I think giving out access to our
 main Git system more widely is a bad idea for several reasons:

  1. Our main Gitolite instance now manages the (plaintext) secteam repo,
 and there is a non-zero risk of someone successfully attacking Git,
 Gitolite, and/or our Gitolite configuration in order to access that repo.
 Every additional person with access to that Gitolite instance increases
 that risk (very) slightly.

  2. People may disappear, whether for months, years, or forever, and we
 will be reluctant to lock their accounts because that might discourage
 them from coming back.  What if someone who got an LDAP account years
 earlier accidentally discloses his SSH secret key and forgets to tell us?

  3. Currently, when someone needs a Git repository created on Tor's Git
 system, Sebastian creates it by hand.  This may mildly inconvenience him,
 and students will be aware of that and may be reluctant to ask for new
 repositories.  That, in turn, may decrease the amount of code they post in
 our Git system, which defeats one purpose of asking them to use it in the
 first place.

  4. If we give out access more widely, we will need to create Git
 repositories on git-rw.tpo more often.  At some point, repository creation
 will become automated -- and I ''do not'' trust a script to not break our
 Gitolite configuration in subtle, nasty ways.  This is the one part of
 âmore people should use git.tpoâ that really scares me.

 For now, I don't oppose putting this year's GSoC students' Git repos on
 our Git system; the drawbacks of doing that are not significant, and the
 potential benefits are significant.  (I suspect that some of them will end
 up maintaining âofficialâ repositories for us anyway by the end of the
 year.)

 But longer-term, we should set up a separate community-git.tpo (or
 similar), initially with accounts issued by hand but with Git repositories
 created by a user-accessible automated script.  We don't need a web
 interface for this beyond Gitweb; repository creation can be done over
 SSH.  (If we had a community-git server, I would move my personal Tor-
 related repositories to it immediately, partly because of issue 3 above
 and partly to dogfood the new system.)

 Once we have that system set up, we can reserve access to git-rw.tpo for
 people who either (a) currently have personal repos on our main Git system
 and use them routinely or (b) need to push to an âofficialâ repository (or
 pull from the secteam repository, if we keep using Git for that).

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3158#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs