# Use system crypt() when possible - Thread: https://externals.io/message/54803 - Original archive: https://news-web.php.net/php.internals/54803 - Started by ondrej@sury.org on 2011-08-22T19:51:08+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #54803 — ondrej@sury.org — 2011-08-22T19:51:08+00:00 URL: https://externals.io/message/54803#54803 Hi, I wrote this patch sometime ago and Debian package uses it: https://bugs.php.net/bug.php?id=51254 which in turn made Debian packages not-vulnerable to #55439. (But I have failed too, I should really start to check to output of the tests when building the package and compare them for any regressions.) So I will (ab)use this time and ask for a feedback (again). I only received this from Pierre: > Not sure I agree with these changes, they are not supposed to be valid. I don't have the time now to reply with a detailed explanation but we will do it asap. and the detailed explanation never came. What the patch does: - it changes the m4 script to check for each individual cipher and if found it will use the system library for found ciphers, it will use PHP implementation for the rest (not-found) O. -- Ondřej Surý Hi, > > I wrote this patch sometime ago and Debian package uses it: > > https://bugs.php.net/bug.php?id=51254 > > which in turn made Debian packages not-vulnerable to #55439. That's a bit easy to come up with that, I don't think either that we should explain again why what was done with 5.3.7-final was wrong in all possible ways and why we are all responsible for this mistake :) > (But I > have failed too, I should really start to check to output of the tests > when building the package and compare them for any regressions.) :) > So I will (ab)use this time and ask for a feedback (again). I only > received this from Pierre: > > > […] > > and the detailed explanation never came. > > What the patch does: > - it changes the m4 script to check for each individual cipher and if > found it will use the system library for found ciphers, it will use > PHP implementation for the rest (not-found) In 5.4+ it should be fine to apply it as long as it is well tested (and not only on Debian pls :), MFH once 100% tested (other esoteric systems), incl. phpt passing everywhere. Then main problem here is about systems doing weird or non standard things. Debian does or did that for a couple of things, I prefer true portability. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54817 — ondrej@sury.org — 2011-08-23T07:16:50+00:00 URL: https://externals.io/message/54803#54817 · In reply to: #54804 Hi Pierre, > hi, > > > […] > > In 5.4+ it should be fine to apply it as long as it is well tested > (and not only on Debian pls :), MFH once 100% tested (other esoteric > systems), incl. phpt passing everywhere. Cool, that was the response I was hoping for :). I can do some basic testing myself and I will speak with other maintainers and porters for help on the esoteric systems (Windows, VMS, etc... :)) > Then main problem here is about systems doing weird or non > standard things. Debian does or did that for a couple of things, I understand your reasoning (doesn't mean I agree :-) and I propose to add tests for hash results to config.m4, so if there is a weird thing in the system `crypt()` it will not be used. > I prefer true portability. On the other hand, one might argue that using the system crypt allows on-system compatibility, so you might use the saved passwords with other languages and system tools. So I will probably go the way I have outlined in the bug - the user will have the choice between system,internal,mixed with mixed as the default option. O. -- Ondřej Surý Cool, that was the response I was hoping for :). I can do some basic > testing myself and I will speak with other maintainers and porters for > help on the esoteric systems (Windows, VMS, etc... :)) Windows will always use the builting versions, so will VMS I think, have to check with Klaus, or if you can do it :) I was more thinking about some non compatible BSD versions and similar, which create non portable hashes or implementation (php side that is). > > […] > > I understand your reasoning (doesn't mean I agree :-) and I propose > to add tests for hash results to config.m4, so if there is a weird thing > in the system `crypt()` it will not be used. > > > […] > > On the other hand, one might argue that using the system crypt > allows on-system compatibility, so you might use the saved passwords > with other languages and system tools. > > So I will probably go the way I have outlined in the bug - the user > will have the choice between system,internal,mixed with mixed > as the default option. Right, that sounds good but it will be a pain to maintain :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org