On 03/21/2011 03:04 PM, Niels Möller wrote:
I don't know how the build system for the perl bindings is setup, but using something like autoconf should make it easier if you really want to support multiple nettle versions, with or without public key support.
that's an interesting suggestion -- i'm afraid i don't know enough about integrating autoconf with perlxs to know how to go down that path without a more research, but i'll consider it for the future. It would only allow backward-compatibility, though -- not forward-compatibility. That is: if you built Crypt::Nettle against libnettle version X, and then upgraded to libnettle version Y, you'd have to also re-build Crypt::Nettle.
That's not a horrible tradeoff, i guess.
But some other parts of the nettle interfaces have not been as stable between releases, so it doesn't solve the problem completely.
yes, that's true -- i'm proposing this just for the ciphers and hashes at the moment.
One may want to think about fancy hardware accelerators (currently not supported at all), which would require some runtime check on what's available.
that's an interesting part i hadn't considered. I'm not certain how to represent such a change, but i like the idea that one could discover available/supported hardware dynamically somehow. Would supporting that use case suggest a different API?
I'm not sure this is as useful. The modes have different properties and generally don't work well as substitutes for each other. And at least, the list is expected to be expanded less frequently than the list of hashes or block ciphers.
OK. Maybe this is a good target for the autoconf approach you mentioned above.
Some comments on the implementation:
+const struct nettle_armor *nettle_armors[] = {
- &nettle_base64,
- &nettle_base16,
- NULL
+};
The typing should be something like
const struct nettle_armor * const nettle_armors[]
to say that both the list itself and the pointed to structures are const.
Yes, you are right, thanks!
Also, I think there should be one compilation unit and object file per list, so that it's, for example, possible to statically link with the list of all hash algorithms without also dragging in all ciphers.
Is there any reason to use this approach for statically-linked tools? Maybe for UI or hardware discoverability, i guess. It certainly wouldn't help in terms of software discoverability or forward/backward compatibility in a statically-linked library.
Do you want me to submit a modified patch with these changes?
--dkg