Slashdot Mirror

unionfs was pulled from the openbsd tree last year.

Here are a couple of the removal commits:
http://marc.info/?l=openbsd-cvs&m=111706859725229& w=2
http://marc.info/?l=openbsd-cvs&m=111707147811254& w=2

And here's the why:
http://marc.info/?l=openbsd-misc&m=110226865110477 &w=2

Hence the error "printer on fire" http://marc.info/?l=linux-kernel&m=102893054014512 &w=2

Analogous how? You patent $foo, I independently make something based on $foo, and then discover your patent while bringing it to market (Or, everyone knows $foo, you patent $foo, and then I choose to knowingly disregard your patent). Very different from, I see your patent and duplicate what it says (which is more analogous to your theater example).

They're *supposed* to, but then so it copyright. The question is whether and how well this actually works.

No, that's really ***ing stupid. If I invent/discover something, I *should not* have to make sure nobody's ever thought of it before. Patents are supposed to be for original, non-obvious inventions only, which would not be duplicated without this kind of publication... the thing is, even the existence of "check the patent office to make sure you're clear" (or, "don't check the patent office because you could get sued worse if you know") demonstrates that this is not the case. (It's also useful to note the "idea whose time has come" phenomenon, which leads to even insanely complex things like the integrated circuit being independently invented (and patented) by multiple teams at almost exactly the same time.)

From:

http://marc.info/?l=openbsd-misc&m=117404837006368 &w=2

List: openbsd-misc
Subject: Re: Important OpenBSD errata
From: Theo de Raadt
Date: 2007-03-16 11:40:54
Message-ID: 200703161140.l2GBesJD020460 () cvs ! openbsd ! org

> This is idiotic, a big hole was found and the devs pissed about
> because they didn't want to admit it.

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.

Let's see... the fsck_ffs fix pedro commited a few hours ago. That
fixes a serious problem where fsck fails to spot filesystem
corruption. Should we spend time fully assessing how rare or common
this situation is, and then errata it up the stream as fast as
possible, maybe even consider if there are security risks from such
filesystem corruption? Come on. Yet that is what some non-experts
moan for. They want projects with only a few people (who are doing
this for a hobby) to struggle down these well-defined p