No audit for --prefer-lowest?
#12603
-
|
Looks like the last
This kind of breaks lot of CI's in my different open source projects. Where there is atleast one Job running on |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments · 10 replies
-
|
Do you have details? Link to build? The problem is due to #11956 which is not really an audit, it removes packages with vulnerabilities from the pool, so it should still be able to find a solution but I guess it gets stuck somewhere because some old packages have no vulnerabilities but depend on other old stuff which does have vulnerabilities and so is not visible to the solver. I am not sure if we should skip this behavior for --prefer-lowest builds, or rather make people bump their requirements because that'd be preferable really. |
Beta Was this translation helpful? Give feedback.
-
|
@Seldaek it appeared in |
Beta Was this translation helpful? Give feedback.
-
|
Just a note: cause here is that the optimizer groups insecure and secure package versions with identical deps. Then with prefer lowest it only leaves behind an insecure version, without it, it gets optimized to a secure version. Can be fixed in optimizer or by doing audit version removal before optimization. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry to clarify: that's the reason it fails rather than just picking more current versions. The overall behavior is a separate issue. |
Beta Was this translation helpful? Give feedback.
-
|
80503cb should fix it, please confirm with a |
Beta Was this translation helpful? Give feedback.
-
|
The |
Beta Was this translation helpful? Give feedback.
-
|
The behavior of To explain why, imagine there is CVE reported against an old version of a library you depend on. This vulnerability allows remote code execution when the library code is autoloaded in a way that is triggerable in GitHub actions. The library authors marked the version insecure and published a safe new version. Now your CI system with Preventing the installation of these old versions should simply lead to a successful composer update that picks slightly newer versions, imitating what users of your library would end up with as well, since Composer would skip the insecure versions for them too. As per my other comment this behavior was broken in some cases, leading to errors rather than picking different versions, that should have been fixed in 80503cb. The easiest solution generally would be to change your requirements to no longer accept the insecure versions. That said, there may well be security vulnerabilities that would not be exploitable in the context of your library, and you may still want to perform tests against such versions in case users of yours still rely on these versions. So I think we should provide enough options for you to be able to explicitly allow specific CVEs/vuln ids to install as part of a |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I think configuring specific ignored CVEs if they don't apply and you absolutely want to test against those versions is the most sensible, or ignoring all advisories but that carries some risk for sure. I'd think this can be committed to the composer.json of the project that's probably the easiest, it'd apply to all builds then but that shouldn't matter as regular builds would anyway prefer highest versions with fixes in. |
Beta Was this translation helpful? Give feedback.
-
Understand the point. How I can in the CI set that I still want allow the insecure versions I tried. |
Beta Was this translation helpful? Give feedback.
-
|
That certainly should/should have worked. |
Beta Was this translation helpful? Give feedback.
-
|
Seems end in invalid argument. Should I open a more detailed issue? |
Beta Was this translation helpful? Give feedback.
-
|
Looks like we forgot to add support for these in config command :) Will PR a fix. |
Beta Was this translation helpful? Give feedback.
-
|
For the |
Beta Was this translation helpful? Give feedback.
-
|
No need IMO, with 2.9.1 prefer lowest should work fine again. |
Beta Was this translation helpful? Give feedback.
The behavior of
--prefer-lowestto skip installation of insecure versions is correct and should remain.To explain why, imagine there is CVE reported against an old version of a library you depend on. This vulnerability allows remote code execution when the library code is autoloaded in a way that is triggerable in GitHub actions. The library authors marked the version insecure and published a safe new version. Now your CI system with
--prefer-lowestwould continue to install the old vulnerable version and effectively allow third parties to execute code in your GitHub action. The only safe default is to prevent installation of such insecure versions by default.Preventing the installation…