scsh-hackers
[Top] [All Lists]

[Scsh-hackers] crypt issues

To: scsh-hackers@lists.sourceforge.net
Subject: [Scsh-hackers] crypt issues
From: shivers@cc.gatech.edu
Date: Sun, 11 Feb 2001 13:29:22 -0500
List-id: Discussion among the implementors <scsh-hackers.lists.sourceforge.net>
Reply-to: shivers@cc.gatech.edu
Sender: scsh-hackers-admin@lists.sourceforge.net
       ; Simply calls the C library function and returns its return value.
       (crypt key salt)
   This was not Posix when I did the very first implementation of scsh.
   Of course, neither were symlinks, and I put those in. How portable is
   crypt?

Mike? What do you know?

My linux man page says it conforms to "SVID, X/OPEN, BSD 4.3," so that is
pretty solid -- (SVID union BSD) is big, X/OPEN is also big. So that's all
good.

   >>>> Doesn't FreeBSD complicate matters with the crypt-classic/crypt-MD5
   >>>> split?

   No, FreeBSD uses the first two characters to determine which algorithm
   to use and is therefore backward compatible.

Heh? As I understand it, the *result* is tagged with the prefix. So *crypt*
doesn't know. *Login* knows. It checks my stored passwd in /etc/passwd, and
the first two chars tell it which function to use to encrypt my supplied
passwd in order to produce the string compared with the entry in /etc/passwd.
I can't find the relevant FreeBSD doc on my FreeBSD box, tho. E.g., I can't
figure out how to get an MD5-style passwd.

However, I did notice that FreeBSD's crypt takes a much hairier salt
argument, with backwards support for the standard two-char salt. Is
this going to be adequate for your purposes, Mike?

I also grumpily note crypt(3) isn't thread safe, hence would require a lock
in an OS-thread implementation. Can we say this loudly in the comments
above the function?
    -Olin


<Prev in Thread] Current Thread [Next in Thread>