I'd say pretty much every protected-mode/mode switching assembly line in 2.0/2.2, and the USB stack issues in 2.4.12 - 2.4.22. And the whole swap mechanism of pre-2.6 (and specially pre-2.4). And the shitty shitty DOS-style syscalls in x86! Wtf was that? Intel/AMD even came up with a shiny new instruction, since apparently linux devs (Linus?) cannot be bothered in reading about level switching with call gates.
Anyway, dreadful bugs? Can't recall any major one. I did have some linux machines locking up randomly, even when they shouldn't, but most of the times, its a driver issue, not the kernel itself.

If you configure any of them to that specific task, there is no technical limitation from their side. But I'm sure you wouldn't consider some scripted operations in Excel to generate and manage certificates a security product, right? That was my point.

And is consistent in every environment? Shall I expect the same quality and behaviour in OpenBSD, Linux and Windows 3.1? Because, you know, this is the actual problem.

Sure, its called ENGINE API. Did LibreSSL removed it? Doesn't seem so. Check https://github.com/libressl/li...

So, you acknowledge they're still not mainstream, as you tried to imply in your previous comment.

Yeah, it didn't. Crypto support in general purpose CPUs is not new, and as you mentioned, the VIA instructions are way older than the incarnation from Intel.

The whole point is, probably some of the critical systems running software implementations in userspace shouldn't. Cryptoprocessors exist for a long time, and cryptocards and SoC are quite common well, everywhere. Bugs will always exist, but the attack surface is way smaller.

