Project

General

Profile

Actions

Bug #101675

closed

Updating EOL-releases using non-ELTS and depending on roave/security-advisories fails because of security advisories to ELTS

Added by Stefan P 6 months ago. Updated 6 months ago.

Status:
Rejected
Priority:
Should have
Assignee:
-
Category:
composer
Target version:
-
Start date:
2023-08-14
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
12
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

This github advisory suggests installing an ELTS release: https://github.com/advisories/GHSA-m8fw-p3cr-6jqc

These advisories are used by https://github.com/Roave/SecurityAdvisories to create its composer.json.

This leads to this behaviour: https://github.com/Roave/SecurityAdvisories/issues/120

Summary : when using composer update on an EOL-but-non-ELTS TYPO3 version it will fail completly when depending on the roave security advisories. So this means you can not even update non-TYPO3 packages this way. Only by spending hours of manually doing an composer update vendor/package for hundreds of packages individually ! Or by dropping the security-advisory dependency (meaning: dropping advisories for non-TYPO3 packages as well). Both are no options for big setups.

This also means if you "inherit" a TYPO3 installation from another agency, that for some reason is not even latest free release, you can not update it to the latest free-release easily.

A security advisory should never-ever force-suggest paid-only versions that once where free.

I flagged this as a regression, because composer update worked on v8-10 and now it does not anymore.
Since I had to select a TYPO3 version in this issue, I selected v12, because it basically is affecting ALL version sooner or later.

