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

[Andrew Haley]

On 05/25/2011 11:31 AM, Gordan Bobic wrote:
> 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.

OK, so that's how it looks to you.

> 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.

The point is not that one licence is better than the other, but that
some licences are incompatible.  The "old" BSD licence with the
advertising clause is broken because it prevents a library from being
used by some packages.  There is a new BSD licence that fixes the
problem.

>> 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.

Aha: I see http://fedoraproject.org/wiki/Nss_compat_ossl

> 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).

Interesting question; not sure.

> 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_?

For bulk crypto operations an extra call via a shim probably doesn't
matter.  For some signature operations it might.

It seems like a clean solution from the point of view of application
developers, though.

> 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.

Well, that's not true for everyone, and certainly not for users of
GPG.

But the real question is whether one group of Fedora developers is
determinedly going to push NSS and the other OpenSSL.  That is not a
route to happiness.

Andrew.