[Devel] A proposal for letting people SSH into the main machine and deploy new versions of the OpenHatch code

[Asheesh Laroia]

I think more people need access to be able to deploy new versions of the 
OpenHatch code. More people also need access to information that helps 
them develop, even if comes at a possible cost of those people being able 
to get a copy of the personal information that people entrust to us.

PURPOSE OF THIS EMAIL

I want to grant shell access to the "deploy" user, and to things like 
session IDs, to more people. There are some people who have been 
contributing who seem quite trustworthy, and I want to empower them to 
make the site better faster, without me as a bottleneck.

I want to get y'all's feeling about it. If no one raises an objection by 
the end of the Saturday meeting, then I will make it a reality. I'm happy 
to hear suggestions to improve the process.

BACKGROUND

So, right now, there are a few people with shell access to the 'deploy' 
account:

* Asheesh Laroia
* Parker Phinney
* John Stumpo
* Raphael Krut-Landau

Only one of those is actually active. All four are "trusted" with the 
ability to deploy new code and read the live database.

Here's how it worked in the past: If Asheesh thought it made sense for you 
to get shell access, then you could have it. Back when OpenHatch, 
Incorporated, was the primary entity contributing to the codebase, this 
especially made sense. John was a Summer of Code student; Parker was an 
intern (you can read about that on the OpenHatch blog!). Raffi and I were 
co-founders.

Maybe we should delete some of the people who aren't me... actually, I'll 
do that right now. Done.

I asked people, informally, to be trustworthy with access. I think they 
were.

The privacy policy at https://openhatch.org/policies-etc/ seems to be in 
line with the above situation.

PROPOSAL

Let's formalize the above system. To get shell access to deploy at linode, 
you will have to:

* Agree to reasonable machine usage policies and to respect users' 
privacy, and not impersonate people maliciously. (I'd like to have a 
write-up of what this means for us. I thought, at first, that we could 
copy http://www.debian.org/devel/dmup but it's not quite as relevant as I 
thought. The write-up should be short, maybe between 1 and 12 sentences in 
length.)

* Email me, and I will say "yes" or "no" within 5 days, and give you a 
reason why I said 'yes' or 'no'.

RATIONALE

This is a simple process, and everyone who has access has to go through me 
for now so that I feel comfortable granting it. Hopefully I won't be a 
bottleneck at that point.

We could be more democratic, but I kind of don't want to be, if that's 
okay.

ADDENDUM: EMAILS THAT ARE POSSIBLY SENSITIVE

Right now, also, when there are exceptions that the live site hits, Django 
emails me, and then I stare at the emails with dread. I don't forward them 
along to public mailing lists because they contain session IDs, which are 
enough information for anyone with the session ID to log in as the user 
who caused the exception. The same thing happens with Roundup, when 
Roundup hits an exception.

Let's do the same thing as above for that: emails that might contain e.g. 
session IDs will go to the [Monitoring-private] list, which will have a 
private archive. Once you agree to be nice, then I'll subscribe you to 
that list.

ADDENDUM: ROOT ACCESS

Same process as for 'deploy at linode'.

-- 
-- Asheesh.

http://asheesh.org/

You will stop at nothing to reach your objective, but only because your
brakes are defective.