1. Explicitly allow packaging of programs that include all required
dependencies (convenience copies, vendoring), provided that
licenses and DFSG are respected.
Others have already raised the aspect of fixing vulnerabilities in such
packages. How would that work in your opinion?
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.
A very simple way would be filing an RC bug to keep such packages out
of
stable releases on the grounds that they are not supportable. Would you
agree with that approach?
- A field in debian/control: e.g. X-Debian-Bundled-Deps: yes
(or: yes, no, partial) or similar within the existing control
structure, so that tools and users can unambiguously identify
such packages.
How about also requiring all vendored dependencies to be listed in the
security tracker?
Tracking vendored deps in the security tracker seems quite doable.
Python deps are already listed in requirements.txt, JS in
package.json, etc. If the maintainer marks which of these are used
as embedded, we can automate tracking: when a CVE appears in libfoo,
automatically file bugs for all packages that ship it. That does not
replace the current workflow (patch/report upstream + Debian bug) but
complements it.
On testing complexity and the Bottles example
When packages.txt has not 5–10 entries but dozens of dependencies
with “==” that in the distro are replaced by “>=” or other versions,
even “does it still work?” becomes non-trivial. The ideal world with
full test coverage is rare; in practice many scenarios are not
covered.
Bottles is a good example. 19 dependencies; from the table below: 5
with no version mismatch (NOW != future), 5 low, 6 medium, 3 high
probability of issues.
The original complaint from Bottles to the distro was exactly
that somewhere a version was replaced, something broke, the
maintainer did not see it, and users did. So the problem is real
support and testing of such dependency graphs, not theory.
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.
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.
Table (Bottles vs Debian):
Probability Debian Bottles
of issues version version
medium 0.46.1-2 wheel==0.44.0
low 6.0.3 PyYAML==6.0.2
low 7.45.7 pycurl==7.45.3
- 5.2.0 chardet==5.2.0
low 2.32.5 requests==2.32.3
medium 3.10.1 Markdown==3.7
high 0.2.0 icoextract==0.1.5
high 4.0.4 patool==3.0.0
low 3.3.1 pathvalidate==3.2.1
- 0.3.4 FVS==0.3.4
medium 3.11.5 orjson==3.10.7
- 1.27.0 pycairo==1.27.0
medium 3.54.5 PyGObject==3.50.0
medium 3.4.4 charset-normalizer==3.3.2
- 3.10 idna==3.10
medium 2.5.0 urllib3==2.2.3
high 2026.1.4 certifi==2024.8.30
- 2024.8.26 pefile==2024.8.26
low 4.5.4-1+b1 yara-python==4.5.1
Total dependencies: 19
Low probability of issues: 5
Medium: 6
High: 3
No issues: 5 (NOW not issues)
