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ý <ondrej@sury.org
hi,
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: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)
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
Hi Pierre,
hi,
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)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ý <ondrej@sury.org
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).
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 systemcrypt()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.
Right, that sounds good but it will be a pain to maintain :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org