[Bug 1574058] Re: php-seclib: Call to undefined method Crypt_Base::Crypt_Base()

[Nish Aravamudan]

On 27.06.2016 [12:11:41 -0000], Robie Basak wrote:
> Careful. If the landing of one SRU breaks another package, it isn't
> sufficient just to SRU both. A Breaks: needs to be added so that users
> don't accidentally pick up one SRU without the other. See bug 1511735
> for an example of how this can go wrong.

Thank you for noticing this, Robie, very good points.

It's not a real "Breaks" in this case, thankfully.

> If I understand this correctly, what you want to do is:
> 
> SRU php-horde-mapi
> SRU this phpseclib with a Breaks: php-horde-map (<< version-just-SRUd)
> 
> Then ask the SRU team to land both together. Though with the Breaks, apt
> will generally do the right thing if both don't land together, although
> it still could confuse users ("why won't phpseclib update?").
> 
> I assumed that php-horde-mapi would actually be broken at runtime
> though, as opposed to a test positive only. If it's not broken at
> runtime, then I guess the consequence isn't so severe. I tend to fall on
> the side of fixing the dep8 test in an SRU anyway though, as otherwise
> the test becomes useless in detecting SRU regressions.

I'ts just a test positive issue, because PHP7 emits a warning to stderr
about deprecation (in src:phpseclib) of same-named constructors during
the test of php-horde-mapi. We can't fix phpseclib, as that causes
regressions like this one, so Debian (and 16.04) have add
src:php-phpseclib, which is actually v2 of phpseclib and is PHP7
compliant. Most packages have moved forward to v2, but not all, in
Stretch, so the older package still exists.

So, if I understand the process correct: this phpseclib update can be
uploaded. It will get stuck in -proposed because php-horde-mapi will
regress its tests. Once we have a proper fix in php-horde-mapi, we can
SRU that back and both will go through. However, given the SRU
timelines, etc., it might be prudent to wait for the php-horde-mapi fix
to be available before SRU'ing either.

Note also there is a much smaller fix that we have pushed to
php-horde-mapi in 16.10, so that phpseclib could sync in 16.10, and that
is to just add a

Restrictions: allow-stderr

to debian/tests/control, so the deprecation warning is not treated as a
failure.

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1574058

Title:
  php-seclib: Call to undefined method Crypt_Base::Crypt_Base()

Status in phpseclib package in Ubuntu:
  Fix Released
Status in phpseclib source package in Xenial:
  Confirmed
Status in phpseclib package in Debian:
  Fix Released

Bug description:
  [Impact]

  DokuWiki fails with a 500 internal server error when logging in.  This
  is caused by a regression in phpseclib introduced in 1.0.1-3 and
  subsequently fixed in 1.0.1-4.

  /var/log/apache2/error.log contains entries like the following:

  [Mon Apr 25 16:09:08.998092 2016] [:error] [pid 10897] [client 127.0.0.1:40832] PHP Fatal error:  Uncaught Error: Call to undefined method Crypt_Base::Crypt_Base() in /usr/share/php/Crypt/Rijndael.php:269
  Stack trace:
  #0 /usr/share/dokuwiki/inc/auth.php(503): Crypt_Rijndael->__construct()
  #1 /usr/share/dokuwiki/inc/auth.php(267): auth_decrypt(...)
  #2 /usr/share/dokuwiki/inc/auth.php(184): auth_login(...)
  #3 /usr/share/dokuwiki/inc/events.php(108): auth_login_wrapper(Array)
  #4 /usr/share/dokuwiki/inc/events.php(231): Doku_Event->trigger('auth_login_wrap...', true)
  #5 /usr/share/dokuwiki/inc/auth.php(117): trigger_event('AUTH_LOGIN_CHEC...', Array, 'auth_login_wrap...')
  #6 /usr/share/dokuwiki/inc/init.php(221): auth_setup()
  #7 /usr/share/dokuwiki/doku.php(29): require_once('/usr/share/doku...')
  #8 {main}
    thrown in /usr/share/php/Crypt/Rijndael.php on line 269

  [Test Case]

    1. Install the following packages:
       * dokuwiki (0.0.20140929.d-1ubuntu1)
       * apache2 (2.4.18-2ubuntu3)
       * libapache2-mod-php7.0 (7.0.4-7ubuntu2)
    2. Visit http://localhost/dokuwiki
    3. Log in

  [Regression Potential]

  The attached minimal diff reverts the patch added in 1.0.1-3, making
  it identical to 1.0.1-2.  This version is known to work according to
  the upstream Debian bug report.

  Client code that subclasses a php-seclib class and calls
  parent::__construct() should still work with the patch reverted
  because PHP will fall back to the old-style constructor name if
  __construct() is not found.

  The reverted patch was originally added to silence some deprecation
  warnings:

      PHP Deprecated:  Methods with the same name as their class will
  not be constructors in a future version of PHP

  These warnings will return with the patch reverted.

  Other than warnings, regressions are likely to appear as problems in
  the packages that depend on php-seclib:

    * Packages that directly depend on php-seclib:
      - civicrm-common
      - collabtive
      - dokuwiki
      - php-horde-mapi
      - php-numbers-words

    * Packages that directly recommend php-seclib:
      - php-horde-imp

    * Packages that indirectly depend on php-seclib:
      - drupal7-mod-civicrm (depends on civicrm-common)
      - wordpress-civicrm (depends on civicrm-common)
      - php-horde-activesync (depends on php-horde-mapi)

    * Packages that indirectly recommend php-seclib:
      - numerous Horde packages
      - php-text-captcha (via php-numbers-words)

  [Other Info]

  == Regression details ==
  Discovered in version: 1.0.1-3
  Last known good version: 1.0.1-2

  Original description:

  Facing the same issue as bug #819420 in Debian.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819420

  Appears fixed in Debian's version 1.0.1-4, can we get the fix in
  Ubuntu Xenial as well?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/phpseclib/+bug/1574058/+subscriptions