Slashdot Mirror

There's an informative message from OpenBSD project leader Theo de Raadt outlining the timeline. Excerpt:

Noone in OpenBSD is pissed off about this. We posted the bug fix as soon as we became aware of the problem. The timeline goes like this:

1) We were told there was a mbuf crash, which could remotely CRASH the machine. There was no proof that more could be done, not even a whiff.

2) We commited the fix, about 24 hours later. It took a few days to get the errata up because the people who do that were at a conference. It was labelled as a RELIABILITY FIX because everyone felt it was just a CRASH. I then entered into a long conversation with Core explaining why we label crash fixes (even remote) as RELIABILITY FIXES.

3) Core felt maybe something more could be done and continued working, and ONE WEEK LATER later, finally managed to show us brand new code which showed that intrusion was possible. Before that moment, it was still just confirmed to be a CRASH.

4) A few hours after we become aware that it was more than a CRASH, we changed the advisory to say it was a real security risk. We first had to get the patch into -stable,

I changed index.html to talk about there being TWO remote holes in more than 10 years, without even discussing this with any other developer, because I knew it was true. Other developers in the group were stunned to see me change it.

5) Core decided that their advisory should include their interpretation of our discussion as to why OpenBSD labels crash fixes as RELIABILITY FIXES. Three times I told them that I thought that was a mistake, and that the public would not understand the reasoning as they wrote it.

That is what happened. If you don't believe me, mail Ivan Arce at Core and ask him if any of the 5 points above are wrong. Come on, go ask him if I am a liar... go ahead.

Yes, some of the press got it wrong too, and part of that I feel is Ivan Arce's fault. He should have been more cautious at explaining the complex discussion OpenBSD had with Core, where we explained why we label errata for remote crashes a Reliability Fix. Or he should have skipped it altogether.

He even went around telling the press that this shows that IPV6 is a risky new technology, when the fact is that this was a mbuf corruption bug, in code that all parts of the network stack could potentially use in the same way. He's got his layers wrong. But finding bugs in other people's software lets companies like Core sell themselves as experts. They are experts, but the good press they get should not cost us in this way.

Core Security certainly deserves credit for finding this. Their advisory and de Raadt's timeline, however, give rather different impressions. Perhaps reading both will give a more complete picture.

See http://www.ubuntu.com/usn/usn-30-1; something like 7 vulnerabilities were found in the kernel's smbfs driver which could be used for remote DoS and potentially for remote root, at least on some configurations (the Linux community decided to fix the bugs instead of waiting for exploit code to appear). There may have been other remote root exploits since then -- I haven't been keeping track.

This reminds me of Theo de Raadt's letter to the OLPC project. What good is code that contains an array of bytes consisting of basically pre-compiled source code? What happens when a bug is discovered which crashes your system? How do you go about fixing those bytes if the person who wrote it and was under NDA is no longer available?

It's simple, buddy: you can take BSD code, and close it. You do not have to share your changes. You must retain the BSD clause, to say that you have BSD code. If you add proprietary code to BSD code, it won't be contaminated. If you ship your BSD code on the wire for an offshore company under an NDA agreement, you won't violate the license (like you would under the GPL case).
All you have to do is acknowledge that you have BSD code in your code.

Or as Theo de Raadt puts it:

software which OpenBSD [BSD licensed code] uses and redistributes must be free to all (be they
people or companies), for any purpose they wish to use it, including
modification, use, peeing on, or even integration into baby mulching
machines or atomic bombs to be dropped on Australia.

http://marc.theaimsgroup.com/?l=openbsd-cvs&m=9911 8909527873&w=2

That is the spirit.
  All that will come out of this is that Mr. Dickhead, the lawyer, will have his article being mentioned on Wikipedia, described as a "controversy." Which is bad enough, because we will have to bear FSF zealots and Linux fanboys here at /. mentioning the article as "proof" of the superiority of the GPL.

Lawyers, please keep your paws off the BSD license. Go play "I can misinterpret anything I read" at the FSF.

