Hi!
Looks like 5.3.7 shipped with broken crypt() (see bug# 55439 and
http://svn.php.net/viewvc/?view=revision&revision=315218) - and I
think it's a serious problem since this means everybody's md5 passwords
will stop working - so should we make 5.3.7pl1?
And maybe not do these changes on 5.3, especially this close to the release?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Am 20.08.2011 01:16, schrieb Stas Malyshev:
Hi!
Looks like 5.3.7 shipped with broken
crypt()(see bug# 55439 and
http://svn.php.net/viewvc/?view=revision&revision=315218) - and I think it's a serious problem since this means
everybody's md5 passwords will stop working - so should we make 5.3.7pl1?And maybe not do these changes on 5.3, especially this close to the release?
+1
please fix https://bugs.php.net/bug.php?id=55283 too because it is
not acceptable to wait months until mysql over ssl works again and
on the other hand staing at 5.3.6 is no option for security reasons
+1
Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Saturday, August 20, 2011 1:17 AM
To: PHP Internals
Subject: [PHP-DEV] 5.3.7pl1Hi!
Looks like 5.3.7 shipped with broken
crypt()(see bug# 55439 and
http://svn.php.net/viewvc/?view=revision&revision=315218) - and I
think
it's a serious problem since this means everybody's md5 passwords will
stop
working - so should we make 5.3.7pl1?And maybe not do these changes on 5.3, especially this close to the
release?Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
To unsubscribe,
visit:
http://www.php.net/unsub.php
Hi!
Looks like 5.3.7 shipped with broken
crypt()(see bug# 55439 and
http://svn.php.net/viewvc/?view=revision&revision=315218) - and I
think it's a serious problem since this means everybody's md5 passwords
will stop working - so should we make 5.3.7pl1?And maybe not do these changes on 5.3, especially this close to the
release?
Yeah, that one was my fault. I had run the tests after switching it to
strncat() but I didn't do it after the strlcat() switch and I obviously
missed the buffer length difference between strlcat and strncat.
The secondary problem is that we are not doing a good job running our
tests prior to releases. I think this is mostly because we have way too
many tests that fail and one more or less failing test gets lost in the
noise.
-Rasmus
Hi!
The secondary problem is that we are not doing a good job running our
tests prior to releases. I think this is mostly because we have way too
many tests that fail and one more or less failing test gets lost in the
noise.
Yes, this is a problem: here
http://gcov.php.net/viewer.php?version=PHP_5_4&func=tests we have 218
failing tests. Unit test system with this amount of failures is next to
useless. So if we have some component that is buggy (like DateTime) or
not updated - we need to figure out a way to separate tests that we know
would fail (XFAIL?) from tests that should not fail and not release a
version until the second number is 0. Otherwise we get broken releases.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi,
Right, I sadly did not run them as I use to between the last RC and
final but only the apps tests (wp&co), which do not use crypt's md5. I
also agree about the amount of failing tests and warnings, for the
same reasons. However checking the delta between two releases should
help too (that's what I use to stop a release).
btw, can we go with 5.3.8 instead? I really don't like the pl thing :)
Cheers,
Hi!
The secondary problem is that we are not doing a good job running our
tests prior to releases. I think this is mostly because we have way too
many tests that fail and one more or less failing test gets lost in the
noise.Yes, this is a problem: here
http://gcov.php.net/viewer.php?version=PHP_5_4&func=tests we have 218
failing tests. Unit test system with this amount of failures is next to
useless. So if we have some component that is buggy (like DateTime) or not
updated - we need to figure out a way to separate tests that we know would
fail (XFAIL?) from tests that should not fail and not release a version
until the second number is 0. Otherwise we get broken releases.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
btw, can we go with 5.3.8 instead? I really don't like the pl thing :)
Well, that's for the 5.3 RM to decide :)
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi,
Hi!
btw, can we go with 5.3.8 instead? I really don't like the pl thing :)
Well, that's for the 5.3 RM to decide :)
I think it's in the README.RELEASE_PROCESS that we don't do pl anymore but clear version numbers. So it will be 5.3.8.
johannes
--
Sent from mobile device
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
From my phone. Apologies for brevity and typos.
The secondary problem is that we are not doing a good job running our
tests prior to releases. I think this is mostly because we have way
too
many tests that fail and one more or less failing test gets lost in
the
noise.
This was a major problem when Drupal added automated testing. Our
solution was to get to a 100% pass rate via a combination of fixing
bugs but also removing failing tests (moving them to patches against
bug reports in the issue queue or occasionally commenting out
assertions). This means we're able to tell instantly if there's a
regression committed when there's test coverage for it, since we test
patches in the queue this usually happens before that anyway.
Tests that fail stay in the queue until they're committed along with
the accompanying bug fix. It's not ideal but it was impossible to keep
track any other way.
Nat
-Rasmus
Looks like 5.3.7 shipped with broken
crypt()(see bug# 55439 and
http://svn.php.net/viewvc/?view=revision&revision=315218) - and I
think it's a serious problem since this means everybody's md5
passwords will stop working - so should we make 5.3.7pl1?
No, we should call it 5.3.8.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Hi!
Looks like 5.3.7 shipped with broken
crypt()(see bug# 55439 and http://svn.php.net/viewvc/?view=revision&revision=315218) - and I think it's a serious problem since this means everybody's md5 passwords will stop working - so should we make 5.3.7pl1?And maybe not do these changes on 5.3, especially this close to the release?
5.3.8 and lets not apply the coverity fixes during the final RC.
S
Hi!
Looks like 5.3.7 shipped with broken
crypt()(see bug# 55439 and http://svn.php.net/viewvc/?view=revision&revision=315218) - and I think it's a serious problem since this means everybody's md5 passwords will stop working - so should we make 5.3.7pl1?And maybe not do these changes on 5.3, especially this close to the release?
5.3.8 and lets not apply the coverity fixes during the final RC.
Let not apply anything before the final RC. That's how it should be.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Am 20.08.2011 01:16, schrieb Stas Malyshev:
will stop working - so should we make 5.3.7pl1?
Not 5.3.7pl1 but rather 5.3.8, please.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/