Re: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure
On Tue, Apr 30, 2013 at 5:59 AM, Daniel Shahaf wrote: > (note CC list) > > Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 18:56:01 -0700: > > @Daniel, > > > > Right, this is about poisoning the committer keys but not touching the > > SVN, instead, counterfeiting a binary release downstream, but faking > > the asc, md5, and sha1 too. (These would not be at dist, and depend > > ASF mirrors do not contain .asc, .md5, .sha1 files. We should probably > verify that in our regular checks, if we don't do so already. > > Assuming "real mirrors have no .md5/.asc files" holds, assuming a user > downloads a rogue .md5 means either the user is using a rogue download > page or there's a rogue .md5 in https://www.apache.org/dist/openoffice/ > --- these are both acceptable risks (the latter because it will have > generated a commit mail which the PMC is supposed to catch). > > > on folks not noticing because the instructions for how to check > > correctly are so obscure. It is very far-fetched, since there are > > easier exploits that rely on user's not being equipped to verify what > > they are getting and not relying on the authentic download location. > > > > > Another way would be to attack the release candidate in the release > > manager's ASF FreeBSD account, although someone who checks the > > signature might notice that it is by an unexpected committer. Again, > > reasonably far-fetched. Two committers would have to be compromised, > > or the Release Manager would have to be compromised and not notice > > that there is a new fingerprint in the RM's profile. I like that last > > one. It has a certain movie-plot plausibility. Who ever looks for > > funny business in their profile, or odd materials in their keys entry? > > Everyone. The PMC is REQUIRED to verify the .asc files in a release > before voting on it. That means verifying it's signed by the correct > key, too. > > Daniel > Thanks Daniel -- copying private@openoffice on this reply so the PMC makes note of this. > > (Note that it is the binaries that are compromised, there is no > > messing with the source tarballs.) > > > > - Dennis > > > > -Original Message- > > From: Daniel Shahaf [mailto:danie...@apache.org] > > Sent: Monday, April 29, 2013 15:58 > > To: Dennis E. Hamilton > > Cc: dev@openoffice.apache.org; pesce...@apache.org > > Subject: Re: Proposal: Improve security by limiting committer access in > SVN -- KEYS Compromise Exposure > > > > Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 10:31:14 -0700: > > > 5. This is sufficient to poison a download mirror site with > > > a counterfeit download so long as the ASC, SHA1, and MD5 locations > > > can also be spoofed without the user noticing. > > > > Right. The normal answer here is "They will have to commit to the dist/ > > repository which will cause a post-commit mail which someone will > > notice". I'd be interested in hearing (on infra-dev@) how you break > > this without assuming a mirror gets compromised (if _that_ happens, > > it's game over for users who don't verify PGP sigs). > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- MzK "There's no upside in screwing with things you can't explain." -- Captain Roy Montgomery, "Castle"
Re: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure
(note CC list) Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 18:56:01 -0700: > @Daniel, > > Right, this is about poisoning the committer keys but not touching the > SVN, instead, counterfeiting a binary release downstream, but faking > the asc, md5, and sha1 too. (These would not be at dist, and depend ASF mirrors do not contain .asc, .md5, .sha1 files. We should probably verify that in our regular checks, if we don't do so already. Assuming "real mirrors have no .md5/.asc files" holds, assuming a user downloads a rogue .md5 means either the user is using a rogue download page or there's a rogue .md5 in https://www.apache.org/dist/openoffice/ --- these are both acceptable risks (the latter because it will have generated a commit mail which the PMC is supposed to catch). > on folks not noticing because the instructions for how to check > correctly are so obscure. It is very far-fetched, since there are > easier exploits that rely on user's not being equipped to verify what > they are getting and not relying on the authentic download location. > > Another way would be to attack the release candidate in the release > manager's ASF FreeBSD account, although someone who checks the > signature might notice that it is by an unexpected committer. Again, > reasonably far-fetched. Two committers would have to be compromised, > or the Release Manager would have to be compromised and not notice > that there is a new fingerprint in the RM's profile. I like that last > one. It has a certain movie-plot plausibility. Who ever looks for > funny business in their profile, or odd materials in their keys entry? Everyone. The PMC is REQUIRED to verify the .asc files in a release before voting on it. That means verifying it's signed by the correct key, too. Daniel > (Note that it is the binaries that are compromised, there is no > messing with the source tarballs.) > > - Dennis > > -Original Message- > From: Daniel Shahaf [mailto:danie...@apache.org] > Sent: Monday, April 29, 2013 15:58 > To: Dennis E. Hamilton > Cc: dev@openoffice.apache.org; pesce...@apache.org > Subject: Re: Proposal: Improve security by limiting committer access in SVN > -- KEYS Compromise Exposure > > Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 10:31:14 -0700: > > 5. This is sufficient to poison a download mirror site with > > a counterfeit download so long as the ASC, SHA1, and MD5 locations > > can also be spoofed without the user noticing. > > Right. The normal answer here is "They will have to commit to the dist/ > repository which will cause a post-commit mail which someone will > notice". I'd be interested in hearing (on infra-dev@) how you break > this without assuming a mirror gets compromised (if _that_ happens, > it's game over for users who don't verify PGP sigs). > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure
On Apr 29, 2013, at 6:56 PM, Dennis E. Hamilton wrote: > @Daniel, > > Right, this is about poisoning the committer keys but not touching the SVN, > instead, counterfeiting a binary release downstream, but faking the asc, md5, > and sha1 too. (These would not be at dist, and depend on folks not noticing > because the instructions for how to check correctly are so obscure. It is > very far-fetched, since there are easier exploits that rely on user's not > being equipped to verify what they are getting and not relying on the > authentic download location. > > Another way would be to attack the release candidate in the release manager's > ASF FreeBSD account, although someone who checks the signature might notice > that it is by an unexpected committer. Again, reasonably far-fetched. Two > committers would have to be compromised, or the Release Manager would have to > be compromised and not notice that there is a new fingerprint in the RM's > profile. I like that last one. It has a certain movie-plot plausibility. > Who ever looks for funny business in their profile, or odd materials in their > keys entry? (Note that it is the binaries that are compromised, there is no > messing with the source tarballs.) When I vote on a release I am looking at the fingerprint. This is where looking for a fingerprint that is on the "Web of Trust" is important. http://people.apache.org/~henkp/trust/ I like Henk's opinion here: > what can I trust, ultimately ? > > The short answer is nothing. > For the ultra sceptics there is no hope. > > • you can't trust the things you did yesterday, because you can't trust > your memory > • you can't trust software you didn't write or hardware you didn't build > • you can't overlook the possibility that apache.org is a fake, set up > especialy to lure you into using bad software > Regards, Dave > > - Dennis > > -Original Message- > From: Daniel Shahaf [mailto:danie...@apache.org] > Sent: Monday, April 29, 2013 15:58 > To: Dennis E. Hamilton > Cc: dev@openoffice.apache.org; pesce...@apache.org > Subject: Re: Proposal: Improve security by limiting committer access in SVN > -- KEYS Compromise Exposure > > Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 10:31:14 -0700: >> 5. This is sufficient to poison a download mirror site with >> a counterfeit download so long as the ASC, SHA1, and MD5 locations >> can also be spoofed without the user noticing. > > Right. The normal answer here is "They will have to commit to the dist/ > repository which will cause a post-commit mail which someone will > notice". I'd be interested in hearing (on infra-dev@) how you break > this without assuming a mirror gets compromised (if _that_ happens, > it's game over for users who don't verify PGP sigs). > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure
@Daniel, Right, this is about poisoning the committer keys but not touching the SVN, instead, counterfeiting a binary release downstream, but faking the asc, md5, and sha1 too. (These would not be at dist, and depend on folks not noticing because the instructions for how to check correctly are so obscure. It is very far-fetched, since there are easier exploits that rely on user's not being equipped to verify what they are getting and not relying on the authentic download location. Another way would be to attack the release candidate in the release manager's ASF FreeBSD account, although someone who checks the signature might notice that it is by an unexpected committer. Again, reasonably far-fetched. Two committers would have to be compromised, or the Release Manager would have to be compromised and not notice that there is a new fingerprint in the RM's profile. I like that last one. It has a certain movie-plot plausibility. Who ever looks for funny business in their profile, or odd materials in their keys entry? (Note that it is the binaries that are compromised, there is no messing with the source tarballs.) - Dennis -Original Message- From: Daniel Shahaf [mailto:danie...@apache.org] Sent: Monday, April 29, 2013 15:58 To: Dennis E. Hamilton Cc: dev@openoffice.apache.org; pesce...@apache.org Subject: Re: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 10:31:14 -0700: > 5. This is sufficient to poison a download mirror site with > a counterfeit download so long as the ASC, SHA1, and MD5 locations > can also be spoofed without the user noticing. Right. The normal answer here is "They will have to commit to the dist/ repository which will cause a post-commit mail which someone will notice". I'd be interested in hearing (on infra-dev@) how you break this without assuming a mirror gets compromised (if _that_ happens, it's game over for users who don't verify PGP sigs). - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure
Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 10:31:14 -0700: > 5. This is sufficient to poison a download mirror site with > a counterfeit download so long as the ASC, SHA1, and MD5 locations > can also be spoofed without the user noticing. Right. The normal answer here is "They will have to commit to the dist/ repository which will cause a post-commit mail which someone will notice". I'd be interested in hearing (on infra-dev@) how you break this without assuming a mirror gets compromised (if _that_ happens, it's game over for users who don't verify PGP sigs). - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure
Today, I did some digging around with respect to a different project and I noticed a vulnerability that had not been discussed: 1. Assume that the credentials of an Apache OpenOffice Committer are compromised (or the committer goes rogue). 2. This allows the compromised/rogue credentials to be used to change the forwarding e-mail address and add/replace the PGP public key fingerprint of the committer. 3. A rogue public key will then end up in <https://people.apache.org/keys/group/openoffice.asc>. This is the file that users are instructed to import keys from in order to check signatures on AOO releases and binary distributions. See <http://www.openoffice.org/download/checksums/3.4.1_checksums.html#howto>. 4. Note that all Apache OpenOffice committers who have provided PGP fingerprints will have their public key show up in that file. Not just release managers, *all* AOO committers who have provided PGP fingerprints. 5. This is sufficient to poison a download mirror site with a counterfeit download so long as the ASC, SHA1, and MD5 locations can also be spoofed without the user noticing. I don't think this is a high risk vulnerability. There are too many easier ways to distribute counterfeit binaries. The use of OS-verified code signing (for Windows and Apple builds, at least) will mitigate all of them to the extent that users come to rely on and be vigilant about signed installs. - Dennis -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Thursday, April 04, 2013 10:44 To: dev@openoffice.apache.org Subject: Re: Proposal: Improve security by limiting committer access in SVN Rob Weir wrote: > On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti wrote: >> 2) The only possible solution would be an authz rule like suggested by >> Dave here; however, Infra quite discourages it, mainly for maintenance >> reasons. This leads me to think we would need some good justifications for >> implementing this. > Would Infra need to maintain the authz , or would that be something that > you do? According to Infra, it's something that I can manage directly, even though I've never looked into this recently (I just needed to make some changes immediately after graduation). And I'm available to take care of this if there is consensus on making write access to /trunk (and other subtrees) optional. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Proposal: Improve security by limiting committer access in SVN
I believe this is the only list to be concerned about: <http://people.apache.org/committers-by-project.html#openoffice> Those are the only Apache committers who have karma for the OpenOffice project. Notice that there is a separate list for the PMC: <http://people.apache.org/committers-by-project.html#openoffice>. - Dennis -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Saturday, April 06, 2013 09:47 To: dev@openoffice.apache.org Cc: Joe Schaefer Subject: Re: Proposal: Improve security by limiting committer access in SVN [ ... ] Committer rights are usually never revoked based on the fact that merit does not expire. But in this case there was no merit at all: there are about 10 people at http://wiki.apache.org/incubator/OpenOfficeProposal that I never heard about. And if nobody ever heard about them, then we might want to prune the committers list (in another discussion). But, again, this is a totally different issue than limiting SVN access to a subset of the committers for (perceived) enhanced security: we already have good scrutiny and revert capabilities in place. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
Rob Weir wrote: On Thu, Apr 4, 2013 at 3:59 PM, Joe Schaefer wrote: Ah NO. Those so-called "phantom" committers had their commit to this projext revoked when you graduated http://people.apache.org/committers-by-project.html#openoffice Maybe you are thinking of openoffice-pmc? I know the PPMC list was reduced when making the TLP's PMC, but did anything happen to the committers list? No, but this is a quite different issue. As far as I know, we had some people sign up as initial committers and never contribute (no code, no activity, no discussion, not even a flamewar). Committer rights are usually never revoked based on the fact that merit does not expire. But in this case there was no merit at all: there are about 10 people at http://wiki.apache.org/incubator/OpenOfficeProposal that I never heard about. And if nobody ever heard about them, then we might want to prune the committers list (in another discussion). But, again, this is a totally different issue than limiting SVN access to a subset of the committers for (perceived) enhanced security: we already have good scrutiny and revert capabilities in place. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
On Wed, Apr 3, 2013 at 5:39 AM, Rob Weir wrote: > We're starting to take a deeper look at what is required to integrate code > signing into the OpenOffice build and release process. As you probably know > operating systems, especially Windows and MacOS, are now checking for > digital signatures and by default prevent users from installing programs > that are not signed. We see similar checks being integrated into > anti-virus scanners and even web browsers now. > > One of the things that has come out in discussions is how large a target > OpenOffice is, to hackers. We're on track to have 50 million downloads in > our first year. If someone is able to get a virus or a trojan into our > code, they have the ability to cause a huge amount of damage. And if we > are also signing our code, then this damage can propagate even faster, > since the OS's "let down their guard" somewhat when dealing with signed > code. (Signed code == trust). > > Of course, none of this has ever happened with OpenOffice, but with the > stature and reach we have, it is reasonable to believe that we could be a > target of opportunity for someone wishing to cause trouble. We should > always keep this in mind and make sure that we are taking reasonable > precautions to prevent this from happening. > > One vulnerability, in theory, is that we have over 100 committers (123 to > be exact) who have permission to modify the source code in Subversion. > Each account is protected by a self-selected passcode. It is not clear to > me that we even have requirements on password complexity or expiration > policies. In any case, the weakness of this approach is not necessarily > what you might think -- brute force attack on the password. If someone > wants to initiate a "spear phishing" attack against a committer, it would > be something like: > > 1) Standard phishing: a spoofed note from Apache Infra, with some invented > story that asks you to change your password but first enter your old one > for confirmation. It leads you to a fake, non-Apache website. > > 2) If you use the same passcode on multiple web services and one of them is > compromised, say by retrieving the passcode hashes, then it is easy to do > offline dictionary attacks (rainbow tables, etc.) and figure out your > Apache password. > > 3) If you lose control of your laptop, at a conference, bar, hotel, > whatever, even temporarily, someone can gain access to your Subversion > account, via applications that cache credentials, like TortoiseSVN. > > 4) Similar to #3, but by taking control of your laptop via remote means, > i.e., via a virus loaded on to your machine via another vulnerability. > > None of these things have happened to us yet, but all of these things are > possible. > > So how do we reduce this risk? There are a few things we do or should be > doing already. > > 1) Be careful on the machines that you use Subversion from. Treat it like > a machine where you access your bank account from. If you are visiting > risky sites or downloading and installing software from dubious places, > then you are putting your Apache account at risk. > > 2) Use a high-complexity Apache passcode, one not used by you on any other > service. > > 3) Change your passcode periodically, say every 90 days. > > 4) On laptops be sure to set a strong login password, but also where > available also a separate harddrive password. These should also be strong > passwords, not reused, and should be periodically changed. > > For those who are building binaries for distribution, the above guidance is > even more critical. > > Of course, we also protect the code through our CTR process. All active > coders should be subscribed to the commits list and should be reviewing the > changes that are made there. Trust the code, not the person. Remember, if > we ever are attacked then it will be through someone's compromised > account. So if you see an odd check-in, say, from Juergen, don't just > accept it saying "Juergen knows what he is doing". If it is odd, then it > should be challenged. > > All of the above should already be going on today. But I'd like to propose > one change to our current process that will, I think, greatly increase > security. This would be to restrict SVN authorization for the code to only > the subset of committers who are actively coding. We should give this > authorization freely to committers who request it. But today we have 123 > committers, some of whom have never used Subversion, and some (like me) who > edit /site and /ooo-site but never touch the code. So we probably have 90 > or more accounts that don't need access to the source code tree. Since > such used accounts are unlikely to be following the best practices outlined > above (changing passwords periodically, etc.) then they are even more > risky. We lose nothing by removing authorization for those users, in order > to reduce the risk profile. Of course, on request we can easily restore > access.
Re: Proposal: Improve security by limiting committer access in SVN
gt; should >>>> avoid regurgitating platitudes. Remember, we're talking about people >> who >>>> have never committed code, who don't even know C, who are not even >>>> subscribed to the dev mailing list, and in some cases have never ever >>>> posted to our mailing lists. They signed up in with the podling in >> July >>>> 2011 and then were never heard of again. You make an extremely weak >>>> argument to pontificate about "privilege" here. >>>> >>>> The risks are real. High profile open source projects attract these >>> kinds >>>> of attacks. There are those who know it, and those who don't know it >>> yet. >>>> >>>> A good read: >>>> >>> >> http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked >>>> >>>> As for those who think that casual review of commit messages will >> review >>>> any attack, that is a dangerously naive few. We should not expect an >>>> attack to be in a filed called trojan.c with comments and clear logic >>>> explaining what the code does. Any hacker with a clue would send a >> patch >>>> backed by a reasonable defect report in Bugzilla that would be >> innocuous >>> to >>>> casual inspection. All you need is a buffer or stack overwrite in a >>>> well-placed area to cause the problem. This might even be done in two >>>> stages, spread out over time, so the impact is not detectable without >>>> looking at the pieces together. >>>> >>>> Now if someone did that in the name of an active committer it would be >>>> *immediately* detected. "WTF!? I didn't check that in!" But when >> done >>> in >>>> the name of an unactive committer it would be less likely to be noticed >>> for >>>> what it is. We might check twice, but that doesn't mean we'd catch all >>> or >>>> even most deliberate attacks. But whatever detection rate we would >> have >>>> there it would be far less than the presentation rate for not having >>>> authorization enabled at all. The prevention rate there is 100% >>>> >>>> Regards, >>>> >>>> -Rob >>>> >>>> >>>> >>>> >>>> >>>>> Cheers, >>>>> -g >>>>> >>>>> On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote: >>>>>> Speaking as one of those "old-hands", Dennis is absolutely spot-on. >>>>>> >>>>>> Partitions, barriers, sub-groups... I call those "divisive" >>> mechanisms >>>>>> which serve to divide the community. Such divisions are rarely >>> needed. >>>>>> >>>>>> As Andrea points out, in Subversion's 13 year history, we have only >>>>>> *requested* people observe certain fences. We have never had a >>>>>> problem. We have never had to take sanctions. A stray commit here >> and >>>>>> there? Sure, it has happened, with the best intent, so we just >> point >>>>>> out that they need a bit more caution. No harm done. >>>>>> >>>>>> Back to Dennis' point: the solution here is proper review of the >>>>>> commits that occur. (IMO) NOT a way to *exclude* or to *limit* the >>>>>> potential contributions of others. >>>>>> >>>>>> Cheers, >>>>>> -g >>>>>> >>>>>> On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote: >>>>>>> In previous generations of this kind of discussion, the ASF >>> old-hands >>>>> will point out that the social process works quite well, folks don't >> do >>>>> commits unless they feel qualified to do so, and it is often the case >>> that >>>>> committers will request RTC (i.e., submit patches rather than update >>> the >>>>> SVN) in contributing where they are not experienced or don't consider >>>>> themselves expert. >>>>>>> >>>>>>> At the ASF this appears to be one of those, "if it is not broken, >>>>> don't fix it." >>&g
Re: Proposal: Improve security by limiting committer access in SVN
On Thu, Apr 4, 2013 at 4:16 PM, Dennis E. Hamilton wrote: > You're *still* understating the extent of the ceremony. They had to go > through everything a subsequently-invited committer had to do, even though > Sam Ruby provided the initial instructions. But thanks for mentioning the > iCLA. That is an useful object to have on file in tracking down a possible > credentials exploit. > > It helps identify the person whose credentials were stolen. This is hardly a consultation to the user whose machine is hacked. It doesn't prevent anything. But it does allow us to contact them and apologize for the embarrassment we caused them by not taking sensible precautions to reduce their authorization when they stopped being active with the project. > I agree that there are those who never showed up after being established. > Rob apparently knows who they are. I assume that any commits from those > (maybe even logons anywhere) will raise vigilant eyebrows. For double > measure, Andrea should have the list, posted on private@ too and maybe > filed in the PMC-private area. That should establish adequate oversight. > > I assume all checkins are reviewed, regardless of who they are from. And if we had supermen programmers who by their mere glance could detect every subtle error in code that could be exploited, and do this 100% of the time with perfect accuracy then I suppose we'd be fine. At that point, of course, I assume they would have found all the other bugs in OpenOffice as well, and our perfect programmers would give us perfect software. But none of these things are likely. In fact we know that is not true. That is why we occasionally need to issue security patches to fix *accidental* errors that crept into code. If we miss the accidental ones, then finding the obfuscated ones intentionally placed would be rather more difficult. > There are also a few committers who have announced their resignation and > not since rescinded it. Put those on that "watch list" also. > > I don't know what is to be done if any of those have used > @openoffice.orge-mail addresses in their iCLA and as their @a.o forwarding > address. I > suppose those are the best to attempt impersonating. The first act to be > accessing the profile of an user -- thus confirming the credential -- and > changing the forwarding address. Then opting-in should be relatively easy, > especially if the original @a.o-holder is not watching any lists here. > Having done that, a malefactor can proceed to establish a PGP signature > verified for the @a.o too. > > So, to lock this door, it is *really* necessary to lock-down those > committer profiles and remove their authz everywhere. To be reinstated, it > is probably necessary to convince the Secretary of the ASF that the request > is authentic. > > Or do what do right now. The last time there was concern about the Apache ID's, Infra just reset the passwords. Everyone had to request a new password which was sent to their email account of record. If their email account is down, then they would need to provide other acceptable proof. That might be slower. Note that unlikely that a committer re-appears after not doing anything for 2 years and has an urgent need to check in code. But if it does happen we have ways of making it work. But it should be extremely rare. -Rob > - Dennis > > -Original Message----- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Thursday, April 04, 2013 12:54 > To: dev@openoffice.apache.org > Subject: Re: Proposal: Improve security by limiting committer access in SVN > > [ ... ] > > But with OpenOffice, there was a two week period of time when we rapidly > bootstrapped the community by making people committers automatically, on > day 1. All they had to do is put their name on a wiki page and return an > ICLA and they were committers. No vetting, no vote. Quite a few of them > never got involved in the project in even the least degree. So we have > these phantom community members, with authorization to change the source > code. > > Regards, > > -Rob > > [ ... ] > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
RE: Proposal: Improve security by limiting committer access in SVN
You're *still* understating the extent of the ceremony. They had to go through everything a subsequently-invited committer had to do, even though Sam Ruby provided the initial instructions. But thanks for mentioning the iCLA. That is an useful object to have on file in tracking down a possible credentials exploit. I agree that there are those who never showed up after being established. Rob apparently knows who they are. I assume that any commits from those (maybe even logons anywhere) will raise vigilant eyebrows. For double measure, Andrea should have the list, posted on private@ too and maybe filed in the PMC-private area. That should establish adequate oversight. There are also a few committers who have announced their resignation and not since rescinded it. Put those on that "watch list" also. I don't know what is to be done if any of those have used @openoffice.org e-mail addresses in their iCLA and as their @a.o forwarding address. I suppose those are the best to attempt impersonating. The first act to be accessing the profile of an user -- thus confirming the credential -- and changing the forwarding address. Then opting-in should be relatively easy, especially if the original @a.o-holder is not watching any lists here. Having done that, a malefactor can proceed to establish a PGP signature verified for the @a.o too. So, to lock this door, it is *really* necessary to lock-down those committer profiles and remove their authz everywhere. To be reinstated, it is probably necessary to convince the Secretary of the ASF that the request is authentic. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, April 04, 2013 12:54 To: dev@openoffice.apache.org Subject: Re: Proposal: Improve security by limiting committer access in SVN [ ... ] But with OpenOffice, there was a two week period of time when we rapidly bootstrapped the community by making people committers automatically, on day 1. All they had to do is put their name on a wiki page and return an ICLA and they were committers. No vetting, no vote. Quite a few of them never got involved in the project in even the least degree. So we have these phantom community members, with authorization to change the source code. Regards, -Rob [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
On Thu, Apr 4, 2013 at 3:59 PM, Joe Schaefer wrote: > Ah NO. Those so-called "phantom" committers > had their commit to this projext revoked when you graduated > Hi Joe, See the list here: http://people.apache.org/committers-by-project.html#openoffice I've been tracking the length of that list since July 2011. It has not decreased. You can see that here: http://www.openoffice.org/stats/committers.html Maybe you are thinking of openoffice-pmc? I know the PPMC list was reduced when making the TLP's PMC, but did anything happen to the committers list? > to a TLP, but the larger point that Greg's making > remains true- it is a false sense of security to > rely on ACL's to pretend you don't need to vet your > commit list. See http://www.apache.org/dev/open-access-svn > for more details of an ongoing debate to simplify > our svn rules accordingly. > One of our issues is that being a committer enables access to multiple systems. some controlled by LDAP, some by authz and some manually, e.g., access to editor rights in the blog. I think there is room for having someone be a committer and having access to all the systems that they want access to for the work they want to do, without assuming that they need access to everything just because they are committers. This might be different in projects where 99% of the commiters are coders. But in our case, our demographics is far different. I hope we all appreciate that this difference exists. Regards, -Rob > > > > > > > > > From: Rob Weir > >To: "dev@openoffice.apache.org" > >Sent: Thursday, April 4, 2013 3:53 PM > >Subject: Re: Proposal: Improve security by limiting committer access in > SVN > > > >On Thu, Apr 4, 2013 at 3:17 PM, janI wrote: > > > >> On 4 April 2013 21:03, Rob Weir wrote: > >> > >> > On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein wrote: > >> > > >> > > Your proposal to alter the community structure is premised upon a > >> > > strawman risk. First, that it would occur. Second, that it wouldn't > be > >> > > noticed. Third, that it would find its way into users' hands. > >> > > > >> > > > >> > So you are asserting that someone who put their name down on the > >> Incubator > >> > wiki in July 2011 and was named a committer by that act, but never > ever > >> > showed up after that, never joined the dev list, never posted to the > dev > >> > list, never contributed code or anything else other than a name on a > >> wiki, > >> > is a member of our community and it would be altering the committee > >> > structure if we removed their authz to our source code, even with the > >> > proviso that we would immediately restore it on request? > >> > > >> > Really? > >> > > >> > >> Just a stupid question from someone who have not been here for > ages...the > >> person just described should loose the committer role, or are we granted > >> commitership for lifetime ?? > >> > >> > >"Typical" and "Apache OpenOffice" should never be used in the same > sentence > >unless mischief is intended ;-) > > > >But other projects, being a committer is permanent, aside from resignation > >or extreme cases. But for most projects becoming a committer requires > >being involved with the project, demonstrating merit, being voted in by a > >PMC, etc., just like you did. > > > >But with OpenOffice, there was a two week period of time when we rapidly > >bootstrapped the community by making people committers automatically, on > >day 1. All they had to do is put their name on a wiki page and return an > >ICLA and they were committers. No vetting, no vote. Quite a few of them > >never got involved in the project in even the least degree. So we have > >these phantom community members, with authorization to change the source > >code. > > > >Regards, > > > >-Rob > > > > > > > >> jan I. > >> > >> > > >> > -Rob > >> > > >> > > >> > > >> > > In the past, the Foundation has *explicitly* said that we would > accept > >> > > a certain level of risk to maintain our communities. > >> > > > >> > > I find your strawman at a level even *lower* than the scenario that > >> > > I'm thinking about(*). > >> > > > >> > > If you're worried abo
Re: Proposal: Improve security by limiting committer access in SVN
Ah NO. Those so-called "phantom" committers
had their commit to this projext revoked when you graduated
to a TLP, but the larger point that Greg's making
remains true- it is a false sense of security to
rely on ACL's to pretend you don't need to vet your
commit list. See http://www.apache.org/dev/open-access-svn
for more details of an ongoing debate to simplify
our svn rules accordingly.
>
> From: Rob Weir
>To: "dev@openoffice.apache.org"
>Sent: Thursday, April 4, 2013 3:53 PM
>Subject: Re: Proposal: Improve security by limiting committer access in SVN
>
>On Thu, Apr 4, 2013 at 3:17 PM, janI wrote:
>
>> On 4 April 2013 21:03, Rob Weir wrote:
>>
>> > On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein wrote:
>> >
>> > > Your proposal to alter the community structure is premised upon a
>> > > strawman risk. First, that it would occur. Second, that it wouldn't be
>> > > noticed. Third, that it would find its way into users' hands.
>> > >
>> > >
>> > So you are asserting that someone who put their name down on the
>> Incubator
>> > wiki in July 2011 and was named a committer by that act, but never ever
>> > showed up after that, never joined the dev list, never posted to the dev
>> > list, never contributed code or anything else other than a name on a
>> wiki,
>> > is a member of our community and it would be altering the committee
>> > structure if we removed their authz to our source code, even with the
>> > proviso that we would immediately restore it on request?
>> >
>> > Really?
>> >
>>
>> Just a stupid question from someone who have not been here for ages...the
>> person just described should loose the committer role, or are we granted
>> commitership for lifetime ??
>>
>>
>"Typical" and "Apache OpenOffice" should never be used in the same sentence
>unless mischief is intended ;-)
>
>But other projects, being a committer is permanent, aside from resignation
>or extreme cases. But for most projects becoming a committer requires
>being involved with the project, demonstrating merit, being voted in by a
>PMC, etc., just like you did.
>
>But with OpenOffice, there was a two week period of time when we rapidly
>bootstrapped the community by making people committers automatically, on
>day 1. All they had to do is put their name on a wiki page and return an
>ICLA and they were committers. No vetting, no vote. Quite a few of them
>never got involved in the project in even the least degree. So we have
>these phantom community members, with authorization to change the source
>code.
>
>Regards,
>
>-Rob
>
>
>
>> jan I.
>>
>> >
>> > -Rob
>> >
>> >
>> >
>> > > In the past, the Foundation has *explicitly* said that we would accept
>> > > a certain level of risk to maintain our communities.
>> > >
>> > > I find your strawman at a level even *lower* than the scenario that
>> > > I'm thinking about(*).
>> > >
>> > > If you're worried about stale committers suddenly inserting trojans,
>> > > then just use 'svn log' to find those outliers. No need to create
>> > > division within the community. Run a simple histogram. There are many
>> > > solutions to your purported attack vector, than to divide into groups.
>> > >
>> > > Cheers,
>> > > -g
>> > >
>> > > (*) a certain large company's lawyer (ahem) was trying to scare the
>> > > ASF ("the risk!!") into adopting certain procedures; we shut her down
>> > >
>> > > On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
>> > > > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein wrote:
>> > > >
>> > > > > Also, let me say one more thing:
>> > > > >
>> > > > > This notion of creating divisions among committers ... it is
>> > "solving"
>> > > > > a problem that has never occurred here.
>> > > > >
>> > > > > NEVER. OCCURRED.
>> > > > >
>> > > > >
>> > > > So frickin' what? That is entirely irrelevant. My house has never
>> > > burnt
>> > > > down either, but I still don't leave open flames around unattended.
>> In
>> > > > fact you might think this is naive view, but avoidance of such risks
>&g
Re: Proposal: Improve security by limiting committer access in SVN
t; "solve" > > a > > > > > non-existent issue. Net result: more problems. > > > > > > > > > > > > > > > > > > Greg, we already do this. Does every ASF Member have credential for > > > Infra > > > > root? Does ever ASF Member have access to legal-private mailing > list. > > > No. > > > > No. We even do this in the AOO project, with separate authz for > > > > openoffice-security, which by the way also includes an SVN tree. > > > > > > > > Anyone who thinks this is a question of dividing and privilege is > > > > expressing a knee-jerk reaction, without thinking of the risks. We > > > should > > > > avoid regurgitating platitudes. Remember, we're talking about people > > who > > > > have never committed code, who don't even know C, who are not even > > > > subscribed to the dev mailing list, and in some cases have never ever > > > > posted to our mailing lists. They signed up in with the podling in > > July > > > > 2011 and then were never heard of again. You make an extremely weak > > > > argument to pontificate about "privilege" here. > > > > > > > > The risks are real. High profile open source projects attract these > > > kinds > > > > of attacks. There are those who know it, and those who don't know it > > > yet. > > > > > > > > A good read: > > > > > > > > > > http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked > > > > > > > > As for those who think that casual review of commit messages will > > review > > > > any attack, that is a dangerously naive few. We should not expect an > > > > attack to be in a filed called trojan.c with comments and clear logic > > > > explaining what the code does. Any hacker with a clue would send a > > patch > > > > backed by a reasonable defect report in Bugzilla that would be > > innocuous > > > to > > > > casual inspection. All you need is a buffer or stack overwrite in a > > > > well-placed area to cause the problem. This might even be done in > two > > > > stages, spread out over time, so the impact is not detectable without > > > > looking at the pieces together. > > > > > > > > Now if someone did that in the name of an active committer it would > be > > > > *immediately* detected. "WTF!? I didn't check that in!" But when > > done > > > in > > > > the name of an unactive committer it would be less likely to be > noticed > > > for > > > > what it is. We might check twice, but that doesn't mean we'd catch > all > > > or > > > > even most deliberate attacks. But whatever detection rate we would > > have > > > > there it would be far less than the presentation rate for not having > > > > authorization enabled at all. The prevention rate there is 100% > > > > > > > > Regards, > > > > > > > > -Rob > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > -g > > > > > > > > > > On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote: > > > > > > Speaking as one of those "old-hands", Dennis is absolutely > spot-on. > > > > > > > > > > > > Partitions, barriers, sub-groups... I call those "divisive" > > > mechanisms > > > > > > which serve to divide the community. Such divisions are rarely > > > needed. > > > > > > > > > > > > As Andrea points out, in Subversion's 13 year history, we have > only > > > > > > *requested* people observe certain fences. We have never had a > > > > > > problem. We have never had to take sanctions. A stray commit here > > and > > > > > > there? Sure, it has happened, with the best intent, so we just > > point > > > > > > out that they need a bit more caution. No harm done. > > > > > > > > > > > > Back to Dennis' point: the solution here is proper review of the > > > > > > commits that occur. (IMO) NOT a way to *exclude* or to *limit* > the > > > > > > potential contributions of others. > > > &
Re: Proposal: Improve security by limiting committer access in SVN
On Thu, Apr 4, 2013 at 3:30 PM, Dennis E. Hamilton
wrote:
> OK, I will speak further.
>
> There are no such people among the current committers. It took *more*
> than being on the June 2011 proposal to become established as an initial
> committer. And you know that. There was considerable activity to on-board
> the willing and have them be established as committers and PPMC members.
> Those who did not show up that much did have their invitations revoked.
> That was over one year ago. (There were also some who declined
> straight-away.)
>
Actually there are people like this. You should check. I did.I
appreciate that you and others did additional work to onboard people,
tracking their ID's and ICLA's, making spreadsheets, etc. But some of them
never did anything since then, never subscribing or posting to the mailing
list.
>
> (At the time, of course, it was apparently in the interests of some to
> crow about the number of committers there were.)
>
> I already commented that "restoration on request" is, without some other
> measures, easy to spoof by someone who has obtained the necessary
> credentials, especially if those credentials are for someone not subscribed
> to the dev list.
>
>
Maybe you want to suggest some additional measures?
> I still consider it far more likely that someone will use an avenue that
> provides more protection against discovery (of either the attacker or the
> exploit) and has more direct rewards. Even for a compromised bad password
> that happens to go with an @a.o credential. I claim that the risk
> management here is being distorted by some sort of absolutism. I must
> remember that the next time I am told that a pass-the-hash attack on an
> encrypted ODF document is infeasible despite it being comparatively trivial
> and defies detection.
>
>
The inability to do everything is not an excuse for avoiding to take
reasonable precautions to reduce our exposure. Giving write access to
source code for a product that millions of users install to people who are
not by any meaning of the word members of our community is ridiculous. To
suggest otherwise is absolutism, of a "Community Ueber Alles" type that
discredits any understanding of what community means. Someone who is not
here and never was is not a member of the community. Why exactly we should
leave the gates open to them is an unanswered question.
-Rob
> - Dennis
>
> PS: I suspect that the protective action will be taken as the only way to
> stop this conversation. That will be its only achievement.
>
> -Original Message-
> From: Rob Weir [mailto:robw...@apache.org]
> Sent: Thursday, April 04, 2013 12:03
> To: dev@openoffice.apache.org
> Subject: Re: Proposal: Improve security by limiting committer access in SVN
>
> On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein wrote:
>
> > Your proposal to alter the community structure is premised upon a
> > strawman risk. First, that it would occur. Second, that it wouldn't be
> > noticed. Third, that it would find its way into users' hands.
> >
> >
> So you are asserting that someone who put their name down on the Incubator
> wiki in July 2011 and was named a committer by that act, but never ever
> showed up after that, never joined the dev list, never posted to the dev
> list, never contributed code or anything else other than a name on a wiki,
> is a member of our community and it would be altering the committee
> structure if we removed their authz to our source code, even with the
> proviso that we would immediately restore it on request?
>
> Really?
>
> -Rob
>
>
>
> > In the past, the Foundation has *explicitly* said that we would accept
> > a certain level of risk to maintain our communities.
> >
> > I find your strawman at a level even *lower* than the scenario that
> > I'm thinking about(*).
> >
> > If you're worried about stale committers suddenly inserting trojans,
> > then just use 'svn log' to find those outliers. No need to create
> > division within the community. Run a simple histogram. There are many
> > solutions to your purported attack vector, than to divide into groups.
> >
> > Cheers,
> > -g
> >
> > (*) a certain large company's lawyer (ahem) was trying to scare the
> > ASF ("the risk!!") into adopting certain procedures; we shut her down
> >
> > On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
> > > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein wrote:
> > >
> > > > Also, let me say one more thing:
> > > >
> > > > This notion of creating divisions among committers ... it is
> "s
RE: Proposal: Improve security by limiting committer access in SVN
OK, I will speak further.
There are no such people among the current committers. It took *more* than
being on the June 2011 proposal to become established as an initial committer.
And you know that. There was considerable activity to on-board the willing and
have them be established as committers and PPMC members. Those who did not
show up that much did have their invitations revoked. That was over one year
ago. (There were also some who declined straight-away.)
(At the time, of course, it was apparently in the interests of some to crow
about the number of committers there were.)
I already commented that "restoration on request" is, without some other
measures, easy to spoof by someone who has obtained the necessary credentials,
especially if those credentials are for someone not subscribed to the dev list.
I still consider it far more likely that someone will use an avenue that
provides more protection against discovery (of either the attacker or the
exploit) and has more direct rewards. Even for a compromised bad password that
happens to go with an @a.o credential. I claim that the risk management here
is being distorted by some sort of absolutism. I must remember that the next
time I am told that a pass-the-hash attack on an encrypted ODF document is
infeasible despite it being comparatively trivial and defies detection.
- Dennis
PS: I suspect that the protective action will be taken as the only way to stop
this conversation. That will be its only achievement.
-Original Message-
From: Rob Weir [mailto:robw...@apache.org]
Sent: Thursday, April 04, 2013 12:03
To: dev@openoffice.apache.org
Subject: Re: Proposal: Improve security by limiting committer access in SVN
On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein wrote:
> Your proposal to alter the community structure is premised upon a
> strawman risk. First, that it would occur. Second, that it wouldn't be
> noticed. Third, that it would find its way into users' hands.
>
>
So you are asserting that someone who put their name down on the Incubator
wiki in July 2011 and was named a committer by that act, but never ever
showed up after that, never joined the dev list, never posted to the dev
list, never contributed code or anything else other than a name on a wiki,
is a member of our community and it would be altering the committee
structure if we removed their authz to our source code, even with the
proviso that we would immediately restore it on request?
Really?
-Rob
> In the past, the Foundation has *explicitly* said that we would accept
> a certain level of risk to maintain our communities.
>
> I find your strawman at a level even *lower* than the scenario that
> I'm thinking about(*).
>
> If you're worried about stale committers suddenly inserting trojans,
> then just use 'svn log' to find those outliers. No need to create
> division within the community. Run a simple histogram. There are many
> solutions to your purported attack vector, than to divide into groups.
>
> Cheers,
> -g
>
> (*) a certain large company's lawyer (ahem) was trying to scare the
> ASF ("the risk!!") into adopting certain procedures; we shut her down
>
> On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
> > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein wrote:
> >
> > > Also, let me say one more thing:
> > >
> > > This notion of creating divisions among committers ... it is "solving"
> > > a problem that has never occurred here.
> > >
> > > NEVER. OCCURRED.
> > >
> > >
> > So frickin' what? That is entirely irrelevant. My house has never
> burnt
> > down either, but I still don't leave open flames around unattended. In
> > fact you might think this is naive view, but avoidance of such risks
> might
> > even be correlated with lack of house fires. Hmmm
> >
> >
> >
> > > In the Foundations's 14+ year history, we have never seen a trojan
> > > commit. Our servers have been compromised a handful of times. When we
> > > were back on CVS, we even had to audit source control to verify no
> > > trojan injection. But we have NEVER had a case of a malware commit.
> > >
> > >
> > Again, that proves nothing. I'm sure the first time apache.org was
> rooted
> > that it had never happened before either, right?
> >
> >
> >
> >
> > > So back to IMO: dividing and partitioning and separate privilege
> > > levels... there is no reason. It creates a social problem to "solve" a
> > > non-existent issue. Net result: more problems.
> > >
> > >
> >
> > Greg, we already do this. Does every ASF Member h
Re: Proposal: Improve security by limiting committer access in SVN
> > > of attacks. There are those who know it, and those who don't know it > > yet. > > > > > > A good read: > > > > > > http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked > > > > > > As for those who think that casual review of commit messages will > review > > > any attack, that is a dangerously naive few. We should not expect an > > > attack to be in a filed called trojan.c with comments and clear logic > > > explaining what the code does. Any hacker with a clue would send a > patch > > > backed by a reasonable defect report in Bugzilla that would be > innocuous > > to > > > casual inspection. All you need is a buffer or stack overwrite in a > > > well-placed area to cause the problem. This might even be done in two > > > stages, spread out over time, so the impact is not detectable without > > > looking at the pieces together. > > > > > > Now if someone did that in the name of an active committer it would be > > > *immediately* detected. "WTF!? I didn't check that in!" But when > done > > in > > > the name of an unactive committer it would be less likely to be noticed > > for > > > what it is. We might check twice, but that doesn't mean we'd catch all > > or > > > even most deliberate attacks. But whatever detection rate we would > have > > > there it would be far less than the presentation rate for not having > > > authorization enabled at all. The prevention rate there is 100% > > > > > > Regards, > > > > > > -Rob > > > > > > > > > > > > > > > > > > > Cheers, > > > > -g > > > > > > > > On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote: > > > > > Speaking as one of those "old-hands", Dennis is absolutely spot-on. > > > > > > > > > > Partitions, barriers, sub-groups... I call those "divisive" > > mechanisms > > > > > which serve to divide the community. Such divisions are rarely > > needed. > > > > > > > > > > As Andrea points out, in Subversion's 13 year history, we have only > > > > > *requested* people observe certain fences. We have never had a > > > > > problem. We have never had to take sanctions. A stray commit here > and > > > > > there? Sure, it has happened, with the best intent, so we just > point > > > > > out that they need a bit more caution. No harm done. > > > > > > > > > > Back to Dennis' point: the solution here is proper review of the > > > > > commits that occur. (IMO) NOT a way to *exclude* or to *limit* the > > > > > potential contributions of others. > > > > > > > > > > Cheers, > > > > > -g > > > > > > > > > > On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote: > > > > > > In previous generations of this kind of discussion, the ASF > > old-hands > > > > will point out that the social process works quite well, folks don't > do > > > > commits unless they feel qualified to do so, and it is often the case > > that > > > > committers will request RTC (i.e., submit patches rather than update > > the > > > > SVN) in contributing where they are not experienced or don't consider > > > > themselves expert. > > > > > > > > > > > > At the ASF this appears to be one of those, "if it is not broken, > > > > don't fix it." > > > > > > > > > > > > There is still the concern about stolen credentials used to > perform > > > > undetected malicious acts. If the oversight that the project > naturally > > > > brings to bear on visible changes to the code base is insufficient, I > > think > > > > the problem is greater than there being a possible exploit of that > > > > inattention. Mechanical solutions may be part of the disease, not > the > > cure > > > > [;<). > > > > > > > > > > > > - Dennis > > > > > > > > > > > > -Original Message- > > > > > > From: Andrea Pescetti [mailto:pesce...@apache.org] > > > > > > Sent: Thursday, April 04, 2013 08:57 > > > > > > To: dev@openoffice.ap
Re: Proposal: Improve security by limiting committer access in SVN
in a > > well-placed area to cause the problem. This might even be done in two > > stages, spread out over time, so the impact is not detectable without > > looking at the pieces together. > > > > Now if someone did that in the name of an active committer it would be > > *immediately* detected. "WTF!? I didn't check that in!" But when done > in > > the name of an unactive committer it would be less likely to be noticed > for > > what it is. We might check twice, but that doesn't mean we'd catch all > or > > even most deliberate attacks. But whatever detection rate we would have > > there it would be far less than the presentation rate for not having > > authorization enabled at all. The prevention rate there is 100% > > > > Regards, > > > > -Rob > > > > > > > > > > > > > Cheers, > > > -g > > > > > > On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote: > > > > Speaking as one of those "old-hands", Dennis is absolutely spot-on. > > > > > > > > Partitions, barriers, sub-groups... I call those "divisive" > mechanisms > > > > which serve to divide the community. Such divisions are rarely > needed. > > > > > > > > As Andrea points out, in Subversion's 13 year history, we have only > > > > *requested* people observe certain fences. We have never had a > > > > problem. We have never had to take sanctions. A stray commit here and > > > > there? Sure, it has happened, with the best intent, so we just point > > > > out that they need a bit more caution. No harm done. > > > > > > > > Back to Dennis' point: the solution here is proper review of the > > > > commits that occur. (IMO) NOT a way to *exclude* or to *limit* the > > > > potential contributions of others. > > > > > > > > Cheers, > > > > -g > > > > > > > > On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote: > > > > > In previous generations of this kind of discussion, the ASF > old-hands > > > will point out that the social process works quite well, folks don't do > > > commits unless they feel qualified to do so, and it is often the case > that > > > committers will request RTC (i.e., submit patches rather than update > the > > > SVN) in contributing where they are not experienced or don't consider > > > themselves expert. > > > > > > > > > > At the ASF this appears to be one of those, "if it is not broken, > > > don't fix it." > > > > > > > > > > There is still the concern about stolen credentials used to perform > > > undetected malicious acts. If the oversight that the project naturally > > > brings to bear on visible changes to the code base is insufficient, I > think > > > the problem is greater than there being a possible exploit of that > > > inattention. Mechanical solutions may be part of the disease, not the > cure > > > [;<). > > > > > > > > > > - Dennis > > > > > > > > > > -Original Message- > > > > > From: Andrea Pescetti [mailto:pesce...@apache.org] > > > > > Sent: Thursday, April 04, 2013 08:57 > > > > > To: dev@openoffice.apache.org > > > > > Subject: Re: Proposal: Improve security by limiting committer > access > > > in SVN > > > > > > > > > > Dave Fisher wrote: > > > > > > Let's focus only on adding one new authz list for the code tree. > > > > > > Call it openoffice-coders and populate it with those who HAVE any > > > > > > commit activity in the current code tree. > > > > > > > > > > I checked feasibility with Infra. Summary: > > > > > > > > > > 1) LDAP is not the solution. Rule it out. > > > > > > > > > > 2) The only possible solution would be an authz rule like > suggested by > > > > > Dave here; however, Infra quite discourages it, mainly for > maintenance > > > > > reasons. This leads me to think we would need some good > justifications > > > > > for implementing this. > > > > > > > > > > 3) If the justification is security, then there are other > privileges to > > > > > monitor. Namely, every committer has shell access to > people
Re: Proposal: Improve security by limiting committer access in SVN
; authorization enabled at all. The prevention rate there is 100% > > > > Regards, > > > > -Rob > > > > > > > > > > > >> Cheers, > >> -g > >> > >> On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote: > >> > Speaking as one of those "old-hands", Dennis is absolutely spot-on. > >> > > >> > Partitions, barriers, sub-groups... I call those "divisive" mechanisms > >> > which serve to divide the community. Such divisions are rarely needed. > >> > > >> > As Andrea points out, in Subversion's 13 year history, we have only > >> > *requested* people observe certain fences. We have never had a > >> > problem. We have never had to take sanctions. A stray commit here and > >> > there? Sure, it has happened, with the best intent, so we just point > >> > out that they need a bit more caution. No harm done. > >> > > >> > Back to Dennis' point: the solution here is proper review of the > >> > commits that occur. (IMO) NOT a way to *exclude* or to *limit* the > >> > potential contributions of others. > >> > > >> > Cheers, > >> > -g > >> > > >> > On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote: > >> > > In previous generations of this kind of discussion, the ASF old-hands > >> will point out that the social process works quite well, folks don't do > >> commits unless they feel qualified to do so, and it is often the case that > >> committers will request RTC (i.e., submit patches rather than update the > >> SVN) in contributing where they are not experienced or don't consider > >> themselves expert. > >> > > > >> > > At the ASF this appears to be one of those, "if it is not broken, > >> don't fix it." > >> > > > >> > > There is still the concern about stolen credentials used to perform > >> undetected malicious acts. If the oversight that the project naturally > >> brings to bear on visible changes to the code base is insufficient, I think > >> the problem is greater than there being a possible exploit of that > >> inattention. Mechanical solutions may be part of the disease, not the cure > >> [;<). > >> > > > >> > > - Dennis > >> > > > >> > > -Original Message- > >> > > From: Andrea Pescetti [mailto:pesce...@apache.org] > >> > > Sent: Thursday, April 04, 2013 08:57 > >> > > To: dev@openoffice.apache.org > >> > > Subject: Re: Proposal: Improve security by limiting committer access > >> in SVN > >> > > > >> > > Dave Fisher wrote: > >> > > > Let's focus only on adding one new authz list for the code tree. > >> > > > Call it openoffice-coders and populate it with those who HAVE any > >> > > > commit activity in the current code tree. > >> > > > >> > > I checked feasibility with Infra. Summary: > >> > > > >> > > 1) LDAP is not the solution. Rule it out. > >> > > > >> > > 2) The only possible solution would be an authz rule like suggested by > >> > > Dave here; however, Infra quite discourages it, mainly for maintenance > >> > > reasons. This leads me to think we would need some good justifications > >> > > for implementing this. > >> > > > >> > > 3) If the justification is security, then there are other privileges > >> to > >> > > monitor. Namely, every committer has shell access to > >> people.apache.org, > >> > > authenticated access to the Apache SMTP server and CMS privileges for > >> > > the openoffice.org website, including publish operations. > >> > > > >> > > For the record, the Subversion project has complex rules like Rob > >> > > pointed out; but it's only a "social enforcement", i.e., all > >> committers > >> > > respect those limitations by their own choice; if you look at the > >> > > technical level, every committer (all Apache committers) can commit > >> code > >> > > to the Subversion subtree. > >> > > > >> > > Regards, > >> > >Andrea. > >> > > > >> > > - > >> > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> > > For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > > > >> > > > >> > > - > >> > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> > > For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > > > >> > > >> > - > >> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > >> > > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
s is absolutely spot-on. > > > > > > Partitions, barriers, sub-groups... I call those "divisive" mechanisms > > > which serve to divide the community. Such divisions are rarely needed. > > > > > > As Andrea points out, in Subversion's 13 year history, we have only > > > *requested* people observe certain fences. We have never had a > > > problem. We have never had to take sanctions. A stray commit here and > > > there? Sure, it has happened, with the best intent, so we just point > > > out that they need a bit more caution. No harm done. > > > > > > Back to Dennis' point: the solution here is proper review of the > > > commits that occur. (IMO) NOT a way to *exclude* or to *limit* the > > > potential contributions of others. > > > > > > Cheers, > > > -g > > > > > > On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote: > > > > In previous generations of this kind of discussion, the ASF old-hands > > will point out that the social process works quite well, folks don't do > > commits unless they feel qualified to do so, and it is often the case that > > committers will request RTC (i.e., submit patches rather than update the > > SVN) in contributing where they are not experienced or don't consider > > themselves expert. > > > > > > > > At the ASF this appears to be one of those, "if it is not broken, > > don't fix it." > > > > > > > > There is still the concern about stolen credentials used to perform > > undetected malicious acts. If the oversight that the project naturally > > brings to bear on visible changes to the code base is insufficient, I think > > the problem is greater than there being a possible exploit of that > > inattention. Mechanical solutions may be part of the disease, not the cure > > [;<). > > > > > > > > - Dennis > > > > > > > > -Original Message- > > > > From: Andrea Pescetti [mailto:pesce...@apache.org] > > > > Sent: Thursday, April 04, 2013 08:57 > > > > To: dev@openoffice.apache.org > > > > Subject: Re: Proposal: Improve security by limiting committer access > > in SVN > > > > > > > > Dave Fisher wrote: > > > > > Let's focus only on adding one new authz list for the code tree. > > > > > Call it openoffice-coders and populate it with those who HAVE any > > > > > commit activity in the current code tree. > > > > > > > > I checked feasibility with Infra. Summary: > > > > > > > > 1) LDAP is not the solution. Rule it out. > > > > > > > > 2) The only possible solution would be an authz rule like suggested by > > > > Dave here; however, Infra quite discourages it, mainly for maintenance > > > > reasons. This leads me to think we would need some good justifications > > > > for implementing this. > > > > > > > > 3) If the justification is security, then there are other privileges to > > > > monitor. Namely, every committer has shell access to people.apache.org > > , > > > > authenticated access to the Apache SMTP server and CMS privileges for > > > > the openoffice.org website, including publish operations. > > > > > > > > For the record, the Subversion project has complex rules like Rob > > > > pointed out; but it's only a "social enforcement", i.e., all committers > > > > respect those limitations by their own choice; if you look at the > > > > technical level, every committer (all Apache committers) can commit > > code > > > > to the Subversion subtree. > > > > > > > > Regards, > > > >Andrea. > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
t; As Andrea points out, in Subversion's 13 year history, we have only >> > *requested* people observe certain fences. We have never had a >> > problem. We have never had to take sanctions. A stray commit here and >> > there? Sure, it has happened, with the best intent, so we just point >> > out that they need a bit more caution. No harm done. >> > >> > Back to Dennis' point: the solution here is proper review of the >> > commits that occur. (IMO) NOT a way to *exclude* or to *limit* the >> > potential contributions of others. >> > >> > Cheers, >> > -g >> > >> > On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote: >> > > In previous generations of this kind of discussion, the ASF old-hands >> will point out that the social process works quite well, folks don't do >> commits unless they feel qualified to do so, and it is often the case that >> committers will request RTC (i.e., submit patches rather than update the >> SVN) in contributing where they are not experienced or don't consider >> themselves expert. >> > > >> > > At the ASF this appears to be one of those, "if it is not broken, >> don't fix it." >> > > >> > > There is still the concern about stolen credentials used to perform >> undetected malicious acts. If the oversight that the project naturally >> brings to bear on visible changes to the code base is insufficient, I think >> the problem is greater than there being a possible exploit of that >> inattention. Mechanical solutions may be part of the disease, not the cure >> [;<). >> > > >> > > - Dennis >> > > >> > > -Original Message- >> > > From: Andrea Pescetti [mailto:pesce...@apache.org] >> > > Sent: Thursday, April 04, 2013 08:57 >> > > To: dev@openoffice.apache.org >> > > Subject: Re: Proposal: Improve security by limiting committer access >> in SVN >> > > >> > > Dave Fisher wrote: >> > > > Let's focus only on adding one new authz list for the code tree. >> > > > Call it openoffice-coders and populate it with those who HAVE any >> > > > commit activity in the current code tree. >> > > >> > > I checked feasibility with Infra. Summary: >> > > >> > > 1) LDAP is not the solution. Rule it out. >> > > >> > > 2) The only possible solution would be an authz rule like suggested by >> > > Dave here; however, Infra quite discourages it, mainly for maintenance >> > > reasons. This leads me to think we would need some good justifications >> > > for implementing this. >> > > >> > > 3) If the justification is security, then there are other privileges >> to >> > > monitor. Namely, every committer has shell access to >> people.apache.org, >> > > authenticated access to the Apache SMTP server and CMS privileges for >> > > the openoffice.org website, including publish operations. >> > > >> > > For the record, the Subversion project has complex rules like Rob >> > > pointed out; but it's only a "social enforcement", i.e., all >> committers >> > > respect those limitations by their own choice; if you look at the >> > > technical level, every committer (all Apache committers) can commit >> code >> > > to the Subversion subtree. >> > > >> > > Regards, >> > >Andrea. >> > > >> > > - >> > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> > > For additional commands, e-mail: dev-h...@openoffice.apache.org >> > > >> > > >> > > - >> > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> > > For additional commands, e-mail: dev-h...@openoffice.apache.org >> > > >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> > For additional commands, e-mail: dev-h...@openoffice.apache.org >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> >
Re: Proposal: Improve security by limiting committer access in SVN
gt; - Dennis > > PS: It seems to me that the special authz arrangements and SVN areas for > security fixes has to do with avoiding premature disclosure of a known > vulnerability that is already in released code. The list is private and > moderated for obvious reasons. Likewise, the private @oo.a.o is for > preserving the confidentiality of certain conversations (and that authz is > for related material on the SVN). There is no confidentiality to protect > in the public code base. That's the point. > > -----Original Message- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Thursday, April 04, 2013 09:44 > To: dev@openoffice.apache.org > Subject: Re: Proposal: Improve security by limiting committer access in SVN > > On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti >wrote: > > > Dave Fisher wrote: > > > >> Let's focus only on adding one new authz list for the code tree. > >> Call it openoffice-coders and populate it with those who HAVE any > >> commit activity in the current code tree. > >> > > > > I checked feasibility with Infra. Summary: > > > > 1) LDAP is not the solution. Rule it out. > > > > 2) The only possible solution would be an authz rule like suggested by > > Dave here; however, Infra quite discourages it, mainly for maintenance > > reasons. This leads me to think we would need some good justifications > for > > implementing this. > > > > > Would Infra need to maintain the authz , or would that be something that > you do? > > Note: we already have a separate authz for openoffice-security and > openoffice-pmc, for the same reasons -- there are some things that should > not be authorized for all committers. Going from 3 authz's to 4 is not > unreasonable, IMHO. > > > > 3) If the justification is security, then there are other privileges to > > monitor. Namely, every committer has shell access to people.apache.org, > > authenticated access to the Apache SMTP server and CMS privileges for the > > openoffice.org website, including publish operations. > > > > > > None of these get automatically included in releases that are installed on > tens of millions of machines. So I would not ask for additional controls > here. I'm asking only for additional controls on source code. > > > > For the record, the Subversion project has complex rules like Rob pointed > > out; but it's only a "social enforcement", i.e., all committers respect > > those limitations by their own choice; if you look at the technical > level, > > every committer (all Apache committers) can commit code to the Subversion > > subtree. > > > > > I'm not concerned with things where social enforcement would work. It is > not a concern that someone unqualified makes a change to the source code > merely because they have permissions. The issue is that the product is so > well-known and so broadly installed that it is automatically a target for > hackers, and with so many authorized user accounts from committers who are > not actively coding, or never were, that these authoriziations are > particularly vulnerable to compromise. > > I believe this a serious issue and we act irresponsibly and do a disservice > to our users if we treat this merely as an inconvenience or a social faux > pas. > > -Rob > > > > Regards, > > Andrea. > > > > > > --**--**- > > To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org< > dev-unsubscr...@openoffice.apache.org> > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: Proposal: Improve security by limiting committer access in SVN
> > > At the ASF this appears to be one of those, "if it is not broken, > don't fix it." > > > > > > There is still the concern about stolen credentials used to perform > undetected malicious acts. If the oversight that the project naturally > brings to bear on visible changes to the code base is insufficient, I think > the problem is greater than there being a possible exploit of that > inattention. Mechanical solutions may be part of the disease, not the cure > [;<). > > > > > > - Dennis > > > > > > -Original Message- > > > From: Andrea Pescetti [mailto:pesce...@apache.org] > > > Sent: Thursday, April 04, 2013 08:57 > > > To: dev@openoffice.apache.org > > > Subject: Re: Proposal: Improve security by limiting committer access > in SVN > > > > > > Dave Fisher wrote: > > > > Let's focus only on adding one new authz list for the code tree. > > > > Call it openoffice-coders and populate it with those who HAVE any > > > > commit activity in the current code tree. > > > > > > I checked feasibility with Infra. Summary: > > > > > > 1) LDAP is not the solution. Rule it out. > > > > > > 2) The only possible solution would be an authz rule like suggested by > > > Dave here; however, Infra quite discourages it, mainly for maintenance > > > reasons. This leads me to think we would need some good justifications > > > for implementing this. > > > > > > 3) If the justification is security, then there are other privileges to > > > monitor. Namely, every committer has shell access to people.apache.org > , > > > authenticated access to the Apache SMTP server and CMS privileges for > > > the openoffice.org website, including publish operations. > > > > > > For the record, the Subversion project has complex rules like Rob > > > pointed out; but it's only a "social enforcement", i.e., all committers > > > respect those limitations by their own choice; if you look at the > > > technical level, every committer (all Apache committers) can commit > code > > > to the Subversion subtree. > > > > > > Regards, > > >Andrea. > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
RE: Proposal: Improve security by limiting committer access in SVN
If the problem is that there are abandoned Apache credentials out there for the taking, the solution is to deal with the inactive committers and revocation of those credentials. And to assume that some sudden resuscitation can go unnoticed strikes me as not very plausible. (It strikes me as far more likely that such committers have lost/forgotten/mislaid their credentials and having them fall into the wrong hands is probably not a material risk.) The claim that there is automatic inclusion of malicious code introduced by a previously silent committer seems unsupportable. Whatever is done has to work without injury to "the Apache Way." Furthermore, modifications to code on the SVN are always reversible. That is considered the main line of defense for inappropriate commits to the SVN. (Use of the web site to create an exploit against browsers is a different problem that might need to be looked into. That's more immediate than attempting to get a patch by a watchful release manager. And, as far as I know, all web site updates also show up on the commit logs.) We've been taken through this rationale before. Why is it being raised anew? Has there been an actual exploit? I am having trouble accepting that there is a plausible risk of undetected exploit here, versus the kinds of attacks that could have far more serious consequences. There are exploits that are already far easier without anything happening at the ASF end of things. Having reliable code signatures would give us a way to discourage and repudiate the continuing reliance on exploit-vulnerable downloads that folks are now being exposed to. There are places in AOO worthy of investigation to limit the ways an AOO install might be an exploit enabler that are probably more important than the proposed defense of the SVN by requiring committer opt-in. I assume the opt-in should be requested using the apache @a.o e-mail (will that be part of the rules)? Will there be some e-mail confirmation requirement to protect against the account *already* having been compromised? Otherwise, this is all self-prescribed placebo. I shall not say anything further about whether or not this is done. While it may set some minds at ease, I think it is not doing much in terms of where the plausible threats already are and where opportunistic exploits may already be happening. - Dennis PS: It seems to me that the special authz arrangements and SVN areas for security fixes has to do with avoiding premature disclosure of a known vulnerability that is already in released code. The list is private and moderated for obvious reasons. Likewise, the private @oo.a.o is for preserving the confidentiality of certain conversations (and that authz is for related material on the SVN). There is no confidentiality to protect in the public code base. That's the point. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, April 04, 2013 09:44 To: dev@openoffice.apache.org Subject: Re: Proposal: Improve security by limiting committer access in SVN On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti wrote: > Dave Fisher wrote: > >> Let's focus only on adding one new authz list for the code tree. >> Call it openoffice-coders and populate it with those who HAVE any >> commit activity in the current code tree. >> > > I checked feasibility with Infra. Summary: > > 1) LDAP is not the solution. Rule it out. > > 2) The only possible solution would be an authz rule like suggested by > Dave here; however, Infra quite discourages it, mainly for maintenance > reasons. This leads me to think we would need some good justifications for > implementing this. > > Would Infra need to maintain the authz , or would that be something that you do? Note: we already have a separate authz for openoffice-security and openoffice-pmc, for the same reasons -- there are some things that should not be authorized for all committers. Going from 3 authz's to 4 is not unreasonable, IMHO. > 3) If the justification is security, then there are other privileges to > monitor. Namely, every committer has shell access to people.apache.org, > authenticated access to the Apache SMTP server and CMS privileges for the > openoffice.org website, including publish operations. > > None of these get automatically included in releases that are installed on tens of millions of machines. So I would not ask for additional controls here. I'm asking only for additional controls on source code. > For the record, the Subversion project has complex rules like Rob pointed > out; but it's only a "social enforcement", i.e., all committers respect > those limitations by their own choice; if you look at the technical level, > every committer (all Apache committers) can commit code to the Subversion > sub
Re: Proposal: Improve security by limiting committer access in SVN
Also, let me say one more thing: This notion of creating divisions among committers ... it is "solving" a problem that has never occurred here. NEVER. OCCURRED. In the Foundations's 14+ year history, we have never seen a trojan commit. Our servers have been compromised a handful of times. When we were back on CVS, we even had to audit source control to verify no trojan injection. But we have NEVER had a case of a malware commit. So back to IMO: dividing and partitioning and separate privilege levels... there is no reason. It creates a social problem to "solve" a non-existent issue. Net result: more problems. Cheers, -g On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote: > Speaking as one of those "old-hands", Dennis is absolutely spot-on. > > Partitions, barriers, sub-groups... I call those "divisive" mechanisms > which serve to divide the community. Such divisions are rarely needed. > > As Andrea points out, in Subversion's 13 year history, we have only > *requested* people observe certain fences. We have never had a > problem. We have never had to take sanctions. A stray commit here and > there? Sure, it has happened, with the best intent, so we just point > out that they need a bit more caution. No harm done. > > Back to Dennis' point: the solution here is proper review of the > commits that occur. (IMO) NOT a way to *exclude* or to *limit* the > potential contributions of others. > > Cheers, > -g > > On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote: > > In previous generations of this kind of discussion, the ASF old-hands will > > point out that the social process works quite well, folks don't do commits > > unless they feel qualified to do so, and it is often the case that > > committers will request RTC (i.e., submit patches rather than update the > > SVN) in contributing where they are not experienced or don't consider > > themselves expert. > > > > At the ASF this appears to be one of those, "if it is not broken, don't fix > > it." > > > > There is still the concern about stolen credentials used to perform > > undetected malicious acts. If the oversight that the project naturally > > brings to bear on visible changes to the code base is insufficient, I think > > the problem is greater than there being a possible exploit of that > > inattention. Mechanical solutions may be part of the disease, not the cure > > [;<). > > > > - Dennis > > > > -Original Message- > > From: Andrea Pescetti [mailto:pesce...@apache.org] > > Sent: Thursday, April 04, 2013 08:57 > > To: dev@openoffice.apache.org > > Subject: Re: Proposal: Improve security by limiting committer access in SVN > > > > Dave Fisher wrote: > > > Let's focus only on adding one new authz list for the code tree. > > > Call it openoffice-coders and populate it with those who HAVE any > > > commit activity in the current code tree. > > > > I checked feasibility with Infra. Summary: > > > > 1) LDAP is not the solution. Rule it out. > > > > 2) The only possible solution would be an authz rule like suggested by > > Dave here; however, Infra quite discourages it, mainly for maintenance > > reasons. This leads me to think we would need some good justifications > > for implementing this. > > > > 3) If the justification is security, then there are other privileges to > > monitor. Namely, every committer has shell access to people.apache.org, > > authenticated access to the Apache SMTP server and CMS privileges for > > the openoffice.org website, including publish operations. > > > > For the record, the Subversion project has complex rules like Rob > > pointed out; but it's only a "social enforcement", i.e., all committers > > respect those limitations by their own choice; if you look at the > > technical level, every committer (all Apache committers) can commit code > > to the Subversion subtree. > > > > Regards, > >Andrea. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
Speaking as one of those "old-hands", Dennis is absolutely spot-on. Partitions, barriers, sub-groups... I call those "divisive" mechanisms which serve to divide the community. Such divisions are rarely needed. As Andrea points out, in Subversion's 13 year history, we have only *requested* people observe certain fences. We have never had a problem. We have never had to take sanctions. A stray commit here and there? Sure, it has happened, with the best intent, so we just point out that they need a bit more caution. No harm done. Back to Dennis' point: the solution here is proper review of the commits that occur. (IMO) NOT a way to *exclude* or to *limit* the potential contributions of others. Cheers, -g On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote: > In previous generations of this kind of discussion, the ASF old-hands will > point out that the social process works quite well, folks don't do commits > unless they feel qualified to do so, and it is often the case that committers > will request RTC (i.e., submit patches rather than update the SVN) in > contributing where they are not experienced or don't consider themselves > expert. > > At the ASF this appears to be one of those, "if it is not broken, don't fix > it." > > There is still the concern about stolen credentials used to perform > undetected malicious acts. If the oversight that the project naturally > brings to bear on visible changes to the code base is insufficient, I think > the problem is greater than there being a possible exploit of that > inattention. Mechanical solutions may be part of the disease, not the cure > [;<). > > - Dennis > > -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Thursday, April 04, 2013 08:57 > To: dev@openoffice.apache.org > Subject: Re: Proposal: Improve security by limiting committer access in SVN > > Dave Fisher wrote: > > Let's focus only on adding one new authz list for the code tree. > > Call it openoffice-coders and populate it with those who HAVE any > > commit activity in the current code tree. > > I checked feasibility with Infra. Summary: > > 1) LDAP is not the solution. Rule it out. > > 2) The only possible solution would be an authz rule like suggested by > Dave here; however, Infra quite discourages it, mainly for maintenance > reasons. This leads me to think we would need some good justifications > for implementing this. > > 3) If the justification is security, then there are other privileges to > monitor. Namely, every committer has shell access to people.apache.org, > authenticated access to the Apache SMTP server and CMS privileges for > the openoffice.org website, including publish operations. > > For the record, the Subversion project has complex rules like Rob > pointed out; but it's only a "social enforcement", i.e., all committers > respect those limitations by their own choice; if you look at the > technical level, every committer (all Apache committers) can commit code > to the Subversion subtree. > > Regards, >Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
On 4 April 2013 19:44, Andrea Pescetti wrote: > Rob Weir wrote: > >> On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti wrote: >> >>> 2) The only possible solution would be an authz rule like suggested by >>> Dave here; however, Infra quite discourages it, mainly for maintenance >>> reasons. This leads me to think we would need some good justifications >>> for >>> implementing this. >>> >> Would Infra need to maintain the authz , or would that be something that >> you do? >> > > According to Infra, it's something that I can manage directly, even though > I've never looked into this recently (I just needed to make some changes > immediately after graduation). And I'm available to take care of this if > there is consensus on making write access to /trunk (and other subtrees) > optional. > +1 when it something we can manage ourself. and we should start by limiting to committers that have committed the last 6 month. > Regards, > Andrea. > > --**--**- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: Proposal: Improve security by limiting committer access in SVN
Rob Weir wrote: On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti wrote: 2) The only possible solution would be an authz rule like suggested by Dave here; however, Infra quite discourages it, mainly for maintenance reasons. This leads me to think we would need some good justifications for implementing this. Would Infra need to maintain the authz , or would that be something that you do? According to Infra, it's something that I can manage directly, even though I've never looked into this recently (I just needed to make some changes immediately after graduation). And I'm available to take care of this if there is consensus on making write access to /trunk (and other subtrees) optional. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti wrote: > Dave Fisher wrote: > >> Let's focus only on adding one new authz list for the code tree. >> Call it openoffice-coders and populate it with those who HAVE any >> commit activity in the current code tree. >> > > I checked feasibility with Infra. Summary: > > 1) LDAP is not the solution. Rule it out. > > 2) The only possible solution would be an authz rule like suggested by > Dave here; however, Infra quite discourages it, mainly for maintenance > reasons. This leads me to think we would need some good justifications for > implementing this. > > Would Infra need to maintain the authz , or would that be something that you do? Note: we already have a separate authz for openoffice-security and openoffice-pmc, for the same reasons -- there are some things that should not be authorized for all committers. Going from 3 authz's to 4 is not unreasonable, IMHO. > 3) If the justification is security, then there are other privileges to > monitor. Namely, every committer has shell access to people.apache.org, > authenticated access to the Apache SMTP server and CMS privileges for the > openoffice.org website, including publish operations. > > None of these get automatically included in releases that are installed on tens of millions of machines. So I would not ask for additional controls here. I'm asking only for additional controls on source code. > For the record, the Subversion project has complex rules like Rob pointed > out; but it's only a "social enforcement", i.e., all committers respect > those limitations by their own choice; if you look at the technical level, > every committer (all Apache committers) can commit code to the Subversion > subtree. > > I'm not concerned with things where social enforcement would work. It is not a concern that someone unqualified makes a change to the source code merely because they have permissions. The issue is that the product is so well-known and so broadly installed that it is automatically a target for hackers, and with so many authorized user accounts from committers who are not actively coding, or never were, that these authoriziations are particularly vulnerable to compromise. I believe this a serious issue and we act irresponsibly and do a disservice to our users if we treat this merely as an inconvenience or a social faux pas. -Rob > Regards, > Andrea. > > > --**--**- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: Proposal: Improve security by limiting committer access in SVN
On Thu, Apr 4, 2013 at 12:23 PM, Dennis E. Hamilton wrote: > In previous generations of this kind of discussion, the ASF old-hands will > point out that the social process works quite well, folks don't do commits > unless they feel qualified to do so, and it is often the case that > committers will request RTC (i.e., submit patches rather than update the > SVN) in contributing where they are not experienced or don't consider > themselves expert. > > At the ASF this appears to be one of those, "if it is not broken, don't > fix it." > > If it is visibly and publicly broken then it is too late to do anything about it. I'd like to think that there is room within the Apache Way for prevention, foresight and reasonable precaution. > There is still the concern about stolen credentials used to perform > undetected malicious acts. If the oversight that the project naturally > brings to bear on visible changes to the code base is insufficient, I think > the problem is greater than there being a possible exploit of that > inattention. Mechanical solutions may be part of the disease, not the cure > [;<). > The project does bear responsibility to review changes. But we also bear responsibility for having reasonable access controls. It is hard to argue that giving authorization for code changes to someone who showed a pulse in July 2011 but has never been heard of since is a reasonable policy. -Rob > > - Dennis > > -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Thursday, April 04, 2013 08:57 > To: dev@openoffice.apache.org > Subject: Re: Proposal: Improve security by limiting committer access in SVN > > Dave Fisher wrote: > > Let's focus only on adding one new authz list for the code tree. > > Call it openoffice-coders and populate it with those who HAVE any > > commit activity in the current code tree. > > I checked feasibility with Infra. Summary: > > 1) LDAP is not the solution. Rule it out. > > 2) The only possible solution would be an authz rule like suggested by > Dave here; however, Infra quite discourages it, mainly for maintenance > reasons. This leads me to think we would need some good justifications > for implementing this. > > 3) If the justification is security, then there are other privileges to > monitor. Namely, every committer has shell access to people.apache.org, > authenticated access to the Apache SMTP server and CMS privileges for > the openoffice.org website, including publish operations. > > For the record, the Subversion project has complex rules like Rob > pointed out; but it's only a "social enforcement", i.e., all committers > respect those limitations by their own choice; if you look at the > technical level, every committer (all Apache committers) can commit code > to the Subversion subtree. > > Regards, >Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
RE: Proposal: Improve security by limiting committer access in SVN
In previous generations of this kind of discussion, the ASF old-hands will point out that the social process works quite well, folks don't do commits unless they feel qualified to do so, and it is often the case that committers will request RTC (i.e., submit patches rather than update the SVN) in contributing where they are not experienced or don't consider themselves expert. At the ASF this appears to be one of those, "if it is not broken, don't fix it." There is still the concern about stolen credentials used to perform undetected malicious acts. If the oversight that the project naturally brings to bear on visible changes to the code base is insufficient, I think the problem is greater than there being a possible exploit of that inattention. Mechanical solutions may be part of the disease, not the cure [;<). - Dennis -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Thursday, April 04, 2013 08:57 To: dev@openoffice.apache.org Subject: Re: Proposal: Improve security by limiting committer access in SVN Dave Fisher wrote: > Let's focus only on adding one new authz list for the code tree. > Call it openoffice-coders and populate it with those who HAVE any > commit activity in the current code tree. I checked feasibility with Infra. Summary: 1) LDAP is not the solution. Rule it out. 2) The only possible solution would be an authz rule like suggested by Dave here; however, Infra quite discourages it, mainly for maintenance reasons. This leads me to think we would need some good justifications for implementing this. 3) If the justification is security, then there are other privileges to monitor. Namely, every committer has shell access to people.apache.org, authenticated access to the Apache SMTP server and CMS privileges for the openoffice.org website, including publish operations. For the record, the Subversion project has complex rules like Rob pointed out; but it's only a "social enforcement", i.e., all committers respect those limitations by their own choice; if you look at the technical level, every committer (all Apache committers) can commit code to the Subversion subtree. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
Dave Fisher wrote: Let's focus only on adding one new authz list for the code tree. Call it openoffice-coders and populate it with those who HAVE any commit activity in the current code tree. I checked feasibility with Infra. Summary: 1) LDAP is not the solution. Rule it out. 2) The only possible solution would be an authz rule like suggested by Dave here; however, Infra quite discourages it, mainly for maintenance reasons. This leads me to think we would need some good justifications for implementing this. 3) If the justification is security, then there are other privileges to monitor. Namely, every committer has shell access to people.apache.org, authenticated access to the Apache SMTP server and CMS privileges for the openoffice.org website, including publish operations. For the record, the Subversion project has complex rules like Rob pointed out; but it's only a "social enforcement", i.e., all committers respect those limitations by their own choice; if you look at the technical level, every committer (all Apache committers) can commit code to the Subversion subtree. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
On Wed, Apr 3, 2013 at 11:30 PM, Louis Suárez-Potts wrote: > Thanks, Rob, et al., > > On 13-04-03, at 22:22 , Peter Junge wrote: > > > One way of implementing this would be to look at all commits for the > >>> past 6 > months (or 1 year?) and remove authorization on /trunk, /tag and > >>> /branches > for those who have not made commits. But preserve authorization for > the > website directories. > > Thoughts? > > -Rob > > > > > In OOo we used SSH2. We also limited actual inclusion to code that had > been reviewed by a small coterie of project managers. This last part—that > that group of elites was another way of saying, "Sun" or, later, "Oracle," > led to displeasure. But not exactly because of the hierarchical system but > because it was perceived that that system allowed Sun to control things > while claiming open source openness. > > Whatever the merits of the critiques, having multiple layers of review and > using SSH2 (which I rather like, as I don't like passwords at all, having > read far too much Schneier) is one step. I'd also concur with the idea of > scrubbing the lists of nonactive committers. That set would include me. I > have not made any commits to the code (or anything) in the last year, at > least. > > I generally agree, but it will be important that we describe this in an accurate way. A "committer" is someone who contributes to the project and has demonstrated merit and then has been voted in as a committer by the PMC. Some will be coders. But many will be contributing in other ways. All committers get an Apache ID and password. These give automatic access to things like: a personal home directory on people.apache.org, the ability to send email from an apache.org email address, etc. There are other things that committers are entitled to, but which a separate request must be made, like a blog editor account or being a list moderator. What we're suggesting is that write access to the source code be one of those things that a committer must request separately. It would not be automatically enabled. So we're not talking about "inactive committers", since they may be active in the project in ways other than coding. I'd just describe it by saying we have committers that are involved in all areas of the project and each committer has the permissions they need to do the tasks they want to do. But we avoid giving automatic SVN permissions to everyone. This is not for hierarchical, or burocratic reasons, but purely for security reasons. We take security very importantly, as befits a product installed and used by many millions of users. -Rob The point here is not to diminish any kind of democratic spirit or > innovation but rather to ensure that the code we call ours (AOO) is really > just ours and not a trap for the unwary—malware. The problem with traps > like that is that rumour of their existence is almost as bad as their > presence. I've had more than one discussion with government officials who > said they could not use OO because they could not absolutely guarantee the > license or sanctity of the code. I was able to convince them of both, but > the point is that this sort of anxiety, fuelled by vicious minds, can only > be dismissed with facts. And if you have doubts, just look to see how > BlackDuck earns its profits. Enterprise adoption of open source is not seen > as risk free. > > BTW, in OOo, Web directories were treated a little differently, than code > but I argued for even stronger differentiation. > > -louis > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: Proposal: Improve security by limiting committer access in SVN
Thanks, Rob, et al., On 13-04-03, at 22:22 , Peter Junge wrote: One way of implementing this would be to look at all commits for the >>> past 6 months (or 1 year?) and remove authorization on /trunk, /tag and >>> /branches for those who have not made commits. But preserve authorization for the website directories. Thoughts? -Rob > In OOo we used SSH2. We also limited actual inclusion to code that had been reviewed by a small coterie of project managers. This last part—that that group of elites was another way of saying, "Sun" or, later, "Oracle," led to displeasure. But not exactly because of the hierarchical system but because it was perceived that that system allowed Sun to control things while claiming open source openness. Whatever the merits of the critiques, having multiple layers of review and using SSH2 (which I rather like, as I don't like passwords at all, having read far too much Schneier) is one step. I'd also concur with the idea of scrubbing the lists of nonactive committers. That set would include me. I have not made any commits to the code (or anything) in the last year, at least. The point here is not to diminish any kind of democratic spirit or innovation but rather to ensure that the code we call ours (AOO) is really just ours and not a trap for the unwary—malware. The problem with traps like that is that rumour of their existence is almost as bad as their presence. I've had more than one discussion with government officials who said they could not use OO because they could not absolutely guarantee the license or sanctity of the code. I was able to convince them of both, but the point is that this sort of anxiety, fuelled by vicious minds, can only be dismissed with facts. And if you have doubts, just look to see how BlackDuck earns its profits. Enterprise adoption of open source is not seen as risk free. BTW, in OOo, Web directories were treated a little differently, than code but I argued for even stronger differentiation. -louis - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
On 4/3/2013 9:05 PM, Rob Weir wrote: On Wed, Apr 3, 2013 at 8:57 AM, Alexandro Colorado wrote: I think restricting this would be a horrible idea, since we still have a shortage of developers. Limiting it by permissions and creating a red tape would be even more problematic. I think the key here is about the aproved releases. I don't really use windows, so I am not very familiar with the topic and whole process at hand when installing and testing. However I would focus more on the final QA than the initial access/commit to the code. I'm talking about restricting access for non-programmers, those who have permissions currently, but who have never ever contributed a single line of code. No actual programmer would be restricted. Could I check in code to be build with AOO? I assume yes. If that assumption is correct, I totally agree that such ability should be disabled. I don't need that to moderate mailing lists and observing from the peanut gallery. Peter For the kinds of risks I'm describing QA would accomplish nothing. Any hacker worth the name would delay activation of an attack until after millions of copies had already been installed, and then they would activate the code remotely. -Rob On 4/3/13, Rob Weir wrote: We're starting to take a deeper look at what is required to integrate code signing into the OpenOffice build and release process. As you probably know operating systems, especially Windows and MacOS, are now checking for digital signatures and by default prevent users from installing programs that are not signed. We see similar checks being integrated into anti-virus scanners and even web browsers now. One of the things that has come out in discussions is how large a target OpenOffice is, to hackers. We're on track to have 50 million downloads in our first year. If someone is able to get a virus or a trojan into our code, they have the ability to cause a huge amount of damage. And if we are also signing our code, then this damage can propagate even faster, since the OS's "let down their guard" somewhat when dealing with signed code. (Signed code == trust). Of course, none of this has ever happened with OpenOffice, but with the stature and reach we have, it is reasonable to believe that we could be a target of opportunity for someone wishing to cause trouble. We should always keep this in mind and make sure that we are taking reasonable precautions to prevent this from happening. One vulnerability, in theory, is that we have over 100 committers (123 to be exact) who have permission to modify the source code in Subversion. Each account is protected by a self-selected passcode. It is not clear to me that we even have requirements on password complexity or expiration policies. In any case, the weakness of this approach is not necessarily what you might think -- brute force attack on the password. If someone wants to initiate a "spear phishing" attack against a committer, it would be something like: 1) Standard phishing: a spoofed note from Apache Infra, with some invented story that asks you to change your password but first enter your old one for confirmation. It leads you to a fake, non-Apache website. 2) If you use the same passcode on multiple web services and one of them is compromised, say by retrieving the passcode hashes, then it is easy to do offline dictionary attacks (rainbow tables, etc.) and figure out your Apache password. 3) If you lose control of your laptop, at a conference, bar, hotel, whatever, even temporarily, someone can gain access to your Subversion account, via applications that cache credentials, like TortoiseSVN. 4) Similar to #3, but by taking control of your laptop via remote means, i.e., via a virus loaded on to your machine via another vulnerability. None of these things have happened to us yet, but all of these things are possible. So how do we reduce this risk? There are a few things we do or should be doing already. 1) Be careful on the machines that you use Subversion from. Treat it like a machine where you access your bank account from. If you are visiting risky sites or downloading and installing software from dubious places, then you are putting your Apache account at risk. 2) Use a high-complexity Apache passcode, one not used by you on any other service. 3) Change your passcode periodically, say every 90 days. 4) On laptops be sure to set a strong login password, but also where available also a separate harddrive password. These should also be strong passwords, not reused, and should be periodically changed. For those who are building binaries for distribution, the above guidance is even more critical. Of course, we also protect the code through our CTR process. All active coders should be subscribed to the commits list and should be reviewing the changes that are made there. Trust the code, not the person. Remember, if we ever are attacked then it will be through someone's com
Re: Proposal: Improve security by limiting committer access in SVN
On Wed, Apr 3, 2013 at 4:58 PM, janI wrote: > On 3 April 2013 22:30, Rob Weir wrote: > > > On Wed, Apr 3, 2013 at 1:45 PM, Andrea Pescetti > > wrote: > > > > > Jürgen Schmidt wrote: [...] > > > > > >> On 3 April 2013 14:39, Rob Weir wrote: > > > > > one change to our current process that will, I think, greatly > > increase > > > > > > security. This would be to restrict SVN authorization for the code > > > > > > > > I don't think this would greatly increase security, since the current > > > review model would still be the better defense. But surely this doesn't > > > decrease security and doesn't impact on people who are not using it. > > > > > > > > Good to think in layers of security. An account that is not authorized > is > > an account we don't need to worry about at all. > > > > Note: we have people currently authorized for our source code, who have > > *never* checked in code and who have *never* posted on the mailing list. > I > > have a heard time believing that they are following best practices to > avoid > > losing control of their Apache login credentials. > > > > > > > > > > I see also no problem if we handle it more careful and give svn access > > >> to the code on demand only. Nobody should take it personal > > >> > > > > > > Before we manage again to make simple discussions complex, let's see: > > > - All committers have the right to have write access to the source code > > > > > > > > > Yes, though the "right" is a de jure right, not exactly equivalent to the > > technical authorization. But one should lead to the other on demand. > > > > > > > > > - By default 3 subtrees (trunk, tags, branches) are read-only > > > - Any committer can receive write access to the 3 subtrees immediately, > > by > > > sending an e-mail here > > > > > > This could be fine for me, provided that: > > > > > > 1) We have the right way to manage this (another LDAP group does not > look > > > like the right solution: people who don't want to understand correctly > > will > > > invent that this is a multi-level hierarchy while it would simply be a > > > permission that we enable on demand) > > > Hmmm that I think ldap would be the normal way of handling it, but it is > pure technical and not something the user sees. > > > > > > > > 2) Enabling write access is extremely simple, especially if this is > > > something that I must take care of! Something like the current " > > > modify_unix_group.pl" scripts currently used for the committers group. > > > > > > Yes, that is how I understand subprojects. PMC can grant write access. > > > > > > > I'd do it like this: > > > > 0) Call it "active" and "dormant" statuses. This doesn't change status > as > > a committer, just status of SVN authorization. > > > +1 > > > > > 1) By default the active list includes only those who have made commits > to > > those trees in the last 12 months (or some other suitable time period). > > "Ever" would be a fine time period as well. > > > +1, I would prefer 6 month. > > > > > 2) Everyone else has authorization for /site, /ooo-site and /devtools > > > Are you sure about devtools, they they are equal to source in my opinion. > > I do work in /devtools/aoo-stats to maintain the python scripts that are used for gathering downloads statistics. I didn't think that anything in /devtools became part of a release. In any case, I don't touch the AOO source code, but I do touch /devtools, so that is why I was suggesting that division. But I may be the the only one in that particular category. -Rob > > > > 3) Any committer can be added to the active list on demand. > > > +1 with emphasis on demaend, default is read-only > > > > > 4) New committers are explained this when they are voted in and asked if > > they want to be on the active list for Subversion. > > > > +1 > > rgds > Jan I > > > > > Regards, > > > > -Rob > > > > Regards, > > > Andrea. > > > > > > > > > > --**--**- > > > To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org< > > dev-unsubscr...@openoffice.apache.org> > > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > > >
Re: Proposal: Improve security by limiting committer access in SVN
I'm going to top-post. I agree that this is a good idea, but I want to define it expansively as a positive. (1) The current authz that defines all of the AOO committers must be preserved. This is used to generate foundation information like: http://people.apache.org/committers-by-project.html#openoffice (2) Let's focus only on adding one new authz list for the code tree. Call it openoffice-coders and populate it with those who HAVE any commit activity in the current code tree. With ta coders authz everyone knows who is on the list by checking: http://people.apache.org/committers-by-project.html#openoffice-coders People can then really know who to bug to get their patch committed. (3) Andrea as PMC Chair or any Apache Member has karma to add or remove people on the coders authz. We can debate the rules, but those don't effect the structure implied. Let's look for Consensus on the structure first. Once that is out of the way we can easily describe how this new structure is a significant improvement and that it is a win all around without a real downside. (Some will spin a downside and parrying that is a different discussion.) Regards, Dave On Apr 3, 2013, at 1:30 PM, Rob Weir wrote: > On Wed, Apr 3, 2013 at 1:45 PM, Andrea Pescetti wrote: > >> Jürgen Schmidt wrote: [...] >> >>> On 3 April 2013 14:39, Rob Weir wrote: > >> one change to our current process that will, I think, greatly increase >> >> security. This would be to restrict SVN authorization for the code >> > >> I don't think this would greatly increase security, since the current >> review model would still be the better defense. But surely this doesn't >> decrease security and doesn't impact on people who are not using it. >> >> > Good to think in layers of security. An account that is not authorized is > an account we don't need to worry about at all. > > Note: we have people currently authorized for our source code, who have > *never* checked in code and who have *never* posted on the mailing list. I > have a heard time believing that they are following best practices to avoid > losing control of their Apache login credentials. > > >> >> I see also no problem if we handle it more careful and give svn access >>> to the code on demand only. Nobody should take it personal >>> >> >> Before we manage again to make simple discussions complex, let's see: >> - All committers have the right to have write access to the source code >> > > > Yes, though the "right" is a de jure right, not exactly equivalent to the > technical authorization. But one should lead to the other on demand. > > > >> - By default 3 subtrees (trunk, tags, branches) are read-only >> - Any committer can receive write access to the 3 subtrees immediately, by >> sending an e-mail here >> >> This could be fine for me, provided that: >> >> 1) We have the right way to manage this (another LDAP group does not look >> like the right solution: people who don't want to understand correctly will >> invent that this is a multi-level hierarchy while it would simply be a >> permission that we enable on demand) >> >> 2) Enabling write access is extremely simple, especially if this is >> something that I must take care of! Something like the current " >> modify_unix_group.pl" scripts currently used for the committers group. >> >> > I'd do it like this: > > 0) Call it "active" and "dormant" statuses. This doesn't change status as > a committer, just status of SVN authorization. > > 1) By default the active list includes only those who have made commits to > those trees in the last 12 months (or some other suitable time period). > "Ever" would be a fine time period as well. > > 2) Everyone else has authorization for /site, /ooo-site and /devtools > > 3) Any committer can be added to the active list on demand. > > 4) New committers are explained this when they are voted in and asked if > they want to be on the active list for Subversion. > > Regards, > > -Rob > > Regards, >> Andrea. >> >> >> --**--**- >> To unsubscribe, e-mail: >> dev-unsubscribe@openoffice.**apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
Am 04/03/2013 10:58 PM, schrieb janI: On 3 April 2013 22:30, Rob Weir wrote: On Wed, Apr 3, 2013 at 1:45 PM, Andrea Pescetti wrote: Jürgen Schmidt wrote: [...] On 3 April 2013 14:39, Rob Weir wrote: one change to our current process that will, I think, greatly increase security. This would be to restrict SVN authorization for the code I don't think this would greatly increase security, since the current review model would still be the better defense. But surely this doesn't decrease security and doesn't impact on people who are not using it. Good to think in layers of security. An account that is not authorized is an account we don't need to worry about at all. Note: we have people currently authorized for our source code, who have *never* checked in code and who have *never* posted on the mailing list. I have a heard time believing that they are following best practices to avoid losing control of their Apache login credentials. I see also no problem if we handle it more careful and give svn access to the code on demand only. Nobody should take it personal Before we manage again to make simple discussions complex, let's see: - All committers have the right to have write access to the source code Yes, though the "right" is a de jure right, not exactly equivalent to the technical authorization. But one should lead to the other on demand. - By default 3 subtrees (trunk, tags, branches) are read-only - Any committer can receive write access to the 3 subtrees immediately, by sending an e-mail here This could be fine for me, provided that: 1) We have the right way to manage this (another LDAP group does not look like the right solution: people who don't want to understand correctly will invent that this is a multi-level hierarchy while it would simply be a permission that we enable on demand) Hmmm that I think ldap would be the normal way of handling it, but it is pure technical and not something the user sees. 2) Enabling write access is extremely simple, especially if this is something that I must take care of! Something like the current " modify_unix_group.pl" scripts currently used for the committers group. Yes, that is how I understand subprojects. PMC can grant write access. I'd do it like this: 0) Call it "active" and "dormant" statuses. This doesn't change status as a committer, just status of SVN authorization. +1 1) By default the active list includes only those who have made commits to those trees in the last 12 months (or some other suitable time period). "Ever" would be a fine time period as well. +1, I would prefer 6 month. 2) Everyone else has authorization for /site, /ooo-site and /devtools Are you sure about devtools, they they are equal to source in my opinion. 3) Any committer can be added to the active list on demand. +1 with emphasis on demaend, default is read-only 4) New committers are explained this when they are voted in and asked if they want to be on the active list for Subversion. +1 rgds Jan I I'm one of them who would loose commit permission to the core code. But for me it would be OK. As my knowledge is not big enough to play with you in this "premier league" of C++/C, Java, etc. it doesn't make any difference for me if I could or could not commit. So, if it helps to increase the security a bit, then I'm fine with it. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
Le 03/04/2013 15:13, Rob Weir a écrit : 3) We have those who are voted in as committers and might access other, non SVN systems. They use their Apache ID's to write blog posts, access Pootle directly, or maybe even just the SMTP servers. But they never touch SVN at all. I'm one of these committers (initially to have a blog account). I said I resigned several months ago but I don't know if I've been removed from the system (I still receive the mail to committers). That would be one inactive account less. Hagar - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
On Wed, Apr 3, 2013 at 5:02 PM, Dennis E. Hamilton wrote: > My sense of this is that there is a desire to reduce the "threat surface" > of the SVN by requiring committers to opt-in. (I assume there is some way > to decide which committers to grandfather.) Apparently, that is a one-time > act and it doesn't alter being relatively inactive. So I guess this will > have to be a periodic ceremonial requirement. > > I take it that this means an attacker breaks into an existing committer's > account in some manner, impersonating that committer in a manner that (1) > the committer doesn't notice (possible) and that (2) it doesn't attract > attention on the commit logs (i.e., CTR fails at R). It seems to me that > new activity by an inactive committer (that orcmid fellow, for example) > would be noticed and it would be difficult to do anything that looked > suspicious. (Orcmid did make a commit recently, but it was to fix > something on the web site and it was done via the CMS.) > > I also don't understand how phishing would work. I can't imagine > receiving anything that requires me to use my @apache credentials anywhere > without attracting great concern. If there's a successful > Man-in-the-Middle exploit against the SVN, it is not the inactive > committers that are going to be hacked. > And I can't imagine that you would fall for a phishing attack either. I'm not thinking of you. But remember, when we first started as a poding we handed out a committer rights to anyone who had a pulse. Every one of their accounts has exactly the same permission set yours does. This is not the place to teach hacking, but getting 5-10% of committers to enter their Apache credentials into a webform linked to by a spoofed email purporting to come from a trusted party would be rather easy, -Rob > > As far as I know, the only successful attacks against the ASF (and Apache > committers) involved compromising servers and stealing password hashes, > making them vulnerable to off-line password discovery. The mitigation > seems to have worked. > > I think an use it or lose it approach to committer authorization might be > more effective. It won't get the account off the books (as far as I know), > but it would shrink the authz surface of the individual project code base. > Fortunately, that will not disturb the bugzilla or authorization to edit > on Planet Apache, afaik. > > - Dennis > > -----Original Message----- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Wednesday, April 03, 2013 13:17 > To: dev@openoffice.apache.org; > Subject: Re: Proposal: Improve security by limiting committer access in SVN > > [ ... ] > It is not about trusting the committers. It is about reducing the > exposures to hackers. Trust of the committer has nothing to do with it. > Every active authorization in SVN is a vulnerable opening for a hacker, who > can gain access, via any number of phishing methods in common use today. > It us only prudent that a committer not have that authorization unless they > are using it. > > -Rob > > > [ ... ] > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
RE: Proposal: Improve security by limiting committer access in SVN
My sense of this is that there is a desire to reduce the "threat surface" of the SVN by requiring committers to opt-in. (I assume there is some way to decide which committers to grandfather.) Apparently, that is a one-time act and it doesn't alter being relatively inactive. So I guess this will have to be a periodic ceremonial requirement. I take it that this means an attacker breaks into an existing committer's account in some manner, impersonating that committer in a manner that (1) the committer doesn't notice (possible) and that (2) it doesn't attract attention on the commit logs (i.e., CTR fails at R). It seems to me that new activity by an inactive committer (that orcmid fellow, for example) would be noticed and it would be difficult to do anything that looked suspicious. (Orcmid did make a commit recently, but it was to fix something on the web site and it was done via the CMS.) I also don't understand how phishing would work. I can't imagine receiving anything that requires me to use my @apache credentials anywhere without attracting great concern. If there's a successful Man-in-the-Middle exploit against the SVN, it is not the inactive committers that are going to be hacked. As far as I know, the only successful attacks against the ASF (and Apache committers) involved compromising servers and stealing password hashes, making them vulnerable to off-line password discovery. The mitigation seems to have worked. I think an use it or lose it approach to committer authorization might be more effective. It won't get the account off the books (as far as I know), but it would shrink the authz surface of the individual project code base. Fortunately, that will not disturb the bugzilla or authorization to edit on Planet Apache, afaik. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Wednesday, April 03, 2013 13:17 To: dev@openoffice.apache.org; Subject: Re: Proposal: Improve security by limiting committer access in SVN [ ... ] It is not about trusting the committers. It is about reducing the exposures to hackers. Trust of the committer has nothing to do with it. Every active authorization in SVN is a vulnerable opening for a hacker, who can gain access, via any number of phishing methods in common use today. It us only prudent that a committer not have that authorization unless they are using it. -Rob [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
On 3 April 2013 22:30, Rob Weir wrote: > On Wed, Apr 3, 2013 at 1:45 PM, Andrea Pescetti > wrote: > > > Jürgen Schmidt wrote: [...] > > > >> On 3 April 2013 14:39, Rob Weir wrote: > > > one change to our current process that will, I think, greatly > increase > > > > security. This would be to restrict SVN authorization for the code > > > > > I don't think this would greatly increase security, since the current > > review model would still be the better defense. But surely this doesn't > > decrease security and doesn't impact on people who are not using it. > > > > > Good to think in layers of security. An account that is not authorized is > an account we don't need to worry about at all. > > Note: we have people currently authorized for our source code, who have > *never* checked in code and who have *never* posted on the mailing list. I > have a heard time believing that they are following best practices to avoid > losing control of their Apache login credentials. > > > > > > I see also no problem if we handle it more careful and give svn access > >> to the code on demand only. Nobody should take it personal > >> > > > > Before we manage again to make simple discussions complex, let's see: > > - All committers have the right to have write access to the source code > > > > > Yes, though the "right" is a de jure right, not exactly equivalent to the > technical authorization. But one should lead to the other on demand. > > > > > - By default 3 subtrees (trunk, tags, branches) are read-only > > - Any committer can receive write access to the 3 subtrees immediately, > by > > sending an e-mail here > > > > This could be fine for me, provided that: > > > > 1) We have the right way to manage this (another LDAP group does not look > > like the right solution: people who don't want to understand correctly > will > > invent that this is a multi-level hierarchy while it would simply be a > > permission that we enable on demand) > Hmmm that I think ldap would be the normal way of handling it, but it is pure technical and not something the user sees. > > > > 2) Enabling write access is extremely simple, especially if this is > > something that I must take care of! Something like the current " > > modify_unix_group.pl" scripts currently used for the committers group. > > > Yes, that is how I understand subprojects. PMC can grant write access. > > > I'd do it like this: > > 0) Call it "active" and "dormant" statuses. This doesn't change status as > a committer, just status of SVN authorization. > +1 > > 1) By default the active list includes only those who have made commits to > those trees in the last 12 months (or some other suitable time period). > "Ever" would be a fine time period as well. > +1, I would prefer 6 month. > > 2) Everyone else has authorization for /site, /ooo-site and /devtools > Are you sure about devtools, they they are equal to source in my opinion. > > 3) Any committer can be added to the active list on demand. > +1 with emphasis on demaend, default is read-only > > 4) New committers are explained this when they are voted in and asked if > they want to be on the active list for Subversion. > > +1 rgds Jan I > > Regards, > > -Rob > > Regards, > > Andrea. > > > > > > --**--**- > > To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org< > dev-unsubscr...@openoffice.apache.org> > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > >
Re: Proposal: Improve security by limiting committer access in SVN
On Wed, Apr 3, 2013 at 1:45 PM, Andrea Pescetti wrote: > Jürgen Schmidt wrote: [...] > >> On 3 April 2013 14:39, Rob Weir wrote: > one change to our current process that will, I think, greatly increase > > security. This would be to restrict SVN authorization for the code > > I don't think this would greatly increase security, since the current > review model would still be the better defense. But surely this doesn't > decrease security and doesn't impact on people who are not using it. > > Good to think in layers of security. An account that is not authorized is an account we don't need to worry about at all. Note: we have people currently authorized for our source code, who have *never* checked in code and who have *never* posted on the mailing list. I have a heard time believing that they are following best practices to avoid losing control of their Apache login credentials. > > I see also no problem if we handle it more careful and give svn access >> to the code on demand only. Nobody should take it personal >> > > Before we manage again to make simple discussions complex, let's see: > - All committers have the right to have write access to the source code > Yes, though the "right" is a de jure right, not exactly equivalent to the technical authorization. But one should lead to the other on demand. > - By default 3 subtrees (trunk, tags, branches) are read-only > - Any committer can receive write access to the 3 subtrees immediately, by > sending an e-mail here > > This could be fine for me, provided that: > > 1) We have the right way to manage this (another LDAP group does not look > like the right solution: people who don't want to understand correctly will > invent that this is a multi-level hierarchy while it would simply be a > permission that we enable on demand) > > 2) Enabling write access is extremely simple, especially if this is > something that I must take care of! Something like the current " > modify_unix_group.pl" scripts currently used for the committers group. > > I'd do it like this: 0) Call it "active" and "dormant" statuses. This doesn't change status as a committer, just status of SVN authorization. 1) By default the active list includes only those who have made commits to those trees in the last 12 months (or some other suitable time period). "Ever" would be a fine time period as well. 2) Everyone else has authorization for /site, /ooo-site and /devtools 3) Any committer can be added to the active list on demand. 4) New committers are explained this when they are voted in and asked if they want to be on the active list for Subversion. Regards, -Rob Regards, > Andrea. > > > --**--**- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: Proposal: Improve security by limiting committer access in SVN
On Wed, Apr 3, 2013 at 4:08 PM, Dennis E. Hamilton wrote: > I'm not clear why a non-LDAP solution is required: > > 1. Being a committer is specific to a project. What it means to be a > committer on a project is very well-defined. > > And in some Apache projects they do exactly what I am proposing. For example, Subversion has full committers, partial committers and dormant committers: https://svn.apache.org/repos/asf/subversion/trunk/COMMITTERS > 2. The SVN repositories of the public ASF projects are publicly > read-only. That's a no-brainer. They are only writable to those who have > SVN permission by virtue of being committers on this project. That's > project specific. There's an authz file that does it. > > Some other SVN repositories are also writeable by virtue of being > committers at the ASF. That seems to be ASF-specific. > > Sort of. They are writable because of the authz. How exactly that is connected to committership is up to the project and is what is under discussion here. > It makes no sense for a committer who is established as a committer of > this project to *not* have committer privileges on the SVN. It's what > committer *means.* > > Actually, it makes no sense to be in the authz file unless you intent to change files in Subversion. If you have the permission but never intent to use it, then you are merely raising the security risk for the project. > The necessary ceremony was the acceptance of a committer invitation (or > being grandfathered as an initial committer who completed the necessary > steps). > > If there are now trust issues, I think the proposed solution is > ineffective. If there is a concern about inactive committers, address that. > > It is not about trusting the committers. It is about reducing the exposures to hackers. Trust of the committer has nothing to do with it. Every active authorization in SVN is a vulnerable opening for a hacker, who can gain access, via any number of phishing methods in common use today. It us only prudent that a committer not have that authorization unless they are using it. -Rob > - Dennis > > -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Wednesday, April 03, 2013 10:46 > To: dev@openoffice.apache.org > Subject: Re: Proposal: Improve security by limiting committer access in SVN > > Jürgen Schmidt wrote: [...] > >>> On 3 April 2013 14:39, Rob Weir wrote: > >>>> one change to our current process that will, I think, greatly increase > >>>> security. This would be to restrict SVN authorization for the code > > I don't think this would greatly increase security, since the current > review model would still be the better defense. But surely this doesn't > decrease security and doesn't impact on people who are not using it. > > > I see also no problem if we handle it more careful and give svn access > > to the code on demand only. Nobody should take it personal > > Before we manage again to make simple discussions complex, let's see: > - All committers have the right to have write access to the source code > - By default 3 subtrees (trunk, tags, branches) are read-only > - Any committer can receive write access to the 3 subtrees immediately, > by sending an e-mail here > > This could be fine for me, provided that: > > 1) We have the right way to manage this (another LDAP group does not > look like the right solution: people who don't want to understand > correctly will invent that this is a multi-level hierarchy while it > would simply be a permission that we enable on demand) > > 2) Enabling write access is extremely simple, especially if this is > something that I must take care of! Something like the current > "modify_unix_group.pl" scripts currently used for the committers group. > > Regards, >Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
RE: Proposal: Improve security by limiting committer access in SVN
I'm not clear why a non-LDAP solution is required: 1. Being a committer is specific to a project. What it means to be a committer on a project is very well-defined. 2. The SVN repositories of the public ASF projects are publicly read-only. That's a no-brainer. They are only writable to those who have SVN permission by virtue of being committers on this project. That's project specific. There's an authz file that does it. Some other SVN repositories are also writeable by virtue of being committers at the ASF. That seems to be ASF-specific. It makes no sense for a committer who is established as a committer of this project to *not* have committer privileges on the SVN. It's what committer *means.* The necessary ceremony was the acceptance of a committer invitation (or being grandfathered as an initial committer who completed the necessary steps). If there are now trust issues, I think the proposed solution is ineffective. If there is a concern about inactive committers, address that. - Dennis -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Wednesday, April 03, 2013 10:46 To: dev@openoffice.apache.org Subject: Re: Proposal: Improve security by limiting committer access in SVN Jürgen Schmidt wrote: [...] >>> On 3 April 2013 14:39, Rob Weir wrote: >>>> one change to our current process that will, I think, greatly increase >>>> security. This would be to restrict SVN authorization for the code I don't think this would greatly increase security, since the current review model would still be the better defense. But surely this doesn't decrease security and doesn't impact on people who are not using it. > I see also no problem if we handle it more careful and give svn access > to the code on demand only. Nobody should take it personal Before we manage again to make simple discussions complex, let's see: - All committers have the right to have write access to the source code - By default 3 subtrees (trunk, tags, branches) are read-only - Any committer can receive write access to the 3 subtrees immediately, by sending an e-mail here This could be fine for me, provided that: 1) We have the right way to manage this (another LDAP group does not look like the right solution: people who don't want to understand correctly will invent that this is a multi-level hierarchy while it would simply be a permission that we enable on demand) 2) Enabling write access is extremely simple, especially if this is something that I must take care of! Something like the current "modify_unix_group.pl" scripts currently used for the committers group. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
Jürgen Schmidt wrote: [...] On 3 April 2013 14:39, Rob Weir wrote: one change to our current process that will, I think, greatly increase security. This would be to restrict SVN authorization for the code I don't think this would greatly increase security, since the current review model would still be the better defense. But surely this doesn't decrease security and doesn't impact on people who are not using it. I see also no problem if we handle it more careful and give svn access to the code on demand only. Nobody should take it personal Before we manage again to make simple discussions complex, let's see: - All committers have the right to have write access to the source code - By default 3 subtrees (trunk, tags, branches) are read-only - Any committer can receive write access to the 3 subtrees immediately, by sending an e-mail here This could be fine for me, provided that: 1) We have the right way to manage this (another LDAP group does not look like the right solution: people who don't want to understand correctly will invent that this is a multi-level hierarchy while it would simply be a permission that we enable on demand) 2) Enabling write access is extremely simple, especially if this is something that I must take care of! Something like the current "modify_unix_group.pl" scripts currently used for the committers group. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
On 03/04/2013 16:13, Rob Weir wrote: > On Wed, Apr 3, 2013 at 9:06 AM, janI wrote: > >> On 3 April 2013 14:39, Rob Weir wrote: >> >>> We're starting to take a deeper look at what is required to integrate >> code >>> signing into the OpenOffice build and release process. As you probably >> know >>> operating systems, especially Windows and MacOS, are now checking for >>> digital signatures and by default prevent users from installing programs >>> that are not signed. We see similar checks being integrated into >>> anti-virus scanners and even web browsers now. >>> >>> One of the things that has come out in discussions is how large a target >>> OpenOffice is, to hackers. We're on track to have 50 million downloads >> in >>> our first year. If someone is able to get a virus or a trojan into our >>> code, they have the ability to cause a huge amount of damage. And if we >>> are also signing our code, then this damage can propagate even faster, >>> since the OS's "let down their guard" somewhat when dealing with signed >>> code. (Signed code == trust). >>> >>> Of course, none of this has ever happened with OpenOffice, but with the >>> stature and reach we have, it is reasonable to believe that we could be a >>> target of opportunity for someone wishing to cause trouble. We should >>> always keep this in mind and make sure that we are taking reasonable >>> precautions to prevent this from happening. >>> >>> One vulnerability, in theory, is that we have over 100 committers (123 to >>> be exact) who have permission to modify the source code in Subversion. >>> Each account is protected by a self-selected passcode. It is not clear >> to >>> me that we even have requirements on password complexity or expiration >>> policies. In any case, the weakness of this approach is not necessarily >>> what you might think -- brute force attack on the password. If someone >>> wants to initiate a "spear phishing" attack against a committer, it would >>> be something like: >>> >>> 1) Standard phishing: a spoofed note from Apache Infra, with some >> invented >>> story that asks you to change your password but first enter your old one >>> for confirmation. It leads you to a fake, non-Apache website. >>> >>> 2) If you use the same passcode on multiple web services and one of them >> is >>> compromised, say by retrieving the passcode hashes, then it is easy to do >>> offline dictionary attacks (rainbow tables, etc.) and figure out your >>> Apache password. >>> >>> 3) If you lose control of your laptop, at a conference, bar, hotel, >>> whatever, even temporarily, someone can gain access to your Subversion >>> account, via applications that cache credentials, like TortoiseSVN. >>> >>> 4) Similar to #3, but by taking control of your laptop via remote means, >>> i.e., via a virus loaded on to your machine via another vulnerability. >>> >> None of these things have happened to us yet, but all of these things are >>> possible. >>> >>> So how do we reduce this risk? There are a few things we do or should be >>> doing already. >>> >>> 1) Be careful on the machines that you use Subversion from. Treat it >> like >>> a machine where you access your bank account from. If you are visiting >>> risky sites or downloading and installing software from dubious places, >>> then you are putting your Apache account at risk. >>> >>> 2) Use a high-complexity Apache passcode, one not used by you on any >> other >>> service. >>> >>> 3) Change your passcode periodically, say every 90 days. >>> >> 4) On laptops be sure to set a strong login password, but also where >>> available also a separate harddrive password. These should also be >> strong >>> passwords, not reused, and should be periodically changed. >>> >>> For those who are building binaries for distribution, the above guidance >> is >>> even more critical. >>> >>> Of course, we also protect the code through our CTR process. All active >>> coders should be subscribed to the commits list and should be reviewing >> the >>> changes that are made there. Trust the code, not the person. Remember, >> if >>> we ever are attacked then it will be through someone's compromised >>> account. So if you see an odd check-in, say, from Juergen, don't just >>> accept it saying "Juergen knows what he is doing". If it is odd, then it >>> should be challenged. >>> >>> All of the above should already be going on today. But I'd like to >> propose >>> one change to our current process that will, I think, greatly increase >>> security. This would be to restrict SVN authorization for the code to >> only >>> the subset of committers who are actively coding. We should give this >>> authorization freely to committers who request it. But today we have 123 >>> committers, some of whom have never used Subversion, and some (like me) >> who >>> edit /site and /ooo-site but never touch the code. So we probably have >> 90 >>> or more accounts that don't need access to the source code tree. Since >>> such used ac
Re: Proposal: Improve security by limiting committer access in SVN
janI wrote: > But we have to very carefull not make it even harder to become/be > committer, compare us a bit with LO, there I can have commit access > within less than a day. > Hi Jan, just to get this straight - we try hard to have your patch committed / initial feedback provided in a day. Getting you actual commit access to the core repos needs consistent, good patches over some time though, and happens after review by several other hackers. Cheers, -- Thorsten signature.asc Description: Digital signature
Re: Proposal: Improve security by limiting committer access in SVN
On 4/3/13, Rob Weir wrote: > On Wed, Apr 3, 2013 at 8:57 AM, Alexandro Colorado wrote: > >> I think restricting this would be a horrible idea, since we still have >> a shortage of developers. Limiting it by permissions and creating a >> red tape would be even more problematic. I think the key here is about >> the aproved releases. I don't really use windows, so I am not very >> familiar with the topic and whole process at hand when installing and >> testing. However I would focus more on the final QA than the initial >> access/commit to the code. >> >> > I'm talking about restricting access for non-programmers, those who have > permissions currently, but who have never ever contributed a single line of > code. No actual programmer would be restricted. > > For the kinds of risks I'm describing QA would accomplish nothing. Any > hacker worth the name would delay activation of an attack until after > millions of copies had already been installed, and then they would activate > the code remotely. > I think this needs to be solved upstream. Apache could handle this disucssions and then recomend what to do. This "sign" issue affects not only openoffice but most of the Apache projects. I dont think we should solve it in a vacum. > -Rob > > > >> On 4/3/13, Rob Weir wrote: >> > We're starting to take a deeper look at what is required to integrate >> code >> > signing into the OpenOffice build and release process. As you probably >> know >> > operating systems, especially Windows and MacOS, are now checking for >> > digital signatures and by default prevent users from installing >> > programs >> > that are not signed. We see similar checks being integrated into >> > anti-virus scanners and even web browsers now. >> > >> > One of the things that has come out in discussions is how large a >> > target >> > OpenOffice is, to hackers. We're on track to have 50 million downloads >> in >> > our first year. If someone is able to get a virus or a trojan into our >> > code, they have the ability to cause a huge amount of damage. And if >> > we >> > are also signing our code, then this damage can propagate even faster, >> > since the OS's "let down their guard" somewhat when dealing with signed >> > code. (Signed code == trust). >> > >> > Of course, none of this has ever happened with OpenOffice, but with the >> > stature and reach we have, it is reasonable to believe that we could be >> > a >> > target of opportunity for someone wishing to cause trouble. We should >> > always keep this in mind and make sure that we are taking reasonable >> > precautions to prevent this from happening. >> > >> > One vulnerability, in theory, is that we have over 100 committers (123 >> > to >> > be exact) who have permission to modify the source code in Subversion. >> > Each account is protected by a self-selected passcode. It is not clear >> to >> > me that we even have requirements on password complexity or expiration >> > policies. In any case, the weakness of this approach is not >> > necessarily >> > what you might think -- brute force attack on the password. If someone >> > wants to initiate a "spear phishing" attack against a committer, it >> > would >> > be something like: >> > >> > 1) Standard phishing: a spoofed note from Apache Infra, with some >> invented >> > story that asks you to change your password but first enter your old >> > one >> > for confirmation. It leads you to a fake, non-Apache website. >> > >> > 2) If you use the same passcode on multiple web services and one of >> > them >> is >> > compromised, say by retrieving the passcode hashes, then it is easy to >> > do >> > offline dictionary attacks (rainbow tables, etc.) and figure out your >> > Apache password. >> > >> > 3) If you lose control of your laptop, at a conference, bar, hotel, >> > whatever, even temporarily, someone can gain access to your Subversion >> > account, via applications that cache credentials, like TortoiseSVN. >> > >> > 4) Similar to #3, but by taking control of your laptop via remote >> > means, >> > i.e., via a virus loaded on to your machine via another vulnerability. >> > >> > None of these things have happened to us yet, but all of these things >> > are >> > possible. >> > >> > So how do we reduce this risk? There are a few things we do or should >> > be >> > doing already. >> > >> > 1) Be careful on the machines that you use Subversion from. Treat it >> like >> > a machine where you access your bank account from. If you are visiting >> > risky sites or downloading and installing software from dubious places, >> > then you are putting your Apache account at risk. >> > >> > 2) Use a high-complexity Apache passcode, one not used by you on any >> other >> > service. >> > >> > 3) Change your passcode periodically, say every 90 days. >> > >> > 4) On laptops be sure to set a strong login password, but also where >> > available also a separate harddrive password. These should also be >> strong >> > passwords, not reused, and sh
Re: Proposal: Improve security by limiting committer access in SVN
On 4/3/13 3:13 PM, Rob Weir wrote: > On Wed, Apr 3, 2013 at 9:06 AM, janI wrote: > >> On 3 April 2013 14:39, Rob Weir wrote: >> >>> We're starting to take a deeper look at what is required to integrate >> code >>> signing into the OpenOffice build and release process. As you probably >> know >>> operating systems, especially Windows and MacOS, are now checking for >>> digital signatures and by default prevent users from installing programs >>> that are not signed. We see similar checks being integrated into >>> anti-virus scanners and even web browsers now. >>> >>> One of the things that has come out in discussions is how large a target >>> OpenOffice is, to hackers. We're on track to have 50 million downloads >> in >>> our first year. If someone is able to get a virus or a trojan into our >>> code, they have the ability to cause a huge amount of damage. And if we >>> are also signing our code, then this damage can propagate even faster, >>> since the OS's "let down their guard" somewhat when dealing with signed >>> code. (Signed code == trust). >>> >>> Of course, none of this has ever happened with OpenOffice, but with the >>> stature and reach we have, it is reasonable to believe that we could be a >>> target of opportunity for someone wishing to cause trouble. We should >>> always keep this in mind and make sure that we are taking reasonable >>> precautions to prevent this from happening. >>> >>> One vulnerability, in theory, is that we have over 100 committers (123 to >>> be exact) who have permission to modify the source code in Subversion. >>> Each account is protected by a self-selected passcode. It is not clear >> to >>> me that we even have requirements on password complexity or expiration >>> policies. In any case, the weakness of this approach is not necessarily >>> what you might think -- brute force attack on the password. If someone >>> wants to initiate a "spear phishing" attack against a committer, it would >>> be something like: >>> >>> 1) Standard phishing: a spoofed note from Apache Infra, with some >> invented >>> story that asks you to change your password but first enter your old one >>> for confirmation. It leads you to a fake, non-Apache website. >>> >>> 2) If you use the same passcode on multiple web services and one of them >> is >>> compromised, say by retrieving the passcode hashes, then it is easy to do >>> offline dictionary attacks (rainbow tables, etc.) and figure out your >>> Apache password. >>> >>> 3) If you lose control of your laptop, at a conference, bar, hotel, >>> whatever, even temporarily, someone can gain access to your Subversion >>> account, via applications that cache credentials, like TortoiseSVN. >>> >>> 4) Similar to #3, but by taking control of your laptop via remote means, >>> i.e., via a virus loaded on to your machine via another vulnerability. >>> >> >> None of these things have happened to us yet, but all of these things are >>> possible. >>> >>> So how do we reduce this risk? There are a few things we do or should be >>> doing already. >>> >>> 1) Be careful on the machines that you use Subversion from. Treat it >> like >>> a machine where you access your bank account from. If you are visiting >>> risky sites or downloading and installing software from dubious places, >>> then you are putting your Apache account at risk. >>> >>> 2) Use a high-complexity Apache passcode, one not used by you on any >> other >>> service. >>> >>> 3) Change your passcode periodically, say every 90 days. >>> >> >> 4) On laptops be sure to set a strong login password, but also where >>> available also a separate harddrive password. These should also be >> strong >>> passwords, not reused, and should be periodically changed. >>> >>> For those who are building binaries for distribution, the above guidance >> is >>> even more critical. >>> >>> Of course, we also protect the code through our CTR process. All active >>> coders should be subscribed to the commits list and should be reviewing >> the >>> changes that are made there. Trust the code, not the person. Remember, >> if >>> we ever are attacked then it will be through someone's compromised >>> account. So if you see an odd check-in, say, from Juergen, don't just >>> accept it saying "Juergen knows what he is doing". If it is odd, then it >>> should be challenged. >>> >>> All of the above should already be going on today. But I'd like to >> propose >>> one change to our current process that will, I think, greatly increase >>> security. This would be to restrict SVN authorization for the code to >> only >>> the subset of committers who are actively coding. We should give this >>> authorization freely to committers who request it. But today we have 123 >>> committers, some of whom have never used Subversion, and some (like me) >> who >>> edit /site and /ooo-site but never touch the code. So we probably have >> 90 >>> or more accounts that don't need access to the source code tree. Since >>> such us
Re: Proposal: Improve security by limiting committer access in SVN
On Wed, Apr 3, 2013 at 9:06 AM, janI wrote: > On 3 April 2013 14:39, Rob Weir wrote: > > > We're starting to take a deeper look at what is required to integrate > code > > signing into the OpenOffice build and release process. As you probably > know > > operating systems, especially Windows and MacOS, are now checking for > > digital signatures and by default prevent users from installing programs > > that are not signed. We see similar checks being integrated into > > anti-virus scanners and even web browsers now. > > > > One of the things that has come out in discussions is how large a target > > OpenOffice is, to hackers. We're on track to have 50 million downloads > in > > our first year. If someone is able to get a virus or a trojan into our > > code, they have the ability to cause a huge amount of damage. And if we > > are also signing our code, then this damage can propagate even faster, > > since the OS's "let down their guard" somewhat when dealing with signed > > code. (Signed code == trust). > > > > Of course, none of this has ever happened with OpenOffice, but with the > > stature and reach we have, it is reasonable to believe that we could be a > > target of opportunity for someone wishing to cause trouble. We should > > always keep this in mind and make sure that we are taking reasonable > > precautions to prevent this from happening. > > > > One vulnerability, in theory, is that we have over 100 committers (123 to > > be exact) who have permission to modify the source code in Subversion. > > Each account is protected by a self-selected passcode. It is not clear > to > > me that we even have requirements on password complexity or expiration > > policies. In any case, the weakness of this approach is not necessarily > > what you might think -- brute force attack on the password. If someone > > wants to initiate a "spear phishing" attack against a committer, it would > > be something like: > > > > 1) Standard phishing: a spoofed note from Apache Infra, with some > invented > > story that asks you to change your password but first enter your old one > > for confirmation. It leads you to a fake, non-Apache website. > > > > 2) If you use the same passcode on multiple web services and one of them > is > > compromised, say by retrieving the passcode hashes, then it is easy to do > > offline dictionary attacks (rainbow tables, etc.) and figure out your > > Apache password. > > > > 3) If you lose control of your laptop, at a conference, bar, hotel, > > whatever, even temporarily, someone can gain access to your Subversion > > account, via applications that cache credentials, like TortoiseSVN. > > > > 4) Similar to #3, but by taking control of your laptop via remote means, > > i.e., via a virus loaded on to your machine via another vulnerability. > > > > None of these things have happened to us yet, but all of these things are > > possible. > > > > So how do we reduce this risk? There are a few things we do or should be > > doing already. > > > > 1) Be careful on the machines that you use Subversion from. Treat it > like > > a machine where you access your bank account from. If you are visiting > > risky sites or downloading and installing software from dubious places, > > then you are putting your Apache account at risk. > > > > 2) Use a high-complexity Apache passcode, one not used by you on any > other > > service. > > > > 3) Change your passcode periodically, say every 90 days. > > > > 4) On laptops be sure to set a strong login password, but also where > > available also a separate harddrive password. These should also be > strong > > passwords, not reused, and should be periodically changed. > > > > For those who are building binaries for distribution, the above guidance > is > > even more critical. > > > > Of course, we also protect the code through our CTR process. All active > > coders should be subscribed to the commits list and should be reviewing > the > > changes that are made there. Trust the code, not the person. Remember, > if > > we ever are attacked then it will be through someone's compromised > > account. So if you see an odd check-in, say, from Juergen, don't just > > accept it saying "Juergen knows what he is doing". If it is odd, then it > > should be challenged. > > > > All of the above should already be going on today. But I'd like to > propose > > one change to our current process that will, I think, greatly increase > > security. This would be to restrict SVN authorization for the code to > only > > the subset of committers who are actively coding. We should give this > > authorization freely to committers who request it. But today we have 123 > > committers, some of whom have never used Subversion, and some (like me) > who > > edit /site and /ooo-site but never touch the code. So we probably have > 90 > > or more accounts that don't need access to the source code tree. Since > > such used accounts are unlikely to be following the best practices >
Re: Proposal: Improve security by limiting committer access in SVN
On 3 April 2013 14:39, Rob Weir wrote: > We're starting to take a deeper look at what is required to integrate code > signing into the OpenOffice build and release process. As you probably know > operating systems, especially Windows and MacOS, are now checking for > digital signatures and by default prevent users from installing programs > that are not signed. We see similar checks being integrated into > anti-virus scanners and even web browsers now. > > One of the things that has come out in discussions is how large a target > OpenOffice is, to hackers. We're on track to have 50 million downloads in > our first year. If someone is able to get a virus or a trojan into our > code, they have the ability to cause a huge amount of damage. And if we > are also signing our code, then this damage can propagate even faster, > since the OS's "let down their guard" somewhat when dealing with signed > code. (Signed code == trust). > > Of course, none of this has ever happened with OpenOffice, but with the > stature and reach we have, it is reasonable to believe that we could be a > target of opportunity for someone wishing to cause trouble. We should > always keep this in mind and make sure that we are taking reasonable > precautions to prevent this from happening. > > One vulnerability, in theory, is that we have over 100 committers (123 to > be exact) who have permission to modify the source code in Subversion. > Each account is protected by a self-selected passcode. It is not clear to > me that we even have requirements on password complexity or expiration > policies. In any case, the weakness of this approach is not necessarily > what you might think -- brute force attack on the password. If someone > wants to initiate a "spear phishing" attack against a committer, it would > be something like: > > 1) Standard phishing: a spoofed note from Apache Infra, with some invented > story that asks you to change your password but first enter your old one > for confirmation. It leads you to a fake, non-Apache website. > > 2) If you use the same passcode on multiple web services and one of them is > compromised, say by retrieving the passcode hashes, then it is easy to do > offline dictionary attacks (rainbow tables, etc.) and figure out your > Apache password. > > 3) If you lose control of your laptop, at a conference, bar, hotel, > whatever, even temporarily, someone can gain access to your Subversion > account, via applications that cache credentials, like TortoiseSVN. > > 4) Similar to #3, but by taking control of your laptop via remote means, > i.e., via a virus loaded on to your machine via another vulnerability. > None of these things have happened to us yet, but all of these things are > possible. > > So how do we reduce this risk? There are a few things we do or should be > doing already. > > 1) Be careful on the machines that you use Subversion from. Treat it like > a machine where you access your bank account from. If you are visiting > risky sites or downloading and installing software from dubious places, > then you are putting your Apache account at risk. > > 2) Use a high-complexity Apache passcode, one not used by you on any other > service. > > 3) Change your passcode periodically, say every 90 days. > 4) On laptops be sure to set a strong login password, but also where > available also a separate harddrive password. These should also be strong > passwords, not reused, and should be periodically changed. > > For those who are building binaries for distribution, the above guidance is > even more critical. > > Of course, we also protect the code through our CTR process. All active > coders should be subscribed to the commits list and should be reviewing the > changes that are made there. Trust the code, not the person. Remember, if > we ever are attacked then it will be through someone's compromised > account. So if you see an odd check-in, say, from Juergen, don't just > accept it saying "Juergen knows what he is doing". If it is odd, then it > should be challenged. > > All of the above should already be going on today. But I'd like to propose > one change to our current process that will, I think, greatly increase > security. This would be to restrict SVN authorization for the code to only > the subset of committers who are actively coding. We should give this > authorization freely to committers who request it. But today we have 123 > committers, some of whom have never used Subversion, and some (like me) who > edit /site and /ooo-site but never touch the code. So we probably have 90 > or more accounts that don't need access to the source code tree. Since > such used accounts are unlikely to be following the best practices outlined > above (changing passwords periodically, etc.) then they are even more > risky. We lose nothing by removing authorization for those users, in order > to reduce the risk profile. Of course, on request we can easily restore > access. But the ide
Re: Proposal: Improve security by limiting committer access in SVN
On Wed, Apr 3, 2013 at 8:57 AM, Alexandro Colorado wrote: > I think restricting this would be a horrible idea, since we still have > a shortage of developers. Limiting it by permissions and creating a > red tape would be even more problematic. I think the key here is about > the aproved releases. I don't really use windows, so I am not very > familiar with the topic and whole process at hand when installing and > testing. However I would focus more on the final QA than the initial > access/commit to the code. > > I'm talking about restricting access for non-programmers, those who have permissions currently, but who have never ever contributed a single line of code. No actual programmer would be restricted. For the kinds of risks I'm describing QA would accomplish nothing. Any hacker worth the name would delay activation of an attack until after millions of copies had already been installed, and then they would activate the code remotely. -Rob > On 4/3/13, Rob Weir wrote: > > We're starting to take a deeper look at what is required to integrate > code > > signing into the OpenOffice build and release process. As you probably > know > > operating systems, especially Windows and MacOS, are now checking for > > digital signatures and by default prevent users from installing programs > > that are not signed. We see similar checks being integrated into > > anti-virus scanners and even web browsers now. > > > > One of the things that has come out in discussions is how large a target > > OpenOffice is, to hackers. We're on track to have 50 million downloads > in > > our first year. If someone is able to get a virus or a trojan into our > > code, they have the ability to cause a huge amount of damage. And if we > > are also signing our code, then this damage can propagate even faster, > > since the OS's "let down their guard" somewhat when dealing with signed > > code. (Signed code == trust). > > > > Of course, none of this has ever happened with OpenOffice, but with the > > stature and reach we have, it is reasonable to believe that we could be a > > target of opportunity for someone wishing to cause trouble. We should > > always keep this in mind and make sure that we are taking reasonable > > precautions to prevent this from happening. > > > > One vulnerability, in theory, is that we have over 100 committers (123 to > > be exact) who have permission to modify the source code in Subversion. > > Each account is protected by a self-selected passcode. It is not clear > to > > me that we even have requirements on password complexity or expiration > > policies. In any case, the weakness of this approach is not necessarily > > what you might think -- brute force attack on the password. If someone > > wants to initiate a "spear phishing" attack against a committer, it would > > be something like: > > > > 1) Standard phishing: a spoofed note from Apache Infra, with some > invented > > story that asks you to change your password but first enter your old one > > for confirmation. It leads you to a fake, non-Apache website. > > > > 2) If you use the same passcode on multiple web services and one of them > is > > compromised, say by retrieving the passcode hashes, then it is easy to do > > offline dictionary attacks (rainbow tables, etc.) and figure out your > > Apache password. > > > > 3) If you lose control of your laptop, at a conference, bar, hotel, > > whatever, even temporarily, someone can gain access to your Subversion > > account, via applications that cache credentials, like TortoiseSVN. > > > > 4) Similar to #3, but by taking control of your laptop via remote means, > > i.e., via a virus loaded on to your machine via another vulnerability. > > > > None of these things have happened to us yet, but all of these things are > > possible. > > > > So how do we reduce this risk? There are a few things we do or should be > > doing already. > > > > 1) Be careful on the machines that you use Subversion from. Treat it > like > > a machine where you access your bank account from. If you are visiting > > risky sites or downloading and installing software from dubious places, > > then you are putting your Apache account at risk. > > > > 2) Use a high-complexity Apache passcode, one not used by you on any > other > > service. > > > > 3) Change your passcode periodically, say every 90 days. > > > > 4) On laptops be sure to set a strong login password, but also where > > available also a separate harddrive password. These should also be > strong > > passwords, not reused, and should be periodically changed. > > > > For those who are building binaries for distribution, the above guidance > is > > even more critical. > > > > Of course, we also protect the code through our CTR process. All active > > coders should be subscribed to the commits list and should be reviewing > the > > changes that are made there. Trust the code, not the person. Remember, > if > > we ever are attacked then it will be through so
Re: Proposal: Improve security by limiting committer access in SVN
I think restricting this would be a horrible idea, since we still have a shortage of developers. Limiting it by permissions and creating a red tape would be even more problematic. I think the key here is about the aproved releases. I don't really use windows, so I am not very familiar with the topic and whole process at hand when installing and testing. However I would focus more on the final QA than the initial access/commit to the code. On 4/3/13, Rob Weir wrote: > We're starting to take a deeper look at what is required to integrate code > signing into the OpenOffice build and release process. As you probably know > operating systems, especially Windows and MacOS, are now checking for > digital signatures and by default prevent users from installing programs > that are not signed. We see similar checks being integrated into > anti-virus scanners and even web browsers now. > > One of the things that has come out in discussions is how large a target > OpenOffice is, to hackers. We're on track to have 50 million downloads in > our first year. If someone is able to get a virus or a trojan into our > code, they have the ability to cause a huge amount of damage. And if we > are also signing our code, then this damage can propagate even faster, > since the OS's "let down their guard" somewhat when dealing with signed > code. (Signed code == trust). > > Of course, none of this has ever happened with OpenOffice, but with the > stature and reach we have, it is reasonable to believe that we could be a > target of opportunity for someone wishing to cause trouble. We should > always keep this in mind and make sure that we are taking reasonable > precautions to prevent this from happening. > > One vulnerability, in theory, is that we have over 100 committers (123 to > be exact) who have permission to modify the source code in Subversion. > Each account is protected by a self-selected passcode. It is not clear to > me that we even have requirements on password complexity or expiration > policies. In any case, the weakness of this approach is not necessarily > what you might think -- brute force attack on the password. If someone > wants to initiate a "spear phishing" attack against a committer, it would > be something like: > > 1) Standard phishing: a spoofed note from Apache Infra, with some invented > story that asks you to change your password but first enter your old one > for confirmation. It leads you to a fake, non-Apache website. > > 2) If you use the same passcode on multiple web services and one of them is > compromised, say by retrieving the passcode hashes, then it is easy to do > offline dictionary attacks (rainbow tables, etc.) and figure out your > Apache password. > > 3) If you lose control of your laptop, at a conference, bar, hotel, > whatever, even temporarily, someone can gain access to your Subversion > account, via applications that cache credentials, like TortoiseSVN. > > 4) Similar to #3, but by taking control of your laptop via remote means, > i.e., via a virus loaded on to your machine via another vulnerability. > > None of these things have happened to us yet, but all of these things are > possible. > > So how do we reduce this risk? There are a few things we do or should be > doing already. > > 1) Be careful on the machines that you use Subversion from. Treat it like > a machine where you access your bank account from. If you are visiting > risky sites or downloading and installing software from dubious places, > then you are putting your Apache account at risk. > > 2) Use a high-complexity Apache passcode, one not used by you on any other > service. > > 3) Change your passcode periodically, say every 90 days. > > 4) On laptops be sure to set a strong login password, but also where > available also a separate harddrive password. These should also be strong > passwords, not reused, and should be periodically changed. > > For those who are building binaries for distribution, the above guidance is > even more critical. > > Of course, we also protect the code through our CTR process. All active > coders should be subscribed to the commits list and should be reviewing the > changes that are made there. Trust the code, not the person. Remember, if > we ever are attacked then it will be through someone's compromised > account. So if you see an odd check-in, say, from Juergen, don't just > accept it saying "Juergen knows what he is doing". If it is odd, then it > should be challenged. > > All of the above should already be going on today. But I'd like to propose > one change to our current process that will, I think, greatly increase > security. This would be to restrict SVN authorization for the code to only > the subset of committers who are actively coding. We should give this > authorization freely to committers who request it. But today we have 123 > committers, some of whom have never used Subversion, and some (like me) who > edit /site and /ooo-site but never touch