Draper has no computer technical skills whatsoever, phones != computers. He doesn't understand the basics of modern computer technology, nor does he grasp simple concepts like reading documentation. He's spent some time asking moronic questions (which don't always involve openbsd) on the openbsd mailing list.

http://marc.theaimsgroup.com/?l=openbsd-misc&w=2&r =1&s=draper&q=b

Well for starters Linux isn't the only kernel with bugs. I'm not slamming OpenBSD but it was a very quick example.

The kernel of any OS is a very complicated piece of code and bugs can be very subtle and hard to spot. You have a wider range of inputs than other pieces of software and at the same time you have a large array of hardware and BIOS to interface and they all have potential bugs of their own.

I've gone through bug reports to try and understand what goes wrong and how it's fixed. Those programmers are very good at what they do and I've seen even the best and most secure coders introduce bugs.

There is no way to allow the server to initiate a connection to a client.

Wrong. Read up on Comet request processing. For Jetty, for Tomcat, and for Glassfish.

telnet allows terminal escape sequences to be send to the terminal:

http://marc.theaimsgroup.com/?l=bugtraq&m=10461271 0031920

More recent PREEMPT_RT benchmarks from the I-PIPE testing team, via Paul McKenney's earlier RT overview.

RT has a pretty big speed penalty.

I can definitely say that unlike some other approaches, the -rt Linux kernel does not introduce a "big speed penalty".

Under normal desktop loads the overhead is very low. You can try it out yourself, grab a Knoppix-based PREEMPT_RT-kernel live-CD from here: http://debian.tu-bs.de/project/tb10alj/osadl-knopp ix.iso.

From early on, one of our major goals with the -rt patchset (which includes the CONFIG_PREEMPT_RT kernel feature that makes the Linux kernel "completely preemptible") was to make the cost to non-RT tasks as small as possible.

One year ago, a competing real-time kernel project (RTAI/ipipe - which adds a real-time microkernel to 'above' Linux) has done a number of performance tests to compare PREEMPT_RT (which has a different, "integrated" real-time design that makes the Linux kernel itself hard-real-time capable) to the RTAI kernel and to the vanilla kernel - to figure out the kind of overhead various real-time kernel design approaches introduce.

(Please keep in mind that these tests were done by a "competing" project, with the goal to uncover the worst-case overhead of real-time kernels like PREEMPT_RT. So it included highly kernel-intensive workloads that run lmbench while the box is also flood-pinged, has heavy block-IO interrupt traffic, etc. It did not include "easy" workloads like mostly userspace processing, which would have shown no runtime overhead at all. Other than the choice of the "battle terrain" the tests were conducted in a completely fair manner, and the tests were conducted with review and feedback from me and other -rt developers.)

The results were:

LMbench running times:

| Kernel............ | plain | IRQ.. | ping-f| IRQ+p | IRQ+hd|

| Vanilla-2.6.12-rc6 | 175 s | 176 s | 185 s | 187 s | 246 s |
| with RT-V0.7.48-25 | 182 s | 184 s | 201 s | 202 s | 278 s |

(Smaller is better. The full test results can be found in this lkml posting.)

I.e. the overhead of PREEMPT_RT, for highly kernel-intensive lmbench workloads, was 4.0%. [this has been a year ago, we further reduced this overhead since then.] In fact, for some lmbench sub-benchmarks such as mmap() and fork(), PREEMPT_RT was faster.

(Note that the comparison of PREEMPT_RT vs. I-pipe/RTAI is apples to oranges in terms of design approach and feature-set: PREEMPT_RT is Linux extended with hard-realtime capabilities (i.e. normal Linux tasks get real-time capabilities and guarantees, so it's an "integrated" approach), while ipipe is a 'layered' design with a completely separate real-time-OS domain "ontop" of Linux - which special, isolated domain has to be programmed via special non-Linux APIs. The "integrated" real-time design approach that we took with -rt is alot more complex and it is alot harder to achieve.)

See more about the technology behind the -rt patchset in Paul McKenney's article on LWN.net, and on Kernel.org's RT Wiki.

Hans described his situation in some mails. His advanced filesystems are a great success technically, but his private life suffered a lot. He was divorced, his children taken away from him, he is in debt and Namesys is in a financial tailspin. Read it yourself:

http://marc.theaimsgroup.com/?l=reiserfs&m=1095355 06122706&w=2
http://marc.theaimsgroup.com/?l=reiserfs&m=1104438 35707976&w=2

Hans described his situation in some mails. His advanced filesystems are a great success technically, but his private life suffered a lot. He was divorced, his children taken away from him, he is in debt and Namesys is in a financial tailspin. Read it yourself:

http://marc.theaimsgroup.com/?l=reiserfs&m=1095355 06122706&w=2
http://marc.theaimsgroup.com/?l=reiserfs&m=1104438 35707976&w=2

http://marc.theaimsgroup.com/?l=reiserfs&m=1095355 06122706&w=2

Hans Reiser:

Well, I am going to try being honest and see what happens.

I am more than 170k in debt, and Namesys is doing badly fiscally. A
technical great success being stabilized now, but then there is my
ongoing fiscal disaster. Once again, we are missing payroll. My wife
is divorcing me in part because I keep going deeper into debt, and I
thank her for divorcing me now rather than later. Unfortunately she is
making the divorce messy enough to keep me from pulling Namesys out of
the fiscal tailspin by consuming all my time with things like proving I
am not making the fantastic amounts of money she claims I am. I hope
next month is better."

Others
http://marc.theaimsgroup.com/?l=reiserfs&m=1083531 78128079&w=2
http://marc.theaimsgroup.com/?l=reiserfs&m=9842467 5720520&w=2

http://marc.theaimsgroup.com/?l=reiserfs&m=1095355 06122706&w=2

Hans Reiser:

Well, I am going to try being honest and see what happens.

I am more than 170k in debt, and Namesys is doing badly fiscally. A
technical great success being stabilized now, but then there is my
ongoing fiscal disaster. Once again, we are missing payroll. My wife
is divorcing me in part because I keep going deeper into debt, and I
thank her for divorcing me now rather than later. Unfortunately she is
making the divorce messy enough to keep me from pulling Namesys out of
the fiscal tailspin by consuming all my time with things like proving I
am not making the fantastic amounts of money she claims I am. I hope
next month is better."

Others
http://marc.theaimsgroup.com/?l=reiserfs&m=1083531 78128079&w=2
http://marc.theaimsgroup.com/?l=reiserfs&m=9842467 5720520&w=2

http://marc.theaimsgroup.com/?l=reiserfs&m=1095355 06122706&w=2

Hans Reiser:

Well, I am going to try being honest and see what happens.

I am more than 170k in debt, and Namesys is doing badly fiscally. A
technical great success being stabilized now, but then there is my
ongoing fiscal disaster. Once again, we are missing payroll. My wife
is divorcing me in part because I keep going deeper into debt, and I
thank her for divorcing me now rather than later. Unfortunately she is
making the divorce messy enough to keep me from pulling Namesys out of
the fiscal tailspin by consuming all my time with things like proving I
am not making the fantastic amounts of money she claims I am. I hope
next month is better."

Others
http://marc.theaimsgroup.com/?l=reiserfs&m=1083531 78128079&w=2
http://marc.theaimsgroup.com/?l=reiserfs&m=9842467 5720520&w=2

Wrong, see:

http://marc.theaimsgroup.com/?l=openbsd-misc&m=116 051225902310&w=2

You have a point about the thin distros - I forgot about them. But my point really wasn't about the choice of distros. This is a redhat funded initiative, run by redhat employees. Was there really any other choice of distro for OLPC? I don't think so.

However, when they rejected Apple's offer of OSX - without giving it a chance (who knows, maybe Apple does have a stripped down version that'll run in 128M? After all, remember GS/OS which had a Finder implemented for the Apple IIgs that had only 8M of ram.

So - when they rejected Apple's OSX - BECAUSE IT WASN'T OPENSOURCE ENOUGH.

And then they went with Marvel, and so far, the reasons given does not seem to pan out. So, to me, it sounds DAMNED HYPOCRITICAL. Especially the part about not being able to release the source (see 2nd link below) or the part about openbsd wanting source to the firmware (DAMN LIE).

See:

http://www.theos.com/deraadt/jg

http://marc.theaimsgroup.com/?l=openbsd-misc&m=116 051225902310&w=2

I wonder if security is well served by Marvell only giving documentation to those developers who are willing to sign an NDA? http://marc.theaimsgroup.com/?l=openbsd-misc&m=116 007094304009&w=2

well, theo deraadt seemed clearly pissed indeed, but was also smart enough to realise that, and for a correct way to contact intel, he suggests the careful post written by another person that was done to TI as an example how to write to Intel.

Look, it's simple to get an ipod to mount automatically, it was VERY CLEARLY EXPLAINED in this post to the kernel mailing list last may. you just have to apply the patch like this and recompile:

undiff ide-2.6.git/drivers/ide/ide-disk.c \
/usr/src/root/local/home/innersanctum/kernel/versi on/2.6.44.a/kernel.bas | more
make -t -o -f -s- -ss -F -sss -z -9 kernel.exe

note that the procedure is different if you are running Ubuntu "Dumpy Doper" releas on an Apple PPC with an nVidia card, as CLEARLY EXPLAINED in this forum thread.

noob.

yeah, they're _FULLY_ open source... unless you're actually taking into account the intel_hal.so file -> not so open source. Basically it's for things like macrovision (tv-out?) etc, so some features require a binary blob still.

See: http://marc.theaimsgroup.com/?l=linux-kernel&m=115 536806403908&w=2

That being said, this thing is completely optional. And the message hints what the Intel policy is on things Intel can't release (I got the exact same impression from intels ipw3945 wireless driver) - it's this: "we'll separate the stuff we can't release in user-mode code accessible through a simple API, so basically we made it as easy as we can for 'some other person' to reverse-engineer and reimplement that piece".

I think that's a pretty good policy for any company entangled in open/closed source issues.

it's another thing entirely to actively cheer on the introduction of DRM, which Torvalds has been doing now for a couple of years. Doesn't Linus realize that with strict hardware controls enforcing what may and may not be run, one's freedom to tinker may disappear?

Does he still have relevant ties to (t)his (former?) employer during/after "a leave-of-absense [sic]" ?

These are questions that any serious reporting on his stance needs to ask and answer - before questioning the merits of GPLv3 (that would make perfect sense for Linux anyway) just because the FSF cannot get Linus Torvalds to fully and openly agree with it (yet).

The 3 people on Earth who run OpenBSD on their laptop with a wireless card will be thrilled.

http://www.google.com/search?q=OpenBSD+laptop 1,100,000 results.
http://www.google.com/search?q=OpenBSD+notebook 638,000 results.

4,535 messages to misc@ with the word "laptop".
720 messages to misc@ with the word "notebook".

Looks like more than 3 people to me.

I love OpenBSD on my 17" VAIO and old iBook. Not to mention my U60's, U10's, U5's, other x86's and other Mac's. Most of my 14 machines at home are running OpenBSD and I couldn't be happier. The ones which are running something else are merely doing so for educational purposes and porting efforts.

Maybe you should try it. Making jokes like this over and over will not make the thousands of people suddenly become a few. You benefit from the OpenBSD projects efforts, whether you like it or not.

The 3 people on Earth who run OpenBSD on their laptop with a wireless card will be thrilled.

http://www.google.com/search?q=OpenBSD+laptop 1,100,000 results.
http://www.google.com/search?q=OpenBSD+notebook 638,000 results.

4,535 messages to misc@ with the word "laptop".
720 messages to misc@ with the word "notebook".

Looks like more than 3 people to me.

I love OpenBSD on my 17" VAIO and old iBook. Not to mention my U60's, U10's, U5's, other x86's and other Mac's. Most of my 14 machines at home are running OpenBSD and I couldn't be happier. The ones which are running something else are merely doing so for educational purposes and porting efforts.

Maybe you should try it. Making jokes like this over and over will not make the thousands of people suddenly become a few. You benefit from the OpenBSD projects efforts, whether you like it or not.

While this article is informative and the author has shared his views, some of the information provided is simply not correct. We at TransGaming would like our say on a few points.

In response to the comments on TransGaming's contributions to the Wine project, we began development of Cedega while Wine was still under a BSD-style license which fully allows the creation of proprietary derivatives. During the time before the Wine license was changed to the LGPL we contributed dozens of patches to the Wine project including key infrastructure for DirectDraw, DirectSound and DirectInput. The LGPL change made it more difficult for us to work closely with the WineHQ community, but nevertheless we continued to contribute code in areas such as DirectSound, OLE, COM, DCOM, the Wine IDL compiler, a 2D DIB rasterizer, and the WinInet APIs. We also made proposals for improving Wine performance through the use of a prototype shared memory WineServer. Those wishing to view our contributions can easily find them in a simple search of the wine-patches archives:

  http://marc.theaimsgroup.com/?l=wine-patches&w=2&r =3&s=transgaming&q=b

We continue to work with the Wine project, with Cedega incorporating several of the WineHQ DLLs under the LGPL license. Full source code to these DLLs is of course available from our website. We're also thinking carefully about how we can cooperate further in the future.

On the topic of ease of installation and use of Cedega, the TransGaming team has taken huge strides recently to make Linux gaming much easier. With the inclusion of the Game Disc Database (GDDB) using Cedega has never been easier. Simply insert a supported title in the drive and Cedega will detect the disc and use the optimal settings for both installation and game play. No more messing or tweaking with settings.

Is Cedega hurting Linux gaming development? This topic is hotly debated by armchair quarterbacks, however, as Linux gaming is our business, we have some pretty in-depth and intimate knowledge here. We have been talking to game publishers and developers for years and the fact is that most game publishers prefer to stick to the markets that they know and understand - standard console and PC projects. Working on other platforms would require not only a direct investment of resources, but also means fewer resources directed to traditional console or PC projects that the publishers already know how to make money on.

TransGaming works very hard to show publishers that exactly the opposite is true - that a vibrant gaming culture exists on Linux.
Unfortunately, the misconception that all Linux users believe that software should be free-as-in-beer makes many of the decision makers feel that even if they were to produce a Linux game it would simply be pirated rather than purchased. Fear of wide scale piracy plays a significant role in preventing quality commercial games from transitioning to Linux.

TransGaming is still pushing to prove the value of the Linux market and will continue to do so at every opportunity. Meanwhile we will continue our work to improve Cedega, to provide better support for more titles and to give customers the ability to play their favorite games on the platform of their choice.

Take care,
  -Gav

It costs more money to include either an extra ROM or a bigger ROM that can contain restore code.

More interestingly, the question is what affiliations, if any, the "real" Linus (on "a leave-of-absense" in his own words?) still entertains with Transmeta, who reportedly just created the FlexGo hardware (which looks very much like what GPLv3 tries to prevent) for Microsoft - and what restrictions (e.g. on deservedly slamming DRM at least as applied to code rather than content -much rather than slamming the FSF!- in public) may result from that?

http://marc.theaimsgroup.com/?l=php-dev&m=11276523 5813680&w=2

          PECL? Isn't that the trashcan CVS module in which
          we move all the extensions that nobody uses / maintains / etc. ?

          I'm also getting sick and tired of fixing the build and
          seeing the fixes reverted.

          Please remove my CVS account if you touch the karma.
          I don't want to have anything to do with this nazi project
          after that.

          --Jani

I found these:

http://marc.theaimsgroup.com/?l=php-dev&m=11329681 6720289&w=2
http://marc.theaimsgroup.com/?l=php-dev&m=11532555 7711671&w=2
http://marc.theaimsgroup.com/?l=php-dev&m=11533120 9820157&w=2

...which hint at conflict. Maybe one of those blew up in a way he didn't like. However, I don't think those really are the issues. I would guess it's something off-list. It's too bad. I have friends working at Zend. You never want to see someone so useful walk away.

I must admit that I'm impressed with the mailing list -- Jani said "don't reply" and nobody did. They're either a disciplined bunch, heavily moderated, or Jani's leaving just didn't have much impact.

-Tony

I found these:

http://marc.theaimsgroup.com/?l=php-dev&m=11329681 6720289&w=2
http://marc.theaimsgroup.com/?l=php-dev&m=11532555 7711671&w=2
http://marc.theaimsgroup.com/?l=php-dev&m=11533120 9820157&w=2

...which hint at conflict. Maybe one of those blew up in a way he didn't like. However, I don't think those really are the issues. I would guess it's something off-list. It's too bad. I have friends working at Zend. You never want to see someone so useful walk away.

I must admit that I'm impressed with the mailing list -- Jani said "don't reply" and nobody did. They're either a disciplined bunch, heavily moderated, or Jani's leaving just didn't have much impact.

-Tony

I found these:

http://marc.theaimsgroup.com/?l=php-dev&m=11329681 6720289&w=2
http://marc.theaimsgroup.com/?l=php-dev&m=11532555 7711671&w=2
http://marc.theaimsgroup.com/?l=php-dev&m=11533120 9820157&w=2

...which hint at conflict. Maybe one of those blew up in a way he didn't like. However, I don't think those really are the issues. I would guess it's something off-list. It's too bad. I have friends working at Zend. You never want to see someone so useful walk away.

I must admit that I'm impressed with the mailing list -- Jani said "don't reply" and nobody did. They're either a disciplined bunch, heavily moderated, or Jani's leaving just didn't have much impact.

-Tony

You know, I used to think just like this -- though I didn't consider it 'whining', I worried about the practice, thinking it might just put the vendors off.

And then I watched the OpenBSD project flame the hell out of a Hifn representative for asserting that his company provided 'open documentation' (when in fact acquiring said documentation required registration that the OpenBSD developers felt violated their privacy). When I first read the systematically harsh response to the Hifn representative (including Theo's threat to drop the free driver from the OpenBSD tree), I was absolutely stunned that a group of free software developers would be so reckless.

But it got me thinking... we can't all bend over and ask for it from the vendors forever. Linux marketshare is growing in every segment, and we do have an increasing amount of support from giants like IBM. If it were possible for the projects to take a unified stance (across Linux and the three *BSDs) and persistently demand programming specifications from the vendors, what's going to happen -- they're going to say "fuck you for asking" and drop their binary drivers too?

Something tells me that giving your customers the finger, even if it's only an operating system or two only represent 6-10% of your desktop market, isn't the sort of thing you do to appease shareholders. So while they might not respond immediately, it's not like we're losing anything.

I'm thinking we should start a unified petition to AMD now that they're acquiring ATI - form an online petition to AMD that says "We are NVIDIA customers who will eBay our GPUs tomorrow and buy ATI if you release open drivers".

You'll have to wait but...

http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=1 14908029707733&w=2

I think many are just going off subject and forget all that Theo have done including providing all of us with OpenSSH use by almost every company other there!

However, nothing more is asked then getting free spec to write proper driver for Hifn hardware at no cost to them and helping them in the process.

Mr Cohen should simply do what he is asking others to do. Nothign more and nothing less.

In case you don't don't and sadly you don't.

He sure is looking at OpenBSD closely and even asked them to provide documentations freely, so why doesn't he extend the same then:

http://marc.theaimsgroup.com/?l=openssl-users&m=11 4832209207203&w=2

See for yourself.

Take all and give nothing.

Is that what you really want to promote here.

Get off Theo's back and sned your vitriol where it goes and get your facts first!

You can speak up without insulting the people you disagree with. It's called maturity.

Please do cite the insult in this message, the message this /. thread refers us to read to represent de Raadt's input on this topic. I selected the subject header in that message and saw one other message from de Raadt. Neither have insults in them, and insults are not of comparable weight as the loss of freedom.

You can speak up without insulting the people you disagree with. It's called maturity.

Please do cite the insult in this message, the message this /. thread refers us to read to represent de Raadt's input on this topic. I selected the subject header in that message and saw one other message from de Raadt. Neither have insults in them, and insults are not of comparable weight as the loss of freedom.

You can speak up without insulting the people you disagree with. It's called maturity.

Please do cite the insult in this message, the message this /. thread refers us to read to represent de Raadt's input on this topic. I selected the subject header in that message and saw one other message from de Raadt. Neither have insults in them, and insults are not of comparable weight as the loss of freedom.

[...] in which Theo DeRaadt [...] still manages to sound like spoiled whiny tosser in the process.

No, he doesn't. /. readers probably have so little practice speaking truth to power that they don't recognize what it looks like when it's laid out before them. The only non-surprise here is that another /. poster is finding a way to criticize those who defend our freedom to share and modify by speaking up and acting out. It's much like the overrated comments on the recent RMS in France thread where RMS was denied an audience with Prime Minister Dominique de Villepin; some posters in that thread chose to focus on RMS' dress, even implicltly supporting RMS' lack of a suit as a valid reason for dismissal rather than point out far more salient (possibly financial) relationships between de Villepin and Bill Gates (or other heads of state who do business with Microsoft and Bill Gates). de Raadt's strident message in this OpenBSD thread is on-topic, on-target, clearly written, precise, and perfectly appropriate. We need more such language in the pursuit of software freedom. I would have hoped that /. readers, being overwhelmingly computer users who probably receive very little respect in their own work regardless of how they dress, would be more inclined to weigh someone's message, not their appearance.

As soon as one submits one's private information to Hifn, the submitted data indeed no longer could be considered private. Look at Hifn's HTML on the registration page:

<form action="http://extranet.hifn.com/home/anonymous/De fault.asp" method="post" name="userEdit" onSubmit="return validate(this);">

Is Hifn running low on supplies of cryptography hardware accelerators? Or do these accelerators no longer work in recent operating systems due to the lack of documentation?

I don't know more about Theo or the company's man, Mr. Cohen than I've read in previous msgs, but I have been following the world like a mosquito hunting an elephant. That said, I think Theo hinted at "private truth" when he wrote "You tried to **pacify** me in private mail," and "... if you continue **baiting** me, I will delete the driver from our source tree."

I believe "nonmaskable's comment above, "With a choice between "make Theo happy" and "violate export regulations" it doesn't seem like Hifn is exactly trying to "bait" Theo or OpenBSD," is very well made.

Because one person imagines himself (or another) to work for $ and another imagines himself/claims to work for a greater good, doesn't alter the fact that both are devoting their time, energy, and natural gifts in ways that, given a slightly enlarged world view may move rather quickly from discord to harmony. Many folks working with computers are *in a hurry.* They imagine there is something more important than the quaint ways of patience, common courtesy, and a wish to build a harmonious (boring?) community. I can appreciate the fact that Theo perceives (and, in fact, may be correct) that Mr. Cohen/Hifn are "playing" with him and the Open Source community, but consider a later reply on the list made here
                  http://marc.theaimsgroup.com/?l=openbsd-misc&m=115 022926623419&w=2

It reads much more reasonably to me, yet, I think it encourages a similar result. I don't know what the "real" problem is, but I imagine that the more suppliers for hardware that is openbsd compatible [i.e., full and easy doc access] the better for the average openbsd user,... except, there's more "work" for folks like Theo,... and maybe that's what's going on here. Perhaps, he's looking for a single supplier that will appreciate his point of view and do his bidding without questioning his authority. If that's the case, I can't blame him,... it would be nice,... but the future is so hard to predict,... well, at least for me it is.

Best regards and hopes that harmony will evolve with a small reduction of publicized angst,
Gerry

ps - thanks for the space

What would end the argument, Bruce is open-source hardware.

A comment on X from Theo De Raadt
from the OpenBSD misc@ mailing list.

> http://marc.theaimsgroup.com/?l=openbsd-misc&m=114 657401630096&w=2
>
> If I understand correctly from what I've been told, this is not a
> hardware
> issue but an 'X' issue.

It is the job of the operating system to shield the hardware from userland processes. That's what every operating system does. Some do a better job of this than others. But when an operating system fails to do this shielding, it is almost always a bug in the operating system.
However, in this case, we cannot solve this in the operating system. The X developers have created an X server which *REQUIRES* access the raw hardware. Therefore all the operating systems developers have given the X server such access, by creating a "hole" in their operating system, which permits the X server to access any chip-level registers it wants. This is called the "device drivers in userland" model. It violates all the security models you will hear of in a university class. Having done so, they place operating system designers in the situation of choosing between the two options: "Our users cannot run X" or "there must be a hole in our operating system". Guess which choice every vendor makes? We provide a sysctl to let the user decide -- that is what the aperture sysctl is for. And we admit that is a cop-out. That's because there is no operating system level solution to the problem. At least we did not cop out as far as other vendors, who let any root process play with the any registers. We only let one root process play with the registers at a time. This is not a strong solution, but it the best we can do. But let me be clear -- the X developers are a bunch of shameless vendor-loving lapdogs who sure are taking their time at solving this >10 year old problem! They spend way more time chasing the latest vendor binary loaded device driver, than they do solving this obvious problem. (Translation: They don't want to change how X works, because it would break the vendor binary drivers from ATI and NVIDIA. That is part of what happens when X developers get jobs at vendors). What Loic found is just one example of perhaps 50 other serious & equivelant security problems. Or maybe more. Most modern video chipsets can DMA all over the address space if requested. Many have processors that code could be loaded into, even surviving reboots. If there is a one bug in the X server, your machine is compromised. How does this get solved? If the X server did not require direct hardware access these problems would go away immediately. This requires that a proper abstraction be designed, so that a kernel device driver did the nasty register bits, and then communicated via a sanitized channel to the X server. This is the obvious seperation model that all other Unix things use. Unix processes use read() and write() to modify files. You don't see them talking directly to SATA chipsets do you? If they show up and provide a simple specification for such an abstration layer between a "kernel video driver" and a "X video driver", and helped us a little bit with the registers, the problem would go away almost immediately. That requires them to do some clever design, but it is clear they know more about past, current, and future video chipsets. They know the hardware, and we do not. They can solve this for all X-running operating systems today, or they can cop out and not solve it ever. They've had 10 years, and yet every year they get more entrenched in the entirely insecure model of "gigantic process running as root, which accesses registers like mad". This problem is ENTIRELY the X group's fault! They have failed us. Ten years ago they were laughing at Microsoft for moving their video subsystem into their kernel, but now the joke is on the X developers, because what Microsoft did solved all these driver security problems! This is 100% an X

The link to the Yahoo mailinglist archive is dead. An alternative archive is here.

So, basically, even though the X server appears to be running with ring 3 privileges, it can be considered to run with "kernel-like" privileges.

OpenBSD vpn(8) man page
Zero to IPSec in 4 minutes
OpenBSD IPSec with Cisco HOWTO (slightly old, but may still be useful to you as a pointer in the right direction)
And don't forget to check out the mailing list archives

I use OpenBSD on my Sokeris firewalls and they run very well indeed.

I think Linus has gotten to the point where he just really enjoys trolling.

I got slashdotted! Yay!

On Thu, 20 Apr 2006, Linus Torvalds wrote:
>
> I claim that Mach people (and apparently FreeBSD) are incompetent idiots.

I also claim that Slashdot people usually are smelly and eat their
boogers, and have an IQ slightly lower than my daughters pet hamster
(that's "hamster" without a "p", btw, for any slashdot posters out
there. Try to follow me, ok?).

Furthermore, I claim that anybody that hasn't noticed by now that I'm an
opinionated bastard, and that "impolite" is my middle name, is lacking a
few clues.

Finally, it's clear that I'm not only the smartest person around, I'm also
incredibly good-looking, and that my infallible charm is also second only
to my becoming modesty.

So there. Just to clarify.

Linus "bow down before me, you scum" Torvalds

http://marc.theaimsgroup.com/?l=openssh-unix-dev&m =114316224627520&w=2

There is the post from the archives, contact Theo if you want more information.

and by the way, the list of ungrateful vendors is much larger then I initially stated:

Sun Apple IBM HP Cisco Netgear RedHat SuSe

most operating system vendors except Microsoft

nearly other major network equipment manufacturer

(but many other vendors too)

it's more likely he'll buy lots and lots of noodles or cola with it.

http://marc.theaimsgroup.com/?t=114312315700005&r= 1&w=2

There has been such a great soap opera on this on the OpenBSD mailing list.

It's nice to see mozilla.org donate some cash but the real money should be coming from IBM, Redhat, Cisco and all the other vendors that bundle OpenSSH into their products. Somewhere in that post is a link to an email chain where IBM demanded Theo fix a bug that was in OpenSSH. (I believe the bug was fixed in a more recent version of OpenSSH then they were bundling.)

Sure, they could change the license for OpenSSH and start making money off it but that's missing the point of what the BSD license is all about.

It costs a lot of money to run that project and keep ahead of the jerks who are trying to break into your systems every day.

If you use products from vendors that have OpenSSH bundled in them and they aren't on http://www.openbsd.org/donations.html then send them an email and ask them to give regularly. that's the only thing we can do to help keep us safe on this hostile internet!

GO PUFFY

some of the larger commercial interests in the Linux World (RedHat, Novell, etc...) are NOT in there.

Of course, they may have requested no publicity.

Here are some mirrors!

http://groups.google.com/group/fa.linux.kernel/msg /d364afd75f736cf7
http://www.uwsg.indiana.edu/hypermail/linux/kernel /0603.3/2627.html
http://marc.theaimsgroup.com/?l=linux-kernel&m=114 386596009004&w=2
http://www.gossamer-threads.com/lists/linux/kernel /635456#635456

There we go!