On 05/24/2011 06:32 PM, Stephen John Smoogen wrote: > On Tue, May 24, 2011 at 11:20, Gordan Bobic<gordan@xxxxxxxxxx> wrote: >> On 05/24/2011 06:11 PM, Andrew Haley wrote: >>> On 05/23/2011 04:12 PM, Gordan Bobic wrote: >>>> omalleys@xxxxxxx wrote: >>>> >>>>> My question, is how hard is this to implement the hardware support >>>>> non-openssl programs. >>>> >>>> Not particularly hard if you're writing your own crypto implementation >>>> anyway, but there's a lot to be said for just linking against OpenSSL. >>>> It's probably safer to link against the library that has a lot of eyes >>>> on it than it is to implement your own. >>>> >>>>> OpenAFS could use this as it can use a lot of DES >>>>> encryption, but it uses its own DES implementation. It also happens to >>>>> be the only one I can think of off the top of my head that uses its own >>>>> implementation. It would be nice to have. >>> >>> gpg seems to use its own AES implementation that's slower than SSL's. >>> It would certainly be nice to fix that to use acceleration. >> >> Sounds like it might be a good idea to post a feature request to the >> upstream bugzilla. Have you checked if there is a build option to make >> it link against OpenSSL instead of using the bundled crypto stack? > > There may be a license incompatibility. OpenSSL has an advertising > clause in it I believe which makes it incompatible with various GPL > unless an exception is given. I didn't think that matters on dynamic linking. Does it? And we are specifically talking about dynamic linking to get the features of the system OpenSSL install. Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
