Re: [PROPOSAL] Move httpd to the subversion repository
Justin Erenkrantz wrote: --On Tuesday, March 16, 2004 8:19 PM + Ben Laurie [EMAIL PROTECTED] wrote: c) You appear to be assuming daily snapshots maintained forever in your story - if so, how do you deal with network problems and the like? How can you tell a commit that didn't make it to the secure server because of a network problem from one that the attacker injected? I think you're misunderstanding here. After every commit, an incremental backup containing that revision is generated. It'd then be copied over to a 'backup' site. There is no reason to re-dump the repository every day as that'd be just too big. If a commit is 'missed' due to an attack or whatnot, it'd be obvious because that particular revision number will not appear. This is not like CVS where the prior history can be directly modified by tweaking the RCS files. For CVS, there is no concept of incrementality - the RCS files just aren't stable enough. I'd suggest seeing minotaur:/x1/svn/hot-backups for an idea as to what we're doing right now. (We have yet to digitally sign anything though.) I'm guessing I need subversion to check that out, right? (This is a good example of what Dirk is talking about, and I'm not even on an old system - I'd install subversion from ports, except my ports are out-of-date, and I leave for a trip tomorrow, so I don't want to update them and break my machine just before I go). In the solution you've rather vaguely outlined, after a server compromise I find myself checking a bunch of commits signed by the compromised server and then making some other vague assumptions I'm not sure I understand to convince myself that they were pre-compromise signatures. I don't feel like my security has been improved. Possibly a clearer explanation is all that is required, or maybe a rethink. I can't tell at this stage. I think you're missing that the incrementality causes us to believe the pre-compromise signatures (as the backup can be done in such a way not to modify already existing files). Remember, everything is uniquely ordered in Subversion. If you also don't trust a hot backup, you can also burn those dumps to a 'permanent' media like a DVD-R to later verify it. But, once revision 1 is committed, that's revision 1 forever - it's immutable once it's in the repository. If it *has* changed, that's evidence of a compromise. -- justin OK, I think I can believe this can work, but it needs to be carefully documented and implemented so we don't find that when it comes to it we've missed some small detail (for example, you don't want the remote backups to have the same date as the local ones - you want them to have the date they were transferred). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PROPOSAL] Move httpd to the subversion repository
On Wed, 2004-03-17 at 11:39, Ben Laurie wrote: Justin Erenkrantz wrote: --On Tuesday, March 16, 2004 8:19 PM + Ben Laurie [EMAIL PROTECTED] wrote: c) You appear to be assuming daily snapshots maintained forever in your story - if so, how do you deal with network problems and the like? How can you tell a commit that didn't make it to the secure server because of a network problem from one that the attacker injected? I think you're misunderstanding here. After every commit, an incremental backup containing that revision is generated. It'd then be copied over to a 'backup' site. There is no reason to re-dump the repository every day as that'd be just too big. If a commit is 'missed' due to an attack or whatnot, it'd be obvious because that particular revision number will not appear. This is not like CVS where the prior history can be directly modified by tweaking the RCS files. For CVS, there is no concept of incrementality - the RCS files just aren't stable enough. I'd suggest seeing minotaur:/x1/svn/hot-backups for an idea as to what we're doing right now. (We have yet to digitally sign anything though.) I'm guessing I need subversion to check that out, right? No, you just need to log in and cd to /x1/svn/hot-backups. (This is a good example of what Dirk is talking about, and I'm not even on an old system - I'd install subversion from ports, except my ports are out-of-date, and I leave for a trip tomorrow, so I don't want to update them and break my machine just before I go). If we can reach concensus that we want to move, I'm sure we can work something out so we can provide everyone help to get to a working subversion installation. I'll happily put some of my time in this. Sander
Re: [PROPOSAL] Move httpd to the subversion repository
On March 16, 2004 09:52 pm, Kean Johnston wrote: Do we need to buy a license? No but if you send us money we'll donate it to the End Sarcasm Campaign. Is that a SCO project or some godless communist movement? I ask only information... Then some smart-ass thought it would be funny to throw in a jibe to me about licensing (some people have no self control). Dude lighten up, I'm waging no license jihad here. I thought my little joke pretty mild and subdued given the nature of the (albeit accidental) posting, ie. proclamations about packaging and redistribution of open source tools coming from the sco.com domain. Anyway, irony is better than flaming, surely? (I'll avoid comments about it being a free world, as the courts have yet to decide that one.) Cheers, Geoff PS: Smile, boys will be Boies. -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/
Re: [PROPOSAL] Move httpd to the subversion repository
On Tue, Mar 16, 2004 at 06:16:07PM -0800, Kean Johnston wrote: By the way, for SCO OpenServer, I have a package called 'GWXLIBS' - it My appologies ... I meant this to be a private reply but did not check the address. For everyone who is not [EMAIL PROTECTED] please ignore. Don't apologize. It is useful information for other people, too. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] Move httpd to the subversion repository
Justin Erenkrantz wrote: --On Monday, March 15, 2004 10:52 AM + Ben Laurie [EMAIL PROTECTED] wrote: It is? How? Unless the committer signs (which ISTR was rejected as an option when I suggested it, so I'm assuming that doesn't happen), then they must be signed by the server - a successful attacker can therefore sign his modifications, too. Or am I missing something? (I don't use subversion yet, so forgive me if the answer is obvious). We're talking about ensuring the integrity of the repository here, not whether malicious people can commit. I know. With the repository and its dumps, everything is date-ordered. The revisions are sequential and the dumps only contain the changes for that particular revision. Once the changes are made, they can be signed by the server and rsync'd via a third-party 'secure' server (*only* adding the new revisions). In the event of an intrusion, we can use those read-only dumps to compare against our 'live' repository. Also, if a malicious set of commits occur, we can also *quickly* remove those as everything is identified by a changeset/revision number across the repository (again, not possible with CVS as it has per-file revnums). I don't see how this defends against a malicious user that has owned the server for long enough for his changes to have been rsynced to the secure server? It is news to me that the board have expressed this view. No, it's not official, but every time we have an intrusion, we have no useful mechanism of auditing the integrity of our CVS repository as people can modify the RCS files directly and that *has* been a concern brought up by the board on several occasions. With Subversion, it is possible to easily verify the integrity of the repository against backups. -- justin I have yet to be convinced of this. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PROPOSAL] Move httpd to the subversion repository
--On Tuesday, March 16, 2004 5:27 PM + Ben Laurie [EMAIL PROTECTED] wrote: I don't see how this defends against a malicious user that has owned the server for long enough for his changes to have been rsynced to the secure server? Because it'd be read-only? That is, the changes won't be on the 'secure' server (i.e. they can't modify things *before* the box was compromised). Once it's compromised, sure, the malicious user can do 'bad' things, but, that's true with any system. Digital signatures by a committer don't add any protection here, either. Those compromised committers can do bad commits, too. However, once the malicious commits are identified, they can be easily rolled back and/or removed from the repository... Do you have a suggestion here? I have yet to be convinced of this. I'm just not sure what you're looking for here. CVS offers *nothing* in the way of integrity checking. Subversion at least gets us moving in the right direction. I think you're underestimating the issues we have auditing our CVS repository. *shrug* -- justin
Re: [PROPOSAL] Move httpd to the subversion repository
At 11:27 AM 3/16/2004, Ben Laurie wrote: Justin Erenkrantz wrote: --On Monday, March 15, 2004 10:52 AM + Ben Laurie [EMAIL PROTECTED] wrote: It is? How? Unless the committer signs (which ISTR was rejected as an option when I suggested it, so I'm assuming that doesn't happen), then they must be signed by the server - a successful attacker can therefore sign his modifications, too. Or am I missing something? (I don't use subversion yet, so forgive me if the answer is obvious). We're talking about ensuring the integrity of the repository here, not whether malicious people can commit. I know. Uhm I beg to differ - I care about both issues :) With the repository and its dumps, everything is date-ordered. The revisions are sequential and the dumps only contain the changes for that particular revision. Once the changes are made, they can be signed by the server and rsync'd via a third-party 'secure' server (*only* adding the new revisions). In the event of an intrusion, we can use those read-only dumps to compare against our 'live' repository. Also, if a malicious set of commits occur, we can also *quickly* remove those as everything is identified by a changeset/revision number across the repository (again, not possible with CVS as it has per-file revnums). I don't see how this defends against a malicious user that has owned the server for long enough for his changes to have been rsynced to the secure server? That is always a risk - which is why the more offsite copies backed regularly, the better. If there is a barrier to rsync'ing the database, or rsyncing the commit history and auto-layering the main repository history into a mirror repository, I'm very adverse to the proposal. If anyone has a cool bookmark on mirroring svn repositories, please share. It is news to me that the board have expressed this view. No, it's not official, but every time we have an intrusion, we have no useful mechanism of auditing the integrity of our CVS repository as people can modify the RCS files directly and that *has* been a concern brought up by the board on several occasions. With Subversion, it is possible to easily verify the integrity of the repository against backups. -- justin I have yet to be convinced of this. Same here diff -u3 backup/source.c,v live/source.c,v you mean to say there is an equally trivial way to compare two repositories to do post-mortem with svn? If so please share! Bill
Re: [PROPOSAL] Move httpd to the subversion repository
Justin Erenkrantz wrote: --On Tuesday, March 16, 2004 5:27 PM + Ben Laurie [EMAIL PROTECTED] wrote: I don't see how this defends against a malicious user that has owned the server for long enough for his changes to have been rsynced to the secure server? Because it'd be read-only? That is, the changes won't be on the 'secure' server (i.e. they can't modify things *before* the box was compromised). Once it's compromised, sure, the malicious user can do 'bad' things, but, that's true with any system. Digital signatures by a committer don't add any protection here, either. Those compromised committers can do bad commits, too. However, once the malicious commits are identified, they can be easily rolled back and/or removed from the repository... Hang on. I'm not suggesting that I have some kind of magic bullet that will fix this problem, but there are some fundamental problems with what you say here: a) A compromised server _cannot_ fake user signatures b) Server signatures do _not_ help with compromised users c) You appear to be assuming daily snapshots maintained forever in your story - if so, how do you deal with network problems and the like? How can you tell a commit that didn't make it to the secure server because of a network problem from one that the attacker injected? Do you have a suggestion here? I have yet to be convinced of this. I'm just not sure what you're looking for here. CVS offers *nothing* in the way of integrity checking. Subversion at least gets us moving in the right direction. I think you're underestimating the issues we have auditing our CVS repository. *shrug* No, I'm saying that if you want to move in the right direction, applying PKI magic pixie dust isn't the way to do it - you have to define your threat model and construct a plausible defence against it. In the solution you've rather vaguely outlined, after a server compromise I find myself checking a bunch of commits signed by the compromised server and then making some other vague assumptions I'm not sure I understand to convince myself that they were pre-compromise signatures. I don't feel like my security has been improved. Possibly a clearer explanation is all that is required, or maybe a rethink. I can't tell at this stage. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PROPOSAL] Move httpd to the subversion repository
William A. Rowe, Jr. wrote: At 11:27 AM 3/16/2004, Ben Laurie wrote: Justin Erenkrantz wrote: --On Monday, March 15, 2004 10:52 AM + Ben Laurie [EMAIL PROTECTED] wrote: It is? How? Unless the committer signs (which ISTR was rejected as an option when I suggested it, so I'm assuming that doesn't happen), then they must be signed by the server - a successful attacker can therefore sign his modifications, too. Or am I missing something? (I don't use subversion yet, so forgive me if the answer is obvious). We're talking about ensuring the integrity of the repository here, not whether malicious people can commit. I know. Uhm I beg to differ - I care about both issues :) I didn't say I didn't care! I said I knew what we were talking about. I also care about malicious users. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PROPOSAL] Move httpd to the subversion repository
On Tue, 2004-03-16 at 21:20, Ben Laurie wrote: William A. Rowe, Jr. wrote: At 11:27 AM 3/16/2004, Ben Laurie wrote: Justin Erenkrantz wrote: --On Monday, March 15, 2004 10:52 AM + Ben Laurie [EMAIL PROTECTED] wrote: It is? How? Unless the committer signs (which ISTR was rejected as an option when I suggested it, so I'm assuming that doesn't happen), then they must be signed by the server - a successful attacker can therefore sign his modifications, too. Or am I missing something? (I don't use subversion yet, so forgive me if the answer is obvious). We're talking about ensuring the integrity of the repository here, not whether malicious people can commit. I know. Uhm I beg to differ - I care about both issues :) I didn't say I didn't care! I said I knew what we were talking about. I also care about malicious users. Can we please move this discussion to [EMAIL PROTECTED] A lot of the points discussed aren't about technical problems of httpd moving over, but overall topics concerning our setup. Most of the concerns that have come up are things that people not directly involved with Infrastructure are likely never having to deal with. PKI, integrated with/on top of, Subversion, can be a joint effort between the Infrastructure and Security Team. If a good, practical solution can be put together we can start looking how to roll that out. Sander
Re: [PROPOSAL] Move httpd to the subversion repository
On Mon, Mar 15, 2004 at 09:15:26PM +0100, Sander Striker wrote: On Mon, 2004-03-15 at 20:39, Ben Collins-Sussman wrote: On Mon, 2004-03-15 at 12:02, Joshua Slive wrote: Disadvantages of moving to subversion: - Not as portable (?) (Subversion clients/servers run anywhere APR does. I think that's actually more portable than CVS, since I don't believe CVS pserver runs on win32 at all.) neon has been the most limiting dependency for a client, I am told. Mmm, such juicy tempting FUD. Your anonymous informant should report portability bugs to [EMAIL PROTECTED], rather than spreading gossip, since I see only a few issues. Amusingly, last time someone touted the neon should use APR flag, it was for the getaddrinfo issue on HP-UX which it turns out APR doesn't actually have a fix for still. APR, n.: not a portability panacea
Re: [PROPOSAL] Move httpd to the subversion repository
On Tue, 2004-03-16 at 22:03, Joe Orton wrote: On Mon, Mar 15, 2004 at 09:15:26PM +0100, Sander Striker wrote: neon has been the most limiting dependency for a client, I am told. Mmm, such juicy tempting FUD. Your anonymous informant should report portability bugs to [EMAIL PROTECTED], rather than spreading gossip, since I see only a few issues. Amusingly, last time someone touted the neon should use APR flag, it was for the getaddrinfo issue on HP-UX which it turns out APR doesn't actually have a fix for still. Sorry Joe, I'm sure the anonymous reporter is happy to respond (I'm BCC'ing him) ;) Sander
Re: [PROPOSAL] Move httpd to the subversion repository
On Tue, Mar 16, 2004 at 09:52:49PM +0100, Sander Striker wrote: Can we please move this discussion to [EMAIL PROTECTED] A lot of the points discussed aren't about technical problems of httpd moving over, but overall topics concerning our setup. Most of the concerns that have come up are things that people not directly involved with Infrastructure are likely never having to deal with. This discussion is about the version control needs of the HTTPD Server Project. Please keep the discussion on this list with the users who will be most affected by the proposed change. PKI, integrated with/on top of, Subversion, can be a joint effort between the Infrastructure and Security Team. If a good, practical solution can be put together we can start looking how to roll that out. If having a tamper-resistant code repository is a new requirement of the HTTPD Server Project then we should discuss this in terms of abstract requirements and not assume a particular implementation. Keep in mind that although the infrastructure team may be charged with managing the infrastructure, it shouldn't be pushing projects to use tools that they don't want to use. -aaron
Re: [PROPOSAL] Move httpd to the subversion repository
On Mar 16, 2004, at 10:03 PM, Joe Orton wrote: neon has been the most limiting dependency for a client, I am told. Mmm, such juicy tempting FUD. Your anonymous informant should report portability bugs to [EMAIL PROTECTED], rather than spreading gossip, since Oh come on - migration is not trivial for older systems. We're going from a very flat/simple cross platform config system in apache 1.3 to apache 2.0 with gnu configure, a new version libtool (1.4), and now with the change of cvs to subversion we're now also adding dependencies on xml and berkely 4. Sure, at _SOME_ point these libraries will simply be in the ports/packages or RPM's of the OS, but if you are dealing with OS released around 1998 then things are not quite trivial. For me the hard ones with respect to Neon are all configure related and the usual ones: QNX 4, FreeBSD 3.1 with IPv6 patch and SCO openserver 5.0.x... but we are working through them slowly (esp. as some of the older systems have 5-10Mbyte disk partitions assigned to them :-) And please - do not pretend that replacing such a fundamental part of your build and release management system is a walk in the park. There is more to software engineering than supporting the coders. Dw
Re: [PROPOSAL] Move httpd to the subversion repository
--On Tuesday, March 16, 2004 8:19 PM + Ben Laurie [EMAIL PROTECTED] wrote: c) You appear to be assuming daily snapshots maintained forever in your story - if so, how do you deal with network problems and the like? How can you tell a commit that didn't make it to the secure server because of a network problem from one that the attacker injected? I think you're misunderstanding here. After every commit, an incremental backup containing that revision is generated. It'd then be copied over to a 'backup' site. There is no reason to re-dump the repository every day as that'd be just too big. If a commit is 'missed' due to an attack or whatnot, it'd be obvious because that particular revision number will not appear. This is not like CVS where the prior history can be directly modified by tweaking the RCS files. For CVS, there is no concept of incrementality - the RCS files just aren't stable enough. I'd suggest seeing minotaur:/x1/svn/hot-backups for an idea as to what we're doing right now. (We have yet to digitally sign anything though.) In the solution you've rather vaguely outlined, after a server compromise I find myself checking a bunch of commits signed by the compromised server and then making some other vague assumptions I'm not sure I understand to convince myself that they were pre-compromise signatures. I don't feel like my security has been improved. Possibly a clearer explanation is all that is required, or maybe a rethink. I can't tell at this stage. I think you're missing that the incrementality causes us to believe the pre-compromise signatures (as the backup can be done in such a way not to modify already existing files). Remember, everything is uniquely ordered in Subversion. If you also don't trust a hot backup, you can also burn those dumps to a 'permanent' media like a DVD-R to later verify it. But, once revision 1 is committed, that's revision 1 forever - it's immutable once it's in the repository. If it *has* changed, that's evidence of a compromise. -- justin
Re: [PROPOSAL] Move httpd to the subversion repository
On Tue, 2004-03-16 at 22:19, Aaron Bannert wrote: On Tue, Mar 16, 2004 at 09:52:49PM +0100, Sander Striker wrote: Can we please move this discussion to [EMAIL PROTECTED] A lot of the points discussed aren't about technical problems of httpd moving over, but overall topics concerning our setup. Most of the concerns that have come up are things that people not directly involved with Infrastructure are likely never having to deal with. This discussion is about the version control needs of the HTTPD Server Project. Let me be more specific: can we move the part of the discussion I replied to? AFAICT it isn't specific to HTTP Server at all. Also, how backups are done and the like shouldn't really be of concern. I mean, in reality, how many people are aware of how that happens now? Let's discuss the version control needs of the HTTP Server project :) Please keep the discussion on this list with the users who will be most affected by the proposed change. The proposed change, the subject of the thread, is moving to subversion, nothing more nothing less. Tamper proofness, etc, are all things that can be discussed later. And, IMO, are things that are not limited to HTTP Server alone. PKI, integrated with/on top of, Subversion, can be a joint effort between the Infrastructure and Security Team. If a good, practical solution can be put together we can start looking how to roll that out. If having a tamper-resistant code repository is a new requirement of the HTTPD Server Project It isn't. Some of us are simply talking about what could be done with Subversion. I'm trying to get us off the side track in this thread, that's all. then we should discuss this in terms of abstract requirements and not assume a particular implementation. Keep in mind that although the infrastructure team may be charged with managing the infrastructure, it shouldn't be pushing projects to use tools that they don't want to use. Is there any reason you are mentioning this explicitly? Sander
Re: [PROPOSAL] Move httpd to the subversion repository
On Tue, Mar 16, 2004 at 10:41:12PM +0100, Dirk-Willem van Gulik wrote: On Mar 16, 2004, at 10:03 PM, Joe Orton wrote: neon has been the most limiting dependency for a client, I am told. Mmm, such juicy tempting FUD. Your anonymous informant should report portability bugs to [EMAIL PROTECTED], rather than spreading gossip, since Oh come on - migration is not trivial for older systems. We're going from a very flat/simple cross platform config system in apache 1.3 to apache 2.0 with gnu configure, a new version libtool (1.4), and now with the change of cvs to subversion we're now also adding dependencies on xml and berkely 4. It's undoubtedly true that CVS is more widely ported than Subversion and its dependencies (at least to Unixes), I wouldn't claim anything else. Merely that I've seen APR's attempts to detect pthreads, shmem etc screw up on old and new Unixes over the last year far far more then the relatively simple neon configure script. But if you're sitting on a bunch of neon bug reports, who am I to comment... To get back on-topic: +1 on moving httpd to Subversion from CVS; it *greatly* improves development work to be able to svn diff and svn st without waiting for packets to go back and forth to California. Regards, joe
Re: [PROPOSAL] Move httpd to the subversion repository
On Mon, 15 Mar 2004 13:39:48 -0600, Ben Collins-Sussman wrote: On Mon, 2004-03-15 at 12:02, Joshua Slive wrote: Disadvantages of moving to subversion: - Not as portable (?) (Subversion clients/servers run anywhere APR does. I think that's actually more portable than CVS, since I don't believe CVS pserver runs on win32 at all.) Well, I know subversion doesn't compile out of the box on OS/2 (I've tried) so I'll probably have to port it myself if we do make it a requirement for accessing httpd. Also, being on a dialup link I currently rsync the cvs repository to a local machine do all my checkout/update/diff/log etc operations from there only commit across the link. Can I do that with subversion or will every operation have to go half way around the world? -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
Re: [PROPOSAL] Move httpd to the subversion repository
--On Wednesday, March 17, 2004 9:47 AM +1000 Brian Havard [EMAIL PROTECTED] wrote: Also, being on a dialup link I currently rsync the cvs repository to a local machine do all my checkout/update/diff/log etc operations from there only commit across the link. Can I do that with subversion or will every operation have to go half way around the world? Subversion does support off-line 'diff' operations (usually the operation most people do off-line). log/update/commit still require a network connection. However, Subversion also provides much more efficient network utilization than CVS. I know that was a prime reason why Xerces-P moved over to Subversion from CVS as one of the main contributors was behind a dial-up and couldn't work with CVS but could use Subversion. -- justin
Re: [PROPOSAL] Move httpd to the subversion repository
are all configure related and the usual ones: QNX 4, FreeBSD 3.1 with IPv6 patch and SCO openserver 5.0.x... but we are working through them By the way, for SCO OpenServer, I have a package called 'GWXLIBS' - it stands for Graphics, Web and X11 Libraries. It ships standard in SCO OpenServer 5.0.7, and is available as an add-on for all releases from 5.0.4 onwards. You can get the latest from ftp://ftp.sco.com/pub/openserver5/opensrc It contains just about every library you're likely to care about, except for NEON and APR (sorry) as they're just not 'final' enough for me to put into GWXLIBS, although when they are, they will be. But it does contain libxml2, expat, xslt, Berkely DB and a plethora of others. They are all highly integrated with all their inter-dependencies well taken care of. I wish that Linux / FreeBSD / Solaris / HP-UX would adopt the package :) Its one-stop shopping for most of the useful open source libraries. Please let me know what you think, as well as if there are any libraries you'd like added to it. Kean
Re: [PROPOSAL] Move httpd to the subversion repository
By the way, for SCO OpenServer, I have a package called 'GWXLIBS' - it My appologies ... I meant this to be a private reply but did not check the address. For everyone who is not [EMAIL PROTECTED] please ignore. Kean
Re: [PROPOSAL] Move httpd to the subversion repository
On March 16, 2004 09:10 pm, Kean Johnston wrote: You can get the latest from ftp://ftp.sco.com/pub/openserver5/opensrc Its one-stop shopping for most of the useful open source libraries. Do we need to buy a license? Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/
Re: [PROPOSAL] Move httpd to the subversion repository
Do we need to buy a license? No but if you send us money we'll donate it to the End Sarcasm Campaign. Kean
Re: [PROPOSAL] Move httpd to the subversion repository
can someone remind me why we are A: putting stuff up at of all places sco? B: Why are we moveing it? -Kyle www.kylehamilton.net www.kylehamilton.com - Original Message - From: Kean Johnston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 6:52 PM Subject: Re: [PROPOSAL] Move httpd to the subversion repository Do we need to buy a license? No but if you send us money we'll donate it to the End Sarcasm Campaign. Kean
Re: [PROPOSAL] Move httpd to the subversion repository
Kyle Hamilton wrote: can someone remind me why we are A: putting stuff up at of all places sco? You're not. Someone mentioned the lack of availability for some libraries that were a pre-requisite for SVN on some OSes, OpenServer being one of them, and I intended to reply to him privately but the reply-to was set to the list and I didnt check before I pressed 'send'. Then some smart-ass thought it would be funny to throw in a jibe to me about licensing (some people have no self control). Please dont worry. The Apache Software Foundation has nothing to do with SCO, nor the other way around. I happen to work for SCO and port Apache to OpenServer, but thats it. Kean
Re: [PROPOSAL] Move httpd to the subversion repository
hehe you have it comeing buddy *this is a new comp and I only read the lastest messages sorry about any insult carryed over to you* it would be like if microsoft started work on apache some people would have a sort of puzzled look on there faces. - Original Message - From: Kean Johnston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 7:05 PM Subject: Re: [PROPOSAL] Move httpd to the subversion repository Kyle Hamilton wrote: can someone remind me why we are A: putting stuff up at of all places sco? You're not. Someone mentioned the lack of availability for some libraries that were a pre-requisite for SVN on some OSes, OpenServer being one of them, and I intended to reply to him privately but the reply-to was set to the list and I didnt check before I pressed 'send'. Then some smart-ass thought it would be funny to throw in a jibe to me about licensing (some people have no self control). Please dont worry. The Apache Software Foundation has nothing to do with SCO, nor the other way around. I happen to work for SCO and port Apache to OpenServer, but thats it. Kean
Re: [PROPOSAL] Move httpd to the subversion repository
* Ian Holsman [EMAIL PROTECTED] wrote: your going to be forcing people to install some other piece of software. while this might be fine for a lot of people, some won't or can't. Some IDE's don't have SVN support yet, and some people have to deal with sysadmins who think redhat 5.2 is acceptable work environment to develop with. Hmm. And how many people don't have cvs access because they don't get the pserver through their firewall? It looks to me, that your argument isn't really one. IMHO sure ... ;-) nd
Re: [PROPOSAL] Move httpd to the subversion repository
--On Sunday, March 14, 2004 11:18 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: as the GNU, ASF, and SF projects all discovered, full backups by third parties are invaluable. What is the equivalent to rsync, and is it as stable? I think you mean cvsup not rsync. We're currently creating incremental dumps on every commit. Those can be digitally signed and rsync'd off-site. This is far more secure and auditable than any CVS-based solution - and is in fact, one reason why the ASF [EMAIL PROTECTED] and the board want to get off CVS. -- justin
Re: [PROPOSAL] Move httpd to the subversion repository
Justin Erenkrantz wrote: --On Sunday, March 14, 2004 11:18 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: as the GNU, ASF, and SF projects all discovered, full backups by third parties are invaluable. What is the equivalent to rsync, and is it as stable? I think you mean cvsup not rsync. We're currently creating incremental dumps on every commit. Those can be digitally signed and rsync'd off-site. This is far more secure and auditable than any CVS-based solution It is? How? Unless the committer signs (which ISTR was rejected as an option when I suggested it, so I'm assuming that doesn't happen), then they must be signed by the server - a successful attacker can therefore sign his modifications, too. Or am I missing something? (I don't use subversion yet, so forgive me if the answer is obvious). - and is in fact, one reason why the ASF [EMAIL PROTECTED] and the board want to get off CVS. It is news to me that the board have expressed this view. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PROPOSAL] Move httpd to the subversion repository
On Mon, 2004-03-15 at 11:52, Ben Laurie wrote: Justin Erenkrantz wrote: --On Sunday, March 14, 2004 11:18 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: as the GNU, ASF, and SF projects all discovered, full backups by third parties are invaluable. What is the equivalent to rsync, and is it as stable? Caching proxies are also an option FWIW. I think you mean cvsup not rsync. We're currently creating incremental dumps on every commit. Those can be digitally signed and rsync'd off-site. This is far more secure and auditable than any CVS-based solution It is? How? Unless the committer signs (which ISTR was rejected as an option when I suggested it, so I'm assuming that doesn't happen), Can someone remind me why/where that was rejected? then they must be signed by the server - a successful attacker can therefore sign his modifications, too. Or am I missing something? (I don't use subversion yet, so forgive me if the answer is obvious). This is correct. However, signed by the server is still better than not signed at all IMO. The certainty it gives is that any changeset was signed by the server, and that all copies elsewhere therefor must match that signature. And when it comes to our server(s) we can do integrity checks by comparing last known signatures, if any old signature is different, raise the red flag. - and is in fact, one reason why the ASF [EMAIL PROTECTED] and the board want to get off CVS. It is news to me that the board have expressed this view. Several people on the board have expressed this view on a personal level, I don't recall the board having put it on the agenda either, nor do I think that it should. Sander
Re: [PROPOSAL] Move httpd to the subversion repository
your going to be forcing people to install some other piece of software. while this might be fine for a lot of people, some won't or can't. Some IDE's don't have SVN support yet, and some people have to deal with sysadmins who think redhat 5.2 is acceptable work environment to develop with. I'm -0.5 on the issue overall. I can't see what benefit it will give httpd overall at this stage. While I can't cast a vote, I'd like to agree with Mr. Holsman and offer a few comments for those that do vote to think about. I understand that SVN is the bright shiny new toy in the toybox and a lot of people have worked very hard to make it work, and its good. But at the same time, one should be careful of falling into the when you have a new hammer everything looks like a nail trap. Before deciding on something as important as switching your working, well-known-with-warts-and-all revision control system to a new one there are implementation details beyond just the tool interface that are worthy of consideration. For example, in CVS, every file under revision control is backed by a filesystem object. In SVN all files are managed in a (much smaller) set of filesystem objects as managed by Berkeley DB. This implies fundamental limitations not present in the current system. Think large files. Sure LFS is not likely to be an issue on your servers but it might be. Its worth thinging about. Whereas currently you would be restricted to 2Gb per filesystem object in a repository, you are now *potentially* restricted to 2Gb per repository. Maybe BerkeleyDB works around this. Maybe it doesn't. Maybe you just dont care and you make LFS a server requirement. Its worth investigating. It also has considerable backup and restore consequences. In the current system, if a repository file goes bad, you can restore just that file. With the SVN approach of you happend to get a bad sector in the middle of your repository you may have to restore the entire thing. Its not a huge deal I know but still, I'm just making sure you consider the issue, even if just to dismiss it as a non-issue. Are you sure that things like keyword expansion will work as they currently do? They probably will do but again, it should be carefully considered. Are there perhaps custom keywords such as $Apache$ or the like that would need to be rolled into the local version of SVN? If there are custom keywords *can* they be implemented at the repository server level or would such expansion be taken care of at the client level (which would imply that all clients would need to be patched accordingly)? The original proposal stated that full history will be preserved. As I recall from the svn dev list the cvs2svn conversion process has been plagued with difficulties. Are all the issues resolved? If you do make such a move is there an auditing mechanism in place that you can run to guarantee that all history has been preserved? Historical data is of inestimable value and if there is even the slightest chance that some of it could be lost or become less accessible these are risks that need to be understood and clearly agreed upon as being acceptable losses. If there are a specific list of problems that frequently hamper developers that such a move would address, it is worth drawing up that list and debating the relative importance of each problem. Moving just because the tool is available is likely to cause some unforseen headaches down the road. Having said all that, I fully acknowledge that svn is a huge step forwards from cvs in many many ways, but at the end of the day, there is no such thing as a magic bullet, and you will really just be exchanging one set of problems for another. Just my $0.02. Kean
Re: [PROPOSAL] Move httpd to the subversion repository
--On Monday, March 15, 2004 10:52 AM + Ben Laurie [EMAIL PROTECTED] wrote: It is? How? Unless the committer signs (which ISTR was rejected as an option when I suggested it, so I'm assuming that doesn't happen), then they must be signed by the server - a successful attacker can therefore sign his modifications, too. Or am I missing something? (I don't use subversion yet, so forgive me if the answer is obvious). We're talking about ensuring the integrity of the repository here, not whether malicious people can commit. With the repository and its dumps, everything is date-ordered. The revisions are sequential and the dumps only contain the changes for that particular revision. Once the changes are made, they can be signed by the server and rsync'd via a third-party 'secure' server (*only* adding the new revisions). In the event of an intrusion, we can use those read-only dumps to compare against our 'live' repository. Also, if a malicious set of commits occur, we can also *quickly* remove those as everything is identified by a changeset/revision number across the repository (again, not possible with CVS as it has per-file revnums). We also have to address changes to a revision post-mortem (i.e. changing the log message), but that can be dealt with rather easily. It is news to me that the board have expressed this view. No, it's not official, but every time we have an intrusion, we have no useful mechanism of auditing the integrity of our CVS repository as people can modify the RCS files directly and that *has* been a concern brought up by the board on several occasions. With Subversion, it is possible to easily verify the integrity of the repository against backups. -- justin
Re: [PROPOSAL] Move httpd to the subversion repository
--On Monday, March 15, 2004 4:47 AM -0800 Kean Johnston [EMAIL PROTECTED] wrote: people have worked very hard to make it work, and its good. But at the same time, one should be careful of falling into the when you have a new hammer everything looks like a nail trap. Subversion serves *exactly* the same purpose as CVS. We're not trying anything new or asking that people switch to a different SCM model (like tla). smaller) set of filesystem objects as managed by Berkeley DB. This implies fundamental limitations not present in the current system. Think large files. Sure LFS is not likely to be an issue on your servers but it might be. Its worth thinging about. Whereas currently you would be restricted to ... thing. Its not a huge deal I know but still, I'm just making sure you consider the issue, even if just to dismiss it as a non-issue. BDB supports largefiles by default. I suggest you read up on Berkeley DB. There are lots of people who are running SVN repositories over several GB (including Conectiva, a Linux distro - last we heard they were over 10GB): http://subversion.tigris.org/svn-repositories2.html Are you sure that things like keyword expansion will work as they currently do? They probably will do but again, it should be carefully considered. Are We don't use keyword expansion in CVS, but Subversion has support for keyword expansion. The original proposal stated that full history will be preserved. As I recall from the svn dev list the cvs2svn conversion process has been plagued with difficulties. Are all the issues resolved? If you do make such a move Yes. Remember, we're not going to delete the CVS repository, only lock it out for future commits. So, if a bug in cvs2svn's conversion is found (unlikely, but possible), we can fix it and re-import. Please don't try to portray this as a 'snap' decision. We've been planning this out for well over a year now. In fact, before I joined [EMAIL PROTECTED] all those years ago, Roy said that we'd be switching over to Subversion 'soon.' Ha! -- justin
Re: [PROPOSAL] Move httpd to the subversion repository
On Sun, 14 Mar 2004, William A. Rowe, Jr. wrote: As I mentioned to the [EMAIL PROTECTED]'ers I would feel much safer moving 2.1-dev over to SVN (with APR 1.0) and leaving 2.0/apr 0.9 alone to the end of their useful life. Ugh. That sounds like it will make back-porting even more of a pain than it already is, and would require two toolsets to be maintained. In essence, I think we would wind up getting all the costs of subversion without most of the benefits (until all the old code is retired). It sounds like there are some serious differences of opinion on this issue. Would it help to make the arguments a little more concrete? I've made a start below. I can commit to STATUS if you'd like. I personally lean towards adoption of subversion. I agree that keeping barriers to entry as low as possible is crucial. But I don't think that subversion needs to be a serious problem there. Advantages of moving to subversion: - All the advantages over cvs as discussed at http://subversion.tigris.org/ (How important are these for Apache?) - Uses Apache 2 as transport, which has the benefits: - Dogfood - Don't need unix accounts for all committers (eventually) - Less problems with firewalls Disadvantages of moving to subversion: - Not as portable (?) - New tool to install/learn - Not integrated into as many IDEs - Backups/integrity (fixable?)
Re: [PROPOSAL] Move httpd to the subversion repository
--On Monday, March 15, 2004 1:02 PM -0500 Joshua Slive [EMAIL PROTECTED] wrote: Disadvantages of moving to subversion: ... - Backups/integrity (fixable?) Not to beat a dead horse, but I think that's an advantage with Subversion: on-the-wire checksums, repository checksums, (incremental) backups, etc. CVS offers none of that. -- justin
Re: [PROPOSAL] Move httpd to the subversion repository
Justin Erenkrantz [EMAIL PROTECTED] writes: --On Sunday, March 14, 2004 11:18 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: as the GNU, ASF, and SF projects all discovered, full backups by third parties are invaluable. What is the equivalent to rsync, and is it as stable? I think you mean cvsup not rsync. We're currently creating incremental dumps on every commit. Those can be digitally signed and rsync'd off-site. This is far more secure and auditable than any CVS-based solution - and is in fact, one reason why the ASF [EMAIL PROTECTED] and the board want to get off CVS. -- justin Justin, what's being done about unversioned properties (since those can change at any time)? Do you have post-revprop-change hook setup to squirrel away those mods so that they could be restored should the worst occur?
Re: [PROPOSAL] Move httpd to the subversion repository
On Mon, 2004-03-15 at 12:02, Joshua Slive wrote: Disadvantages of moving to subversion: - Not as portable (?) (Subversion clients/servers run anywhere APR does. I think that's actually more portable than CVS, since I don't believe CVS pserver runs on win32 at all.)
Re: [PROPOSAL] Move httpd to the subversion repository
--On Monday, March 15, 2004 1:29 PM -0600 C. Michael Pilato [EMAIL PROTECTED] wrote: Justin, what's being done about unversioned properties (since those can change at any time)? Do you have post-revprop-change hook setup to squirrel away those mods so that they could be restored should the worst occur? Yes. -- justin
Re: [PROPOSAL] Move httpd to the subversion repository
On Mon, 2004-03-15 at 20:39, Ben Collins-Sussman wrote: On Mon, 2004-03-15 at 12:02, Joshua Slive wrote: Disadvantages of moving to subversion: - Not as portable (?) (Subversion clients/servers run anywhere APR does. I think that's actually more portable than CVS, since I don't believe CVS pserver runs on win32 at all.) neon has been the most limiting dependency for a client, I am told. Sander
Re: [PROPOSAL] Move httpd to the subversion repository
On Mon, 2004-03-15 at 20:29, C. Michael Pilato wrote: Justin Erenkrantz [EMAIL PROTECTED] writes: --On Sunday, March 14, 2004 11:18 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: as the GNU, ASF, and SF projects all discovered, full backups by third parties are invaluable. What is the equivalent to rsync, and is it as stable? I think you mean cvsup not rsync. We're currently creating incremental dumps on every commit. Those can be digitally signed and rsync'd off-site. This is far more secure and auditable than any CVS-based solution - and is in fact, one reason why the ASF [EMAIL PROTECTED] and the board want to get off CVS. -- justin Justin, what's being done about unversioned properties (since those can change at any time)? Do you have post-revprop-change hook setup to squirrel away those mods so that they could be restored should the worst occur? We currently have not pre-revprop-change hook in place, so this is currently not an issue. Sander
Re: [PROPOSAL] Move httpd to the subversion repository
I would +1 moving over after release of 2.0.49 and 1.3.30... :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [PROPOSAL] Move httpd to the subversion repository
Jim Jagielski wrote: I would +1 moving over after release of 2.0.49 and 1.3.30... :) +1 Bill
Re: [PROPOSAL] Move httpd to the subversion repository
On Sat, Mar 13, 2004 at 02:04:09PM +0100, Sander Striker wrote: I hereby would like to propose that we move the HTTP Server project codebase to the Subversion repository at: http://svn.apache.org/repos/asf/. -1 This will, at least for now, raise the bar to entry for contributors. -aaron
Re: [PROPOSAL] Move httpd to the subversion repository
* Aaron Bannert [EMAIL PROTECTED] wrote: On Sat, Mar 13, 2004 at 02:04:09PM +0100, Sander Striker wrote: I hereby would like to propose that we move the HTTP Server project codebase to the Subversion repository at: http://svn.apache.org/repos/asf/. -1 This will, at least for now, raise the bar to entry for contributors. Why? nd
Re: [PROPOSAL] Move httpd to the subversion repository
On 13.03.2004, at 14:04, Sander Striker wrote: Hi, I hereby would like to propose that we move the HTTP Server project codebase to the Subversion repository at: http://svn.apache.org/repos/asf/. +1. I've proposed the same on the [EMAIL PROTECTED] list with respect to the APR project. It would be convenient, although not nessecary, if both projects decided to move at the same time. +1. Cheers, Erik smime.p7s Description: S/MIME cryptographic signature
Re: [PROPOSAL] Move httpd to the subversion repository
In article [EMAIL PROTECTED], Andre Malo [EMAIL PROTECTED] wrote: * Aaron Bannert [EMAIL PROTECTED] wrote: On Sat, Mar 13, 2004 at 02:04:09PM +0100, Sander Striker wrote: I hereby would like to propose that we move the HTTP Server project codebase to the Subversion repository at: http://svn.apache.org/repos/asf/. -1 This will, at least for now, raise the bar to entry for contributors. Why? nd your going to be forcing people to install some other piece of software. while this might be fine for a lot of people, some won't or can't. Some IDE's don't have SVN support yet, and some people have to deal with sysadmins who think redhat 5.2 is acceptable work environment to develop with. I'm -0.5 on the issue overall. I can't see what benefit it will give httpd overall at this stage.
Re: [PROPOSAL] Move httpd to the subversion repository
At 03:12 PM 3/13/2004, Sander Striker wrote: On Sat, 2004-03-13 at 21:35, Jeff Trawick wrote: Sander Striker wrote: Hi, I hereby would like to propose that we move the HTTP Server project codebase to the Subversion repository at: http://svn.apache.org/repos/asf/. So when? Can we get some lead time (7-10 days from the time there is a complete httpd and apr snapshot in subversion to play with) so developers can get clients installed everywhere and have time to address platform issues or changed scripting requirements before the project switches over? Ofcourse. Your idea of giving lead time starting when we have a test snapshot is very sensible. Lets make that 14 days from then, so that everyone has plenty of time to address issues. One issue I immediately foresee... as the GNU, ASF, and SF projects all discovered, full backups by third parties are invaluable. What is the equivalent to rsync, and is it as stable? As I mentioned to the [EMAIL PROTECTED]'ers I would feel much safer moving 2.1-dev over to SVN (with APR 1.0) and leaving 2.0/apr 0.9 alone to the end of their useful life. Bill
Re: [PROPOSAL] Move httpd to the subversion repository
* Sander Striker ([EMAIL PROTECTED]) wrote : Hi, I hereby would like to propose that we move the HTTP Server project codebase to the Subversion repository at: http://svn.apache.org/repos/asf/. +1. -Thom
Re: [PROPOSAL] Move httpd to the subversion repository
--On Saturday, March 13, 2004 2:04 PM +0100 Sander Striker [EMAIL PROTECTED] wrote: I hereby would like to propose that we move the HTTP Server project codebase to the Subversion repository at: http://svn.apache.org/repos/asf/. +1. -- justin
Re: [PROPOSAL] Move httpd to the subversion repository
* Sander Striker [EMAIL PROTECTED] wrote: I hereby would like to propose that we move the HTTP Server project codebase to the Subversion repository at: http://svn.apache.org/repos/asf/. I've played around a bit within the test repos. Seems it works ;-)) So +1. nd
Re: [PROPOSAL] Move httpd to the subversion repository
Sander Striker wrote: Hi, I hereby would like to propose that we move the HTTP Server project codebase to the Subversion repository at: http://svn.apache.org/repos/asf/. So when? Can we get some lead time (7-10 days from the time there is a complete httpd and apr snapshot in subversion to play with) so developers can get clients installed everywhere and have time to address platform issues or changed scripting requirements before the project switches over?
Re: [PROPOSAL] Move httpd to the subversion repository
On Sat, 2004-03-13 at 21:35, Jeff Trawick wrote: Sander Striker wrote: Hi, I hereby would like to propose that we move the HTTP Server project codebase to the Subversion repository at: http://svn.apache.org/repos/asf/. So when? Can we get some lead time (7-10 days from the time there is a complete httpd and apr snapshot in subversion to play with) so developers can get clients installed everywhere and have time to address platform issues or changed scripting requirements before the project switches over? Ofcourse. Your idea of giving lead time starting when we have a test snapshot is very sensible. Lets make that 14 days from then, so that everyone has plenty of time to address issues. Sander
Re: [PROPOSAL] Move httpd to the subversion repository
Ofcourse. Your idea of giving lead time starting when we have a test snapshot is very sensible. Lets make that 14 days from then, so that everyone has plenty of time to address issues. I would not mind a bit more time than just 14 day s - (I spend the last 72 hours trying to get subversion to work on QNX :-) - and sofar have failed to get a working combo on FreeBSD 4.2.x due to neon (I think) deps. Dw
