I'm not really sure of where to request this, so please redirect me if I'm wrong. I'm trying to figure out if we can make it easier for newbies to get involved in mozilla. One nasty step is that newbies who provide patches are generally asked to push to tryserver, which they have no access to. And so begins the dance of frustration as they try to get people who have other priorities to push for them. I'd like to remove this bottleneck, or at least improve it. What are the reasons for requiring level 1 access? Off the top of my head: - it needs ssh keys - it gets the contributor agreement - fear of DDOS I don't believe any of these are important enough to introduce this bottleneck.

It's not just DDOS, they can run arbitrary code inside the build network. AIUI that's why this has been WONTFIXed in the past.

How about the level 0 proposal here? http://groups.google.com/group/mozilla.dev.planning/msg/c1f4877943a01620

This has been WONTFIXED in the past, for precisely the reason Kyle gives. Securing this is hard. The Level 0 proposal doesn't adequately match the downside for Mozilla (compromise of our internal network) with the reputational risk to the individual. If some community member signs off on harmful code, and we get rooted, they can just shrug their shoulders and say "well, it was well hidden". I suspect you will not get infrasec to sign off on that. Is there a way we can make it not necessary for them to push-to-try, for example doing local builds and tests? Gerv

(In reply to comment #3) > Is there a way we can make it not necessary for them to push-to-try, for > example doing local builds and tests? Bug 616089 suggests: > * A link on the desktop to run test suites against the last local build

(In reply to comment #3) > This has been WONTFIXED in the past, for precisely the reason Kyle gives. > Securing this is hard. Right. The ways through this that I can think of are: - enable tryserver stuff to run on EC2, with each build in it's own VM - set up appropriate sandboxes In other words, long term at best, if we can get appropriate people on board. And to be honest, since these are pretty big changes, I'm not convinced of the trade-offs. I'm thinking a better way to achieve the same goal is to optimize the pipeline for getting level 1 access. Gerv, I think you know something about setting up a website for doing this? > Is there a way we can make it not necessary for them to push-to-try, for > example doing local builds and tests? Sort of. This can lead to backouts, which will scare newcomers off. And also, in general we should aim to make the same facilities available to new contributors as new employees.

Getting Level 1 access isn't terribly difficult. Besides the committer's agreement (which AIUI is required for legal reasons) all someone has to do is post an ssh key in a bug and get a voucher. I, at least, will vouch for L1 access for anyone who's made at least one substantive patch, so the bar here isn't too high. I think a large part of the difficulty here is that people don't know when it's appropriate to ask for commit access. Back in the days of the old commit policy (the one that required sr, and a vouch from someone who hadn't read your code) I contributed for almost a year before getting commit access and didn't dare ask for it before I was told by somebody that I should get it. The barriers here are: 1. New contributors have to learn that the tryserver and L1 access exist 2. ........................ work up the nerve to ask for it. 3. ........................ find a voucher. 4. ........................ submit an SSH key. 5. ........................ submit the committer's agreement. Recently I've filed a few bugs for L1 access for new contributors that I'm aware of and who should be taking advantage of L1 access. If an existing project member files a bug for L1 access that eliminates barriers 1-3 above. I think the real solution here is to make this practice more widespread.

E.g. Bug 647506

tl;dr for my post above: we should be giving new contributors access to the tryserver, not making people come request it from us.

(In reply to comment #5) > I'm thinking a better way to achieve the same goal is to optimize the pipeline > for getting level 1 access. Gerv, I think you know something about setting up > a website for doing this? Well, there was talk of a website for a click-through for the Committer's Agreement, but it's currently vapourware. The current rules are pretty good - then even allow taking a digital photo of your signed form and attaching it to your access bug: http://www.mozilla.org/hacking/notification/ So the process is: - File a bug asking for L1 access - Fill in the form and submit it using any of the methods available - Get another person in the community with L2 access or above to vouch for you - Profit Gerv

I think at the backend, there are many humans in the loop, which means we are subject to PTO, weekends, time zones, etc. I had hoped the website would automate this somehow, but that's probably difficult. Let me see if I can look through old l1 requests and see how long they take. I perceive they take multiple days, but perhaps I'm mistaken.

We can't automate it because there has to be a human involved - if it were automatable, then it would be the same as having it open to anyone. A human has to vouch for the person, and a human has to create the account. There should be multiple people who can do those roles, in both cases - if it's not true, e.g. in IT, then we need to ask IT to fix that. But I'm pretty sure it is. Gerv

The site could require the voucher to log in using their LDAP credentials to vouch, so it would have the same security as the current implementation. But let me do some research here before we move this along. I want to figure out where the bottlenecks are. My suspicions are (copying khuey's chart): 1. New contributors have to learn that the tryserver and L1 access exist 2. ........................ work up the nerve to ask for it. 3. ........................ [explicitly ask or CC] a voucher. 6. Human process behind the scenes. If it's 1-3, I don't want to incorrectly malign those involved in step 6.

sfink suggested something like the following: - new contributors (without level 1 access) would push to tryserver - their jobs would be held in a queue, visible on tbpl - tbpl users could view the job, and authorize it using their LDAP credentials Politically and technically, how possible is this?

The tbpl functionality would be handy for automating LandingQueues for production repos, too. if (SSH key is the public one) hold_in_queue = true else if status is METERED hold_in_queue = true Then sheriffs could allow things through by accepting them from the moderation queue. This isn't as nice as it sounds, since current practice also includes people queuing up before their patches are 100% ready and other shenanigans. But it would still provide a nice part of the solution. Heck, it would even serve as a base for automated metering (eg once the robot sees enough greens, it grabs the next push from the queue. Or it just waits N minutes between pushes. Whatever is needed for the current variety of breakage that necessitated the metering in the first place.)

(In reply to comment #13) > sfink suggested something like the following: > > - new contributors (without level 1 access) would push to tryserver > - their jobs would be held in a queue, visible on tbpl > - tbpl users could view the job, and authorize it using their LDAP credentials > > Politically and technically, how possible is this? Surely if someone has Level 2 (normal) access, and they trust this person to push to try, they could just vouch for the person to get Level 1 access and then it wouldn't need this system? The risk of the above is that it means people will just say "yeah, sure, it's probably OK" for people they don't know very well, and it unacceptably raises the risk. You can't get around the fact that pushing to try requires a certain level of trust in a person, except by fixing the try server to be sandboxed - and that's hard (so I'm told). Gerv

(In reply to comment #15) > You can't get around the fact that pushing to try requires a certain > level of trust in a person I think the point is that the pusher would be able to give the code a once-over, rather than having to trust the individual.

(In reply to comment #15) > Surely if someone has Level 2 (normal) access, and they trust this person to > push to try, they could just vouch for the person to get Level 1 access and > then it wouldn't need this system? Yes, absolutely. This mechanism is for people a level 2 user does *not* trust enough yet. "Level x access" is a shorthand. It says "we trust all of this user's pushes". The security question here is only relative to pushes, not people (pushers). So the proposal is that in situations where we are not willing to trust a push to be safe based on the identity of the pusher, that we have a fallback mechanism to mark the push itself as trusted. What is required to mark a push as trusted is debatable. A level 2 user can vouch for the push's safety. Should a level 1 user be able to as well? After all, if they're ok with it they have the rights to push it themselves. But I'm more comfortable with vouching that somebody won't push harmful code than I am vouching that somebody is capable of detecting harmful code in others' pushes, so I'd be ok with saying that level 2 is required for moderating (accepting things in the queue.) > The risk of the above is that it means people will just say "yeah, sure, it's > probably OK" for people they don't know very well, and it unacceptably raises > the risk. You can't get around the fact that pushing to try requires a certain > level of trust in a person, except by fixing the try server to be sandboxed - > and that's hard (so I'm told). No, pushing to try requires a certain level of trust in the code being pushed. So you're right; what you describe above *is* the risk, but I don't see why it can't be adequately mitigated by making sure that per-push vouchers recognize what they are doing (and in the interface, making sure they see the code they're accepting before allowing it through.) I'm skeptical of sandboxing as an entire solution, though it might be nice for requiring a little less trust here and there. Still, I see it as more useful for incompetence than for malice.

Well, I'm still not convinced, but that's OK because it's not my call :-) It's infrasec you will need to convince. Gerv