That's how all software works. It wasn't a serious/catastrophic bug. The peer review process from the community worked as expected, the bug was spotted and then fixed. The bug was tied to a specific implementation that wasn't very well thought of. Doesn't really matter, it was fixed. The bug itself was quite hard to exploit, specially if used on a secure environment (where process accounting is common; in fact, it baffles me the inane amount of Linux servers without any resource accounting at all, and the huge amount of sysadmins that don't even know how to configure this); I'd guess it is quite easier to gain root access on a given Linux server by using a more "generic" exploit (and then do as much hijacking as you want) than to hijack a crypto channel by using a fork bomb. And if it was Linus doing a similar fuckup, no biggie. But because it's Theo, it is newsworthy.

So, it generates prime numbers and does some math between them. If that is a security product, so is everything else capable of producing that kind of output - it includes both Excel and the C language, as an example.

Define "recently" and "greatly". Because if this bug actually happened in OpenSSL, I suspect that we'd have to wait months for the proper patch from upstream.

It's a shame that you don't realize that *modern* Intel is only a subset of the cpu market, and not even that relevant in network appliances. Have a look at http://en.wikipedia.org/wiki/R..., and you'll quickly see that the instruction you mention is about 2 years old. So, either you have the experience you say you have in other posts, and you're perfectly aware of this and are trolling, or you actually have no clue on the diversity of hardware out there.

OpenSSL/LibreSSL are *not* security products. They are crypto middleware. They can be used to build security products, or to build completely unsecured products. They do nothing by itself. Which is fun, because the LibreSSL Linux port actually required *extra* code so it would work with dumbass admins. And this extra code had the bug. True, Linux PID behaviour is not a security feature, but it is an entropy source. Maybe not a good one, granted. But it was used as fallback. Want to bitch about it, go ahead. It was detected, it was fixed. It is not a big deal. What is the problem?

It isn't. Apparently is an issue related to portability (aka Linux), and lack of permissions to access to proper RNGs in real-world scenarios (no access to /dev/urandom). While this is definitely a bug, it *isn't* a biggie. Its an edge case where the implementation should have been more robust, that's it.

I know. But those are only a subset of the contributors. And eg. for big, important projects, development is done mainly by companies (eg. Linux Kernel, Java, some GCC infrastructure, Mozilla, WebKit, etc), even if the commiters are listed individually. As I explained, the idea of the poor lonely guy in a basement writing code and being sued by the "big corps" is skewed from reality, and it has been for many many years.

That number may be absolute (as you're implying with the SI reference) or relative. Checking yourself into a hospital because of an anxiety attack and getting a prescription and some off time because of the whole situation is easily quantifiable. Many health-related quantifications are done in percent of an expected, well known pattern. And insurance and disability funds are paid based on that.

While I do agree with your point (relying on a 3rd party is usually not a good idea, specially when you can self-host the codebases), this is more common than you think. I myself maintain/contribute to several private (paid) repositories that rely on external dependencies from OSS projects.

Again, if someone publicly acuses you of a crime that is later proved you didn't commit, you are entitled to indemnification by damages caused to your reputation and your business/whatever. As this is not a matter of crime, it is a dispute filed on a civil court. There is no prosecuter on this. It is a dispute between two entities.

Yeah, but again, they are only a subset.

Please tell me one well-known, widespread OSS project that is completely community-driven and mostly built with unpaid volunteer work. And no, stuff like foundations don't count - they're done for tax purposes.

You are assuming a "volunteer" is not paid. In many cases, it is a false assumption.

Americans (mostly) don't use SI units. But what is the SI unit to bone damage in a broken leg? What is the SI unit for autism? What is the SI unit that measures impact of an infection on the organism? All these cases are quite easy to quantify.

So I hire an assassin. The assassin commits a crime, and I'm not responsible for inciting and paying for the execution of the crime? Wow.

Many many tools rely on automated checkout of libraries and components (under FLOSS licensing) from repositories. Having a base library or something like that unaccessible based on false pretext breaks those tools. This may translate on commercial releases that can't be done because further manual integration needs to be done. If I maintain or contribute to one of those tools, and my employer cannot deploy the latest bugfix or our platform because some monkey decided to file a DMCA, I'd bet they'll be having a bad time. And yes, again - this is quite common; OSS maintainers that are paid for what they do and integrate that work into the employer's product line. The notion that a project volunteer is a poor nerd in a basement, while romantic - is generically wrong. They exist, but they are not the majority.

A prosecuter is necessary for a public crime. And some crimes are semi-public (they require a lawyer to file the complaint).

Crossing the road is also dangerous.

Or not. You assume the system is rigged "for the big guys". I don't. In Qualcomm's case, any doubts about licensing of their driver/firmware code would have direct impact on sales. Pushing this to court while blatantly wrong would cause damage to the existing business. Qualcomm is not SCO; its not a patent troll trying to make a quick buck. As an example, I've done consulting on embedding systems for small network appliances. One of the criterias I use for component/platform selection was how "untainted" the driver is. Does the manufacturer provide a OSS-licensed reference driver? Is it known to push back or discontinue existing drivers? Are the drivers actual working drivers, or a wrapped blob? Is the licensing clear? Does it require an NDA? etc. etc. Given the rising popularity of android and linux systems, and the fact that many other companies also factor in these elements when choosing provider (not only price or funcionality), I'd be surprised if they try to move this forward.

Again, you assume its a guy in a basement. More often than not (at least for code that is actually useful), its not the case.

Besides lost time, the fact that code was unavailable for possible futural employers to look at, the fact that the volunteer was publicly pointed out as a copyright infringer and may not feel comfortable continuing his pet project? Heck, just the stress of it all is quite easy to prove and quantify.

Meanwhile I actually read the DMCA from Qualcomm, and it seems that - in most cases - the claim seems legit. Well, for the cases that aren't, you have your *public repo* with your name on it linking to a frivolous DMCA claim. While the claim itself is perfectly legal, advertising it may constitute libel if the claim is bogus. Also, if the files aren't accessible, they are depriving you of your intellectual property, by claiming its theirs. You already have a ton of posts on this thread explaining in detail why when someone states they're the legitimate copyright owner in a DMCA claim when that is false is - by itself - a crime.

There is no lawsuit. There is a DMCA complaint. If it is publicly displayed and its proved wrong, its libel, and grounds for suing. If the DMCA complaint itself violates the law, its grounds for suing. But I'd be very surprised to see Qualcomm taking anyone to court - you see, that kind of move scares away their customers that use Qualcomm code and semiconductors. This is usually settled fast (outside the court system) and silently.

...yet. And Venezuela isn't a politically stable country. I wouldn't be surprised if sooner or later those Colo companies were nationalized.

They are still liable for the damages caused by their good faith claim. As anyone that is wrongfully accused of a crime.

Not really. If you can prove that Qualcomm's false DMCA claim caused you harm (financially, psicologically, etc), you're getting jack and his wife. Public perception frowns upon "big companies abusing the little guy", so I'd expect this to not even go to court and to be settled with a non-disclosure clause, as it is common practice.

Imagine this - you go to court to prove the code is yours, and its an actual part of Qualcomm's product line, to such an extent they thought they owned it. They caused you harm *while* benefiting from your unpaid work. An you think they would stand a chance in an appeal/counter suit? Now imagine its your pet project, and you subtly change the license to forbit explicit usage from Qualcomm from the get-go, while the process carries on? Then its possible for you to actually slap them with a DMCA claim of your own, and even *gasp*, prove it in court.

The actual news seems like Qualcomm hired some IP firm that doesn't know shit about code and found automatically some "infringing" files. If this is the case, they will do everything to avoid going to court, regardless of the number of lawyers on staff, while silently settling the case with the IP company. And this shit keeps happening because no one bothers into taking it to court.

My favourite banjo song: https://www.youtube.com/watch?...

You are right, I wasn't aware of that. But it doesn't change the argument - it does not constitute a commercial contract (you're not paying for services or goods). And it is responsability of the receiver (or more commonly, his employer) to actually comply with the tax law. Even in the US, receiving a tip is not illegal. Not declaring it in your IRS may be, but - by itself - is perfectly legal as an act.