TYPO3 Core

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.

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.

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.

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.

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.

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.

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:

• https://getcomposer.org/doc/04-schema.md#repositories - since you maintain a custom fork of TYPO3 already with individual patches, you can put that into a local Git repository and assign your own tags (versions)
• https://getcomposer.org/doc/articles/aliases.md#require-inline-alias - you could trick Composer into using a different internal version, like typo3/cms-core:"10.4.x-dev as 10.4.99"

Stop ranting! Start researching!

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).

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!