Opened 8 years ago

Closed 7 years ago

#3158 closed defect (implemented)

Need a clearer policy about who gets ldap accounts

Reported by: arma Owned by: phobos
Priority: Medium Milestone:
Component: Company Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

atagar and I want to give torproject git repos to all the gsoc students.

I believe one needs a tor ldap account in order to get a tor git repo. True/false?

A while ago there was a concern about giving ldap accounts to people just to give them a git repo: "doesn't having an ldap account mean you can access systems you shouldn't need to access?" I believe it was resolved with "no, the list of who can access which system is a separate list."

Sebastian tells us that a consensus was reached at the Feb dev mtg about heuristics for who should get an ldap account. Great.

Nick and I don't remember it though. Once we collectively remember, we should write it down somewhere. (Where?)

Child Tickets

Change History (18)

comment:1 Changed 8 years ago by Sebastian

iirc correctly the idea was "think about a person who should get access, and how to identify their gpg key. Mail the suggestion to tor-internal. if nobody objects after some time (we left that kind of open), create the account. If someone objects, fight a bit, reach consensus, move on"

comment:2 in reply to:  description Changed 8 years ago by Sebastian

Replying to arma:

I believe one needs a tor ldap account in order to get a tor git repo. True/false?

true

A while ago there was a concern about giving ldap accounts to people just to give them a git repo: "doesn't having an ldap account mean you can access systems you shouldn't need to access?" I believe it was resolved with "no, the list of who can access which system is a separate list."

The concern is more that anyone who has an ldap account with git access has git access, so if they pwn git they can clobber all our official repositories without any additional linux exploit.

comment:3 Changed 8 years ago by rransom

I noticed when I received access to the Tor Git server that I had read access to the gitolite-admin repo, which contains the complete history of the list of all Git repos on git-rw.tpo and who has access to them. (I confirmed that I had read access using ‘git ls-remote’, not ‘git clone’ or any other command that would have actually retrieved the repository contents.) If there is anything sensitive in there, we should restrict access to that repository before handing out LDAP accounts and Git access to people we know less well.

comment:4 Changed 8 years ago 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.
  1. 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?
  1. 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.
  1. 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).

comment:5 Changed 8 years ago by atagar

But longer-term, we should set up a separate community-git.tpo

I really like this idea, though with the addition that we should move all of the personal repos there. This would clean up the unpleasantly cluttered gitweb landing page (making it more newcomer friendly) and also allow us to drop ldap credentials entirely when a person no longer needs push access to official repos without cutting them off from personal repos.

If we don't have some account (and repo?) removal policy then I agree that point #2 will be an issue. The svn repo seems to be an example of this, such that over the years its accumulated several projects I've never heard of (torwall? torpedo? bsockets?) and who knows how many accounts.

Cheers! -Damian

comment:6 in reply to:  4 Changed 8 years ago by sjmurdoch

Replying to rransom:

But longer-term, we should set up a separate community-git.tpo (or similar)

An alternative we could consider is to set up a GitHub "organization" under which we can put community-run projects which are somehow part of the Tor ecosystem. People with GitHub accounts could be easily added to the access-control-lists ("teams") by a Tor administrator and people can fork projects without having to ask for permission.

One downside of this (and the community-git.tpo) approach is to differentiate between Tor Inc. and non-Tor Inc. projects. Another which only affects using GitHub is that it could go down permanently or temporarily. We could mitigate this problem by having automated backups.

Setting up an organization is free for open-source projects and you get 0.3 Gb for repositories (but this can be extended if a case is made). I've done it for the CTSRD TESLA project: https://github.com/CTSRD-TESLA/

comment:7 Changed 8 years ago by arma

Another thought is that personal repositories should in general go elsewhere (that set of people could explode without bound), whereas *project* repositories are quite reasonable to put on git.torproject.org, along with an ldap account for the person pushes to it.

Then Tor community people who write patches for existing projects can put them wherever they like, and it's not awkward because that's what most people do.

I wonder if that last sentence will actually work. :)

comment:8 Changed 8 years ago by phobos

I vote for personal repos on gitorious.org, under a torproject organization. Official projects can also be mirrored there, but they really go on git.tpo.

As for gitorious over github, gitorious is a free as in freedom network service and we have some hope of getting all of our code out of it should we decide to migrate. Github is facebook for coders, proprietary, and generally a black box. Gitorious is also free for open source projects with no limits on accounts, repos, or storage.

comment:9 Changed 8 years ago by phobos

I'm not sure of next steps. I think the answer is, we're not going to host random projects for the world. As I said 8 months ago, use gitorious.

comment:10 Changed 8 years ago by phobos

I talked to gitorious. We can host torproject.gitorious.org and get users setup there as needed. This lets us host everything related to tor in one spot, and avoids the ldap overhead for non-core projects. The gitorious repos can clone and mirror our official repos for the sake of completeness.

comment:11 Changed 8 years ago by phobos

And now we have three outstanding "get X an ldap account" requests and zero resolutions.

comment:12 Changed 8 years ago by phobos

And clearly this discussion isn't done, as seen in comments of #5260.

comment:13 Changed 8 years ago by arma

I believe the policy that has emerged is:

  • If you need to be able to push to a torproject project git repo (as is the case in #5260), then we need to make an ldap account for you.
  • If you are a committer for a torproject git repo where somebody else is the maintainer (meaning you do not push to the torproject project git repo), then it's not necessary to have an ldap account. It comes down to a judgement call about community integration, how active a committer you are, expected future participation, etc.

comment:14 in reply to:  13 ; Changed 8 years ago by phobos

Replying to arma:

I believe the policy that has emerged is:

  • If you need to be able to push to a torproject project git repo (as is the case in #5260), then we need to make an ldap account for you.
  • If you are a committer for a torproject git repo where somebody else is the maintainer (meaning you do not push to the torproject project git repo), then it's not necessary to have an ldap account. It comes down to a judgement call about community integration, how active a committer you are, expected future participation, etc.

Do we then purge ldap accounts if you haven't committed in X days? Where X could be > 180?

comment:15 in reply to:  14 Changed 8 years ago by nickm

Replying to phobos:

Do we then purge ldap accounts if you haven't committed in X days? Where X could be > 180?

I'd vote for locking accounts over purging them, if that's an option. Six months from last commit, or from the announcement of this policy, whichever comes later, seems about right.

comment:16 Changed 8 years ago by phobos

How about this:

  1. Every new account has to have a sponsor. The sponsor must be someone who has signed keys by Roger, Andrew, Peter, or Nick. Practically, this means we've met the sponsor and talked to them long enough to sign keys.
  1. The sponsor is responsible for introducing the person to the LDAP system, getting the new account keys into the system, and generally shepherding the person into the system for LDAP, git, etc.
  1. If the new account hasn't committed any code in git or svn in 180 days, their account is locked from commits. If the person hasn't done anything related to Tor in 360 days, their LDAP account is locked.

comment:17 Changed 8 years ago by phobos

Another thought is that the sponsor is responsible for keeping the person part of the community, etc. I have no idea how to enforce this, or even reference it in LDAP, but it should keep the people who just want a 1-time patch committed from getting LDAP accounts, and should keep people engaged if they really care about a project or part of Tor.

comment:18 Changed 7 years ago by phobos

Resolution: implemented
Status: newclosed

My last two comments appear to be the policy. Closing until we decided to revisit this yet again.

Note: See TracTickets for help on using tickets.