|
||||
Quote:
|
|
|||
The old "compromised" program threat is geared more toward a system where an authorized user has replaced/tampered with a frequently used binary (..like the toolchain/compiler).
It's not that easy to introduce such code into a peer reviewed source repository, something complex enough to produce malicious executables would not go unnoticed. There is no doubt that GCC 4.2.1 was recently audited before it was added to the tree, they had to deal with portability problems on several architectures. Also, GCC doesn't actually generate executables.. that's done by the assembler, which receives an assembly representation, anyone can generate this using the -S argument of the compiler. There is no sense discussing this, not unless anyone here has audited.. you'll have to trust that the accusation will be dealt with, or "shut up and hack". |
|
||||
>you'll have to trust that the accusation will be dealt with, or "shut up and hack".
The usual bullcrap-attitude of OpenBSD? It's all about trust and if there is some disturbance, then OpenBSD has a problem. You can live with such an attitude up to a certain degree, but it begins to hurt if the already rather small money flow declines even more. And if there is no money, then OpenBSD finally has to shut up. Such discussions are necessary at least on a certain level, if there is no discussion anymore it's just faith only. And I'm not a religious man. I can follow technology in OpenBSD up to a certain level, I can even follow parts of the source code, I don't want to badmouth it, but I do need every clue about possible threats, so that I'm able to take certain actions.
__________________
use UNIX or die :-) |
|
|||
Quote:
Any discussions we have here won't effect the end results, and no, I'm not saying that we should trust that the developers should resolve the situation, I'm saying that if you're worried about the problem, audit things yourself, otherwise suck it up and move on. |
|
||||
Quote:
That said, there are times to just shut up, but there are also times to discuss. At the moment I don't see any problems in discussing this topic.
__________________
use UNIX or die :-) |
|
||||
Without discussion we would not have such great standards and protocols - RFC (Request for COMMENTS)
__________________
religions, worst damnation of mankind "If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”. vermaden's: links resources deviantart spreadbsd |
|
||||
Apart from that, I've found an interesting article more specific about the matter
http://extendedsubset.com/?p=41
__________________
use UNIX or die :-) |
|
|||
I see we're still claiming 'Only two remote holes in the default install, in a heck of a long time!' - time to revisit this strap line?
|
|
||||
There are two assumptive errors I noted in that article, Oliver:
It is true that cryptographic logic was classed as a "munition" and treated as such by the US Department of State under International Traffic in Arms Regulations (ITAR). Under ITAR, US citizens, or non-US citizens working for US-owned companies are disallowed the export of munitions without permission from the Department. Those who do not follow ITAR can find themselves charged with violating the Arms Export Control Act. This "export" can be defined as any disclosure of any information -- including when attending seminars and meetings outside the US. That the information can already be public (such as found on the Internet) has no bearing on the export. The State Department can find, if they like, the combination of two public documents constitutes a "teaching" and therefore an export of munititions technology. Theo has already emphatically articulated, publicly and in writing, the constraints under which crypto code was developed. No US citizens or non-US citizens employed by US companies worked on the crypto code development. I'm thinking this was published by eWeek or InformationWeek or some other IT journal when the story broke last week, but I cannot find the reference at the moment. I'll look for it when I have time later this week, unless someone else posts a reference to it here sooner. #2 Release data pressures The OpenBSD release cycle is twice yearly. But there is no significant pressure to complete a particular development in time for this cycle. If code is not ready, by in large, it does not go in. Development is conducted in -current, for approximately four months. Then development is intentionally slowed for two months, during which the code is tested heavily, and a release produced. Release dates are flexible, to a degree, and when code is expected but is a little late, releases have been held in order to complete the development. But by-in-large, the project strives for quality over functionality as a culture. |
|
|||
They will probably do so if they find a backdoor. Remember, as of now it’s just an allegation.
__________________
Many thanks to the forum regulars who put time and effort into helping others solve their problems. |
|
||||
Regarding ITAR, Damien Miller (djm@) is the developer who responded publicly:
Quote:
(Like Marsh Ray, Larry Seltzer misunderstood the ITAR rules. Damien referred to Niels Provos making trips to Canada, but did not explicitly state that Damien is a German citizen, or that he was not employed by a US company. AFAIK, Damien is now at Google.) |
|
||||
@jggimi no need to search arround, just read the postings in this thread and you'll find the reference you're looking for:
http://marc.info/?l=openbsd-tech&m=129237675106730&w=2 However, the best way to follow the information: just follow the mailinglists as I do.
__________________
use UNIX or die :-) |
|
|||
For those who might not be keeping up with tech@:
Kurt Knochner (who is not a developer) posted about his own audit of the IPSEC code; in response, Theo posted some more information on the situation. Quote:
__________________
Many thanks to the forum regulars who put time and effort into helping others solve their problems. |
|
||||
The problem with sneaking something into GCC, is you have to maintain it and keep other people from breaking it.
__________________
My Journal Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''. |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Need Help Please About IPsec | wong_baru | FreeBSD Security | 2 | 21st June 2010 08:00 AM |
Securing wifi networks with ipsec/ssh and openbsd | Oko | OpenBSD Security | 4 | 16th April 2009 07:32 AM |
openBSD IPSEC gateway w/WINDOWS XP roadwarrior | s2scott | OpenBSD Security | 7 | 13th January 2009 11:01 AM |
Ipsec freebsd openbsd failure | kasse | OpenBSD General | 3 | 31st December 2008 01:42 AM |
IPsec on openbsd | hitete | OpenBSD Installation and Upgrading | 1 | 12th July 2008 01:57 AM |