[patch #1800] [Patch #1800] clean up some more crypt() things in idvec-verify.c

[noreply]

Patch #1800 has been updated. 

Project: 
Category: libshouldbeinlibc
Status: Open
Summary: clean up some more crypt() things in idvec-verify.c

Follow-Ups:

Date: Wed 08/06/2003 at 11:48
By: jeroen

Comment:
We don't have to make crypt() weak nor check whether crypt() exist because it's 
always in glibc now.
-------------------------------------------------------

Date: Wed 08/06/2003 at 13:07
By: marcus

Comment:
Right.  I have committed this change.  Thanks!
-------------------------------------------------------

Date: Thu 08/07/2003 at 00:13
By: marcus

Comment:
I have reverted this change.  Shame on you because you didn't test it (and 
shame on me for not testing it either, nor asking you if you did).

The pragma is necessary because not all programs linked to libshouldbeinlibc 
should also be linked to crypt.

The allowance for a missing crypt is not necessary anymore.  But I reverted 
that change as well for now, because the code
would segfault otherwise if crypt happened not to be linked in by accident.  A 
modified patch that disables plaintext passwords (which don't make much sense 
today anymore, I think), would be ok, assuming it is properly tested.


-------------------------------------------------------

Date: Fri 08/08/2003 at 20:55
By: jeroen

Comment:
I uploaded a new patch, this will return ENOTSUP when crypt is not available 
instead of using plain-text passwords. I tested it and it works fine.

-------------------------------------------------------

Date: Fri 08/08/2003 at 22:12
By: marco_g

Comment:
I have some serious doubt about this piece of code anyway. IMHO we shouldn't 
touch this unless we are really sure about the consequences. Is it for exmple 
possible that crypt isn't defined (or better returns ENOSYS) because of crypt 
import/export restrictions?

And I think it is better to have plain text passwords than nothing at all. 
Perhaps if crypt isn't available the password should be ignored and the used 
can login (or root can login...). See how other parts of libshouldbeinlibc deal 
with a missing root user in /etc/passwd.

-------------------------------------------------------

Date: Sat 08/09/2003 at 18:57
By: marcus

Comment:
The crypt export restrictions have in fact been the reason that this provision 
for plaintext passwords were made.

However, today this is not an issue anymore.  Either because of the relaxed 
export restrictions, or because crypt add ons for glibc exist outside the US.  
As you want it :)

The reason to return an error is if you accidentially link your password 
checking program not against -lcrypt, then you would get a wrong password 
message with the current code, instead seeing the error.  Do you agree that 
this is better behaviour?

The missing root user is really a hack.  I have my doubts about that one, too, 
but this is a different question.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://savannah.gnu.org/patch/?func=detailpatch&patch_id=1800&group_id=30

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/