phpunit <12 still marked as vulnerable

[uuf6429]

The fix in 7d0034b is not correct. PHPUnit <12 is still marked as vulnerable, when in fact only two specific versions were vulnerable (one in v12 and one in v13). See also: github/advisory-database#7430

AFAIK the advisory in Composer/Packagist looks more correct as it takes into consideration other vulnerabilities: https://packagist.org/packages/phpunit/phpunit/advisories

[xabbuh]

See also: github/advisory-database#7430

Once this PR is merged this database should update automatically shortly after IIRC.

[Ocramius]

What other sources could be crawled? 🤔

[uuf6429]

@xabbuh it just worries me that GitHub hasn't accepted a simple, clear and urgent fix in almost 12 hours. Anyone relying on this package has been unable to run CI (relying on PHPUnit <12) without hacks during this time frame.

What other sources could be crawled? 🤔

@Ocramius If I understand this right, maybe https://github.com/FriendsOfPHP/security-advisories (which is used by composer/packagist?)?

To be clear, I'm only annoyed about GitHub/GHSA... I totally get it that you might not want to tweak anything manually in the meantime.

[Ocramius]

@Ocramius If I understand this right, maybe https://github.com/FriendsOfPHP/security-advisories (which is used by composer/packagist?)?

already used here

[uuf6429]

Then I suppose there is nothing to do here, just wait for GitHub to do their thing.

[naderman]

@Ocramius Would it make sense to you, to switch generation of the conflicts for this package from github/friendsofphp to the packagist API, that also pulls in data from both sources, but then disambiguates and lets friendsofphp override github advisories? That would have let Sebastian fix this instance via friendsofphp without waiting for github to correct their advisory here too.

[Ocramius]

but then disambiguates and lets friendsofphp override github advisories

TBH, this sort of temporary hiccups always occur: this system only merges advisories, without setting any priority.

The only thing that breaks is composer update, and it is possible to work around it with AS (in composer.json) anyway, so I'm not too happy about considering one source more prioritary than others: would rather crack the whip to get people to fix advisories in upstream.

We already have mechanisms to override specific advisories, BTW: it's a sufficient workaround for when something is really broken for a longer time.

[naderman]

Yeah of course there are workarounds. May reduce the amount of support requests someone like Sebastian receives for no fault of his own in a situation like this one here, if he can quickly fix it. That is, why we pick friendsofphp data over github in case of conflicting metadata for the same issue: We can better control actual maintainers have their say on the friendsofphp data than the github advisory database. Anyway, up to you in the end! It's certainly not a big deal either way. As you said yourself, can be worked around.

[talkinnl]

Having different priorities can introduce bugs, inconsistencies and social engineering targets.

Github must fix the range.
(And maybe not overrule the range without understanding the issue to begin with)

[uuf6429]

Having different priorities can introduce bugs, inconsistencies and social engineering targets.

Relying on a single (commercial) provider with an automated process is supposed to be less risky? This situation shows the opposite.

This has real impact on users. I’ve already had to remove this repository entirely because I can’t afford to wait through a weekend for a non-issue to be corrected. A few hours ago I was notified that nearly all of my repositories are now “vulnerable,” (which is not a big deal in my case, but I assume it affects a great many users), and I can already anticipate the time I’ll have to spend tomorrow at work explaining and working around a problem that shouldn’t exist in the first place.

I understand and respect the decision to follow GitHub as a source of truth, but treating it as infallible when it’s demonstrably wrong is risky. At the very least, situations like this deserve more than passive acceptance. We should be willing to clearly call out the issue and apply pressure for a timely correction (GitHub-side).

[jrfnl]

The problem is not this package. The problem is GitHub incorrectly interpreting the version information provided in the CVE.

IMO this is not something which needs to be fixed here. This needs to be fixed upstream.

If you, like me, have gotten GitHub security notifications for dozens of repos... then one way to help get this fixed upstream is to dismiss every single one of those as "Inaccurate/incorrect". If enough people do that, that should get GH's attention.

[Ocramius]

IMO this is not something which needs to be fixed here. This needs to be fixed upstream.

Agreed.

That said, feel free to send a patch with a GHSA override, if that's really such a high impact, @uuf6429: see https://github.com/Roave/SecurityAdvisoriesBuilder/blob/41b4e6cbad4d744b102bdc6d64d889f4e5f2201c/src/Roave/SecurityAdvisories/AdvisorySources/GetAdvisoriesFromGithubApi.php#L42