551752 - need to set up private repo(s) for landing security patches

Status: RESOLVED FIXED

(mozilla.org Graveyard :: Server Operations, task, P1)

Description

[chris hofmann]

more details on why this is needed in the top level tracking bug.

first step is to set up a repo that is combination of security patches and mozilla central.

later we might expand the repo's to active maintenance branches.

Comment 1

[Al Billings [:abillings - ex-MoCo]]

I don't think that's a "might" as we aren't really protecting the patches if we don't protect them when they are checked into branches.

Comment 2

[Chris AtLee [:catlee]]

If this bug is requesting private hg repos, then it should be flipped over to IT.

Who needs access to push/pull/see these repositories?

Comment 3

[chris hofmann]

bug  551750 is about getting hardware from IT.

this bug is about setting up the hg infrastructure on that hardware so that we can pull from the public trees and merge with the collection of checked in security patches.

then  bug  551756 is about throwing every bit of automated testing, and making builds available for "trusted" testing partners.

all members of the security group will need access.  we can probably extend to moco employees as well.

Comment 4

[chris hofmann]

so after discussions at a meeting on 3/15 it turns out we need 2 things for this bug

# private hg repo (IT)
# hgweb (IT)

Comment 5

[Daniel Veditz [:dveditz]]

aravind, mrz: this is the first step we need to work on a private security patches.

1. a trunk-parallel hg repo with access to MoCo employees and security group members.

2. a LDAP-protected (but not requiring VPN access) "hg.mozilla.org" instance or branch. Don't know if you can LDAP protect branches on that same server or if we need a separate domain, I leave that up to you. Again access should be MoCo employees and security group members.

A short-cut for "security group members" might be people with access to securitywiki.mozilla.org, or you can have people added by request (filing IT bugs).

Do we need 1 and 2 split into separate bugs?

Comment 6

[matthew zeier [:mrz]]

Major to IT means within 24 hours and I know we won't be able to hit that time frame.  What's a reasonable time frame for you?

Comment 7

[Daniel Veditz [:dveditz]]

This is the linchpin bug for this project, not much else can happen until this part is done. Can it happen this week?

Comment 8

[Aravind Gottipati [:aravind]]

There are a couple of questions here..

