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."
This should get really interesting.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
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...
Implication: they are collecting the data in case they're asked to provide it. To the US Govt. Yeah, that's pretty hissy-worthy when you're trying to claim that you're opening up access. I have little doubt that registration will lead to some non-disclosure agreement or other, though I'm not prepared to try it myself.
Incidentally, how does the supplying information without charging for it constitute "export"? And by comparison, if I want to download a manual for something I bought second-hand, why can't I? Just a thought.
Meta will eat itself
>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.
You know what, if you'd wanted this 15 years ago, you would have phoned them up, given them the EXACT SAME INFO THEY'RE ASKING FOR on their web site, and they would have mailed it to you.
And a sales-person might have called to see if you wanted to buy some chips.
Theo's "50 questions" is email, name, company name, title, address, phone number, and "what is your project? What is your role? When do you want to buy some chips?" How about a little reality here. Theo does some great stuff, but that doesn't mean he gets to bend how the world works to his will.
Just like the "I don't get any donations" rant from him a bit ago, he just doesn't seem to be well grounded in business realities. If you want donations, you need a tax-exempt foundation, not "make checks out to Theo." If you want data sheets, you might have to tell the company who you are and why you want them.
The preferred solution is to not have a problem.
"Jason and I spent a lot of time writing that code in the
past, but because your policies are privacy invasive towards us, and
thus completely thankless for the sales that we have given you in the
past -- we will not spend any more time on your crummy products."
Sales?
Unless Theo can give a decent estimate of how much 'sales' OpenBSD has 'given' them, I doubt the upper brass at Hifn cares about Theo's whinging.
If you want drivers for "less mainstream OS'es", please attach your request to a large multi-mega-million part order from <insert vendor here>. If you don't believe me, we'll, the only reason NVIDIA's Linux support is miles ahead of ATI is due to the demand from Hollywood setups to use high-end-5000%-margin professional cards on Linux, not geeks on Slashdot playing Tuxracer.
I really don't see how this is supposed to be a violation of export licences
h y
AFAIK (and IANAL), detailed hardware documentation is considered the same as the product under the export license laws. Cryptographic technology actually falls under an even more restrictive license class - munitions.
http://en.wikipedia.org/wiki/Export_of_cryptograp
Read the "Current Status" section. My point is that Hifn isn't "baiting" anyone. You might disagree with their lawyer or think it's your right to demand that Hifn fight "the man", but that's another issue.
AFAIK (and IANAL), detailed hardware documentation is considered the same as the product under the export license laws.
Please post links supporting this contention, or withdraw it.
Cryptographic technology actually falls under an even more restrictive license class - munitions.
Whle this is true, the source code can still be legally exported in written format, since it falls under Free Speech.
From this article:
Given that, as you stated, crypto falls under the even more restrictive license class of 'munitions', if you can export PGP source code without violating U.S. export restrictions, I'm betting you can export data sheets too.
My point is that the HIFN's explanation of their requirement for personal info to satisfy their U.S. export license is pure codswallop, your nonsensical comments about HIFN 'fighting the man' notwithstanding.
____
~ |rip/\/\aster /\/\onkey
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?
Such kernels developers feedback are very precious and insightful for us, customers. It's not only a matter of freedom an principles, it's about quality.
Be sure that - whatever the OS you use, being Linux, OpenBSD or FreeBSD -, when a vendor behaves that bad and is so reluctant in providing open access to documentation, you won't have a good driver nor a good support.
Those vendors behaviours are usually symptoms of a "closed" attitude, secrecy centerd, so even when we accept NDA, we can't expect them to disclose the whole needed informations (like, say, all firmwares versions bugs that needs a workaround in drivers level, know bad behaviour of their chipsets etc). This attitude will also discourage some knowledgeable developers to help to improve the driver, to fix bugs etc. Requiring NDA will prevent OSS kernel developers to share sensitive informations regarding their experience with the device (between OS, and even sometime inside the same kernel dev team).
So for now, if you need a stable encryption accelerator device, consider choosing an other vendor. Look out for Via C3, or SafeNet (and even some Broadcom) chipsets: those vendors plays the game well, don't seat on their customers (we) and the developers needs. They don't even hide behind a "U.S. export laws restrictions" argument, and didn't faced trials, proving the hypocrisy of HiFn assertions.
I'm willing to bet that there's a limit to what you can export, even in book form. Going to extremes, if I tried to export plans for the W80 nuclear warhead in book form (or print it on a T-shirt), I'd guess not only would export of that book be banned, but I'd be taking a nice long vacation at Club Fed..
Facts do not cease to exist because they are ignored. - Aldous Huxley
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
Just give bogus information.
Everybody does!
The applicable categories are obvious.
If they're so obvious, why didn't you post links to those categories, or better yet, applicable excerpts?
Don't forget to read interpretations
Fair enough...I read through Part 770 - Interpretations, but strangely enough, the word 'documentation' is only used once in the entire document. I've posted the relevant passage for clarity:
Please explain how the above supports your contention that 'detailed hardware documentation is considered the same as the product under the export license laws'.
and supplement 2.
Which supplement 2? The Supplement No. 2 to Part 764 - Denied Persons List, or the Supplement No. 2 to Part 774 - General Technology and Software Notes? (HINT: Neither supplement contains anything to support your contention that 'detailed hardware documentation is considered the same as the product under the export license laws'.)
In short, it looks like you thought you could try to justify your argument by pointing me to a ridiculously large government document, and then hoping I wouldn't bother to actually read it. You thought wrong.
I'm not going to respond to the rest of your rant,
Translation: I can't refute it, so I'll shut my eyes and pretend it's not there.
other than to suggest you get legal advice somewhere other than mailing lists and agitprop web sites.
And this from the person who qualified their original contention with 'AFAIK' and "IANAL'. Pot, meet kettle.
____
~ |rip/\/\aster /\/\onkey
in a form that will be made public. They need a PR person.
He is right in principal in many cases, however he has absolutely no talent when it comes to voicing that principal. OpenBSD seriously need a PR person that knows how to deal with actual people, you know with a hint of tact, cause he doesnt have any whatsoever.
The phrase "more better" is acceptable English. suck it grammar Nazis
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
Well, we all have our limits. Some people worry, and justifiably so, that their BIOS isn't open. I'm somewhere in the middle in that I use the proprietary NVidia drivers, even though I don't like it. I'd think that everyone, though, would agree that the crypto engine is the absolute last thing you want to cede control of.
Dewey, what part of this looks like authorities should be involved?
The applicable categories are obvious.
If they're so obvious, why didn't you post links to those categories, or better yet, applicable excerpts?
Laziness. Category 5pt2, and 4 & 5pt1 also. Look how broad ITAR 120.10 is (and according to another poster in the thread they can also classify info as a "service" and use those sections).
In short, it looks like you thought you could try to justify your argument by pointing me to a ridiculously large government document, and then hoping I wouldn't bother to actually read it. You thought wrong.
I thought right. It looks like you searched a couple of sections for the word "documentation" without even trying to follow it. Understanding "ridiculously large" and complex laws that put people in jail is hard, that's why lawyers get paid big.
other than to suggest you get legal advice somewhere other than mailing lists and agitprop web sites.
And this from the person who qualified their original contention with 'AFAIK' and "IANAL'. Pot, meet kettle.
Or with more thought and less attitude you might infer that I take my own advice.
I'm not going to respond to the rest of your rant,
Translation: I can't refute it, so I'll shut my eyes and pretend it's not there.
Better translation: Oops, I'm wrestling a pig in mud.
Is Hifn's hardware supported in Linux?
Not in the kernel tree, but there is a third-party driver available. My understanding from associates who work with the Linux version is it isn't as feature-rich as the OpenBSD driver, and those who develop on it are also frustrated by Hifn's new policies.
What percentage of their customers rely on OpenBSD support? Who are they more loyal to, Hifn for the hardware or OpenBSD for the OS?
As someone who works for a place that uses crypto cards, I can tell you: we are more bound to the OS than the crypto hardware. There's a lot of different crypto hardware on the market, but if you want to do any kind of hardcore embedded systems development using a POSIX API, there aren't a lot of choices out there.