crypt and POSIX

[Joel Sherrill]

On Thu, Aug 13, 2020 at 11:49 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> 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
> >> <sebastian.huber at embedded-brains.de <mailto:
> sebastian.huber at embedded-brains.de>>
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200814/5eabeb9c/attachment.html>