The problem is not the other open source projects. It's the commercial Linux and Unix vendors (and other as well) that use all the benefits of OpenSSH, but do nothing in return. To name a few: IBM, HP, Cisco.
However, from a practical perspective my guess is that there are few attacks on Apache/named/dhcp/ftpd/OpenSSH and whatnot that work on Linux that fail to work on OpenBSD, because OpenBSD modified Apache in a way the Apache project wouldn't accept patches back.
This clearly shows how uninformed you are. OpenBSD ships its own version of these tools in the base install, and the differences between the stock version and the OpenBSD version are sometimes big. named and dhcp use privilege separation for example, httpd is chrooted by default, etc. etc.
Your assumption that userland code isn't audited is also false. A large effort has gone into userland, and since auditing is a continuous process, it will go on.
Some examples:
sometimes new classses of attacks are found, and a complete scan of the tree is done for the specific error. Some time ago the whole base tree has been cleaned wrt to strcpy, strcat and sprintf. No more unbounded string operations remain in the tree.
1st: OpenBSD is a developers' system. Having a source code control system is vital to that. Check the OpenBSD goals for details.
2st: It is a question of priorities. The OpenBSD projecty does not want such an important tool (and a networking tool as well) for their development to be of questionable quality. Other posts provide more info why we think GNU CVS is a security hazard.
In "open source" world you would probably have had N fixes from X different people, each claiming that theirs is the best. If you want to see a real open source mess, check out Zaurus - just as an example there is a large number of libSDL ports, each different, each having different problems, each compatible with different games, none fully usable.
This is not how OpenBSD works. There's only one place for official errata, and these patches are published only after carefull scrutiny.
While you may be right for some Open Source projects, the OpenBSD team applies sound engineering techniques.
Is it stable enough to be part of the release? Yes, and according to OpenBSD standards that actually means something.
Will there be bugs? Probably.
Will these bugs affect you? That's for you to try and decide.
Re:OpenBSD 3.6 released
on
OpenBSD 3.6 Live
·
· Score: 3, Informative
MD5 is still safe for the purpose of file digests. The methods published do not allow the attacker to find a collision for a given digest value. Check this FAQ for some details.
Instead of installing bash, I would recommend to use ksh from the base install. For most work, including command line editing, it behaves pretty much like bash.
Also there are reasons not to change the root shell, see the
OpenBSD FAQ.
Re:The BSDs require GPLed code to develop
on
BSD For Linux Users
·
· Score: 1
For details on which GPL'ed tools are part of OpenBSD, for example, see the gnu portion of their cvsweb [gnu.org].
It includes GCC, the binutils (assember, linker and all commands dealing with object files, like nm, ar, etc), the debugger, and many other standard Unix tools such as diff, bc, grep, etc.
Funny you mention diff, bc, grep. These tools have been replaced b, BSD licensed, versions in OpenBSD-current. More to come.
BTW, the link to OpenBSD's CVSweb is wrong. But if you check the repository, you'll see a lot of empty dirs in the gnu subtree.
The summary suggests fupids is imported into the OpenBSD tree.
This is not true. Fupids is work by a single person, who is not an OpenBSD developer. At this point in time, nothing suggests it will be put into the OpenBSD tree.
do the only legal move not involving the smallest disk
Much easier to remember and perform by hand than the various iterative C programs posted. The proof that it works is left as an exercise to the reader...
You cannot copy the bits because you cannot access the memory. The memory is protected by the smartcard. Only if you can authenticate yourself properly to the smartcard's serial interface you can (indirectly) access the smartcard's memory.
The smartcard's memory bus is not exposed to the outside world. Smartcards are relatively tamper proorf, which means that you'll have big problems accessing the memory without destroying the card, if possible at all.
If they are smart, the card only carries a serial number and the actual amount is stored elsewhere (like credit cards)
You are wrong. Like the system used here in the Netherlands it is an off-line system. The card itself stores the bit string representing the money. On-line transcations are too expensive for this type of transaction, which is typically used here for parking fees.
Hacking it may be possible, but is quite difficult. Reasonbly strong crypto is used in these card. The cards carry a smart card that is capable of doing arithmetic functions that are needed for doing the cryptographical computations.
The protocol used for "charging" the cards does work on-line, and needs special terminals that are mostly located at banks.
Oliver Friedrichs, a senior manager with Symantec, said the "SQL" worm was taking advantage of a vulnerability detected six months ago in Microsoft sequel servers, used mainly by companies to store information.
Nice to see they know how to pronounce SQL. OTOH, I still think they do not know what they are talking about.
That only applies to old systems. Newer BIOSes do not have this strict limitation. Acutally reading the text tells you that.
European prices INCLUDE 21% VAT.
The problem is not the other open source projects. It's the commercial Linux and Unix vendors (and other as well) that use all the benefits of OpenSSH, but do nothing in return. To name a few: IBM, HP, Cisco.
Which doesn't mean they do not produce good code. Probably the quality is higher than what you'll see produced by most profesional developers.
Read some of the background articles to learn what the money will be spend on.
Still, it is a good think to clear confidential data when done with it. Because if the page gets reused within the same program, the data may leak.
Swapping isn't a problem on OpenBSD since the swap space is encrypted by default.
Not true. A lot of upstream providers (sendmail, bind and more) have taken diffs submitted by OpenBSD developers. Apache is an exception.
This clearly shows how uninformed you are. OpenBSD ships its own version of these tools in the base install, and the differences between the stock version and the OpenBSD version are sometimes big. named and dhcp use privilege separation for example, httpd is chrooted by default, etc. etc.
Your assumption that userland code isn't audited is also false. A large effort has gone into userland, and since auditing is a continuous process, it will go on.
Some examples: sometimes new classses of attacks are found, and a complete scan of the tree is done for the specific error. Some time ago the whole base tree has been cleaned wrt to strcpy, strcat and sprintf. No more unbounded string operations remain in the tree.
2st: It is a question of priorities. The OpenBSD projecty does not want such an important tool (and a networking tool as well) for their development to be of questionable quality. Other posts provide more info why we think GNU CVS is a security hazard.
This is not how OpenBSD works. There's only one place for official errata, and these patches are published only after carefull scrutiny.
While you may be right for some Open Source projects, the OpenBSD team applies sound engineering techniques.
Quite a generic question, so let's that split up:
MD5 is still safe for the purpose of file digests. The methods published do not allow the attacker to find a collision for a given digest value. Check this FAQ for some details.
Most common reason for a reject is a dup. We'll see....
Check the OpenBSD 3.6 page for other new things in the 3.6 release.
Also there are reasons not to change the root shell, see the OpenBSD FAQ.
Funny you mention diff, bc, grep. These tools have been replaced b, BSD licensed, versions in OpenBSD-current. More to come.
BTW, the link to OpenBSD's CVSweb is wrong. But if you check the repository, you'll see a lot of empty dirs in the gnu subtree.
According to this article.....
The article confuses epoch and ticks. The epoch is a fixed point in time. Ticks is a number of seconds (or other time unit) since the epoch.
This is not true. Fupids is work by a single person, who is not an OpenBSD developer. At this point in time, nothing suggests it will be put into the OpenBSD tree.
Imagine the disk are in a cricle. Repeat:
- move the smallest disk one step clockwise
- do the only legal move not involving the smallest disk
Much easier to remember and perform by hand than the various iterative C programs posted. The proof that it works is left as an exercise to the reader...The kernel has its own set of library functions, aptly named "the kernel library". This kernel library included strcpy() and strcat(), but not aymore.
I'm using it here for some months.
Luckily the summary of the summary (the key facts) is only 2 pages.
The smartcard's memory bus is not exposed to the outside world. Smartcards are relatively tamper proorf, which means that you'll have big problems accessing the memory without destroying the card, if possible at all.
You are wrong. Like the system used here in the Netherlands it is an off-line system. The card itself stores the bit string representing the money. On-line transcations are too expensive for this type of transaction, which is typically used here for parking fees.
Hacking it may be possible, but is quite difficult. Reasonbly strong crypto is used in these card. The cards carry a smart card that is capable of doing arithmetic functions that are needed for doing the cryptographical computations.
The protocol used for "charging" the cards does work on-line, and needs special terminals that are mostly located at banks.
Oliver Friedrichs, a senior manager with Symantec, said the "SQL" worm was taking advantage of a vulnerability detected six months ago in Microsoft sequel servers, used mainly by companies to store information.
Nice to see they know how to pronounce SQL. OTOH, I still think they do not know what they are talking about.