How to determine/know Debian packages rollout from unstable -> testing -> stable -> ...

[ggbce]

Hi,

Since few years, I'm facing more and more complexity with obtaining "latest version of an application" versus the security path to follow. I know this situation is on all platforms, but I mainly use "Debian" when I work under Linux. Then, due a lot of security issues... I would get more information on how to determine and get latest versions of package in a "acceptable timing".

I will explain with a true situation:

Currently, the Stable version (where I need to assume using an Old Stable or Stable version for a production environment, where many providers are compatible like AWS, Microsoft Azure, VMware or On-Premise installation and using third party applications based on Linux are ready to use) is the version to use. No, I couldn't use Unstable/Testing version because to much incompatibilities... And sometime when a newer Stable version appear on the market, it need a gap before this new Stable is offered.

Probably like many users, the main servers installed that they are facing Internet are something to give "Internet Services" (Apache HTTP Server),"Give a management Interface" (OpenSSH),"Give a tunneling solution to securing the data over Internet" (OpenVPN) and in background using "Using a secure protocol" (OpenSSL). The products named are just an example and other solution could be used.

I understand most "commons products who offer an Internet service" is also those they are mostly "attacked products in the world" where the security flaws are discovered... And in most situation, the solution is not just putting a configuration, a mitigation settings... but getting an updated version ! The providers of these products are almost of the time very fast to answer on these attacks creating security fixes.

I also understand, making a Linux distro is complicated and generate alot of dependencies to validate and maintain in a homogen system.

I also understand I could not use packages provided from the distro and compile from sources to obtain the very latest version... But in a real world using this method is not a solution because all packages should be maintained manually on one, ten, hundred, thousand, etc. machines for some people... This is the goal of a distro to maintain these packages !

But in the same time, these vulnerabilities need to be fixed ASAP (in a timeframe of 0-day, 7-days, 30-days... depending of the situation). And in parallel world an "acceptable" timeframe of some weeks/months is often targeted, but more and more difficult to reach !!

In this sample "true" situation:

Actually Debian 11 Bullseye (even with backports and proposed-updates) is giving OpenSSH Server 8.4p1 version and Debian 12 Bookworn is giving OpenSSH 9.2p1 available. Since July 2023, All versions of OpenSSH between 5.5 and 9.3p1 are marked vulnerable with a CPS 10.00 / CVSS 9.8 gravity. On this date, the provider had publish the information and also a fix using OpenSSH 9.4. It's a very critical situation since 2 months !

Today availability for OpenSSH under Debian (2 months later): https://tracker.debian.org/pkg/openssh


After explain all these reality, I would like to known how the Debian team in charge of the "packages release and rollout" are determining when a package could pass from the unstable -> testing -> stable distro ? What determine the priority ? How, as a client person, I could get a feedback on planned release date ?

My background idea :

Option #1: May be, could I obtain some "specific packages ONLY" from unstable or SID and not the entire distro... A kind of "temporary FastTrack" just for critical situation ? It could happen OpenSSH 9.5 will be released in 6 months and just to innovate, not fixing a critical vulnerability and at this moment I will not need to obtain this package on Stable version and stay with "older package will probably the newer approved package".

Option #2: Getting more easly the information for each packages when will be approved for next distro (unstable -> testing -> stable distro) and the targeted release date or know "it will never possible to obtain a newer package for a software on this distro".

I known it a complicated and tough discussion, but I'm sure many users are in the same situation if the security of their installations is important !

[lindi]

Please summarize your post, what are you actually asking exactly?

[lindi]

But as a summary: Packages do not move from testing to stable. Security updates are generally done by fixing the security bugs in the stable packages, only in rare cases is a new upstream version of a package added to stable (firefox, chromium, linux). CVSS scores are quite arbitrary, it is hard to comment on your issue without more information on the issue.

[FreewheelinFrank]

As lindi mentioned, Stable gets security updates, Testing gets version updates (which may fix security issues), but which may also break things in Stable.

It would be better to look at the security tracker. Not sure which bug you are concerned about, but I guess it could be this one; it's a good example anyway.

https://security-tracker.debian.org/tra ... 2023-38408

It's fixed in Testing but the new version seems to depend on new libraries which aren't in Stable. The tracker gives the reasons an issue is not fixed in Stable and links for more information.

[FreewheelinFrank]

Other distro's secrity information is useful too.

Mitigation

Remote exploitation required that a user establishes an SSH connection to a compromised or malicious SSH server with agent forwarding enabled. The agent forwarding is disabled by default. Review your ssh client configuration files for the use of ForwardAgent configuration directive and invocations of ssh client for the use of -A command line argument to see if agent forwarding is enabled for specific connections.

Exploitation can also be prevented by starting ssh-agent(1) with an empty PKCS#11/FIDO allowlist (ssh-agent -P '') or by configuring an allowlist that contains only specific provider libraries.

https://access.redhat.com/security/cve/cve-2023-38408

Again, not sure if this is the vulnerability you are worried about but it's a good example. The vulnerability doesn't affect the default installation and mitigating against it is easy.

[Uptorn]

The first suspect is lack of maintainer resources. The total number of packages in Debian grows with each release, and I don't see how this growth is sustainable.