One of the main benefits of the OpenBSD 5.6 release is its new httpd HTTP server that includes FastCGI and SSL support.
As httpd contributor Reyk Floeter describes it:
httpd was written in and by OpenBSD and it shares a lot of code and efforts with other daemons, including relayd, snmpd, iked and even the "cousins" bgpd, ospfd, smtpd and others. The FastCGI implementation was contributed by florian@ based on his slowcgi code. We have an amazing lineup of tools in base, but they are not individual software projects -they share code, principles, and concepts. They are not "alien" to us and we have multiple people who "know" or understand the code base. I get useful contributions, tests, bug reports and direct feedback from many OpenBSD developers and our user community.
OpenBSD is already known as one of the most, if not the most, secure and robust operating system in existence. As the project's home page states, OpenBSD has suffered from "Only two remote holes in the default install, in a heck of a long time!" Given the project's remarkable focus on security, and the project's long history of developing extremely reliable software, it is without a doubt that httpd will soon reach the stature of the OpenBSD community's other renowned and respected projects, including OpenSSH and LibreSSL. For those desiring a strong and secure, yet capable, web server stack, OpenBSD is clearly worth a look.
(Score: 4, Informative) by Lagg on Sunday November 02 2014, @02:06AM
You guys probably should have included the paragraph above his ML post. The tone of it in the summary makes it look unfortunate.
So basically nginx was there because it had a fastcgi implementation, now that httpd does they're removing nginx and noting that it's better this way because of the reused code that is known to be proven in multiple daemons for multiple years. I'm okay with that and can understand the irritation at reinventing stdlib functions, even though I love nginx in a way no man should love a project. Except for the open core "enterprise" part of it. Fuck that.
http://lagg.me [lagg.me] 🗿
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @02:30AM
What makes it look "unfortunate"? I think it's a great thing that OpenBSD maintains such high standards. That includes having maintainable code. If the OpenBSD developers don't find nginx's code to be easily reviewable and up to their standards, then getting rid of it from the core system is the most responsible thing they can do. It's even better that they're replacing it with code they do trust. If the OpenBSD developers trust this code, then I feel confident trusting it, too, because I trust their judgment.
(Score: 2) by Lagg on Sunday November 02 2014, @02:59AM
For one thing it's probably a good idea to note that the topic of the post quote involves nginx and for another it kind of makes it look as though this is a justification for something that isn't the removal of nginx. What my first thought was when I saw the summary is "please don't tell me you're making justifications for coupling your stuff". That wasn't the case at all and I kind of hoped it wasn't since the guys maintaining openbsd aren't like that but it was still a momentary "Wait what".
http://lagg.me [lagg.me] 🗿
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @03:59AM
How does nginx even matter? It's still available in ports. If you want it, just install it. Otherwise, it is irrelevant, as it should be.
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @02:35AM
What the fuck are you even talking about? The only place I see any mention of that term is in your comment.
(Score: 2) by Lagg on Sunday November 02 2014, @02:37AM
Because my fragile ego must be maintained I feel compelled to note that I don't support that part of nginx whenever I mention how much I love it.
http://lagg.me [lagg.me] 🗿
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @02:40AM
OK, I see. You just aren't very good at expression ideas. Fair enough.
So what the fuck did you mean when you wrote:
As somebody else pointed out, the tone is perfectly acceptable. Why do you have a problem with it?
(Score: 2) by Lagg on Sunday November 02 2014, @03:03AM
You'll never learn reading comprehension if you blame others for your lack of it
http://lagg.me [lagg.me] 🗿
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @03:14AM
I'm reading what you wrote, but it's all non sequitur. Your ideas are all over the place. They're not related to one another. And none of them are related to the topic at hand here.
(Score: -1, Troll) by Anonymous Coward on Sunday November 02 2014, @02:10AM
Few remote holes in the default install is trivial to achieve if your default install has few/zero services enabled.
Using the same logic you could say MS DOS has zero remote holes in its default install. Does that make it a more secure OS? No, of course not. Worse if in most installations people would enable stuff that turns out to be exploitable. For example Microsoft likes to say IE on their server stuff is secure in its default configuration, but that's because lots of stuff is turned off that IE users would turn back on (if they really want to use IE).
You'd compare whether the security model is better AND the actual implementation of it less buggy and exploitable than average.
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @02:27AM
That's great, but you're totally ignoring the fact that OpenBSD is still extremely secure even with many services enabled.
(Score: 1, Troll) by melikamp on Sunday November 02 2014, @02:59AM
I call BS. To the best of my understanding, OpenBSD has within the default install the Amtel wireless firmware, which is non-free, sourceless, and is only allowed to be distributed in object form ( /etc/firmware/atu-license in base ). Thus OpenBSD, as an OS, is far less secure than any FSF-endorsed distro or vanilla Debian. It should be regarded as already compromised.
(Score: 1) by Anonymous Coward on Sunday November 02 2014, @03:11AM
First of all, it's Atmel, not "Amtel".
Second of all, the firmware isn't used if the device isn't present.
Third of all, it's firmware, for crying out loud. You do understand what firmware is, don't you? It's code that runs on the hardware itself, not on the main CPU. Instead of being burned into ROM or otherwise on the hardware itself, it's loaded at runtime by the operating system's driver for the device. This makes the hardware cheaper, and the firmware easier to fix. And if you don't trust the device itself, then don't fucking use it!
Come on. If you're going to try and argue this, at least make cogent arguments. It's fucking sad when you're accusing others of "BS", when you're the one spewing bullshit.
(Score: 2) by melikamp on Sunday November 02 2014, @03:38AM
What are you, some kind of angry marketing shill?
I am saying, OpenBSD likely has a backdoor in the default install, which is as insecure as one can get. And that's their attitude. What you are saying is irrelevant.
Of course. Firmware is a kind of software, usually a binary blob, that runs inside my computer.
Oh, you only care if the main CPU spies on you? You don't care if an auxiliary CPU spies on you just as effectively? Again, irrelevant.
On Linux, they say, wireless adapter firmware has DMA access to RAM by design, and proof-of-concept exploits exist for some cards, whereas firmware can do arbitrary code execution in RAM. How is it in OpenBSD? Enlighten us please.
I am no security professional, but you are so off, you seem to have no idea what "security" is, or just pretend not to understand. When no one is allowed to look at the wireless adapter code, it's a scam and a backdoor. Security for the vendor, not for the user.
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @03:42AM
Jesus Christ. Your stupidity boggles my mind. How are we supposed to discuss this if you can't get basic stuff right, like the spelling of the device manufacturer's name? And how the hell are we supposed to discuss this if you don't even understand what firmware is, or how it works?
(Score: 2) by melikamp on Sunday November 02 2014, @03:45AM
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @03:57AM
I'm not the AC you were chatting with earlier, but I do agree that you may not know what you're talking about here. That other AC presented valid points based around fact. You've given us speculation based on your apparently incorrect and incomplete understanding of what firmware is.
Can you give us more concrete evidence that there are problems with this specific firmware? If you're going to make accusations, I don't think it's too much for us to ask for you to provide some concrete proof that the problems you claim exist actually do exist.
(Score: 2) by Kilo110 on Sunday November 02 2014, @03:53AM
"OpenBSD likely has a backdoor"
That's quite the accusation.
Do you have any proof other than the existence of a binary blob to back this up?
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @03:54AM
He doesn't. He doesn't even understand what firmware is, how it works, or when it's used. If he can't get the basics right, he sure as hell isn't going to get anything beyond that right, either.
(Score: 2) by melikamp on Sunday November 02 2014, @04:17AM
What do you mean by proof? You won't stop using a blob until someone disassembles it for you? Are you not outraged by the vendor's refusal to provide source for software that runs on the wireless card? They are scamming you, and they they don't even try to hide their ill intent. OpenBSD, at the same time, redistributes software that no one can review, which is not nearly as evil, but still does not deserve to be called "secure", let alone "one of the most secure systems".
Do I seriously need to start listing backdoors and spyware discovered in proprietary software to date? How many backdoors will it take before you will say "OK, I want to be able to see the source code before I run this"? How profitable and explicitly legal does spying have to become before you make a reasonable assumption of guilt for a non-free software vendor?
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @04:25AM
You've made the claim that the Atmel firmware has security flaws, or is otherwise malicious in some way. But you haven't provided specific details. These details are what we want from you.
Problems with other firmware are irrelevant. Emotional reactions to firmware are irrelevant. We need to know very specifically what harmful behavior you see the Atmel firmware exhibiting.
If you can't provide us specific information about this vulnerability or vulnerabilities, then maybe you should retract your statements and apologize.
(Score: 2) by melikamp on Sunday November 02 2014, @04:49AM
Like I said before, AC, you don't understand what user security even means. If I email you a binary blob for your arch, will you run it? Probably not. Well, the same part of your brain that prevented you from running my blob should be telling you not to run non-free wireless network firmware. If you do, you are being used. You are a mark. It's like a most basic scam. You are making a cash purchase when you buy a card. This is when you should be asking yourself: why can't I read the source code? Why can I read it for some chipsets, but not for this one? WTF? They lose nothing when they get caught. Computer fraud laws don't seem to apply to those who have TV ads and hack millions of paying customers at a time.
The security risk is so basic, I can't believe we still have to argue this. I don't need to prove it's faulty. The vendor must give me a reasonable assurance it is not. Doing so in this case is very easy for the vendor. No trouble at all. Just release the source code and whatever specs you have. So when a vendor refuses to honor this very minimal request, it means they are out to fuck you. It's that easy.
(Score: 1) by Techlectica on Sunday November 02 2014, @06:12AM
There are plenty of Linux wireless drivers that use blobs [debian.org] and when there is an alternative with free source it had been painstakingly developed through reverse engineering. My understanding is that this is in large part due to regulations by the FCC (and their equivalents in other countries) to ensure that the devices emit only in their allowed frequencies. This is also why you have separate firmware bundles for the radios in Android smartphones. So, yes, it is a potential security risk and if it is a significant concern for you then, as the other poster pointed out, don't buy that particular piece of hardware and that code will never be executed.
(Score: 1) by Techlectica on Sunday November 02 2014, @06:21AM
I mean seriously, if you're that concerned aout security, why are you even using wireless, giving up a degree of physical isolation for defense in depth in favour of electromagnetic broadcast, thereby making it slightly easier for someone to try to hack into your systems?
(Score: 2) by melikamp on Sunday November 02 2014, @05:13PM
I don't think I am increasing my security marginally by refusing to use wireless firmware blobs that originated with vendors who are openly hostile to consumers. If you think using code from someone who is open about being a liar and a cheat poses only a slight security risk, then you failed to grasp my argument. Not providing source for the code that runs on wireless cards is BS, and any such vendor is trying to take advantage of you. No one should trust these vendors, and no system that includes their code deserves to be called secure.
And even though the groupthink labeled me as troll, it is the summary submitter who flame-bated us into this discussion by calling OpenBSD "one the most secure systems". You don't call systems "secure" if no one is allowed to audit them. How hard can this be, people?
(Score: 1) by Techlectica on Tuesday November 11 2014, @09:23AM
Name an "open source" operating system ( or O/S distribution ) that doesn't include any firmware BLOBs for drivers and yet which supports wireless cards.
If you can't point out such a system, then you can't claim that OpenBSD isn't the most secure just because it provides an optional feature which also happens to be included in every possible substitute.
(Score: 1) by Techlectica on Tuesday November 11 2014, @09:28AM
I mean if you're really that paranoid, rebuild the OpenBSD kernel and drivers from source while specifically excluding those BLOB-using drivers that offend you. I haven't done that in over a decade, but I remember that it wasn't that hard after the initial kernel config file set up. It might even have gotten easier since I last did it.
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @01:45PM
Can you please stop skirting the issue? Provide the evidence to back up your claims, or retract them and apologize. Those are your only two options.
(Score: 2) by melikamp on Sunday November 02 2014, @04:59PM
I am not skirting the issue, AC, I am dealing with it straight on, but you can't seem to understand the issue at all. When you get an email telling you to do things in order to receive $10000, what do you do? From what you've been telling me, you must be following the directions and sending your banking info to that nice person, since you can't possibly produce a proof of him lying to you. Do you bring your Apple laptop to the shower too?
No, I'll say it again. Every OS with binary blobs likely contains a backdoor, and none of them deserves to be called secure, just like a safe where you are not allowed to have the only key cannot be called secure. You are the one who keeps skirting this issue of actual security, while you keep talking about my inability to disassemble, which is irrelevant here. I am talking about a very reasonable, very conservative assumption on the part of a user. I am talking about putting zero trust in a hardware vendor that hid the code for no technical reason, and obviously just so that he can insert malware without the users' knowledge. If you think otherwise, you are being a sap, and you are being taken advantage of.
(Score: 2) by tangomargarine on Monday November 03 2014, @03:52PM
Nobody is disputing closed source can have backdoors. They're disputing that it's likely to have backdoors, as you say, and they would shut up if you provided any kind of actual evidence other than "because I believe so."
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by melikamp on Monday November 03 2014, @07:27PM
I understand this very, very well, and I keep saying to them, dismissing this assumption is border-line idiotic. It may have been feasible to get by on faith 20 years ago, but the times have changed. ACs argue like they didn't read any news the last 10 years. Why don't we also let pharmacists sell us untested mystery drugs? The only difference between these two kinds of fraud is that the latter one we've made illegal. The same should be done for the blobs, and in the meanwhile, ACs are drinking snake oil. And you know what? I am sad they are hurting themselves, but that's not why I am yelling at them here. What gets me into the mood is their audacity to declare this snake oil "one of the most effective cures". If they can't give up their blobs, the least they could do is stop spreading (marketing) lies about them. If Theo wrote with big red letters on his site "OpenBSD base contains binary blobs, which cannot be audited by anyone and should be assumed to be malicious", OpenBSD would still be insecure, but at least Theo would come across as someone who respects his users' security.
(Score: 2) by tangomargarine on Monday November 03 2014, @08:34PM
Isn't there like a grand total of exactly one distribution* that is all open code, everywhere, down to the bytecode? That one RMS uses with his open bootloader and open firmware and whatnot. Like he was running gNewSense on an old Dell notebook with special hardware or something.
It's really a choice between idealism and pragmatism. I would love to have a computer that was ethically produced and I fully understand...but I have limited time, money, and brainpower.
https://stallman.org/stallman-computing.html [stallman.org]
* setup...computing solution...however you want to put it...
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by melikamp on Monday November 03 2014, @10:48PM
(Score: 2) by tangomargarine on Monday November 03 2014, @11:32PM
Collusion, okay. But fraud? Did they ever promise to let us see all their source code anywhere?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by melikamp on Tuesday November 04 2014, @12:03AM
Did drug manufacturers ever promise you to conduct rigorous efficacy and safety testing? Oh yeah, they did, because we made them by law. Before that they sold mystery miracle cures with no liability, which is a text-book case of fraud. How's selling mystery software any different?
And so when people have the audacity to call OpenBSD secure, I just have to ask if it went through the most basic kind of security audit one can imagine, whereas a party we can trust simply looks over the source code and tells us "it is not obfuscated and appears to be benign". Am I crazy or paranoid for asking this little for a blob produced by a fraudster? You can read the answers I get in this thread :)
(Score: 2) by tangomargarine on Tuesday November 04 2014, @04:12PM
I don't really disagree with your core argument, but you sure communicated it in the most inflammatory and confrontational way possible. Maybe I've just given up on the idea of purely ethical behavior in an area like the PC industry where our capitalist market discourages such measures (much riskier putting your code out there than locking up your IP, marginal benefits, and almost nobody actually cares).
So what do you use, if even OpenBSD isn't good enough?
And so when people have the audacity to call OpenBSD secure, I just have to ask if it went through the most basic kind of security audit one can imagine
You say "most basic imaginable" and then describe a process 99.9% of products would fail. These concepts would seem to be at odds with each other.
a party we can trust simply looks over the source code
After all this, I'd expect you to say we can't really trust anybody but ourselves (i.e. me personally reading over all the source code I run).
Am I crazy or paranoid for asking
You're not paranoid if they really are out to get you :P After Trusted Computing, and SecureBoot, and NSA Tor hijinks, and, and, and...
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by melikamp on Wednesday November 05 2014, @05:34AM
It is not my fault people freak out when I make trivial judgements like "OpenBSD likely contains malware". Is that what you meant by inflammatory and confrontational? There is no other way to say it though. Users need to be told this. Theo should be telling this to his users, not me.
I happen to use deblobbed Slackware. But actually I would be OK with deblobbed OpenBSD as well.
No, it just shows how fucked we all are. The vast majority of popular products contain malware. Every cell phone is backdoored. Every Windoze and every Mac is backdoored. All popular communication tools are logged by a man in the middle. Yeah, I am aware. Which is why it is of utmost importance to cut the BS and start describing things as they are.
Even the free software, which is the most secure software we have today, it woefully insecure. Our taxes should be paying for developing and auditing by independent panels of experts, but instead we have to trust the good will of unpaid volunteers. But here we have at least a semblance of security, here we can talk about probabilities and rates of getting owned. With blobs, the probability is one for all practical purposes.
(Score: 2) by melikamp on Sunday November 02 2014, @06:08PM
Seriously? I need to apologize? For making a very reasonable (frankly, obvious) assumption about a turd in every blob?
It is Atmel that needs to apologize, and it can only do so by releasing complete source code with docs. It is the maintainers of OpenBSD who need to apologize. Not to me, but to their users, for making the user security an afterthought, since working with sleazy wireless adapter vendors and "supporting" their black-box cards happens to be convenient for the devs. I wonder, if the proof you guys are clamoring for was indeed discovered, would Theo go on record and apologize to his users for being a moron who trusted an obvious cheat? Or would he wash his hands and say "Atmel's fault, not mine"? Would you apologize to me for flaming my very simple, very straightforward security argument? Would you appologize to users who read your rants, believed you, and got served malware as a result?
Sheesh....
(Score: 1) by Jesus_666 on Sunday November 02 2014, @02:10PM
For that matter, your mainboard most likely runs on some version of BIOS, Open Firmware or EFI. How can you be certain that part of you system isn't compromised? Have you checked the source code yourself to ascertain the absence of possible backdoors? How about the source code and machine code of the compiler used to build it? What about your CPU and the mainboard? Could they have attack code in hidden ROM somewhere? Besides, as far as I can tell neither Intel nor AMD provide the sources for their processor microcodes so those could be malicious as well.
Everyone needs to start trusting their equipment at some point because it's not reasonable to put every chip in the system under an electron microscope to look for potentially malicious circuits. You appear to trust hardware but find software automaticaly malicious unless you can read the source code. Most people, however, decide that if they already trust the manufacturer of their hardware to make non-malicious hardware they can also trust them to make non-malicious firmware. If the manufacturer's firmware can't be trusted, why should one trust the hardware?
So no, most people don't see how OpenBSD is automatically backdoored just because they decided that Atmel hardware and firmware is probably not malicious. Besides, unless repeatedly seeing misconduct from a company, most people still subscribe to "innocent until proven guilty" because the opposite would be impractical to the point of making it impossible to operate a computer.
(Score: 2) by melikamp on Sunday November 02 2014, @05:27PM
Demanding vendors to release internal source and docs would not make it impossible to operate a computer. I know that's what people think, but they are plainly wrong, and OpenBSD devs are wrong to ignore the issue. At this point in history, this is similar to giving a presumption of innocence to a Nigerian prince who wants to send you money in exchange to some bank account info. How many times do I have to respond to the idiotic statement "if we can't disassemble it, it's probably secure"? If you can't disassemble it, it's the very definition of insecure. It is, in fact, likely to be intentionally malicious. Just think about the vendor's most likely motivation.
(Score: 2) by maxwell demon on Sunday November 02 2014, @10:24PM
The vendor would probably just put the software in some ROM on the device, making absolutely no practical difference (the blob would still be executed, just its distribution method would be different).
No wait, what the vendor would actually do is say "I don't care about OpenBSD; if you don't want my blob, then just live with the device not being supported on that system."
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by melikamp on Monday November 03 2014, @12:31AM
That's perfect for the user, unless the user enjoys being taken advantage of. It would also produce an OS that we can honestly call secure. May be it wouldn't be an OS for everyone, but it least it would be secure. OpenBSD isn't.
(Score: 1) by Jesus_666 on Monday November 03 2014, @01:23AM
As or the rest: Demanding source code is different from obtaining it. If you can't obtain the source code you still can't trust the firmware, thus you can't use the component. It seems likely that Intel and AMD have already been asked for their microcode sources and haven't provided them (as evidenced by AMD K8 microcode having been reverse-engineered, something that wouldn't have happened had AMD provided it). This means that Intel and AMD processors are untrustworthy, restricting you to platforms such as OpenSPARC. Which you'd have to etch yourself unless you want to open yourself to possible risk.
Or do you use COTS hardware? In that case, why is Intel/AMD trustworthy enough to put their proprietary blob between you and the metal but Atmel isn't? How do you distinguish between inherently trustworthy and inherently untrustworthy components or companies?
As for the most likely motivation: Trade secrets and licensing agreements. For instance, GPU drivers tend to include licensed technologies (S3TC support comes to mind) which the manufacturer is not allowed to distribute in source form. Another reason for closed-source firmware is that the manufacturer doesn't want competitors to see how they implemented certain things – not to hide malicious code (a huge liability if discovered) but to maintain a perceived advantage over competitors who solved the same problems in inferior ways. You could argue that people shouldn't ever use patent-encumbered technologies but the hardware makers would disagree. You could argue that keeping source code as a trade secret destroys customer trust but most customers don't seem to subscribe to that notion.
In the end it runs down to most people assuming that Atmel is not actively out to attack users of their own products and that distro maintainers redistributing Atmel firmware are not willing accomplices to Atmel's hypothetical computer intrusion business. And, of course, the firmware doesn't do anything at all if no corresponding hardware is present in the system, which gives you a pretty good defense against having your computer hacked by Atmel.
That's why everyone else in the thread argues that the presence of closed-source firmware in the OpenBSD package tree is not a big deal.
(Score: 2) by melikamp on Monday November 03 2014, @07:51PM
I understand this, and I am OK with the fact that for most people, it's not a big deal. All I want is for these people to stop spreading marketing propaganda and call this dung secure. I don't want people to be ashamed of using blobs, just like I don't want them to be ashamed of using tobacco. But they really cross the line when they start advertising them to others as the best thing since the sliced bread.
How do you distinguish between inherently trustworthy and inherently untrustworthy pharmacists? When you have a serious illness, or even an annoying symptom, do you use a drug from a manufacturer who REFUSES to list ingredients, REFUSES to go through testing, and PROMISES TO SUE you if you dare to make sense out of it? I hope not, because that vendor is obviously selling snake oil, and he doesn't care if it kills you, as long as he can escape all liability. How is the blob different in this situation? It's the same basic fraud, only it happens to be legal for the time being.
You are buying this story? It is coming the the marketing department of a company engaged in a fraud. How come other companies are able to do it, damned? How come FSF keeps certifying more and more hardware, and would certify even more if only they had resources? Obviously it's possible to produce free and open-source platforms, but vendors can simply make more money by lying to users, defrauding them, and exploiting them. Why are you defending this scum? A wireless card manufacturer makes its money when it sells you a card, which is a physical object. If they cannot survive in the free market by manufacturing a quality chip, no one will cry over it. We all know everything they say about patents and copyrights is BS and lame excuses, because patents and copyrights have no practical purpose except distorting the market, censoring, and stiffing innovation.
(Score: 3, Informative) by FatPhil on Sunday November 02 2014, @12:27PM
>> That's quite the accusation.
>> Do you have any proof other than the existence of a binary blob to back this up?
> What do you mean by proof?
He means "proof". A set of agreed-upon presumptions, followed by a set of deductions (inductive, rather than deductive, reasoning would be sufficient for a "likely" claim) from those presumptions which lead to the conclusion that OpenBSD has a backdoor.
We appear to have one presumption agreed upon, the existence of a blob, but after that, your deductive and inductive reasoning has been entirely absent, even when pressed for it.
Inductive reasoning from the above supports a conclusion that you indeed do not have a proof.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by melikamp on Sunday November 02 2014, @04:46PM
(Score: 2) by FatPhil on Sunday November 02 2014, @05:21PM
From what I actually wrote, you can equally validly conclude that I will fuck you in the arse with a red hot pitchfork. Laughing the whole time.
You are absolutely logic-proof. Bye-bye.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by melikamp on Sunday November 02 2014, @05:40PM
I think you meant to answer "no", but may be it began to dawn on you that I am right, so you decided to use more flowery language?
What is your basis for trusting Atmel? Why do you assume good will there? Because your argument is precisely "I cannot disassemble this software, I don't know what it does, but I will use it because I am certain Atmel would never serve malware on purpose". Can you think of most likely reasons why a wireless card manufacturer won't let you see the source code? Can you think of some perfectly legal ways in which the vendor, a for-profit company, can increase its profit or market position by selling you out or by striking a deal with law enforcement?
WTF does logic have to do with this argument? What is the logic you use when you get a money offer from Nigeria? Can you apply the same logic to this situation?
(Score: 2) by maxwell demon on Sunday November 02 2014, @10:36PM
Putting Atmel hardware in your computer is already trusting Atmel. If I were producing hardware and wanted to exploit customers' machines, I wouldn't hide the exploit in the firmware blob which, despite being binary, can be disassembled and analysed. I would put it directly in the hardware.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by melikamp on Monday November 03 2014, @12:56AM
This is not relevant for my argument either. The manufacturer registers as a severe dickhead on my scam radar as soon as it refuses to provide source code for software that will run in my computer. This is a move so openly hostile to us, the users, I cannot believe people are still reaching for their wallets, let alone try to seriously argue that the vendor is probably benign.
You are grasping at straws, anyway. It is far less likely that a vendor will burn a backdoor into the chip, as it will be harder to conceal (what if some honest engineer leaks it?), impossible to remove, and the reputation damage will be orders of magnitude greater. It is also impossible for the vendor to burn a backdoor into the chip after you bought it, but it is trivial to distribute a firmware update the moment FBA or NSA find any bogus excuse to tap someone (or, as it stands, everyone).
We can talk about quantifying the risk when using chips with open specs and complete free software support. I admit, the risk is still there. You seem to be saying though, it's the same as using a chip manufactured by a known scumbag whose business strategy centers around fucking the users. This is just plain blindness, like signing a contract before you read it. ACs refuse to engage me, but may be you can answer this: will you take your Apple computer to the shower with you without duct-taping the webcam? Will you advise it to everyone as something that is safe to do? If yes, then you have no idea what security is. If no, I'd like to hear why, and how the same explanation does not apply to wireless firmware or any other code that runs inside your computers. I am sure you have absolutely zero proof that some Apple rep is watching you, but you nevertheless reach an obviously correct conclusion that the risk is enormous.
(Score: 2) by maxwell demon on Monday November 03 2014, @08:38AM
Since I don't own an Apple computer, I certainly wouldn't be able to take it to the shower even if I wanted. Anyway, even if I had one, it would probably be a too expensive item to risk ruining it in a shower ;-)
OK, but let's assume you took a more reasonable example, like leaving the computer running with the camera pointed at your bed while you make sex.
No, I wouldn't do it. What's different about the driver? Well, the difference is that it as long as you don't have the hardware, it is dead code. So if I decide that I don't trust the company (why I decide that is completely unrelated to this; I might well decide not to trust it because it requires binary blobs), I can just decide to not buy any of their hardware, just as I decide not to buy anything from Apple. And if I don't have the hardware, the blob is nothing but a random collection of bits that cannot do any harm, so there's no harm in having it lying around.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by melikamp on Monday November 03 2014, @07:11PM
So you are saying now, even if we knew for a fact that the blob is backdoored, you would still call OpenBSD a secure OS? Because under some circumstances the blob isn't active? You would call an OS with a known backdoor a secure OS? Just like you are happy to call it secure now, even though OpenBSD is knowingly distributing mystery code from a party which we know is hostile towards users? Is this some kind of sick joke, or are you serious? I am beginning to think that you, just like all the ACs here, do not understand what security means.
You don't call an OS secure when it comes with a backdoor, or when there is a reasonable assumption that it might, an assumption based on a very educated guess about the vendor's motivations. You call it an insecure POS. The fact that you can plug the backdoor by refusing to use a certain chipset is irrelevant, just as it is irrelevant that you can simply refuse to use the OS in the first place. If you took OpenBSD, cut out proprietary firmware, and then put it up back onto the Web, NOW you would be distributing a secure OS, and that's exactly what Theo (and Linus, and all the self-respecting projects out there) are ought to do if they still give a damn about their users.
(Score: 2) by FatPhil on Monday November 03 2014, @08:54AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by melikamp on Monday November 03 2014, @11:01PM
I understand exactly what you are saying, but you don't understand me at all. What makes the blob untrustworthy is it being distributed by a vendor who is engaged in a fraud. Will you address this issue or just keep calling me names? What do you do when a drug maker sells you a drug, but refuses to tell you ingredients, refuses to let you test it out of your pocket, forbids you to modify it, and promises to sue if you analyze it and tell others about it? This is a fraud, and the drug is snake oil, and if you are willing to take it, then your understanding of security is so broken, you are missing parts responsible to help your self-preservation.
What if it's not a drug but a pacemaker with a computer chip? How do you fail to reach the same conclusion? The vendor is defrauding you, and you would probably be safer without the chip.
What if it's a wireless card? The vendor is defrauding you again, but you seem to be OK with it for no reason other than it is happening to everyone for the last 25 years.
(Score: 2) by maxwell demon on Sunday November 02 2014, @10:29PM
So you will compile and run a program a stranger sends to you as source code?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by melikamp on Monday November 03 2014, @01:12AM
(Score: 2) by maxwell demon on Monday November 03 2014, @08:41AM
So you have read and understood all the code of all the programs you're running?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by melikamp on Monday November 03 2014, @07:16PM
(Score: 2) by maxwell demon on Monday November 03 2014, @07:39PM
So how is source code you don't check but just trust the source of any more secure than binary code that you don't check but just trust the source of?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by melikamp on Monday November 03 2014, @11:46PM
But I don't trust Atmel at all, that's my whole point right there. I have zero confidence in Atmel. They are proudly running a scam which happens to be legal. They wouldn't think twice before betraying users' trust. They would just consult their lawyers and figure out if the profit they make by fucking the users can beat the losses they incur in the unlikely event they are caught with no pants on. And the next day OpenBSD users will get a backdoor in the firmware update.
ACs who say we should gamble with our security at these odds are basically saying, it's OK to gamble even though we can't know how the deck is shuffled. The probability of losing is exactly 1 here because we know that the deck is marked and the opponent is a cheat. We may appear to breaking even or even winning at times, but the deck is marked and the opponent is a cheat, so we can rest assured we will lose before we stand up.
(Score: 2) by maxwell demon on Tuesday November 04 2014, @07:37AM
If you don't trust them, then why are you buying their hardware?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by melikamp on Wednesday November 05 2014, @05:21AM
(Score: 2) by maxwell demon on Thursday November 06 2014, @12:31AM
Then this binary blob cannot affect your security.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @04:16AM
Like those other commenters have asked, can you please give us some evidence of what you're saying? If there is some sort of a flaw that you're aware of, you need to let us and the OpenBSD developers know. If there isn't, or if you don't have any evidence, then perhaps you should publically apologize to us, as well as to Atmel and to the OpenBSD developers.
(Score: 2) by melikamp on Sunday November 02 2014, @04:22AM
Yes, the flaw is: they are distributing binary and/or object code software which runs in users' network cards, but we don't know what the software does, because the vendor won't let us. And they, OpenBSD, are fully aware of it, and they are doing it anyway.
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @04:30AM
So if we don't know what the firmware does, how can you seriously make the claim that it's doing harm? It could very well be doing nothing harmful at all.
If you have evidence that the firmware is harmful in some way, then you need to provide it to us and to the OpenBSD developers immediately. You did say that "OpenBSD likely has a backdoor in the default install", which makes it sound like you do have evidence that something is amiss.
Now if you actually don't have any evidence, and all you've been doing so far is unjustifiable fear-mongering, then the responsible thing for you to do would be to acknowledge this, to retract everything you've said so far, and to offer public apologies to Atmel, to the OpenBSD developers, and to the entire SoylentNews community.
(Score: 2) by melikamp on Sunday November 02 2014, @04:51AM
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @01:47PM
The parent asked for proof, not yet more of the avoidance that you've been giving us so far.
(Score: 2) by melikamp on Sunday November 02 2014, @05:16PM
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @10:18AM
Fact? What facts? How much more secure is OpenBSD compared to "normal Linux", SELinux or FreeBSD with the same services enabled?
Please give examples of the services enabled, why and how they would be more secure on OpenBSD.
FreeBSD has jails too. Ubuntu has apparmor.
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @01:49PM
OpenBSD is a lot more secure. None of the other options you listed can honestly say, "Only two remote holes in the default install, in a heck of a long time!" They've all been compromised much more than that, in a far shorter period of time.
(Score: 0) by Anonymous Coward on Tuesday November 04 2014, @12:13PM
First of all, SELinux is a patchset. It includes some features OpenBSD rejects and others that are similar. It is enabled partially in some distros and disabled or worked around in the most popular. FreeBSD has jails, which are -officially- useless according to OpenBSD management. Nothing else. Better hope your vulnerable process is jailed because that is the only security measure in FreeBSD unless you run current which is still behind OSX and Windows.
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @02:13PM
Don't blame the parent who makes a good point but the guy who wrote the summary for this article.
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @02:19AM
Its secure if no one can access it because the new version disabled module loading and you can no longer get your network hardware working.
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @02:32AM
LOL, oh my. The only way you could've been any more wrong is if you'd mentioned something about them integrating systemd.
(Score: 2) by Fnord666 on Sunday November 02 2014, @02:21AM
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @02:38AM
That's an odd thing to say. The different versions of TLS are broken in a number of critical ways, too.
You're basically suggesting that they not offer any sort of communication security at all. I hope you see the idiocy in what you're saying.
(Score: 0) by Anonymous Coward on Sunday November 02 2014, @04:18AM
Wow, that's newsworthy... for 1996, maybe.