On Thu, Aug 13, 2020 at 11:49 PM Sebastian Huber < [email protected]> wrote:
> On 13/08/2020 21:52, Chris Johns wrote: > > > On 13/8/20 11:47 pm, Joel Sherrill wrote: > >> On Thu, Aug 13, 2020 at 7:52 AM Sebastian Huber > >> <[email protected] <mailto: > [email protected]>> > >> wrote: > >> > >> On 13/08/2020 14:49, Joel Sherrill wrote: > >> > >> > Why was crypt() removed? It is in the FreeBSD version at the > bottom of > >> > the file. > >> > > >> > > https://github.com/freebsd/freebsd/blob/master/lib/libcrypt/crypt.c > >> It is not thread-safe. > >> > >> But it is standards compliant. > > Could it be added and just return NULL or even generate an internal > error? The > > lack of crypt stopped me from using and it made me consider the issues. > It is > > easy to forget these things when adding passwords to the console or > telnet > > server and really hard to see an issue. > > If you prefer a run time error to a link time error you can add > something like this: > > char * > crypt(const char *passwd, const char *salt) > { > errno = ENOSYS; > return NULL; > } > We came to general agreement that link-time errors were preferable to run-time ones during the SMP discussions. So no, I wouldn't want that. It is either a functional implementation with the known reentrancy issues or it is missing. > > The ready to use shell function to do a login check is: > > extern bool rtems_shell_login_check( > const char *user, > const char *passphrase > ); > > > > >> And this would seem to violate the rules of source transparency in the > >> way the code was removed. If you wanted to disable it, it should have > >> been wrapped in ifndef __rtems__. > > I am confused, the code in cpukit/libcrypt is not from FreeBSD? > The file "cpukit/libcrypt/crypt.c" is not from FreeBSD, so there is no > point of having #ifndef __rtems__ stuff in it. Other files in the > libcrypt are from FreeBSD. > OK. That's why they looked familiar and I missed that crypt.c wasn't BSD. --joel
_______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
