| |||||||||||||
|
| |||||||||||||
An attempt to backdoor the kernelAn attempt to backdoor the kernelPosted Nov 6, 2003 19:16 UTC (Thu) by jonabbey (subscriber, #2736)Parent article: An attempt to backdoor the kernel Interestingly, Graydon Hoare's Monotone is built entirely around cryptographic protocols.. files are identified in the archive by SHA1 hashes, not by filename, and all changesets and relationship between file versions are expressed through digitally signed assertions. It's a neat re-thinking of one of the premises of revision control systems, even though some folks (Tom Lord of Arch, for one) have expressed the opinion that Monotone is not perhaps as well thought out over the totality of the revision control problem space as it might be.
(Log in to post comments)
An attempt to backdoor the kernel Posted Nov 6, 2003 22:37 UTC (Thu) by lm (guest, #6402) [Link] Re: the monotone SHA1 hashes...Val Henson has written a paper recently about the fact that using a hash as a way to identify files isn't such a good idea. The paper basically says that just because you can use a hash + linked list search to find an item does not mean that you should use a hash without the linked list backup; hashes get proven to not be unique all the time. http://www.usenix.org/events/hotos03/tech/full_papers/henson/henson_html/ Using hashes in a version control system is appealing from the point of view of implementation but as I'm fond of saying to my engineers "we're not in the get-it-almost-right business". An open source system which uses this technique is probably fine, the chance of hash collisions is small and you didn't pay for the product. On the other hand, a commercial system that used hashes the same way as monotone does or opencm does, that's a lawsuit waiting to happen.
An attempt to backdoor the kernel Posted Nov 6, 2003 22:55 UTC (Thu) by jonabbey (subscriber, #2736) [Link] Yeah, I had the same concern, honestly. It's nice that you've got 20 bytes of SHA1 hash.. in theory, the odds against a single pair-wise collision should be a perfectly even 1 in 2^160 (or 1.46xe48), but that's still not zero, and the semantics of the thing really do call for perfect differentiability.We'll see.. whether Monotone succeeds or fails, I doubt that it'll founder on the difference between 1/(2^160) and 0. There's so much else in a revision control system to get right.
An attempt to backdoor the kernel Posted Nov 7, 2003 3:55 UTC (Fri) by lm (guest, #6402) [Link] > in theory, the odds against a single pair-wise collision should be a> perfectly even 1 in 2^160 (or 1.46xe48), but that's still not zero, As I've said in the past "In theory, practice and theory are the same, but in practice they are different" :) Your 1 in 2^160 assumes a perfectly random distribution of inputs. Math people love to assume Gaussian (or some other equally pleasant to math) distribution but those nasty programmers have a bad habit of not being that random. What does that mean? It means that all your math is meaningless. You are doing the math over the wrong set of data, data which doesn't exist, so you get a slanted (and incorrect) view of the world. If a file system or a SCM system is using hashes for their names of objects, be afraid. 99% of the time or more it will work but it will not work all of the time.
An attempt to backdoor the kernel Posted Nov 7, 2003 7:14 UTC (Fri) by hingo (guest, #14792) [Link] In a general sense, the above is right, but...A prime design criteria for a good hash function is that the resulting checksums should be evenly spread out over the output space, even if the inputs are very similar. Thus, assuming an even distribution is correct, if the hash function is "good". henrik
Hashes and collisions Posted Nov 7, 2003 10:54 UTC (Fri) by nowster (subscriber, #67) [Link] Even with a good hash function, you need to build in the ability to handle collisions. Consider the following problem: How many people do you have to have in a room before you have a better than 50% chance that two of them share the same birthday (ignoring the year)? The answer is surprisingly low (23). This is known as the Birthday Paradox. The probability of a collision approaches "evens" when (very) approximately sqrt(total_number_of_slots) hash slots have been used. Collisions are possible (but very rare) even with just two hash entries.
Hashes and collisions Posted Nov 10, 2003 16:49 UTC (Mon) by dd9jn (subscriber, #4459) [Link] You are mixing up simple hash fucntions (e.g. CRC-32) with cryptographic hash functions (e.g. SHA-1). The latter have a couple of important design criteria and thus you won't ever see a duplicated hash value. If you ever find or can construct a different second file hashing to the same value you have broken that hash function with huge consequences for about all cryptographic protocols. Even for the old MD5 algorithms, no collision has ever been found (the often reported weakness found by Hans Dobbertin is on a reduced MD5 variant). Using MD5 or SHA-1 is a perfectly good choice to identify a text.
Hashes and collisions Posted Nov 13, 2003 10:47 UTC (Thu) by rjw (guest, #10415) [Link] Erm.A hash function produces a small fixed number of bits from a large, potentially limitless number of bits. Just think for one second about that. How the hell do you think that every one of 2^(2^32) combinations can map to 2^160 combinations uniquely? Cryptographic hash functions merely make it computationally hard to find a match, and even harder to find a match which contains what you want it to.
Hashes and collisions Posted Nov 13, 2003 9:01 UTC (Thu) by hingo (guest, #14792) [Link] The Birthday Paradox is a different problem. In that, you are asking for the probability of any two persons "to collide". The cracker who wants to inject code into a BK repository, faces the task of constructing a collision for a given file (somewhat equivalent to finding a person with the same birthday as mine). The probability of finding a collision there is much lower (practically impossible with current hashes, with birthdays of course, you only have 365 days to pick from).henrik
Hashes and collisions Posted Feb 16, 2004 14:37 UTC (Mon) by Omnifarious (guest, #19508) [Link] The birthday paradox, applied to SHA-1, means that you must have approximately 1/2**75 separately hashed entities before you start seeing a significant chance of collision. This is still pretty tiny. So, in theory, hash by value should actually be pretty good. The paper is making the point that, while hash functions are designed to have certain properties, there is no guarantee that they do, and any lapse is catastrophic for algorithms that rely on them that heavily.
An attempt to backdoor the kernel Posted Nov 13, 2003 9:43 UTC (Thu) by ekj (subscriber, #1524) [Link] Actually no. You're wrong.A Cryptographically strong hash-function (such as sha1) does *not* assume that the inputs are random. On the contrary, it is made under the assumption not only that the inputs are non-random (as changesets are), but even that the inputs may be deliberately choosen so as to provoke a collision. A hash-function is cryptographically strong even if in this scenario, the chanse of collisions still is no bigger than the mathemathical minimum 1 in 2^num_bits. That is, there is no (known) way of generating different strings such that the probability that the strings have identical sha1sum is higher than 2^num_bits. It's still true that two changesets (or files or whatever) migth be identical trough pure dumb luck, but if I where you, I'd find something else to worry about, the chanse that a comsic ray will flip a bit in your ram and cause the program to give the wrong result is probably much much higher.
An attempt to backdoor the kernel Posted Nov 6, 2003 23:03 UTC (Thu) by coriordan (guest, #7544) [Link] > On the other hand, a commercial system that used hashesI assume you mean a proprietary system, but I don't see why peoples standards should be raised or lowered based on whether the software comes with freedom or not. If the software is bad, don't use it. The only difference I see, is that with Free Software, you don't have to deal with secret file formats, so migrating to new software is easier. Or if you want to use the bad software, you can fix it.
An attempt to backdoor the kernel Posted Nov 7, 2003 1:16 UTC (Fri) by proski (subscriber, #104) [Link] I wonder if you are Richard Stallman. Your style of writing is very similar. First you "translate" words into your own vocabulary, and then you "don't see" :-)I think lm meant "commercial". If you sell software with known defects like this, you may be held responsible, whether the software is free (as in speech) or not. I know, GPL disclaims any warranty, but this disclaimer is not valid in some jurisdictions.
An attempt to backdoor the kernel Posted Nov 7, 2003 1:55 UTC (Fri) by coriordan (guest, #7544) [Link] This is a mistake. My name is Drahcir Namllats, anybody that says otherwise is trying to mislead you. They want you to pre-judge whatever I am talking about, before reading my whole comment. This is not conducive to clear and open minded thinking.On translating words; I do Free Software, so I cannot comment in the name of Open Source. I have yet to see a jurisdiction where my^H^HFSF's GPL warranty disclaimer is not valid. Drahcir Namllats
An attempt to backdoor the kernel Posted Nov 7, 2003 6:35 UTC (Fri) by bajw (guest, #11712) [Link] I, for one, am very often impressed with your comments. Much like those of some guy with a weird name that is similar to, but backwards from, yours.I too fail to see why the standards should be raised or lowered by the level of freedom associated with the software.
An attempt to backdoor the kernel Posted Nov 7, 2003 7:33 UTC (Fri) by hingo (guest, #14792) [Link] Yeah, hat's of to coriordan (the rms of Europe? :-). We are especially thankful for your recent (andongoing I hope) work with the software patents directive. And also for your reporting of it here. As for the warranty disclaimer, I'm too under the impression that it's not valid in most of Europe. Wasn't that what a German law professor something pointed out in a study recently? (The story was reported in press with headlines like "GPL invalid in Europe", which was perhaps a bit too much.) I'm sure in Finland you couldn't get away with - sell a piece of (free/whatever) software for purpose X - software deletes all files on harddisk - "Not my fault, it says there is no warranty!" In Europe things are a bit different than in the US, from where we have learned to insert disclaimers everywhere. (McDonalds is not responsible for the fact that their coffee is hot, etc... Isn't it the point of coffee that it should be hot? I could understand if somebody sued them for the coffee being too cold :-) henrik
warranty disclaimer Posted Nov 7, 2003 10:55 UTC (Fri) by ber (subscriber, #2142) [Link] As for the warranty disclaimer, I'm too under the impression that it's not valid in most of Europe. Wasn't that what a German law professor something pointed out in a study recently?The study you are refering to, was funded by a huge business association where major proprietary software vendors pay member fees. The result was used to create bad press about the legal situation around Free Software and a lot of people bought into it. Read ifross news on it if you want to know the details: Dispute on Legal Issues Surrounding Free Software Intensifies. It concludes with: VSI's announcement about the legal risks in developing and using Free Software was premature. [..] The new study contains mostly long-known findings. At least in Germany strapping on a Free Software license is like giving something away like a gift. For gifts you are only responsible if you (a) on purpose try to do something nasty or (b) act very unreasonable. (b) translates into actions that almost everybody would have known to cause serious problems. So you do not necessarily need the warranty disclaimers as the legal situation is already okay. We should start point out that the legal risks around proprietary software is a lot higher compared to Free Software.
warranty disclaimer Posted Nov 13, 2003 9:34 UTC (Thu) by hingo (guest, #14792) [Link] Hashes aside, I see that Larry of BitMover has collided with The RMS of Europe. Ouch, didn't see that happening, especially since this is not slashdot. Anyway, too late now.I completely agree with the above clarifications. In summary: 1. A warranty disclaimer in Europe is meaningless. You are responsible for some of your actions wether you want it or not. For Free Software (as in beer, even) a warranty disclaimer might even be an empty statement. 2. This was nothing new, however some rich and twisted people decided to make a fuzz about it. The headlines "GPL is invalid in Europe" were of course only humorous at best. As for the coffee thing, if I spillt coffee on myself because I was "drinking and driving" and burned myself, I would not want to announce it to the world in a lawsuit that I'm that stupid. This is the difference with US citizens and the rest of the world. I have no need to defend McDonalds however. henrik
McDonald's coffee suit Posted Nov 14, 2003 14:40 UTC (Fri) by Max.Hyre (subscriber, #1054) [Link] Details of the case. Read before discussing. 'Nuff said.
warranty disclaimer Posted Nov 14, 2003 21:56 UTC (Fri) by giraffedata (subscriber, #1954) [Link] 1. A warranty disclaimer in Europe is meaningless. You are responsible for some of your actions wether you want it or not.The second part, "You are responsible..." is also true in the US, and probably everywhere else. The first part, "A warranty disclaimer is meaningless" is not true in the US, and I kind of doubt it is anywhere else either. In the US, I am responsible for my actions under laws that have nothing to do with warranty: tort law. However, I am responsible for additional things because I gave a someone a warranty. In some cases the law says I give that warranty implicitly, and in some of those cases, the law says I can override that implied warrantee by explicitly disclaiming it. Here's where freely distributed software comes in: For some of those actions for which I am responsible under tort law, a person may assume the risk from me, in exchange for valuable compensation from me. So in return for my valuable software I may demand from you, instead of cash, indemnity against the risks inherent in distributing software (the risk that through some fault of mine, the software hurts you). Exactly how free we are to make that trade varies a lot from one jurisdiction to another. And finally, most of the "disclaimers" we see all the time are not warranty disclaimers. They are merely notice that the person does not intend to assume a certain risk, and they serve to defeat ridiculous claims such as, "I would not have parked my car there except that the owner of the building led me to believe he would protect my car."
An attempt to backdoor the kernel Posted Nov 8, 2003 2:03 UTC (Sat) by coriordan (guest, #7544) [Link] Thanks for the comments, and to bajw too.Georg Greve (president of FSFeurope) might be the closest thing Europe has to an RMS, but I'm sure most people haven't heard of him. Digital freedom needs so much work, that people working on these issues usually don't have time to contribute to public fora like LWN. So this leave such fora filled with a high percentage of contribution by armchair generals etc., and I think this sucks, so I make time for LWN, and sometimes lesser fora such as slashdot. Regarding the enforceability of the GPL in europe, I second ber's info, as for McDonalds coffee, RMS mentions it in this article. It's interesting that ber mentions FS being a gift in Germany. Last year a law professor proposed a law to forbid the gift transfer of copyrighted material without reasonable compensation. His aim was to prevent musicians being ripped off by the recording industry, but he hadn't realised that this put distribution of FS in jeopardy. Georg Greve, and the others in FSFeurope and another org called iFROSS, got an FS exception added to the law, and FS was safe again. But since he deosn't post to LWN, most people didn't hear of this ;-)
An attempt to backdoor the kernel Posted Nov 7, 2003 3:47 UTC (Fri) by lm (guest, #6402) [Link] Re: free vs notLots of free software is "good enough". Using hashes as a way to name files is "good enough" in the opinion of some free software SCM systems. It's not good enough for a commercial system because if it fails the customer can, and probably will, sue the vendor. Like I said, we aren't in the "almost got it right" business, that may be fine for lots of people, look at CVS, it's heavily used and it has no integrity checks at all. If a disk goes bad, memory goes bad, the network file system goes bad, a malicious or naive user goes bad, none of that is detected in CVS and all of that would be detected in BitKeeper. Commercial software has to be paranoid, it's part of the deal. That's one of the reasons why you pay money, we worry about the extremely unlikely cases that have a nasty habit of happening at the absolute worse time. The argument against our paranoia is that "things don't go wrong that often so it's OK to let it slide". That's a fine argument for software that you don't pay for but how would you feel if you'd paid a pile of money and I said that to you about the software you just bought?
An attempt to backdoor the kernel Posted Nov 7, 2003 5:58 UTC (Fri) by coriordan (guest, #7544) [Link] lm, you're confusing the issue, which makes it hard to respond to, but I'll try anyway because this issue is important.You compare Free Software to commercial software, but these things are not exclusive, there is a lot of commercial Free Software. The MySQL database is one great example. The GNU Arch revision control system is another. If people want support or new features in GNU Arch, they can pay the highly talented Tom Lord for these things: The GNU Arch Commercial offerings page If you are trying to copy BK, give it up. We'll simply follow in the footsteps of every other company faced with this sort of thing and change the protocol every 6 months. Since you would be chasing us you can never catch up. If you managed to stay close then we'd put digital signatures into the protocol to prevent your clone from interoperating with BK. -- Larry McVoy, LKML I wouldn't use software that is afraid of competition, specifically I would steer well clear of software that uses file-format lock-in to keep it's userbase. GNU Arch obviously doesn't create this problem, and it has a user community and plenty of Free documentation as a bonus.
An attempt to backdoor the kernel Posted Nov 7, 2003 8:34 UTC (Fri) by jamesh (subscriber, #1159) [Link] You seem to be confusing the issue yourself. Would you be willing to sell/support a piece of software (proprietary or free software) and provide a warranty if you knew it had defects that might affect your clients? It sounds like a great way to get sued. You would want to minimise the risk as much as possible. Larry is essentially saying that the chance of data loss with some other source code management systems is too high to make supporting them profitable. ie: [amount of money lost in lawsuit] * [probability of lawsuit] > [profit from selling support/warranty] Providing a warranty like this is a commercial activity -- you would be stupid to take on a liability like that without getting something in return. So it seems to be the right term to use here.
Arch documentation Posted Nov 7, 2003 9:19 UTC (Fri) by lolando (subscriber, #7139) [Link] > GNU Arch obviously doesn't create this problem, and it has a user> community and plenty of Free documentation as a bonus. Quick reminder: the documentation is Free-for-the-FSF, but not Free-for-everyone. Specifically, it is, as far as I know, released under the GNU Free Documentation License, the Freedom of which is not recognised by everyone (see the mighty dispute between the FSF and Debian) for a start, and it even includes Invariant Sections, which should make it clear that it is not quite Free. *And* at least one of the invariant sections contains text that is controversial. As for the "plenty"... No man page, no info page, just the one tutorial (which was outdated last time I tried it). This is not a troll. I'd love to use TLA / GNU Arch, which seems to have the features I want. But I found it easier to get started with Subversion, even though it doesn't have all of them. The Subversion documentation is just much more polished.
Arch documentation Posted Nov 7, 2003 10:47 UTC (Fri) by coriordan (guest, #7544) [Link] to lolando:I accept your point about the GFDL, indeed I'm not a fan of the GFDL myself. I hadn't noticed the lack of infopages. I'll see if I can find someone to fix this, or stick it on my todo list for early 2004. There is a more than just a tutorial though: Quick Introduction, Quick Reference, Reference Manual, Tutorial, FAQ. to jamesh: > Would you be willing to sell/support a piece of > software (proprietary or free software) It seems Tom Lord is happy to do this. If you read my previous comment again, you'll notice that I linked to a page offering support for GNU Arch for a fee. > and provide a warranty if you knew it had defects that might > affect your clients? It sounds like a great way to get sued. > You would want to minimise the risk as much as possible. Well, I'd provide a warrany, if you don't specify how good it has to be. How about "I'll fix all problems you have with GNU Arch, if they occur on Mars". Any good? no. So lets look at the BK warranty: Where's BitKeepers warrany? here it is: BitMover represents and warrants for a period of ninety (90) days ("Warranty Period") that it will make a reasonable effort to ensure the Software operates substantially in accordance with the applicable Documentation ...it then goes on to list 8 things that could invalidate your license, and then: NEITHER BITMOVER NOR ITS LICENSORS MAKE ANY OTHER WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THE SOFTWARE. BITMOVER DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE SOFTWARE WILL MEET YOUR REQUIREMENTS OR THAT OPERATION OF THE SOFTWARE WILL BE UNINTERRUPTED OR ERROR-FREE. ...only mildly better than my mars warranty. They're not exactly liable for much, are they?
Arch documentation Posted Nov 7, 2003 14:41 UTC (Fri) by jamesh (subscriber, #1159) [Link] It seems Tom Lord is happy to do this. If you read my previous comment again, you'll notice that I linked to a page offering support for GNU Arch for a fee. That is consistent with what Larry said earlier. He said that it would be difficult/unproffitable to support an SCM system that relied on hashes alone to identify files. IIRC, Arch doesn't fall into this category. As for the BK license you link to, it states that when you buy the software, you aren't getting support. Section 7 seems to indicate that you can buy support separately. The support contract is most likely separate. You might not like the BK licensing (I wouldn't feel too comfortable relying on it for my own software either), but Larry hasn't really said anything controversial here.
Arch documentation Posted Nov 7, 2003 21:50 UTC (Fri) by coriordan (guest, #7544) [Link] > That is consistent with what Larry said earlier.Larry said a lot of things. Some were quite confused. He compared Free Software to commercial software, so I gave an example that is both. and he said that "Commercial software has to be paranoid, it's part of the deal", so I pointed out that his company disclaim virtually all warranty, and that GNU Arch support is available. So, with commerce, support, and warranty out of the way, I think the only thing that no one addressed was my LKML quote about competition and proprietary file/protocol-format lock-in tactics: If you are trying to copy BK, give it up. We'll simply follow in the footsteps of every other company faced with this sort of thing and change the protocol every 6 months. Since you would be chasing us you can never catch up. If you managed to stay close then we'd put digital signatures into the protocol to prevent your clone from interoperating with BK. -- Larry McVoy, LKML
Arch documentation Posted Nov 8, 2003 2:58 UTC (Sat) by lm (guest, #6402) [Link] > Larry said a lot of things. Some were quite confused.Funny, I don't feel confused. I must be so confused that I don't realize I'm confused :) Our license is standard boilerplate, it's no different than other license and that's with good reason. The boilerplate exists because of previous lawsuits and changing it is not a good idea. I'll tell you a story about that. Our original commercial license was written by me and it was a license you would have loved. It had a clause in there that said if you hit a severe bug and we wouldn't or couldn't fix it promptly, we'd come to your site and pull your data out of BK and put it into the source management system of your choice, retaining all revision history such as dates, user names, etc. A large two letter company that builds chips took offense at this clause. How could that be possible? The clause was designed to make the customer feel good, we were standing behind our software to the extent that we'd drop everything and help the customer if something went wrong (a policy which we have to this day even if it isn't in our contract, ask any BK user). The company pointed out that it was just fine if we did that for them, but suppose we had sold a pile of seats to Sony Japan. And Sony had some problem and half our engineering team had to fly to Japan to extract the data and put it in Arch which was just not done yet so we had to sit there and fix Arch as part of the contract. Where does that leave our two letter company? They are getting crappy support because we are off honoring a contract clause that put us at too much risk. Think about that. It's really smart. They were looking ahead and they educated us as to why it is bad to be different. It's certainly OK to be a little different but in general you want to do things the way other people do them because those ways have withstood the test of time. Beating us up about our boilerplate is just silly and naive. You might as well attack 100% of the companies which ship commercial software. You haven't found anything that is different in our license from theirs, it's all the same. So why pick on us? Especially given that we are a company who has given away their technology to help your cause, given away hardware and bandwidth to help your cause, given away salaries to help your cause, and this whole thread is about how we prevented a trojan horse from getting into Linux. And you're attacking us? It's hard to see how that makes sense for anyone other than a zealot and that doesn't help your cause, it hurts it.
Arch documentation Posted Nov 8, 2003 5:28 UTC (Sat) by coriordan (guest, #7544) [Link] So you legaly promise crappy support, but you actually give very good support whenever possible. ok."So why pick on us?" - It's nothing personal, I reject all proprietary software. "we are a company who has given away their technology to help your cause" You have developed software, but you have decided to use copyright law to prevent users from helping themselves or eachother. This decision to exert power over your users completely contradicts my cause. Your decision to use secret file format/protocols to prevent competition reminds me of why proprietary software must be rejected. Your business model relys on control, and to this end it compels you to do whatever's neccessary to maintain this control. Like when Pavel Machek started to write a BKclone at home on his own time, you contacted Pavels boss, asking him to pressure Pavel into not writing the software, you even complained that Pavels boss should have made him choose between that home project and keeping his job. No level of warranty can makes it okay to treat people this way. People deserve freedom.
Arch documentation Posted Nov 8, 2003 5:52 UTC (Sat) by lm (guest, #6402) [Link] Just out of curiousity, how do you reconcile your obviously negative view of our company with the undisputed point that we just did the free software world a pile of good? If your precious open source tool was the one that was used this security flaw would likely be in the kernel right now.While you are at it, how do you reconcile your obviously negative view with the fact that we produced a BK->CVS gateway so you can have the source you want in a 100% God fearing politically correct form? You're quick to jump on anything that supports your point of view, but isn't it interesting that this evil company is the one that is actually _doing_ the work that needs to be done? Pavel & Co are great at making noise but have you looked at the code? There isn't any. If you were to stop and think for a minute you'd realize that we have to have a profitable business if we are going to keep on giving out the support that we do to open source world. It costs us more than $100K a year to do what we do for you, actually, a lot more than that now that I think of it, it's probably more like $250K or so. You're oh so eager to beat us up when we protect the very money it is that we use to help you but I don't see you coughing up that cash, that time, that software, or that support. I'm open to a better way to do things but in case you haven't noticed, nobody else has stepped forward with anything except a lot of talk.
Arch documentation Posted Nov 8, 2003 7:44 UTC (Sat) by coriordan (guest, #7544) [Link] You only solved a problem you created. If it was Arch and Arch2CVS, anyone and everyone could be running integrity checks, but you've created central control.BK bashing on lkml was bad advertising, so you made a gateway to hush the protestors. Yes you are putting effort into your plan, it's a pity Pavel didn't finish his clone, and it's unfortunate that Linus trades away his freedom. "more than $100K a year to do what we do for you"
Silly zealots Posted Nov 8, 2003 15:37 UTC (Sat) by lm (guest, #6402) [Link] You're right, you figured me out. I joined the kernel development 10 years ago, worked with Linus for years, all the while carefully planning to use them to make money.And even though I was the 4th person at Google, and even though it was obvious that I could make tons of money at Google, I choose to leave that place and start a source management company because I thought that would make *more* money than Google. And you, with your incredible insight, have seen through my dastardly plan. Rats! Foiled again!
Sounds like the Spanish civil war Posted Nov 9, 2003 17:58 UTC (Sun) by vblum (guest, #1151) [Link] IMO, one of the saddest spectacles in history is the Spanish civil war. It was lost notnecessarily because the republican forces were weaker than their fascist opponents. It was lost because different factions among the antifascists attempted to eat one another at a time when they should have stood together. Not that Free Software vs Big Money is even remotely similar to that - for all their market But the lesson is an important one - in Spain, the idealists failed miserably because they Ciaran: I respect your stance for free software (and usually appreciate your comments; I only Larry: I read many of your posts on why you keep BK licensed as it is; and, I see your need to On the other hand, your customers also face deadlines (at least if they're in big companies) cheers, V.
war Posted Nov 9, 2003 19:28 UTC (Sun) by coriordan (guest, #7544) [Link] BitKeeper offers an immediate practical convenience on condition that we ignore the issue of freedom. If we accept this deal, will we ever have a Free Software SCM that rivals BitKeeper?We didn't all accept the proprietary Qt. Now we have GNOME, and Qt has been GPL'd. If Linus chose Arch, the whole community would have benefitted from increased developer interest in Arch. Maybe it would now have the features it lacks compared to BitKeeper. BitKeeper is not a friend of the Free Software community. It's a friend to Linus, but Linus is not fighting for our freedom. this here is software, not crimes against humanity! The software divide between 1st & 3rd world countries is a humanitarian problem. Free Software is a solution.
re:war Posted Nov 9, 2003 20:30 UTC (Sun) by vblum (guest, #1151) [Link] errm ... just to explain my wording (crimes against humanity) - I wanted to put my ownexample back into perspective, and only my own - nobody else had implied anything remotely similar to Franco et al here, and I just wanted to make sure I could not be misread. If my implication was that anyone else had - sorry about that. I do see the freedom-related issues, but there must also be a path to get there; BK seems to If Larry's contribution ultimately ends up making Arch (or whatever else) a stronger system -
re:war Posted Nov 10, 2003 11:11 UTC (Mon) by coriordan (guest, #7544) [Link] Software was going proprietary, so RMS started GNU, Qt was proprietary, so he started GNOME, BitKeeper is proprietary, so he endorsed Arch and it's now a GNU project. It's true that solutions are born from problems, but I wouldn't use this as a basis for supporting the problem :-)
Sounds like the Spanish civil war Posted Nov 9, 2003 21:54 UTC (Sun) by lm (guest, #6402) [Link] Re: could we make a business based on serviceThe service model has been tried before in this space. We *spend* more in a year providing free services to the open source world than has ever been made from supporting an open source management system. Ask Tom Lord how easy it is to convince people to spend money in this space, he spent the last year begging for enough money to keep his internet connection on. Contrast that with having to pay a dozen engineers and you start to get the picture. Re: BitKeeper limits your freedom I really don't want to argue about this and I would like this to be my last post to this thread (and I'm off to the beach with my family and no laptop so there is a good chance :) We are sensitive to the needs of the open source world and we do our best. BK has always made it trivial to get the data out of BK if you want to do that. If that's not enough, we built and run the BK->CVS gateway so that the zealots don't even have to touch BK. That's as much as we can do, if it doesn't make you happy, I'm sorry about that, but I can't help you.
Sounds like the Spanish civil war Posted Nov 9, 2003 22:15 UTC (Sun) by vblum (guest, #1151) [Link] I know - no annoyance intended, thanks for taking the time to respond. I guess I alwayshave the Trolltech example in mind. I also realize BK and Qt cater to different spaces. Have fun at the beach! (I should be in the mountains, really ...)
An attempt to backdoor the kernel Posted Nov 7, 2003 11:31 UTC (Fri) by rschroev (subscriber, #4164) [Link] I think there is a huge difference between problems that arise as a result of conflicting hashes on one side, and not detecting corruption on the other side.Colliding hashes is a bug in the system, in my view. The system may be "almost good enough", but never "good enough". Detection of errors introduced outside of the system is a nice feature, but it is one I can live without. Lack of the feature is not a bug. The system is effectively "good enough".
An attempt to backdoor the kernel Posted Nov 20, 2003 13:30 UTC (Thu) by Wol (guest, #4433) [Link] Colliding hashes is MATHEMATICALLY INEVITABLE.It can't, therefore, be a bug. Being able to generate a file that results in the hash you want, however, most definitely IS a bug, because it is a gaping security hole. Cheers,
An attempt to backdoor the kernel Posted Nov 7, 2003 18:55 UTC (Fri) by zooko (subscriber, #2589) [Link] If you can find collisions in SHA-1, you can probably use that to forge digital signatures and gain remote authorizations to any system that uses cryptography for authentication. (This includes, among others, any system which uses SSH, TLS, or a cryptographically authenticated VPN.)Is it a lawsuit waiting to happen to run sshd?
An attempt to backdoor the kernel Posted Nov 8, 2003 18:54 UTC (Sat) by Stephen_Beynon (✭ supporter ✭, #4090) [Link] You could only do that if you manage to find a way of generating a blockof data with a pre-determined hash. The problem of finding 2 blocks of data which generate the same hash (any hash) is a far smaller problem.
An attempt to backdoor the kernel Posted Nov 13, 2003 9:59 UTC (Thu) by ekj (subscriber, #1524) [Link] Sure. More spesifically, the magnitude of the problem is proportiaonal to the square root ofthe other problem. So finding two strings with the same 160 bit hash requires you to generate and hash on the order of 2^80 strings. I wouldn't loose much sleep over this, but if you do, there's no problem with going to a bigger hash. If you could generate and hash 2^30 strings a second (and store all the hashes you already have created...) you'd still need 2^50 seconds before you'd on the average get lucky. Everyone designing cryptographic hashes is aware of this issue, which is why the hashes are so big in the first place.
An attempt to backdoor the kernel Posted Nov 15, 2003 4:04 UTC (Sat) by graydon (subscriber, #5009) [Link] this paper is simple fud. see http://www.venge.net/monotone/docs/Hash-Integrity.html for a detailed response.
An attempt to backdoor the kernel Posted Nov 20, 2003 6:40 UTC (Thu) by khim (subscriber, #9252) [Link] "In theory, practice and theory are the same, but in practice they are different" Exactly! Here is difference: if we have two systems - one uses SHA1 without any colluisions detection and other uses SHA1 and linked list as backup then version without backup is less reliable in theoty but more reliable in practice! I'm joking, right ? How the hell version without collision detection can be more reliable ? No, I'm not joking. You all ussume that you "perfect" program will work on some "perfect" hardware. That's not so. Real CPU, memory, hard disk and other components are not 100% reliable. Thus you program can misdetect even if you algorythm is perfect. And this probability is increased when linked list added as backup for strong crypto hash. For most non-trivial programs this increase is so big that it completely dwarfs mythical SHA1 collisions. Think about it and then try to advocate you backup plans. Preferrable with numbers for hardware in hands, not with some abstract righteosy.
|
|
||||||||||||