On Thu, Feb 05, 2026 at 04:55:20PM +0300, Dmitry E. Oboukhov wrote: > The process is the same as today. The DD tries to fix > things (patch to upstream or report and ask for help) and always > files a bug with upstream. An RC bug to keep unsupportable packages > out of stable is a reasonable tool in that toolkit.
This is a very nice way of looking at it, but at the same time it also is very far removed from reality. It is not the case that the majority of maintainers accurately track vulnerabilities in their packages. The security team tries to map published vulnerabilities to packages and often reports RC bugs. When it comes to fixing those bugs, there are several processes. Once reported, unstable often is fixed with maintainer uploads of new upstream releases. It also is not unheard of that the security team fixes packages in unstable and NMUs are also used due to the usually high severity. When it comes to stable and oldstable, the ratio of fixes uploaded maintainers shrinks. It shifts towards the security team, the LTS team and NMUs. So if the process is the same as today, you are saying that you want to dump the additional work due to vendored copies onto those teams. I hope you are not surprised to have me disagree with that. > > How about also requiring all vendored dependencies to be listed in the > > security tracker? > > > Tracking vendored deps in the security tracker seems quite doable. Great. Can you share more details on the tooling you use? I also think that the file format likely needs an extension for this use case. At present it basically maps a source package to other source packages that include a copy of the former. It also includes an optional version of when the copy ceases to exist. In particular, there is no way to record when a copy was introduced. With more vendoring going on, that aspect is becoming more important to keep the workload manageable. > On “vulnerabilities” in this kind of application > Bottles is an application for running games, unprivileged. Even if a > vulnerability is found in one of those libraries, in this context it > often will not be a practical security issue. Stability for the user > is critical, and testing all usage scenarios here is hardly > realistic. A reasonable scenario here would be infected game data. The recommended way of running Bottles (via flatpak) already provides some containment that shields against such a scenario to some extent. I can easily imagine us classifying a containment escape as a vulnerability in Bottles and also see that as relevant to users of Bottles. > Hence the question of value: what matters more to the user — being > able to run Windows games on Debian, or having e.g. patool 4.0.4 in > the tree? I would optimise for the former and for policy on vendored > deps and the security tracker not making such applications > unrealistically hard to maintain for little security gain. Your comparison indicates that Debian always has an equal or higher version. Russ highlighted that the common action for fixing vulnerabilities would be bumping to the latest version. Using the packaged libraries achieves just that. Now consider writing some autopkgtests for Bottles. Then whenever Debian upgrades one of those libraries, your test runs and when it fails you can give Bottles upstream a very early warning that changes are needed when they get around to updating a dependency. This is a major benefit that Debian (and Fedora, Arch and others) provide to the free software community: Indicating compatibility problems with later versions before they (or their users) run into them themselves. So the data you give here convinces me even more that vendoring is a disservice to both Bottles upstream and our users in the particular case you give. Helmut
