#1
Reasonable concern "What if people upgraded, use the (wrong, old and non-serviced) mod-php happily and will now be broken by the SRU?
=> As shown above, once you are in this situation your mod-php is doing nothing.
That IMHO invalidates the regression concern for that set of users.
Only if you would manually ensure to keep all of the bionic php stack (libapache2-mod-php7.2 php7.2-cli php7.2-common php7.2-json php7.2-opcache php7.2-readline) installed from bionic would it still work.
I tried bryce PPA on this special corner case of already a special situation.
Yes it would upgrade (as intended)
The following packages were automatically installed and are no longer required:
libargon2-0 php7.2-cli php7.2-common php7.2-json php7.2-opcache php7.2-readline
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
libapache2-mod-php libapache2-mod-php7.4 php7.4-cli php7.4-common php7.4-json php7.4-opcache php7.4-readline
The following packages will be upgraded:
libapache2-mod-php7.2
1 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
PHP is still working, but now in 7.4 instead of the former 7.2.
#2
"Is this just our case, after all one of the server team filed it?"
let me be honest - I'm not a php user or web server admin. But other than this bug we know that "in the wild" this has happened more than a few times.
Bryce has mentioned that while working on this he found a few external references of people hitting and working around it in some way.
#3
Why do we consider this important "now" so late"?
Well, we have to admit of not seeing/knowing it earlier -> that explains the lateness.
I'm (personally, I don't know how bad that really is as I'm neither a PHP nor a security expert) concerned that people might expose secrets by accident.
Imagine the former php code used on bionic was this:
$ echo '<html> <head> <title>Test</title> </head> <body> <?php echo "<p>You only see this</p>"; # secret to DB is foobar ?> </body> </html>' > /var/www/html/index.php
On the web page as served to people on Bionic they saw see:
"You only see this".
But after upgrading to Focal the bug is active and people will see:
"You only see this; # secret to DB is foobar ?>"
I know it would be bad practice to put such secrets there in the first place, but still for me this gives the importance of the issue a slight bump.
I'm not sure if this is convincing enough, but I considered it worth to share/summarize.
Relating this example above to a few details:
#1
Reasonable concern "What if people upgraded, use the (wrong, old and non-serviced) mod-php happily and will now be broken by the SRU?
=> As shown above, once you are in this situation your mod-php is doing nothing.
That IMHO invalidates the regression concern for that set of users.
Only if you would manually ensure to keep all of the bionic php stack (libapache2- mod-php7. 2 php7.2-cli php7.2-common php7.2-json php7.2-opcache php7.2-readline) installed from bionic would it still work.
I tried bryce PPA on this special corner case of already a special situation.
Yes it would upgrade (as intended) mod-php libapache2- mod-php7. 4 php7.4-cli php7.4-common php7.4-json php7.4-opcache php7.4-readline mod-php7. 2
The following packages were automatically installed and are no longer required:
libargon2-0 php7.2-cli php7.2-common php7.2-json php7.2-opcache php7.2-readline
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
libapache2-
The following packages will be upgraded:
libapache2-
1 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
PHP is still working, but now in 7.4 instead of the former 7.2.
#2
"Is this just our case, after all one of the server team filed it?"
let me be honest - I'm not a php user or web server admin. But other than this bug we know that "in the wild" this has happened more than a few times.
Bryce has mentioned that while working on this he found a few external references of people hitting and working around it in some way.
#3
Why do we consider this important "now" so late"?
Well, we have to admit of not seeing/knowing it earlier -> that explains the lateness.
I'm (personally, I don't know how bad that really is as I'm neither a PHP nor a security expert) concerned that people might expose secrets by accident.
Imagine the former php code used on bionic was this:
$ echo '<html> <head> <title>Test</title> </head> <body> <?php echo "<p>You only see this</p>"; # secret to DB is foobar ?> </body> </html>' > /var/www/ html/index. php
On the web page as served to people on Bionic they saw see:
"You only see this".
But after upgrading to Focal the bug is active and people will see:
"You only see this; # secret to DB is foobar ?>"
I know it would be bad practice to put such secrets there in the first place, but still for me this gives the importance of the issue a slight bump.
I'm not sure if this is convincing enough, but I considered it worth to share/summarize.