Problem/Motivation
After resolving https://github.com/php-tuf/php-tuf/issues/396, we (@ergonlogic and myself) were hoping to be able to un-postpone #3477553: [PP-1] Manually test TUF-enabled Composer projects.
When testing TUF-enabled repositories in various Drupal cobebases, we noticed some unrelated issues which seem to be related to the generated metadata in the drupal.org TUF repository and/or drupal.org composer repository.
Diagnosing this issue is made more difficult by poor error reporting from composer-integration and possibly composer itself, captured in the upstream ticket https://github.com/php-tuf/composer-integration/issues/128. This ticket may be postponed on the upstream issue or other issues to make this error reporting more detailed and helpful.
Steps to reproduce
Setup:
ddev config --project-type drupal11 --docroot web
ddev start
ddev composer create-project "drupal/recommended-project:^11"
ddev composer config allow-plugins.php-tuf/composer-integration true
ddev composer require php-tuf/composer-integration:dev-main --dev
mkdir tuf
wget https://packages.drupal.org/8/metadata/1.root.json -O tuf/packages.drupal.org.json
wget https://packagist-signed.drupalcode.org/metadata/1.root.json -O tuf/packagist-signed.drupalcode.org.json
ddev composer tuf:protect https://packages.drupal.org/8
ddev composer config repositories.drupal-core composer https://packagist-signed.drupalcode.org
ddev composer tuf:protect https://packagist-signed.drupalcode.org
ddev composer -vv update
Reproducing the issue:
ddev composer require drupal/yoast_seo
(This module is a dependency of drupal/drupal_cms_seo_tools)
Expected result: drupal/yoast_seo package added to the project.
Actual result:
https://packages.drupal.org/8 could not be fully loaded (Maximum allowed download size reached. Downloaded 17395 of allowed 17395 bytes), package information was loaded from the local cache and may be out of date
In a bit more detail:
In CurlDownloader.php line 429:
Maximum allowed download size reached. Downloaded 17395 of allowed 17395 bytes
Affected modules/packages
A non-exhaustive list of affected modules, in alphabetical order:
- drupal/eca_modeller_bpmn
- drupal/yoast_seo
Proposed resolution
TBD
Remaining tasks
- Improve error reporting (see https://github.com/php-tuf/composer-integration/issues/128)
- Diagnose and fix where the actual issue is in the stack
User interface changes
Some error messages may change.
API changes
TBD
Data model changes
TBD
| Comment | File | Size | Author |
|---|
Comments
Comment #2
star-szrComment #3
star-szrComment #4
star-szrAs of today I can no longer reproduce this issue with
drupal/yoast_seo. I have started a list of modules/packages in the issue summary based on our previous findings, since I can still reproduce the issue usingdrupal/eca_modeller_bpmn:This may be a slightly different issue, since 1024 is the default/fallback.
Comment #5
star-szrFor now, to get more information when testing with ddev:
Then we can patch the site-local composer to get better error reporting:
Now when we run the site-local composer:
ddev exec vendor/bin/composer require drupal/eca_modeller_bpmn -vvAnd get something along these lines (note the packages.drupal.org URL now included in the message):
Comment #6
star-szrUploading a revised patch for composer that covers more exception messages since we seem to be hitting different instances of the MaxFileSizeExceededException.
Comment #7
star-szrQuick note about Xdebug/DDEV/composer, see also https://docs.ddev.com/en/stable/users/debugging-profiling/step-debugging...
Prepending
COMPOSER_ALLOW_XDEBUG=1in various forms didn't seem to be effective and I don't really feel the need to shave this yak, so:Allows you to stop on breakpoints while composer commands are running, and composer commands will now output a message like
Composer is operating slower than normal because you have Xdebug enabled. See https://getcomposer.org/xdebug.Comment #8
star-szrUpdate: Now I can't reproduce the issue with drupal/eca_modeller_bpmn either (using the steps to reproduce from the issue summary, but substituting drupal/eca_modeller_bpmn for the require step), and today I still can't reproduce with drupal/yoast_seo.
I did get the following error a few times, but can't reproduce anymore. This does seem to point to some error handling that could be added to php-tuf/php-tuf.
Comment #9
star-szrRunning
ddev composer require drupal/eca_modeller_bpmn -vva few times today on a fresh instance of the steps to reproduce setup.Getting all kinds of fun errors today, including some ones I've never seen before.
Attempt 1 result:
Attempts 2 and 3 result:
Attempt 4 result:
Success! 🤔 Wait, what?
Comment #10
star-szrTo add a few more notes:
Composer cache seems to play a part, so we started testing with the following set of commands (when using a site-local composer).
This results in a much more consistent reproduction of that particular problem (the 1024 bytes one). I suspect DDEV's global composer cache is the reason for some of the inconsistency when not clearing composer's cache. More details to come on the eca_modeller_bpmn-specific problem, the short version is: @ergonlogic and I narrowed down to it being a metapackage, and there not being a signed target for it in the TUF repository.
Comment #11
star-szrNoting here that we opened #3580996: Send metapackage composer metadata to Rugged for signing to take care of the "1024" bug with metapackages.
Comment #12
star-szrI believe I've come up with a list of packages that all have a similar issue, separate from the metapackage issue:
Edit: Removed packages that actually had a different type of error.
I took one of the bin files (essentially at random, just one that had popped up in previous testing), and tried requiring all of its packages, one by one. For now I've ignored modules that aren't D11 compatible, with the goal of just gathering data on the types of failures and hopefully finding some that fail consistently.
One-liner (requires jq) to generate a set of composer require commands from a bin file:
curl https://packages.drupal.org/8/metadata/bin_984-987.json | jq '.signed.targets | keys' | grep "drupal/" | grep -v "files/packages" | awk -F '/' '{print "ddev exec vendor/bin/composer require -vvv drupal/"$2}'If they seem to work, you may need to reset things by running:
Example from
cas:The actual metadata does say the size is 17965 so the bug doesn't seem to be with either of the php-tuf packages.
Snippet from https://packages.drupal.org/8/metadata/bin_4d8-4db.json :
Comment #13
ergonlogicIt looks to me like the latest release of
drupal/caswasn't added as a target.Based on:
We should see the latest release (
drupal/cas/3.0.1.0) in https://packages.drupal.org/8/metadata/bin_3b8-3bb.json. But it's not there.Compare that to the previous release (
drupal/cas/3.0.0.0) which we do find where expected: https://packages.drupal.org/8/metadata/bin_69c-69f.jsonSo I suspect this is a transitory failure, rather than a systemic one.
Comment #14
star-szrJust to note...
Edit: Removing a different category of error, will post that in another comment.
drupal/yoast_seois still giving:And from what I see in https://packages.drupal.org/8/metadata/bin_3d0-3d3.json the expected size says 17394, off by only one byte.
Comment #15
star-szrPossibly a different class of error that we are seeing some instances of:
drupal/lti_tool_providerdrupal/weightdrupal/mailjet_webform_subscriptiondrupal/shariffThese are consistently giving this type of error:
Comment #16
star-szrFound more byte size mismatches (similar but not necessarily the same as
drupal/casanddrupal/yoast_seo), note that the expected bytes are +1 from what's in the TUF metadata, but this is by design in the php-tuf composer-integration plugin.drupal/freelinking(expected 7670 bytes) https://packages.drupal.org/8/metadata/bin_30c-30f.json, package for 4.0.2.0 is in https://packages.drupal.org/8/metadata/bin_6f0-6f3.jsondrupal/formatage_models(expected 23827 bytes) https://packages.drupal.org/8/metadata/bin_3bc-3bf.json, package for 4.1.62.0 expected to be in https://packages.drupal.org/8/metadata/bin_bd8-bdb.json but not present, found 4.1.61.0 in https://packages.drupal.org/8/metadata/bin_610-613.json and requiringdrupal/formatage_models:4.1.61results in the same errordrupal/ldap_auth(expected 26223 bytes) https://packages.drupal.org/8/metadata/bin_9dc-9df.json, package for 2.0.22.0 is in https://packages.drupal.org/8/metadata/bin_a40-a43.jsonSigning off for now, haven't dug into verify if the latest versions have signed targets or not for the actual packages (to see if it's similar to the cas case).
Edit: Added more data after digging in further.
Comment #17
star-szrMaking this into a meta-issue, since we plan to spin off more issues from this one.
Comment #18
star-szrThese may end up being moved to different projects, but created new child issues: