We missed this patch which is included in https://www.openssh.com/txt/release-9.3p2 https://nvd.nist.gov/vuln/detail/cve-2023-38408
CVE: (none) => CVE-2023-38408Source RPM: (none) => openssh
Hi, Bug 32704 already fixed CVE-2023-38408. Best regards, *** This bug has been marked as a duplicate of bug 32704 ***
Status: NEW => RESOLVEDCC: (none) => nicolas.salgueroResolution: (none) => DUPLICATE
is there any good reasion, we patched instead of updating to the official 9.3p2 release?
Resolution: DUPLICATE => (none)Status: RESOLVED => REOPENED
We cannot decide for you two. It is for Nicolas to reply.
Assignee: bugsquad => nicolas.salguero
(In reply to Marc Krämer from comment #2) > is there any good reasion, we patched instead of updating to the official > 9.3p2 release? Regarding security issues, notably when it comes to critical components like openssh whose regressions could lead to difficulties to access remote servers, I try to follow a conservative policy, like many other distributions (RedHat, SUSE, Debian, Ubuntu...) do: if some patches are available, apply them rather than update to a new version. QA tests should also be easier.
but the release is the patched version. This is really irritating if it is the original release (which patched their code) and also if you have other security news which state "versions before xxx are affected". We also did the p1 update instead of patching.
Hello Marc, Here is my explanation to answer your question. We follow here the best practices adopted also by Debian which is the more strict on this matter: instead of upgrading to a new version we extract security patches (only and just them) and we backport them on our maintained version(s). This way we fix security issues without* impact at all on the behaviour of the software. Some other distributions have a less strict policy on this topic and use minor upstream upgrades instead of patching surgically their versions => as a result they push also to their users deprecation upgrades, code cleaning and refactoring, minor changes in configuration interpretation, optimizations and (theoretically) minor enhancements which in turn can lead to production problems. It does not happen often but it happens with minor upgrades (i could share really painful memories about this around a beer)... and no distribution should allow even the slightest possibility for this to happen. Debian (and Mageia) strict way is by far the best way to reduce this risk for our users. It involves more work and more precautions, but it is by far the safest strategy. Let's let Nicolas complete as our Leader. Kind regards and best wishes for this end of year. Maât -------------------------------------- * : ideally because sometimes the fix itself has an effect on the behaviour of the software... in this case the only way is to communicate a lot and explain in detail how to deal with the change.
CC: (none) => maat-ml
Indeed, and this is nothing new or unique to this package. It should also be covered by our updates policy. *** This bug has been marked as a duplicate of bug 32704 ***
Status: REOPENED => RESOLVEDResolution: (none) => DUPLICATE