If not, way not change this in the future and put the file needed for crypt(), since is a useful function for passwords, specially on web. I can't imagine actually using crypt()...
So? You completely missed the point.
No I didn't. If the point is to work with crypted passwords then the digest functions I mentioned blow this out of the water. If the point is to work with a passwd file then there are modules for that (but never having actually written anything to muck with /etc/passwd or /etc/master.passwd I don't know their names). Or then there is Apache passwd file - but there's a module for that.
Seeking Green geeks in Minnesota
| [reply] |
Yes you did.
crypt is a builtin perl function.
Because of the reasons gmpassos lists, there is no reason not to include the sourcecode to crypt with the perl source.
It has nothing to do with actually using crypt as a form of encryption over SH1 or whatnot (it's not about cryptograpy, but about including the sourcecode for a builtin perl function).
Get it now? -- BTW, best form of encryption is a bitwise or (it's not, but who cares, that's not at argument here)
| [reply] |
And you missed that the other reason for posting is that gmpassos wants to be able to use crypt() for password checking in web apps. So regardless of whether crypt() is actually included or not there are better things out there that should be used anyway. I suppose this is like having dbmopen() in core — there are people who would miss it were it to disappear (given that I understand things like DB_File replace it) but new development shouldn't be using it anyway.
Seeking Green geeks in Minnesota
| [reply] |
And if you are dealing with /etc/passwd, then you already have a library that contains crypt(), so you don't need to get one 'by hand'. If you don't have a library that contains crypt, then where did the passwords in /etc/passwd come from?
| [reply] |