summaryrefslogtreecommitdiffstats
path: root/lib/libc/regex/regex2.h
diff options
context:
space:
mode:
authorpeter <peter@FreeBSD.org>2000-12-28 11:23:01 +0000
committerpeter <peter@FreeBSD.org>2000-12-28 11:23:01 +0000
commit2e70e5e9f05362230980f2e1acf0cb76332c241e (patch)
tree315074f6e51340bed8f7e625e9b6b5dc1c60e6b3 /lib/libc/regex/regex2.h
parent117ae0dab37bc1cc35a0315ff2df8e77e35977e1 (diff)
downloadFreeBSD-src-2e70e5e9f05362230980f2e1acf0cb76332c241e.zip
FreeBSD-src-2e70e5e9f05362230980f2e1acf0cb76332c241e.tar.gz
Hindsight is wonderful, but I got cold feet over the crypt(3) default
so I am backing it out for now. The problem is that some random program calling crypt() could be passing a DES salt and the crypt(3) library would encrypt it in md5 mode and there would be a password mismatch as a result. I wrote a validater function for the DES code to verify that a salt is valid for DES, but I realized there were too many strange things to go wrong. passwd(1), pw(8) etc still generate md5 passwords by default for /etc/master.passwd, so this is almost academic. It is a big deal for things that have their own crypt(3)-ed password strings (.htaccess, etc etc). Those are the things I do not want to break. My DES salt recognizer basically checked if the salt was either 2 or 13 characters long, or began with '_' (_PASSWORD_EFMT1). I think it would have worked but I have seen way too much crypt() mishandling in the past.
Diffstat (limited to 'lib/libc/regex/regex2.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud