Proposal for the general support of binary packages in the official Debsources API
Hello!
At the moment, I'm trying to help create a new JSON format for a new API
endpoint on the Debian Security Tracker to easily get information about
every DLA/DSA advisory via JSON. You can track the progress here:
https://salsa.debian.org/security-tracker-team/security-tracker/issues/1
While working out the best possible format, I realized that a simple
"source package" like "qemu" in this example
(https://security-tracker.debian.org/tracker/DSA-4616-1) is not
sufficient for informing the end user about which binary packages
actually need to be updated for vulnerability mitigation.
As you can see here
(https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=sourcenames&keywords=qemu),
there are 15-18 binary packages listed for Qemu, depending on the Debian
release, such as "qemu-utils" or "qemu-system-common". These are pretty
much the actually installed packages that are being affected by the
vulnerability stated in the DSA.
Currently and in the past, we (anyone who works with DSAs) are/were
forced to parse HTML to understand which binary packages are associated
with the corresponding "source package" like "qemu". This should not be
the case anymore. That's why this proposal is needed.
In the past there was this issue that is still open from what I can
tell: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761083
There, Luciano Bello states that it would be easier if there was a way
to get the binaries for packages in different releases that could then
be included in DSAs directly. Actually, there even was some code that
has been written and discussed in that issue, but was never merged, as
(not) seen here:
https://salsa.debian.org/qa/debsources/-/commits/master/lib/debsources/app/infobox.py
Luciano has told me that he hasn't touched Debsources for a couple of
years already, but I feel like we definitely need to revive this issue
and implement/merge the code as soon as possible. Users really really
need a reliable way of acquiring the binary package names related to
their source packages, especially users like vulnerability scanners.
In fact, we could absolutely use a simple way of "connecting the dots"
between source packages and all binary packages depending on the
release. The information is clearly in the database, it just needs to be
presented via a simple API endpoint and listed here:
https://sources.debian.org/doc/api/
The table "binaries" contains this exact association already
(https://sources.debian.org/static/db-schema/index.html#public.table.binaries),
so I can see this working. The one thing I'm currently not seeing here
is the association with the different releases (buster, bullseye,
jessie, etc.), but the association is clearly there when searching for
the packages like I linked above
(https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=sourcenames&keywords=qemu).
My question is: Can we get this feature implemented? I know for a fact
that it has huge implications and makes my life easier, as someone who
works with DSAs and really needs access to the information about what
source package has which binary packages associated with it. I have
prepared a text file with an example JSON format for Qemu specifically,
so this example only has this one element. It tries to replicate the
information present when searching for source packages here:
https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=sourcenames&keywords=qemu
Keep in mind: This proposal is mostly about providing a general API
endpoint for accessing information about the association between source
packages and their binary package names. Having this information present
in DSAs is not directly a part of this proposal.
Best wishes,
Thorsten Paßfeld
{
"qemu": {
"jessie": {
"version": "1:2.1+dfsg-12+deb8u13",
"binary_packages": [
"qemu",
"qemu-guest-agent",
"qemu-kvm",
"qemu-system",
"qemu-system-arm",
"qemu-system-common",
"qemu-system-mips",
"qemu-system-misc",
"qemu-system-ppc",
"qemu-system-sparc",
"qemu-system-x86",
"qemu-user",
"qemu-user-binfmt",
"qemu-user-static",
"qemu-utils"
]
},
"stretch": {
"version": "1:2.8+dfsg-6+deb9u9",
"binary_packages": [
"qemu",
"qemu-block-extra",
"qemu-guest-agent",
"qemu-kvm",
"qemu-system",
"qemu-system-arm",
"qemu-system-common",
"qemu-system-mips",
"qemu-system-misc",
"qemu-system-ppc",
"qemu-system-sparc",
"qemu-system-x86",
"qemu-user",
"qemu-user-binfmt",
"qemu-user-static",
"qemu-utils"
]
},
"buster": {
"version": "1:3.1+dfsg-8+deb10u4",
"binary_packages": [
"qemu",
"qemu-block-extra",
"qemu-guest-agent",
"qemu-kvm",
"qemu-system",
"qemu-system-arm",
"qemu-system-common",
"qemu-system-data",
"qemu-system-gui",
"qemu-system-mips",
"qemu-system-misc",
"qemu-system-ppc",
"qemu-system-sparc",
"qemu-system-x86",
"qemu-user",
"qemu-user-binfmt",
"qemu-user-static",
"qemu-utils"
]
},
"bullseye": {
"version": "1:4.2-3",
"binary_packages": [
"qemu",
"qemu-block-extra",
"qemu-guest-agent",
"qemu-kvm",
"qemu-system",
"qemu-system-arm",
"qemu-system-common",
"qemu-system-data",
"qemu-system-gui",
"qemu-system-mips",
"qemu-system-misc",
"qemu-system-ppc",
"qemu-system-sparc",
"qemu-system-x86",
"qemu-user",
"qemu-user-binfmt",
"qemu-user-static",
"qemu-utils"
]
},
"sid": {
"version": "1:4.2-3",
"binary_packages": [
"qemu",
"qemu-block-extra",
"qemu-guest-agent",
"qemu-kvm",
"qemu-system",
"qemu-system-arm",
"qemu-system-common",
"qemu-system-data",
"qemu-system-gui",
"qemu-system-mips",
"qemu-system-misc",
"qemu-system-ppc",
"qemu-system-sparc",
"qemu-system-x86",
"qemu-user",
"qemu-user-binfmt",
"qemu-user-static",
"qemu-utils"
]
}
}
}
Reply to: