Where can you find info about services versions released?

MMarko

Verified User
Joined
May 10, 2006
Messages
73
Location
eu
So when update like this become available:

PHP 8.3 8.3.31* to 8.3.31 update is available

Where can you find out more about this particular update? Earlier there was Required Services subforum for this...
 
I understand that, but would be good to have something about that published as changelog / update somewhere to be able to double check if this was not maybe malicious update / supply chain attack.
 
@johannes so what info do you see from php.net 8.3 official changelog about patching existing latest ver of php 8.3.31 that DA published couple days ago?
 
I saw this in the build log

replacing 'sapi/litespeed' with files from LiteSpeed Technologies '/usr/local/directadmin/custombuild/cache/ls-php-litespeed-8.3.tgz'
Configuring PHP 8.4 ...
Maybe this?
 
The * symbol near the software version is an internal CustomBuild mechanism to prompt users to rebuild the software. It means the software version from the upstream will be the same, but CustomBuild might execute slightly different commands when building it or apply some additional patches. It can never cause a supply chain attack because CustomBuild will reuse the same upstream sources package that was already downloaded and will not re-download it again.

Examples of when the * version were used by CustomBuild:
  • For Apache 2.4.67, upstream fixed a problem when .htaccess files can be used to access arbitrary files using the apache user. We have added additional patch to extend the fix provided by upstream to cover more directives in .htaccess.
  • For MySQL/MariaDB CustomBuild changed the default location of the UNIX socket used for connections to the DB. It show * near the version if MySQL/MariaDB still uses the old UNIX socket location.
  • For Exim 4.99, we provide additional patch to fix crashes under some circumstances, the patch is taken from Exim upstream but Exim team does not include this patch in the 4.99 releases.
  • For PHP we used to add patches for security fixes for old PHP releases, however there were no mechanism to prompt users to rebuild old PHP versions. In the DA 1.702 a new mechanism is introduced to track how many patches were applied when building PHP. It will show version with * if CustomBuild have more patches for that particular version.
In the upcoming DA 1.703 all PHP versions will show * in the version (ask to be recompiled) because we are adding patches to make old PHP versions compatible with Ubuntu 26. These are not security patches, just making sure very old PHP code can still be compiled using the latest GCC (version 15).


To sum up, there could be various reasons why the same version with * appears in CustomBuild updates list. It just means CB asks to recompile/reinstall this software.
 
Ok, are these examples logged in change log for each version?

What if the patches introduced are malicious, this could be problem and this is why it would be nice to have this in changelog to which we can refer and double check.
 
No, the instances of * version usage is not explicitly logged in the change-log. But we do log what we actually change. For example MySQL/MariaDB socket location change-log entry:

The MySQL and MariaDB server configuration is updated to make sure the UNIX socket for accepting client connections will be created in /run/mysql/mysql.sock. Before this change, the default socket location used to be /var/lib/mysql/mysql.sock.
...

CustomBuild changes are created by the same people who write the DA change-log. This is DA development team. From a DA developer perspective it would be far more easier to add malicious code into the main DA binary than to patch 3rd party software. All patches that we ship are publicly visible in the custombuild/patches directory. The CustomBuild code is also easy to inspect with the --debug flag (for example da build --debug versions). If you are worried that DA team might add malicious code, you should not use this product at all.

One more recent example - RoundCube. We have updated the install script to adjust PHP-FPM and Nginx webserver configuration when RoundCube is used. It has nothing to do with the RoundCube code, but makes sure all Nginx users rebuild RoundCube with the new FPM config. The * near RoundCube version makes it easy to see the software needs to be reinstalled.
 
Back
Top