(I really hope this wasn't by intention - forcing people in the paid ELTS plan by soft-blocking updates to 3rd party packages this way, would really shine a bad light on TYPO3)

Actions #1

Updated by Stefan P 6 months ago

  • Subject changed from EOL-releases using non-ELTS and depending on roave/security-advisories fail because of security advisories to ELTS to Updating EOL-releases using non-ELTS and depending on roave/security-advisories fails because of security advisories to ELTS
Actions #2

Updated by Stefan P 6 months ago

  • Description updated (diff)
Actions #3

Updated by Stefan P 6 months ago

  • Description updated (diff)
Actions #4

Updated by Oliver Hader 6 months ago

  • Status changed from New to Needs Feedback
  • Is Regression changed from Yes to No

The package roave/security-advisories is NOT a dependency in the TYPO3 core packages, but has been installed manually for that particular project.

Quote from the purpose description of that package (https://github.com/Roave/SecurityAdvisories#purpose):

This package ensures that your application doesn't have installed dependencies with known security vulnerabilities.

In case you tend to ignore that information about vulnerable packages, there is no point of using roave/security-advisories at all. You simply need to uninstall the package. This is NOT as regression!

Actions #5

Updated by Oliver Hader 6 months ago

In case you just want to know the security status of your project, without blocking to install vulnerable packages, you could use https://github.com/fabpot/local-php-security-checker instead.

Actions #6

Updated by Stefan P 6 months ago

Oliver Hader wrote in #note-4:

The package roave/security-advisories is NOT a dependency in the TYPO3 core packages, but has been installed manually for that particular project.

True. But the security advisories roave uses to built its package constraints, come directly from the TYPO3 team.

The point is: TYPO3 is publishing advisories that break 3rd party dependency chains.

I can just remove roave from the compsoer.json, true. But then I will have a very hard time to keep up to date on non-TYPO3 packages as well.

In case you tend to ignore that information about vulnerable packages, there is no point of using roave/security-advisories at all. You simply need to uninstall the package. This is NOT as regression!

It seems to me that uninstalling typo3/cms-core in a TYPO3 installation is not a wise step. :)

We have an inherited TYPO3 setup using Non-ELTS-TYPO3 v10 and roave. Calling composer update fails because TYPO3 wants to be 10.4.40 (ELTS). Removing roave from compsoer json would succeed technically, but then I would also not see otehr vulnerbale packages (packagese which would be easily upgradabale because tehy are free, but are not notified to me anymore because roave is gone).

So, TYPO3 publishing security advisories for paid TYPO3 versions soft-block security updates for unrelated packages. That's what I am reporting.

Actions #7

Updated by Stefan P 6 months ago

Or in other words: ELTS users are aware of security updates anyway, because they are explciitly paying to be ELTS. But the whole ELTS process should not impact non-ELTS users in any way to behave any different to just use the latest free version. But currently they are forced to, even if just removing roave from compsoer.json.

Actions #8

Updated by Oliver Hader 6 months ago

  • Status changed from Needs Feedback to Rejected

Stefan P wrote in #note-7:

Or in other words: ELTS users are aware of security updates anyway, because they are explciitly paying to be ELTS. But the whole ELTS process should not impact non-ELTS users in any way to behave any different to just use the latest free version. But currently they are forced to, even if just removing roave from compsoer.json.

As mentioned already above:

The ELTS process has zero impact on your local projects. roave/security-advisories is something that has been installed individually, this is not enforced by TYPO3.

The information, concerning which package versions have known vulnerabilities is taken from the CVE, parsed by packagist.org and is reused by roave/security-advisories, e.g. https://packagist.org/packages/typo3/cms-core/advisories?version=7348365 refers to "GitHub" (our CNA for CVEs) as source.

Your request sounds like, that we (the TYPO3 security team) should stop issuing security advisories and CVEs for EOL versions - we will continue doing that, since this is one of the duties of a security teams.

I'm convinced we are done here.

Actions #9

Updated by Stefan P 6 months ago

The ELTS process has zero impact on your local projects.

Wrong. That's what made me write this ticket. Since ELTS is using the same composer package name as the free versions, when depending on roave I will have to change my 3rd party (non-TYPO3) package update workflow or drop roave completly to be able to run composer update as soon as a CVE for ELTS is published. So, of course, ELTS does in fact can have impact on my local project if it suddenly forces me to alter my composer.json (by dropping roave) or alter my workflow (by doing one-by-one composer updates manually).

Of course I'm not suggesting to stop publishing CVEs, but there should be some distinction bewteen ELTS and non-ELTS (like a different composer identifier/package name). So that both "infrastructures" won't mix up.

Actions #10

Updated by Oliver Hader 6 months ago

Stefan P wrote in #note-9:

The ELTS process has zero impact on your local projects.

Wrong. That's what made me write this ticket. Since ELTS is using the same composer package name as the free versions, when depending on roave I will have to change my 3rd party (non-TYPO3) package update workflow or drop roave completly to be able to run composer update as soon as a CVE for ELTS is published. So, of course, ELTS does in fact can have impact on my local project if it suddenly forces me to alter my composer.json (by dropping roave) or alter my workflow (by doing one-by-one composer updates manually).

Of course I'm not suggesting to stop publishing CVEs, but there should be some distinction bewteen ELTS and non-ELTS (like a different composer identifier/package name). So that both "infrastructures" won't mix up.

There were real vulnerabilities in the reference composer package names. Those vulnerabilities won't disappear when using a different package name like e.g. typo3/elts-core (instead of typo3/cms-core). Your request does not make any sense from a security point of view.

Since you decided to run outdated, insecure software with known vulnerabilities, why do you depend so much on having the roave security package at all!? That does not make sense. And again: No, we won't change the security process just because you refuse to uninstall a superfluous package in your own projects.

Actions #11

Updated by Stefan P 6 months ago

Since you decided...

No, our customer did.

... to run insecure software with known vulnerabilities

No, only decided to continue to run typo3/cms-core as non-ELTS. I fix security issues in TYPO3 "manually" (with Hooks, XClassing, copy-over a custom file or using a composer patches plugin). But I still want to be informed about other probably insecure packages as well! Which TYPO3 suddenly prevents us from doing so when using roave, because TYPO3 requires to make our customer pay for ELTS this way if we want to use roave.

I will fix TYPO3 security issues manually, but for free packages I want to use the offical fixes of course, which TYPO3 ELTS makes really hard now.

Actions #12

Updated by Oliver Hader 6 months ago

Stefan P wrote in #note-11:

I will fix TYPO3 security issues manually, but for free packages I want to use the offical fixes of course, which TYPO3 ELTS makes really hard now.

Bullshit! There are a bunch of possibilities with Composer to work around and fake version dependencies:

Stop ranting! Start researching!

Actions #13

Updated by Stefan P 6 months ago

since you maintain a custom fork of TYPO3 already

No. It comes from the official sources via composer. The patches are just inside our repository (which simply requires typo3/cms-core and roave/security-advisories). You make a lot of un-reported assumptions, I notice.

All I reported is this: an ELTS minor release in combination with a CVE may suddenly impact year-long running non-ELTS instances without warning, forcing to run additonal changes in the local workflow. Not just an forcing to patch some PHP code, but to change the whole sourrounding update/deployment workflow.

That's slightly so as if Georg Ringer would make ext:news v12 a paid-only version, with the impact that all pre-12 version can not be installed/minor-updated via composer as well anymore as long as you don't pay for v12 even if you need to install only v10. Surely I wouldn't be the only one to be "ranting" about such a change (up until now I wasn't ranting, but simply reporting, please don't just assume things that are not there).

Actions #14

Updated by Oliver Hader 6 months ago

Stefan P wrote in #note-13:

...

...

I have spent a lot of time trying to explain the context and scenario, provided three possible solutions or work-arounds (uninstall roave; use a composer repository; use composer inline alias). I responded to those rants about TYPO3 you have taken to other open source projects, e.g. at https://github.com/Roave/SecurityAdvisories/issues/120#issuecomment-1680497480

All is said. I don't want to continue wasting my time on your rants. I'm out!

Actions

Also available in: Atom PDF