How does the current commit (http://www.mozilla.org/hacking/commit-access-policy/) policy apply to this?  Do I apply that policy on top of restricting access to moco employees and security group?

Are we going to re-use the same build/test infrastructure for this work?  Will we be re-using the same old cltbld, ffxbld accounts for this work?  

Can we limit everything to accessing this over ssh only?  Will these repos need all the bells and whistles that the current hg.m.o has?  (pushlog feeds, tree closure hooks, etc)?

If you need http access to this repo and if I throw the entire thing behind a basic http auth (against some ldap group), will the build/test infrastructure be able to handle it?

Comment 9

[Reed Loden [:reed]]

(answering a few of the questions that I know the answer to... leaving the others to releng and other people to answer)

(In reply to comment #8)
> How does the current commit
> (http://www.mozilla.org/hacking/commit-access-policy/) policy apply to this? 
> Do I apply that policy on top of restricting access to moco employees and
> security group?

Indeed. r/w access should be the same as the normal repositories. The only thing changing is read access, which should be restricted to MoCo employees and the security group. 

> Will these repos need
> all the bells and whistles that the current hg.m.o has?  (pushlog feeds, tree
> closure hooks, etc)?

Yep. Definitely need pushlog feeds and such. Not sure how often we'll use the tree closure stuff, but it's better to have it than not.

> If you need http access to this repo ...

We definitely need some type of HTTP access to the repository in order to view the pushlogs and so we can get tbpl to work with it.

Comment 10

[Daniel Veditz [:dveditz]]

As reed says, we're not granting extra access, we're restricting the visibility to a subset. We could possibly get away with not restricting commit ability since if anyone of our committers is malicious they could just check in bad code, but it's possibly safer to start with a subset so we don't get tripped up by people who don't understand the purpose of the branch.

The http-visible hgweb site, though, definitely needs to be restricted. More employees will need access than commiters (e.g. QA).

We do not need tbpl initially. It's currently not even hosted by us and I don't want to gate this project on getting tbpl hosted internally. Once we do have tbpl under our control it certainly would be nice to add to this branch (with restricted visibility, of course) but that can be done later. There's another bug covering tbpl on the security-patch branch (bug 553684).

Comment 11

[Daniel Veditz [:dveditz]]

Where are we with this? It wasn't "within 24hrs" last week, but a week later it's edging toward critical. Can't move forward until we have a repo.

Comment 12

[Aravind Gottipati [:aravind]]

(In reply to comment #11)
> Where are we with this? It wasn't "within 24hrs" last week, but a week later
> it's edging toward critical. Can't move forward until we have a repo.

Dan: I am waiting on feedback from build & release.  I need to know how they plan on accessing the repo etc.  I don't want to setup a bunch of this stuff only to change it all again.

Comment 13

[Al Billings [:abillings - ex-MoCo]]

Who specifically are you waiting for feedback from so we can ping them directly on this?

Comment 14

[Aravind Gottipati [:aravind]]

(In reply to comment #13)
> Who specifically are you waiting for feedback from so we can ping them directly
> on this?

I asked a bunch of stuff in comment 8, Reed answered some, I need responses on the remaining.  Things like what network will this be using, how will they be accessing it if its access controlled, ssh only access etc..

Comment 15

[Al Billings [:abillings - ex-MoCo]]

The point of my question was to get the specific names of who you need feedback from so we can make sure that they are CC'd and act on things.

Comment 16

[Aravind Gottipati [:aravind]]

(In reply to comment #15)
> The point of my question was to get the specific names of who you need feedback
> from so we can make sure that they are CC'd and act on things.

In comment 12, I said feedback from build and release.  And John is already copied on this bug.

Comment 17

[Al Billings [:abillings - ex-MoCo]]

"build and release" isn't a name. John is. So, we should be clear that we're waiting specifically for feedback from John O'Duinn then.

Comment 18

[Aravind Gottipati [:aravind]]

@Derek: need an external ip that pats (443 and 22) to 10.2.74.85 and 10.2.74.86

Comment 19

[Aravind Gottipati [:aravind]]

I am done with my scripts and ran through some basic tests, and it seems to be working okay.  However there are two ldap oddities we need to get things to work correctly.

Anyone that has to be able to checkin code needs to be in the cn=scm_sec_sensitive group and in the cn=SecurityWiki group.  The first group is needed for ssh checkins, the second is needed for https basic authentication.  I guess, on the plus side we could allow folks in the SecurityWiki group to just view code (and clone via https), if they don't care about checking stuff into the repos.

Comment 20

[Daniel Veditz [:dveditz]]

What other additional things does cn=scm_sec_sensitive group get someone, or is that a new grouping you set up for this task?

If it's an existing group I'm worried that its purpose might not wholly align with "people who need to check in security patches". If it's new that sounds great.

I'm a little ambivalent about re-using SecurityWiki access rather than a new group. It's certainly the list I'd have recommended to pre-populate any new group with so it's not terrible. We can always create a new group later if we need it, right?

Comment 21

[Aravind Gottipati [:aravind]]

(In reply to comment #20)
> If it's an existing group I'm worried that its purpose might not wholly align
> with "people who need to check in security patches". If it's new that sounds
> great.

Its a new group, whose sole purpose is to grant read/write access (via ssh) to these repos.

> It's certainly the list I'd have recommended to pre-populate any new
> group with so it's not terrible. We can always create a new group later if we
> need it, right?

Yup, it can be changed anytime.

Comment 22

[Daniel Veditz [:dveditz]]

dmoore, aravind: How are we coming with those IP addresses from comment 18 last week?

Comment 23

[Daniel Veditz [:dveditz]]

The repo itself only needs to contain the "mozilla-central" tree, not (for now) the 1.9.2/1.9.1 branch repos or anything else. Reusing the mozilla-central name will cause confusion, though. Let's call it "shadow-central", which makes it easy to expand to shadow-comm, shadow-1.9.2, etc. if we need to add branches in the future.

Comment 24

[Derek Moore [:dmoore]]

Per comment 18, we have created an external IP address which load balances SSH and HTTPS connections between the two internal servers:

63.245.209.141 (currently hg-pvt.services.acelb.mozilla.com, CNAME as needed)

Comment 25

[Aravind Gottipati [:aravind]]

hgpvt.mozilla.org is now ready and can be accessed over https and ssh.

The same rules as hg.mozilla.org apply, you need a .ssh/config file and set your e-mail address as your ssh username.

The domain allows user repos just like hg.mozilla.org.

Browsing over https will require a ldap login (you have to be in the securitywiki ldap group).

Cloning over ssh will require you to be in the scm_sec_sensitive ldap group.

Please test it and let me know if you notice stuff that isn't working.

Comment 26

[Daniel Veditz [:dveditz]]

filed bug 571325 on bleed-through from the hg.mozilla.org repo

Please also apply the patch in bug 571333 (fixes the mixed-mode bustage)