[SRU] add PHP 8 on Apache2 conf & require PHP 8 (LP: #1975892) & CVE-2023-25727 & fix Recommends:

[William Desportes]

[ Impact ]

 * The PHP 8 support in Apache2 conf will allow users to have a correct PHP `include_path`
   and prevent issues like (https://github.com/phpmyadmin/phpmyadmin/issues/18299).
   This fix is already upstream Debian and released.

 * Forcing PHP 8 is required as users posted their concerns and invade Internet about this subject since then
    - See: https://github.com/phpmyadmin/phpmyadmin/issues/17503
    - See: https://github.com/phpmyadmin/phpmyadmin/issues/17523 (same as above but with the hate/heat enabled)
    - The packaging of symfony is made so it's impossible to run PHP < 8

 * Updating Recommends: will allow users to only have to do `apt install phpmyadmin`
   and not end up confused on why the webpage shows PHP source code.
   Internet is filled with users asking why there is PHP code displayed.
   This update is already upstream Debian and released.

 * And finally a CVE fix for CVE-2023-25727, PMASA-2023-1
   Already fixed upstream Debian and released.

[ Test Plan ]

 * To reproduce the `include_path` bug
   - install phpmyadmin and `libapache2-mod-php`
   - browse http://localhost/phpmyadmin
   - See the working UI
   - set `php_admin_value open_basedir .` in an Apache2 conf file
     of your choice in `/etc/apache2/conf-enabled/`.
   - restart Apache2
   - refresh the page, error 500 reported at phpMyAdmin issue #18299
   - add the config block from my patch
   - restart Apache2
   - See the working UI

 * To reproduce the forced PHP 8 message, install deb sury's PHP 7.4
   or an Ubuntu jammy with PHP 7.4 installed and Apache2
   and the packages mentioned in https://bugs.launchpad.net/ubuntu/+source/symfony/+bug/1975892
   - Now that everything is installed, admire the error 500
   - Apply my patch on `libraries/common.inc.php`
   - Refresh, and see the HTML
   Alternative solution, change the `PHP_VERSION_ID < 80000` to `true` and see the HTML.

 * To reproduce the "Recommends:" user problem
   - new VM
   - apt install phpmyadmin
   - service apache2 start
   - browse http://localhost/phpmyadmin
   - PHP code !
   - Install `libapache2-mod-php` and restart Apache2
   - You can see the login page

 * About CVE-2023-25727
   - create a file named `"><img src=x onerror=alert(11)>.sql`
   - install phpmyadmin and a local database
   - login
   - drag and drop the file
   - view the uploads and click `Failed` to see the XSS
   - apply the patch on `js/dist/drag_drop_import.js` to try it
     The real patch applies to the source file that is build at build time

[ Where problems could occur ]

 * If the Apache2 config was in a wrong syntax the server would not start
   If it did not work, the reproduction steps would not lead to no more 500 error.

 * If "Recommends:" was wrong you would be missing Apache2 by default.
   If the recommends allowed you to only have to install the package
   and you can see HTML and not PHP code, then it works.

 * Users could complain about the change for the PHP 8 version required,
   but that would mean they tweaked their distribution in a very weird way to have the symfony packages non buggy.

 * The CVE if not well applied the code would break when you test the drag and drop

[ Other Info ]

 * Do not forget to install the mbstring extension if it's not already here, this could be your first error 500 reason.
 * All the source code was pushed to https://salsa.debian.org/phpmyadmin-team/phpmyadmin/-/commits/ubuntu/jammy

Changelog:
  * Add PHP 8 support on apache2 conf
  * Require PHP >= 8.0 (Ref: LP: #1975892)
  * Recommend libapache2-mod-php and not apache2 to avoid
    displaying PHP code after the package install.
  * Add a patch for CVE-2023-25727, PMASA-2023-1

[William Desportes (williamdes)]

Pushed on a branch that forks the last ubuntu1 version: https://code.launchpad.net/~williamdes/ubuntu/+source/phpmyadmin/+git/phpmyadmin/+ref/ubuntu/jammy-stable

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Debdiff between ubuntu1 and ubuntu2" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Athos Ribeiro (athos-ribeiro)]

Hi William,

Thanks so much for working on these.

While a single debdiff will suffice here, could we split this in multiple bugs? Then if each changelog entry can refer to a different LP bug. This should make it easier for the SRU team to review this one (each of the bugs should be filled with an SRU template). We can use LP: #1975892 for the minimal version one.

Finally, we should make sure all these issues are also addressed in the Ubuntu development version as well (lunar) before we can SRU them. While we are in a freeze, we still have time to upload these to lunar since they are all bug fixes.

[William Desportes (williamdes)]

Hi Athos,

> While a single debdiff will suffice here, could we split this in multiple bugs? Then if each changelog entry can refer to a different LP bug. This should make it easier for the SRU team to review this one (each of the bugs should be filled with an SRU template). We can use LP: #1975892 for the minimal version one.

Okay, so I extract the bugs and keep the debdiff on this one ?
Not all entries have LP bugs to close, is that something problematic ?

> Finally, we should make sure all these issues are also addressed in the Ubuntu development version as well (lunar) before we can SRU them. While we are in a freeze, we still have time to upload these to lunar since they are all bug fixes.

Lunar has most of the fixes: https://launchpad.net/ubuntu/+source/phpmyadmin/4:5.2.1+dfsg-1
The CVE is referenced as "PMASA-2023-1" in d/changelog

Since Debian is in freeze, I can not upload new stuff to unstable. Should I wait to make a new SRU for the "libapache2-mod-php" change ?
It's already applied on the package phpsysinfo. And works as expected.

Please let me know more in detail what to do, this is my first SRU.

[Athos Ribeiro (athos-ribeiro)]

> Okay, so I extract the bugs and keep the debdiff on this one ?

Yes, you can leave the debdiff here if you want. I can apply and upload it once the paperwork is complete so all the proper bugs will be referenced.

Not all entries have LP bugs to close, is that something problematic ?

Yes, we want each entry to be related to an SRU in this case.

> Should I wait to make a new SRU for the "libapache2-mod-php" change ?

Up to you. We can go ahead of debian with a patch in Lunar if you want to. Since we won't be able to do this in time for the final freeze (my bad who did not reply to this thread last week), we could go for a zero-day SRU.

> Please let me know more in detail what to do, this is my first SRU.

File one bug per logical change being performed (one per changelog entry in this case) and ensure each of them have the SRU template filed.

Then, I will proceed to perform the uploads, and we will wait for an SRU team review. Once we get that approved, we will need to verify the fix in the proposed pocket and if everything is fine, the fixes should land in the updates pocket.

Thanks for working on this :)

[William Desportes (williamdes)]

> Up to you. We can go ahead of debian with a patch in Lunar if you want to. Since we won't be able to do this in time for the final freeze (my bad who did not reply to this thread last week), we could go for a zero-day SRU.

Thank you, that would be awesome (SRU: https://bugs.launchpad.net/ubuntu/+source/phpmyadmin/+bug/2016017)

> Yes, we want each entry to be related to an SRU in this case.

Okay I did open more SRU bugs for the paperwork:

- PHP 8 in Apache2 config: https://bugs.launchpad.net/ubuntu/+source/phpmyadmin/+bug/2016015
- PHP 8 needs to be required (the most important fix to upload): https://bugs.launchpad.net/ubuntu/+source/phpmyadmin/+bug/2016016
- The updated "Recommends:": https://bugs.launchpad.net/ubuntu/+source/phpmyadmin/+bug/2016017
- The CVE: https://bugs.launchpad.net/ubuntu/+source/phpmyadmin/+bug/2016018

[William Desportes (williamdes)]

Hi Athos,
Do I need to do somme action for this SRU to be uploaded to jammy?

[Athos Ribeiro (athos-ribeiro)]

Hi William, sorry for the delay here. I got caught up in a work related trip and let this one fall a bit behind.

I had a short discussion about this SRU with some other Ubuntu core-devs and during that conversation, I was let know that the change requiring PHP >= 8 could be frowned upon when proposed as an SRU since it could introduce a regression for some very specific use cases.

Since those use cases are custom (odd/non-supported) setups, I believe that by adjusting the SRU template we can indeed have a good case for an SRU. Therefore, I went ahead and made some adjustments to the SRU paperwork in LP: #2016016.

I then made some minor adjustments to the patch and filed https://code.launchpad.net/~athos-ribeiro/ubuntu/+source/phpmyadmin/+git/phpmyadmin/+merge/442711 so you can review that before we land it in mantic and start SRUing it along with any of the other missing patches, when applicable.

Finally, in case you are interested, check out how I changed the SRU paperwork in LP: #2016016. There is absolutely nothing wrong with the initial paperwork file there. However, being very descriptive in the test plan should make the whole SRU process smoother since the SRU reviewers will want to have a deep understanding of the problem before they accept the change.

[Athos Ribeiro (athos-ribeiro)]

OK, Now that we have LP: #2016015, #2016016, #2016017, #2016018, I believe we could close this one as invalid. WDYT?

I also went ahead and made some small changes to the SRU text in some of those bugs to ensure we provide enough information for the SRU reviewers! Feel free to revert or add to any of those changes :)

[Athos Ribeiro (athos-ribeiro)]

Closing this one as invalid as per the comment above (this bug was split in the 4 different bugs above).