From 96c065cb7bcdfc0965fb111e1eab6e9180e9e186 Mon Sep 17 00:00:00 2001 From: Philip Hazel Date: Tue, 5 Dec 2006 11:35:28 +0000 Subject: Documentation and comment tidies. --- doc/doc-txt/NewStuff | 6 ++-- doc/doc-txt/OptionLists.txt | 4 +-- src/src/EDITME | 25 +++++++++++---- src/src/expand.c | 74 +++++++++++++++++++++++++++++++++++++++------ 4 files changed, 89 insertions(+), 20 deletions(-) diff --git a/doc/doc-txt/NewStuff b/doc/doc-txt/NewStuff index 67901a28c..9d0e93993 100644 --- a/doc/doc-txt/NewStuff +++ b/doc/doc-txt/NewStuff @@ -1,4 +1,4 @@ -$Cambridge: exim/doc/doc-txt/NewStuff,v 1.123 2006/11/14 16:40:36 ph10 Exp $ +$Cambridge: exim/doc/doc-txt/NewStuff,v 1.124 2006/12/05 11:35:28 ph10 Exp $ New Features in Exim -------------------- @@ -198,8 +198,8 @@ Version 4.64 available for compatibility.) 12. The "message" modifier can now be used on acl verbs to vary the message - that is sent when an SMTP command. For example, in a RCPT ACL you could - have: + that is sent when an SMTP command is accepted. For example, in a RCPT ACL + you could have: accept message = OK, I'll allow you through today diff --git a/doc/doc-txt/OptionLists.txt b/doc/doc-txt/OptionLists.txt index 1b73b1e5e..e484f98e9 100644 --- a/doc/doc-txt/OptionLists.txt +++ b/doc/doc-txt/OptionLists.txt @@ -1,4 +1,4 @@ -$Cambridge: exim/doc/doc-txt/OptionLists.txt,v 1.27 2006/11/06 15:50:12 ph10 Exp $ +$Cambridge: exim/doc/doc-txt/OptionLists.txt,v 1.28 2006/12/05 11:35:28 ph10 Exp $ LISTS OF EXIM OPTIONS --------------------- @@ -776,7 +776,7 @@ DB_DIRECTORY_MODE optional* mode for hints directory DB_LOCKFILE_MODE optional* mode for hints lock files DB_LOCK_TIMEOUT optional* timeout for hints lock files DB_MODE optional* mode for hints files -DEFAULT_CRYPT optional use crypt16() as default +DEFAULT_CRYPT optional default crypt() function DELIVER_IN_BUFFER_SIZE optional* DELIVER_OUT_BUFFER_SIZE optional* DISABLE_D_OPTION optional disables -D option diff --git a/src/src/EDITME b/src/src/EDITME index 17f83297e..cd20335eb 100644 --- a/src/src/EDITME +++ b/src/src/EDITME @@ -1,4 +1,4 @@ -# $Cambridge: exim/src/src/EDITME,v 1.17 2006/10/02 13:38:18 ph10 Exp $ +# $Cambridge: exim/src/src/EDITME,v 1.18 2006/12/05 11:35:28 ph10 Exp $ ################################################## # The Exim mail transport agent # @@ -536,7 +536,7 @@ HEADERS_CHARSET="ISO-8859-1" # configuration of an authenticator for use with SMTP AUTH.) At least one # operating system has an extended function called crypt16(), which uses up to # 16 characters of a password (the normal crypt() uses only the first 8). Exim -# supports the use of crypt16() as well as crypt(). +# supports the use of crypt16() as well as crypt() but note the warning below. # You can always indicate a crypt16-encrypted password by preceding it with # "{crypt16}". If you want the default handling (without any preceding @@ -548,10 +548,23 @@ HEADERS_CHARSET="ISO-8859-1" # an encrypted password with "{crypt}". For more details, see the description # of the "crypteq" condition in the manual chapter on string expansions. -# Since most operating systems do not include a crypt16() function (yet?), Exim -# has one of its own, which it uses unless HAVE_CRYPT16 is defined. Normally, -# that will be set in an OS-specific Makefile for the OS that have such a -# function, so you should not need to bother with it. +# Some operating systems do not include a crypt16() function, so Exim has one +# of its own, which it uses unless HAVE_CRYPT16 is defined. Normally, that will +# be set in an OS-specific Makefile for the OS that have such a function, so +# you should not need to bother with it. + +# *** WARNING *** WARNING *** WARNING *** WARNING *** WARNING *** +# It turns out that the above is not entirely accurate. As well as crypt16() +# there is a function called bigcrypt() that some operating systems have. This +# may or may not use the same algorithm, and both of them may be different to +# Exim's built-in crypt16() that is used unless HAVE_CRYPT16 is defined. +# +# However, since there is now a move away from the traditional crypt() +# functions towards using SHA1 and other algorithms, tidying up this area of +# Exim is seen as very low priority. In practice, if you need to, you can +# define DEFAULT_CRYPT to the name of any function that has the same interface +# as the traditional crypt() function. +# *** WARNING *** WARNING *** WARNING *** WARNING *** WARNING *** #------------------------------------------------------------------------------ diff --git a/src/src/expand.c b/src/src/expand.c index 11582529a..7f1515c98 100644 --- a/src/src/expand.c +++ b/src/src/expand.c @@ -1,4 +1,4 @@ -/* $Cambridge: exim/src/src/expand.c,v 1.72 2006/11/13 12:32:58 ph10 Exp $ */ +/* $Cambridge: exim/src/src/expand.c,v 1.73 2006/12/05 11:35:28 ph10 Exp $ */ /************************************************* * Exim - an Internet mail transport agent * @@ -13,12 +13,20 @@ #include "exim.h" +/* Recursively called function */ + +static uschar *expand_string_internal(uschar *, BOOL, uschar **, BOOL); + #ifdef STAND_ALONE #ifndef SUPPORT_CRYPTEQ #define SUPPORT_CRYPTEQ #endif #endif +#ifdef LOOKUP_LDAP +#include "lookups/ldap.h" +#endif + #ifdef SUPPORT_CRYPTEQ #ifdef CRYPT_H #include @@ -28,15 +36,63 @@ extern char* crypt16(char*, char*); #endif #endif -#ifdef LOOKUP_LDAP -#include "lookups/ldap.h" -#endif - - - -/* Recursively called function */ +/* The handling of crypt16() is a mess. I will record below the analysis of the +mess that was sent to me. We decided, however, to make changing this very low +priority, because in practice people are moving away from the crypt() +algorithms nowadays, so it doesn't seem worth it. + + +There is an algorithm named "crypt16" in Ultrix and Tru64. It crypts +the first 8 characters of the password using a 20-round version of crypt +(standard crypt does 25 rounds). It then crypts the next 8 characters, +or an empty block if the password is less than 9 characters, using a +20-round version of crypt and the same salt as was used for the first +block. Charaters after the first 16 are ignored. It always generates +a 16-byte hash, which is expressed together with the salt as a string +of 24 base 64 digits. Here are some links to peruse: + + http://cvs.pld.org.pl/pam/pamcrypt/crypt16.c?rev=1.2 + http://seclists.org/bugtraq/1999/Mar/0076.html + +There's a different algorithm named "bigcrypt" in HP-UX, Digital Unix, +and OSF/1. This is the same as the standard crypt if given a password +of 8 characters or less. If given more, it first does the same as crypt +using the first 8 characters, then crypts the next 8 (the 9th to 16th) +using as salt the first two base 64 digits from the first hash block. +If the password is more than 16 characters then it crypts the 17th to 24th +characters using as salt the first two base 64 digits from the second hash +block. And so on: I've seen references to it cutting off the password at +40 characters (5 blocks), 80 (10 blocks), or 128 (16 blocks). Some links: + + http://cvs.pld.org.pl/pam/pamcrypt/bigcrypt.c?rev=1.2 + http://seclists.org/bugtraq/1999/Mar/0109.html + http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q0R2D- + TET1_html/sec.c222.html#no_id_208 + +Exim has something it calls "crypt16". It will either use a native +crypt16 or its own implementation. A native crypt16 will presumably +be the one that I called "crypt16" above. The internal "crypt16" +function, however, is a two-block-maximum implementation of what I called +"bigcrypt". The documentation matches the internal code. + +I suspect that whoever did the "crypt16" stuff for Exim didn't realise +that crypt16 and bigcrypt were different things. + +Exim uses the LDAP-style scheme identifier "{crypt16}" to refer +to whatever it is using under that name. This unfortunately sets a +precedent for using "{crypt16}" to identify two incompatible algorithms +whose output can't be distinguished. With "{crypt16}" thus rendered +ambiguous, I suggest you deprecate it and invent two new identifiers +for the two algorithms. + +Both crypt16 and bigcrypt are very poor algorithms, btw. Hashing parts +of the password separately means they can be cracked separately, so +the double-length hash only doubles the cracking effort instead of +squaring it. I recommend salted SHA-1 ({SSHA}), or the Blowfish-based +bcrypt ({CRYPT}$2a$). + +*/ -static uschar *expand_string_internal(uschar *, BOOL, uschar **, BOOL); -- cgit v1.2.3