[fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)

[Gordan Bobic]

Andrew Haley wrote:
> On 05/25/2011 10:38 AM, Gordan Bobic wrote:
>> Emmanuel Seyman wrote:
>>> * Gordan Bobic [25/05/2011 11:25] :
>>>> aph:
>>>>> Perhaps, but its licence seems to be broken, so it can't be used as a
>>>>> general-purpose crypto library for Fedora.
>>>> This doesn't seem to prevent it from being used as such, as far as I can 
>>>> see.
>>> Actually, it does: http://lwn.net/Articles/428111/
>> That's all very theoretical and academic as long as half the distro is 
>> linking against OpenSSL anyway. We are where we are, and that will take 
>> time to change. Meanwhile, those of us living in the real world need to 
>> stick with the pragmatic approach of using what is there and works.
> 
> I don't think it's merely theoretical.  If there's one lesson we
> should have learned over the past few years, it's that licences
> really do matter.

It seems to me (and always has, thinking about it) that the argument of 
BSD vs. GPL vs. LGPL vs. whatever-other-open-source-licence has always 
been a passtime for people who lack either the ability or the 
inclination to get on with real productive work. Flame me for that 
statement all you want, but that's just what it's always looked like to me.

I don't see that this particular licensing "issue" is stopping OpenSSL 
shipping with every major distro, with a lot of packages linking against 
it. Hardlining on this issue seems like it blows things way out of 
proportion.

> It looks as though Fedora is going the NSS route
> anyway,  so presumably an OpenSSL-compatible library could be built on
> top of NSS, and the problem would go away.

I'm not against NSS - really I'm not. But there are other considerations 
to be taken into account.

1) Does NSS have any kind of support for hardware crypto offload? If so, 
I haven't found any references to it (but maybe my google-foo is weak 
today).

2) More abstraction (a OpenSSL->NSS shim library), means more bloat, 
more context switching and less performance. Is that really the way 
forward? I mean _really_?

3) Volume of supported commonly used software - if NSS has a clear 
advantage in terms of support base, then so be it, let's all put our 
weight behind it. But my perception is that this is not the case. 
Everything I touch upon on a daily basis seems to be linked against 
OpenSSL rather than NSS.

Gordan