New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[5.1] TUF-based core updates #42799
[5.1] TUF-based core updates #42799
Conversation
Fix DB structure
Tuf/databasestorage
Co-authored-by: Tobias Zulauf <zero-24@users.noreply.github.com>
Database stuff
I've successfully tested all 7 scenarios. In addition I've tested that updating from 4.4.3 to the package with this PR works with MySQL and PostgreSQL. In scenario 3 I made additional tests for custom update URLs in the old XML format created by drone for pull requests:
In scenario 6 I additionally tested a not fulfilled database requirement by hacking the getVersion method of the DB driver. I've noticed that in opposite to now without this PR, only the details of the first not fulfilled requirement are shown, but not both in case if both the PHP and the database requirement are not fulfilled. I've made a PR to the branch of this PR for an improvement about that, but it can also be done later with a follow-up PR in the CMS repo. Important note for other testers: When testing scenario 7 on a current 5.1-dev branch or a 5.1.0-alpha4 with this PR applied, you will get errors after the update which come from the update not being up to date with latest changes in the 5.1-dev branch, so some admin modules which were converted to the new service provider structure will be downgraded to the before status and so cause failures. These are not related to this PR but to the update used for testing being out of date. |
…k-enhancement [CMS PR 42799] Show all failed constraint checks and not only the first one
Co-authored-by: Brian Teeman <brian@teeman.net>
Co-authored-by: Brian Teeman <brian@teeman.net>
I have tested this item ✅ successfully on 5585d32 This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/42799. |
is the CLI installation TUF aware ? |
It should be as it uses the model. But as I just could see the CLI doesn't show any details of failed constraints in scenario 6. But that was also the case without TUF, I think.
|
Hmm, it seems not to be ready for the CLI. Trying the update (scenario 7) with
|
In the update log after CLI update attempt:
|
That failure is not related to the actual TUF implementation but to the fact that the test release has invalid package URLs on 2 of 3 mirrors. The backend updater will fall back to the working one, the CLI updater fails on the first package. The information retrieval (that's the key part) works as expected. |
Ready, Set, Go... This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/42799. |
Thanks to all involved in this great project! 🚀 💯 🚀 |
so it's a new feature and/or it is a release blocker ? does it work from cli ? |
Summary of Changes
This pull requests changes the way how Joomla retrieves update information for Joomla core.
So far, the information about available updates has been retrieved using an XML file hosted on the Joomla.org CDN. Whatever information was written in that XML file was trusted and there was no way for a Joomla installation of that update XML actually is a legit file distributed by the project.
This makes the project vulnerable to supply chain attacks, where an attacker, once he gains access to the update XML file, might be able to distribute malicious update packages. The already implemented security measure of package hashes is no proper mitigation for that scenario as the package URL und the package hashes are stored in the same XML.
In order to succesfully mitigate such attacks, we would like to use "The Update Framework" (short "TUF") to the Joomla core updater. We are not going to introduce the general concepts of TUF in this PR as it's very extensively documented at https://theupdateframework.io/
The main changes in this PR are:
Testing Instructions
Preparation steps
composer install
Scenario 1: successful retrieval of a legit core update via TUF
Scenario 2: blocked retrieval of a malicious core update via TUF
Scenario 3: successful retrieval of a core update via a custom XML server
Scenario 4: successful retrieval of an extension update via the existing XML mechanisms
Scenario 5: reinstall feature is available
administrator/components/com_joomlaupdate/src/Model/UpdateModel.php
and change line 119 from$updateURL = 'https://update.joomla.org/cms/';
to$updateURL = 'https://update.joomla.org/alpha/';
#__updates
table and change the version from 5.1.100 to 5.1.0-alpha4-dev (or whatever your local 5.1.x version is)Scenario 6: Constraint information is availabel
administrator/components/com_joomlaupdate/src/Model/UpdateModel.php
and change line 119 from$updateURL = 'https://update.joomla.org/cms/';
to$updateURL = 'https://update.joomla.org/alpha/';
libraries/src/Updater/ConstraintChecker.php
, line 151, replaceif (!$result) {
withif (!$result || true) {
to simulate a failed php constraintScenario 7: successful installation of a core update
administrator/components/com_joomlaupdate/src/Model/UpdateModel.php
and change line 119 from$updateURL = 'https://update.joomla.org/cms/';
to$updateURL = 'https://update.joomla.org/alpha/';
Test Queries
Valid production metadata - MySQL and MariaDB
Valid production metadata - PostgreSQL
Invalid test metadata - MySQL and MariaDB
Invalid test metadata - PostgreSQL
Link to documentations
Please select:
Kudos
This is not my personal work, a ton of people helped creating this feature and I would like to thank Harald, Benjamin, Niels, Martina, Hannes, Magnus, Tobias, Franciska, Timo, Stefan and Elias for their time and contributions!