group.of.nepali.translators team mailing list archive

[Nish Aravamudan <nish.aravamudan@xxxxxxxxxxxxx>]

** Changed in: php7.0 (Ubuntu)
       Status: New => Fix Committed

** Also affects: php7.0 (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Also affects: php7.0 (Ubuntu Yakkety)
   Importance: Undecided
       Status: New

** Description changed:

+ SRU team: as this is a SRU and security regression, I'm hopeful we can
+ bypass the 7-day waiting period, presuming @jbruijn or I can test the
+ version from -proposed first.
+ 
  [Impact]
  
-  * The prior SRU of 7.0.15 included an upstream regression to MySQL
+  * The prior SRU of 7.0.15 included an upstream regression to MySQL
  support with large blobs.
  
-  * The fix has not yet been published in an upstream release, but is
+  * The fix has not yet been published in an upstream release, but is
  planned for 7.0.17.
  
  [Test Case]
  
  - Ubuntu 16.04
  - MariaDB Server (not tested on mysql, but I expect similar results)
  - php 7.0 (7.0.15)
  - phpMyAdmin
  
  Configuration:
  MariaDB: max_allowed_packet = 128M
  php: post_max_size and upload_max_filesize raised to 128M
  
  Import some SQL data, for instance: https://we.tl/vb37KISpUU.
  This will build you a MyISAM table with 4 columns, 3x varchar(1) and 1 longblob. The table will have one big blob in it, with 32Mbyte worth of 0x20 (space)
  
  Downloading the binary through phpMyAdmin on 7.0.15 will produce a file
  with a null-character inserted at (for my setup) 0xFFFFF6, the rest of
  the file is as expected.
  
  [Regression Potential]
  
-  * This upload includes the upstream fix, as well as testcases for the
+  * This upload includes the upstream fix, as well as testcases for the
  same. As this is a fix to an existing regression, I do not believe there
  is any chance of regression and it should be caught by the test sutie.
  
  ---
  
  I'm running a web application serving rather big binary blobs from a
  MariaDB table. After the unattended update (7.0.8-0ubuntu0.16.04.3 to
  7.0.15-0ubuntu0.16.04.2), the application would routinely break while
  trying to fetch a >16Mbyte row from the database server.
  
  Requests resulting in a row under 16Mbyte are processed normally,
  anything above it would return columns in the wrong order, and right
  around 0xFFFFF2 a null-character (0x00) is inserted into the stream
  (when the resulting file is compared to one served with the version used
  previously)
  
  Rolling back to 7.0.4-7ubuntu2 immediately fixed the issue. I'm pretty
  sure the problem was introduced somewhere between 7.0.8 and 7.0.15, but
  I cant find anything relevant in the changelog for those versions.
  
  Please let me know what I can do to assist!

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1668017

Title:
  Large mysql requests broken after security update, null character
  inserted close to 16MB boundary

Status in php7.0 package in Ubuntu:
  Fix Committed
Status in php7.0 source package in Xenial:
  New
Status in php7.0 source package in Yakkety:
  New

Bug description:
  SRU team: as this is a SRU and security regression, I'm hopeful we can
  bypass the 7-day waiting period, presuming @jbruijn or I can test the
  version from -proposed first.

  [Impact]

   * The prior SRU of 7.0.15 included an upstream regression to MySQL
  support with large blobs.

   * The fix has not yet been published in an upstream release, but is
  planned for 7.0.17.

  [Test Case]

  - Ubuntu 16.04
  - MariaDB Server (not tested on mysql, but I expect similar results)
  - php 7.0 (7.0.15)
  - phpMyAdmin

  Configuration:
  MariaDB: max_allowed_packet = 128M
  php: post_max_size and upload_max_filesize raised to 128M

  Import some SQL data, for instance: https://we.tl/vb37KISpUU.
  This will build you a MyISAM table with 4 columns, 3x varchar(1) and 1 longblob. The table will have one big blob in it, with 32Mbyte worth of 0x20 (space)

  Downloading the binary through phpMyAdmin on 7.0.15 will produce a
  file with a null-character inserted at (for my setup) 0xFFFFF6, the
  rest of the file is as expected.

  [Regression Potential]

   * This upload includes the upstream fix, as well as testcases for the
  same. As this is a fix to an existing regression, I do not believe
  there is any chance of regression and it should be caught by the test
  sutie.

  ---

  I'm running a web application serving rather big binary blobs from a
  MariaDB table. After the unattended update (7.0.8-0ubuntu0.16.04.3 to
  7.0.15-0ubuntu0.16.04.2), the application would routinely break while
  trying to fetch a >16Mbyte row from the database server.

  Requests resulting in a row under 16Mbyte are processed normally,
  anything above it would return columns in the wrong order, and right
  around 0xFFFFF2 a null-character (0x00) is inserted into the stream
  (when the resulting file is compared to one served with the version
  used previously)

  Rolling back to 7.0.4-7ubuntu2 immediately fixed the issue. I'm pretty
  sure the problem was introduced somewhere between 7.0.8 and 7.0.15,
  but I cant find anything relevant in the changelog for those versions.

  Please let me know what I can do to assist!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/php7.0/+bug/1668017/+subscriptions