As the proud owner of that particular patch, I guess I should say something... :)
>>>>> "Daniel" == Daniel Martin at cush <[EMAIL PROTECTED]> writes: Daniel> Ok, I've looked at it. Daniel> I really don't know quite what to do with this. On the Daniel> one hand, automatically reading the shadow password Daniel> entries is desireable since it keeps old scripts working Daniel> without knowing whether shadow passwords are being used or Daniel> not. On the other hand, doing a getspnam for every getpw* Daniel> call causes serious performance issues. When I wrote the patch, I didn't have a 3000 entry /etc/passwd so was unaware of any major performance issue with getspnam. Daniel> The solution, as I said before, seems to be invoking some Daniel> kind of magic on the scalar that's second in the list Daniel> returned by getpw*. (what traditionally is the encrypted Daniel> password field) This, IMHO, is overkill. A less intrusive solution may be to do an setspent call in the setpwent code within p_sys.c. Unfortunately, my getspent man page seems to have gone missing so I can't check on the feasiblity of this solution right now. Daniel> Here's the problem: Perl has various kinds of builtin Daniel> magics, but all of them do highly specialized things, such Daniel> that adding a new kind of builtin magic necessitates Daniel> changes in several different places, and any new "shadow Daniel> password entry" magic type might be incompatible with Daniel> future versions of perl. Now there are two types of magic Daniel> reserved for use by extensions, but I'm loathe to use them Daniel> since it's hard to avoid name conflicts with those magics; Daniel> also, changing getpw* mucks with perl's internal code and Daniel> the docs seem to suggest that internal perl procedures Daniel> shouldn't use those types of magics. (Admittedly, a bit Daniel> of "U"-type magic might serve as a temporary fix, and may Daniel> be the best (read: most easily implemented) solution at Daniel> the moment) If you wanted to go that route it would make more sense to do a hidden tie on the pw scalar and use that to control the lookup. The you'd just have to find an appropriate namespace for such a beast. Daniel> Also, is the Cc: list on this mail too broad? Should Daniel> someone else be getting these messages too? Should this Daniel> be taken off debian-devel? It should, in fact, be on the p5p list. -- Stephen --- all coders are created equal; that they are endowed with certain unalienable rights, of these are beer, net connectivity, and the pursuit of bugfixes... - Gregory R Block -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]