I've checked in some changes to make nettle compile on systems which lack alloca, and on systems which lack inttypes.h.
For systems without alloca, some arbitrary limits have been placed on the input of a few functions, but I hope that won't be a problem in practice.
As I don't have access to any systems that have these problems, I'll appreciate if Simon and any other people that have seen the problems could try it out and see if it works.
As some shared but crucial files are not stored in the nettle corner of the cvs, the recommended way of cvs access is to check out the entire lsh tree, as per the instructions at http://www.lysator.liu.se/~nisse/lsh, run the top-level ./.bootstrap script (which sets up a few important symlinks and runs .bootstrap scripts in subdirectories), and then descend into the src/nettle directory for a standard ./configure && make there.
Best regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
I've checked in some changes to make nettle compile on systems which lack alloca, and on systems which lack inttypes.h.
For systems without alloca, some arbitrary limits have been placed on the input of a few functions, but I hope that won't be a problem in practice.
As I don't have access to any systems that have these problems, I'll appreciate if Simon and any other people that have seen the problems could try it out and see if it works.
I'm using the new nettle files in gsasl 0.0.13, we'll see if I get any reports about C89 incompatibilities.
A nit though, I see Nettle configure.ac says AX_CREATE_STDINT_H([nettle-types.h]), I think it is better to say AX_CREATE_STDINT_H(nettle-types.h, sys/types.h). Then sys/types.h is also searched for the C99 uint*_t etc. I recall some systems put the definitions there. I asked the AX_CREATE_STDINT_H maintainer to add this some time ago, but for some reason it hasn't happened. (Of course, alternatively, you could modify ax_create_stdint_h.m4.)
A wishlist item as well: splitting up hmac.h into hmac.h, hmac-md5.h, hmac-sha.h would be useful. Then you don't have to copy code for sha if you only need md5, and vice versa. Untested code attached, based on current CVS. (Update copyright year etc as appropriate.)
Thanks, Simon
Simon Josefsson jas@extundo.com writes:
A nit though, I see Nettle configure.ac says AX_CREATE_STDINT_H([nettle-types.h]), I think it is better to say AX_CREATE_STDINT_H(nettle-types.h, sys/types.h).
The version of AX_CREATE_STDINT_H I use contains code like
if test "_$ac_cv_header_stdint_x" = "_" ; then if test "_$ac_cv_header_stdint_o" = "_" ; then AC_CACHE_CHECK([for stdint u_int32_t], [ac_cv_header_stdint_u],[ ac_cv_header_stdint_u="" # the BSD typedefs (sys/types.h) AC_MSG_RESULT([(..)]) for i in sys/types.h inttypes.h sys/inttypes.h $inttype_headers ; do
so it seems sys/types.h should be considered already. Do you know that it doesn't work?
A wishlist item as well: splitting up hmac.h into hmac.h, hmac-md5.h, hmac-sha.h would be useful. Then you don't have to copy code for sha if you only need md5, and vice versa.
Hmm, can you explain what's the problem with this "copying"? There are four different object files, hmac.o, hmac-md5.o, hmac-sha1.o and hmac-sha256.o, so with static linking, only the needed ones should be dragged into the executable.
I try to keep the number of header files down a little, for example sha1 and sha256 are both declared in sha.h, des and des3 are both in des.h, all rsa-related functions collected in rsa.h, etc. Do you see a problem with that design? (I'm not 100% consistent, in particular md4 are md5 are declared in separate header files).
One alternative that would almost work is to replace the `#include "md5.h"' in hmac.h with a forward declaration `struct md5;'. Then users of hmac-md5 would need to include both hmac.h and md5.h. I can't say if that would solve your problem, though, as I don't know what it is...
The reason a forward declaration won't work right away, is the hmac.h declaration
struct hmac_md5_ctx HMAC_CTX(struct md5_ctx);
which needs the storage size of struct md5_ctx to make sense.
BTW, there's one known bug in the nettle-1.8 distribution: A few of the header files are forgotten by the make install target. I'll wait some more for bug reports before making a bugfix release to address that.
Best regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
Simon Josefsson jas@extundo.com writes:
A nit though, I see Nettle configure.ac says AX_CREATE_STDINT_H([nettle-types.h]), I think it is better to say AX_CREATE_STDINT_H(nettle-types.h, sys/types.h).
The version of AX_CREATE_STDINT_H I use contains code like
if test "_$ac_cv_header_stdint_x" = "_" ; then if test "_$ac_cv_header_stdint_o" = "_" ; then AC_CACHE_CHECK([for stdint u_int32_t], [ac_cv_header_stdint_u],[ ac_cv_header_stdint_u="" # the BSD typedefs (sys/types.h) AC_MSG_RESULT([(..)]) for i in sys/types.h inttypes.h sys/inttypes.h $inttype_headers ; do
so it seems sys/types.h should be considered already. Do you know that it doesn't work?
The for loop is in several places, my version only has sys/types.h in one of them. After I added it to the for loop at line 78, for uintptr_t, and to line 94, for uint32_t, someone using cygwin managed to get it to work. I'm not familiar with the script to tell if it is the right solution, but it did solve a genuine problem at the time. Perhaps the AX_CREATE_STDINT_H author can chime in. I later found out it was possible to pass in additional headers as a parameter, so I reverted my modified .m4 and used AX_CREATE_STDINT_H(nettle-types.h, sys/types.h) and nobody has complained since.
A wishlist item as well: splitting up hmac.h into hmac.h, hmac-md5.h, hmac-sha.h would be useful. Then you don't have to copy code for sha if you only need md5, and vice versa.
Hmm, can you explain what's the problem with this "copying"? There are four different object files, hmac.o, hmac-md5.o, hmac-sha1.o and hmac-sha256.o, so with static linking, only the needed ones should be dragged into the executable.
I try to keep the number of header files down a little, for example sha1 and sha256 are both declared in sha.h, des and des3 are both in des.h, all rsa-related functions collected in rsa.h, etc. Do you see a problem with that design? (I'm not 100% consistent, in particular md4 are md5 are declared in separate header files).
One alternative that would almost work is to replace the `#include "md5.h"' in hmac.h with a forward declaration `struct md5;'. Then users of hmac-md5 would need to include both hmac.h and md5.h. I can't say if that would solve your problem, though, as I don't know what it is...
The reason a forward declaration won't work right away, is the hmac.h declaration
struct hmac_md5_ctx HMAC_CTX(struct md5_ctx);
which needs the storage size of struct md5_ctx to make sense.
I guess my use of Nettle isn't the typical one: I copy the files I need into my projects. In gsasl, there is no need for (HMAC-)SHA*, but HMAC-MD5 is needed. So I need hmac.h, but do not want sha*. The source of the problem is that hmac.h #include's sha.h. I have been modifying hmac.h to remove the sha* stuff, but this requires more work when copying the files from Nettle.
I guess one solution is to add sha.h, but not sha*.c, so hmac.h works, but since I don't need SHA, it feels slightly confusing.
Any ideas appreciated. Of course, all this is very minor.
Thanks, Simon
Simon Josefsson jas@extundo.com writes:
The for loop is in several places, my version only has sys/types.h in one of them. After I added it to the for loop at line 78, for uintptr_t, and to line 94, for uint32_t, someone using cygwin managed to get it to work.
I see. I'm changing the AX_CREATE_STDINT_H invocation to
# According to Simon Josefsson, looking for uint32_t and friends in # sys/types.h is needed on some systems, in particular cygwin. AX_CREATE_STDINT_H([nettle-types.h], [sys/types.h])
I guess one solution is to add sha.h, but not sha*.c, so hmac.h works, but since I don't need SHA, it feels slightly confusing.
Any ideas appreciated. Of course, all this is very minor.
Perhaps it would make sense to add something like
#ifndef NETTLE_WANT_HMAC_SHA1 # define NETTLE_WANT_HMAC_SHA1 1 #endif
...
#if NETTLE_WANT_HMAC_SHA1 # include "sha.h" ... hmac-sha1-related stuff ... #endif
to hmac.h. Then you can just add -DNETTLE_WANT_HMAC_SHA1=0 to your CPPFLAGS. It will clutter up the header files a little, especially if it's done consistently for other header files that declares many related structures.
(I've also been thinking of hacks where hmac.h examines NETTLE_SHA_H_INCLUDED, but I dislike that because I don't want the order of the #include directives in users' files to matter).
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
I guess one solution is to add sha.h, but not sha*.c, so hmac.h works, but since I don't need SHA, it feels slightly confusing.
Any ideas appreciated. Of course, all this is very minor.
Perhaps it would make sense to add something like
#ifndef NETTLE_WANT_HMAC_SHA1 # define NETTLE_WANT_HMAC_SHA1 1 #endif
...
#if NETTLE_WANT_HMAC_SHA1 # include "sha.h" ... hmac-sha1-related stuff ... #endif
to hmac.h. Then you can just add -DNETTLE_WANT_HMAC_SHA1=0 to your CPPFLAGS. It will clutter up the header files a little, especially if it's done consistently for other header files that declares many related structures.
Yes. For what it's worth, I think the clutter makes the file unreadable, which I (objectively) think is worse than requiring me to include an unused sha.h in a package. Perhaps I can find some use of SHA in my package, so the file isn't unused... But if Nettle supported HMAC with many hashes (MD2, MD4, ...), I guess I would once again have the feeling that the current hmac.h approach doesn't scale.
Again, this is not that important.
Thanks, Simon
nettle-bugs@lists.lysator.liu.se
-
nisse＠lysator.liu.se -
Simon Josefsson