Slashdot Mirror
Hifn Restricts Crypto Docs, OpenBSD Opens Fire
Mhrmnhrm writes "After totally closing off public access to documentation for their chips roughly five years ago, Hifn is again offering them, but with an invasive registration requirement. Needless to say, Theo de Raadt and the rest of the OpenBSD team were not amused, and following a Hifn manager's missive, the gauntlet has been thrown. Either open the docs fully, or be removed from the system. This wouldn't be the first time... the same thing happened to both Adaptec and Intel following similar spats."
Oi, Theo! I agree with you 100%, but please, tone down the virtiol just a smidge! From TFA:
Calling their products "crummy" and threatening them with driver deletion if they don't stop "baiting" you is not a way to get what you want. Now it means some egomaniacal manager has to eat crow for the driver to go public. I was in 100% agreement with your post until I got to this point.
Sometimes, I wish someone would just slip some sort of tranquilizer in the water supply near Alberta...
>I count 12 required fields where you have to enter data.
>Is this worth throwing a hissy fit over?
And I count one (1) principle at stake.
Which is *always* worth throwing a fit over.
NOTICE: This notice will appear at the bottom of all my slashdot posts.
That's a typical OpenBSD discussion, in which Theo DeRaadt
i) is basically right
ii) still manages to sound like spoiled whiny tosser in the process.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
From Theo's response:
Theo is essentially taking the position that personal information is tantamount to currency, and therefore, requesting personal info is tantamount to charging...hence, HIFN can no longer be considered Open Source. This position may currently be confined to OSS in general and the HIFN question in particular, but it's not difficult to imagine this argument generalized to apply to any situation in which an entity requests personal information. Personal info needs to be treated as the valuable commodity that it is...kudos to Theo for taking a stand on this issue.
Theo also addreses something many of us here are worried about:
Even disregarding the 'personal info == currency' argument outlined above, this objection stands on its own. HIFN is basically stating that yes, the info gathered will be handed over to the U.S. government on request, to satisfy their licensing requirements. This alone is a deal-breaker.
Theo sums his entire argument up beautifully here:
Well said, Theo. I for one don't care to support a company who engages in such practices, and I would rather see no support for a product than half-assed support, because the driver writers were not allowed full, unfettered access to the data sheets.
And finally from Theo's response:
Don't just say it, Theo, do it. If you stand by your statement, then HIFN has no place in the source tree, and should be deleted immediately.
____
~ |rip/\/\aster /\/\onkey
If he objects to providing that information, he can say so, but this sort of easily-refuted hyperbole doesn't help.
Yes.
You have to sign an NDA to get the documents. So you would be violating the NDA to redistribute them.
There isn't a business advantage to this sort of secrecy because your competitors can easily obtain this same information through a blind. So it comes down to policy motivated by irrational fear & greed. Who needs to really deal with company with these qualities?
This topic is of primary interest to me because I am shopping for a crypto accelerator card right now, for use in the fall. Given the success and ease I have had using OpenBSD, and given the great support I have from the mailing lists, this is a reasonable criterion to use when purchasing hardware. In fact at some point of the decision making process for all of my hardware I have done a search on the OpenBSD mailing lists. This sort of information makes installation and maintenance a simple thing.
So it really does boil down to unless the OpenBSD group recommends a certain piece of hardware I won't buy it...
Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
How would this violate US Export Licences???
Fine, don't export chips overseas without knowing who you're selling to, but documentation? For driver developers no less?? When Hifn themselves are trying to say that this information is open and free???
This is the key point of Theo's argument, surely: that Hifn are not at all obliged to demand this information, and therefore are going against the principles of open access/source by demanding it. Can someone please explain what I'm missing here.
Meta will eat itself
Would that not be on documentation that explained exactly how the chip worked and not just how to send and receive bits from it?
If this is the case with HIFN, why do some other hardare companies in the same field not have the same restrictions?
There was a good comment made later in the thread:
Perhaps you can talk to your legal counsel and actually break out the documentation needed for these open source drivers into a separate and truly open to the "general public" anonymous download site. I doubt that the documentation that is being requested by developers is putting you in violation of US Export Regulations
....snip....
I understand it's very easy these days for attorneys to just say put everything behind your registration only access extranet to be safe. This is not acceptable and, in my opinion, is not open to the general public like you stated.
That sums up my thoughts much more succinctly.
I am NaN
While I whole-heartedly agree with the point Theo was making in his article, I can't help but think that engaging in hyperbole (50 questions? ~25 is accurate) and verbally abusing and threatening the vendor is going to help in any way.
Documentation on how to interface with the hardware chip is NOT covered by export regulations. Only the actual chip, and its design specifications in regard to implemented algorithms, are covered.
Hence, the docs that OpenBSD folks need (and had access to, until a few years ago) are NOT covered.
The choice is between "giving back access to documentation to allow developers to work with your hardware" or "keep track of developers for marketing purposes".
Export regulations enter the picture only if you don't know them.
-- Let's go Viridian.
Everybody seems to be sidestepping the main issue.
The real question that should be answered is whether hifn are indeed required by law to ask personal information of the people downloading documentation, as hifn claims they are.
If they are, than hifn simply cannot comply with OpenBSD's demands without breaking U.S. law.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
It's the most security oriented. Funny...a crypto chip vendor spurning the most security oriented
OS developers' desires for unfettered acces, etc. No personal info should need to be given to a
vendor unless he's entering into a sales relationship with them. Honestly- too much risk of Identity
Theft through this sort of thing.
Seriously, I'd have to agree with him on this one- and I'm from the Linux camp and would be driving
sales into that segment very shortly. I'd be making a big stink about it too. And what's sad about
all these vendors is that they're doing nothing but pissing off the people that'd be helping them
sell chips.
In reality, the vendors are doing this because idiot IP lawyers tell them to do so. There should
be no IP revealed in the systems interfaces to a device. It should be the silicon equivalent to
an API. If there is IP honestly revealed, then you've got something new, and the patent itself
should be sufficient to protect it. If you're trying to hide a design flaw by not revealing info-
don't. You should design devices with interfaces that make sense and are system safe or can be made
so with the right device driver code.
Keeping it secretive helps nobody in reality. For example, ATI's drivers work adequately on the
desktop space but are less performant on at least part of the laptop line under Linux- because of
a design/coding flaw in the closed source drivers. I can't reccomend anyone get a laptop with an
ATI based display because they just don't seem to work as well. If someone had source code and
technical data access they could most likely fix the problems in question- unless the chip had a
design hickey. Even then, unless it's something that would compromise security, it should be
able to be coded around- Windows drivers can do Sideport memory correctly, why can't the Linux
support do the same thing?
At any rate, I believe I've drifted from the conversation... Yes Theo's got a niche play- but
in the segment that Hifn's in, it's an important one all the same.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Fair enough, Hank. But I reserve the right to not use proprietary crypto code in sensitive applications - which are the only ones that I'd actually buy hardware acceleration for in the first place.
Let's get this straight: there's a world of difference between closed video card drivers and closed crypto drivers. Many of us are squeamish about about the former, so why would you think we'd cheerfully accept the latter? A closed source video driver could potentially crash my non-networked game machine. A closed source encryption accelerator cold potentially open my VPN server to the whole world.
I hope you can appreciate the community's position here, but whether you agree with it or not is immaterial. Should you change your opinion to better mesh with that of your would-be customers, please let us know. Many of us would like to buy your products if they become usable for our applications.
Dewey, what part of this looks like authorities should be involved?
If I have the choice, I run OpenBSD on servers because when it fits, it fits like a glove. If Theo acts like everyone else and just rolls over when a suit tells him no, OpenBSD would be just like every other Linux/BSD distro. This sort of attention to details (in both software and licenses) makes OpenBSD distictive. In marketing-speak, this is called 'developing a niche'. Within its niche, OpenBSD has no equal. If it looses its niche, then it will loose its market share. So I think the best thing Theo can do is to be Theo.
Think global, act loco