The GNU Hurd - Patches: patch #1800, clean up some more crypt() things...
You are not allowed to post comments on this tracker with your current authentication level.
patch #1800: clean up some more crypt() things in idvec-verify.c
Submitter: | Jeroen Dekkers <jeroen> | ||
Submitted: | Wed 06 Aug 2003 09:46:45 AM UTC | ||
Category: | libshouldbeinlibc | Priority: | 5 - Normal |
Status: | Done | Privacy: | Public |
Assigned to: | marcus | Open/Closed: | Closed |
Planned Release: | None | ||
Wiki-like text discussion box: | libcrypt is actually external nowadays :)
|
Sat 09 Aug 2003 04:57:02 PM UTC, comment #5: |
Marcus Brinkmann <marcus> |
Fri 08 Aug 2003 08:12:22 PM UTC, comment #4: 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?
|
Marco Gerards <marco_g> |
Fri 08 Aug 2003 06:55:24 PM UTC, comment #3: 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.
|
Jeroen Dekkers <jeroen> |
Wed 06 Aug 2003 10:13:18 PM UTC, comment #2: 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).
|
Marcus Brinkmann <marcus> |
Wed 06 Aug 2003 11:07:44 AM UTC, comment #1: Right. I have committed this change. Thanks! |
Marcus Brinkmann <marcus> |
Wed 06 Aug 2003 09:46:45 AM UTC, original submission:
We don't have to make crypt() weak nor check whether crypt() exist because it's always in glibc now. |
Jeroen Dekkers <jeroen> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 8 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2020-01-27 | sthibaul | Status | None | Done | |
Open/Closed | Open | Closed | |||
Wiki-like text discussion box | libcrypt is actually external nowadays :) And support for checking for it has been added | ||||
2003-08-08 | jeroen | Patch Code | Modified - New Version | ||
2003-08-06 | marcus | patch_status_id | 2 | ||
2003-08-06 | marcus | patch_status_id | 1 | ||
Assigned to | None | None | |||
Closed on | - | - |
Powered by Savane 3.13-3230.
Corresponding source code
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.