Hi,
On 2/3/26 8:29 PM, Dmitry E. Oboukhov wrote:
2. Require such packages to be clearly distinguishable from
"normal" ones that depend on separate packages from the archive.
Options (to be chosen or combined, to be decided in discussion):
The main issue is that version-pinned dependencies are, by definition,
unmaintained because changes that are introduced by the maintainers of
these packages do not update the version pin.
Some packaging ecosystems *do* support somewhat automatic updates of
dependencies, but the metadata used by these is no longer visible from
the outside of a Debian package. Two possible ways of solving this:
exposing the fact that a source package comes from a particular
ecosystem (so the security tracker can interrogate the metadata inside),
or processing the metadata into something ecosystem-agnostic that the
security tracker can consume.
One simple approach would be to package vendored dependencies as
separate .orig archives, ideally (if they come from git submodules) with
the git-archive commit ID annotation inside the archive. The security
tracker could import these annotations from all known archives, map them
to their origin projects, and then check if the packaged commit ID is a
descendant of a commit that introduces a particular fix.
Another possible approach would be to list the vendored projects' pinned
commits inside the dsc file, ideally together with a hint which project
the commit is from so we don't need to guess. This could be combined
with the other approach.
Where fork information from a forge is available, this might also be
valuable to include.
So, raw ideas for policy extensions:
1. a dsc field "Git-Commit" with a similar format to the checksum
fields, but listing the git commit associated with a particular .orig
tar archive
2. a dsc field "Git-Repository" pointing at the repository a particular
.orig file can be generated from if needed
3. a dsc field "Git-Excludes" that lists additional paths that should be
omitted from the archive that don't already have an export-ignore
attribute in the upstream repo.
Rule: "git archive --remote=... ...", inserting the repository URL and
commit ID should produce an equivalent if not identical archive. If
"Git-Excludes" are present, an attributes file containing export-ignore
attributes for these paths is constructed and given to git-archive.
4. a dsc field "Ecosystem:" with values like "cargo", "python" or
"golang" that indicates that machine readable dependency information for
this ecosystem is inside, so automated scanners know which packages to
look into.
5. a file below debian/source containing the fork hierarchy of any
projects pulled from forges -- these would be fairly static, so it makes
sense to archive them inside the source packages so we can reconstruct
that hierarchy without querying forges if need be.
- Naming: a suffix or name part, e.g. -static, -bundled,
-standalone (or another agreed marker), so that the package name
indicates that dependencies are included;
For vendored .orig archives, I'd like to go with names like e.g.
ngscopeclient_0.1.1.orig-vendor-imgui.tar.xz
this would be unpacked into a "vendor-imgui" directory in the source
tree, and the first patch file would then contain a git-style patch that
creates a symlink in the appropriate place (thanks to Guillem for that
idea!).
As soon as I find the time I'm planning to teach uscan to build archives
like that, that doesn't require any policy changes. Likewise, an
"XS-Ecosystem" field would be fairly simple to get going from a
technical point of view.
Simon
