Add Debian ecosystem #10
Conversation
|
@rsc what do you think of this general naming convention for Linux distro packages? |
docs/schema.md
Outdated
| @@ -318,6 +318,7 @@ The defined ecosystems are: | |||
| | `Maven` | The Maven Java package ecosystem. The `name` field is a Maven package name. | | |||
| | `NuGet` | The NuGet package ecosystem. The `name` field is a NuGet package name. | | |||
| | `Linux` | The Linux kernel. The only supported `name` is `Kernel`. | | |||
| | `Debian` | The Debian package ecosystem; the `name` field is of the format `<lowercase distro codename>:<package name>`. For example, `buster:python3` refers to the "python3" package in Debian Buster. | | |||
There was a problem hiding this comment.
Is this intended to also support Ubuntu and Debian derivatives?
There was a problem hiding this comment.
Ubuntu would be its own ecosystem. This is just a start and we'll need to add more later.
There was a problem hiding this comment.
Thanks! And why would you need a <lowercase distro codename> for Debian? All packages live in a single unified pool that is not specific to a "distro codename" as in http://ftp.us.debian.org/debian/pool/main/f/ffmpeg/
I reckon debian publishes vulnerabilities with a distro info as in https://security-tracker.debian.org/tracker/source-package/ffmpeg but would make this required?
There was a problem hiding this comment.
Thanks! I wasn't aware that packages are part of a unified pool. That makes this a lot simpler.
There was a problem hiding this comment.
@oliverchang There has been some discussion about adoption of a database schema similar to the OSV ecosystem, but I don't know at this moment if there is consensus yet for adoption. We are aiming to determine that an to see if we have resources for an implementation.
There was a problem hiding this comment.
@oliverchang It's easy for a scanner to extract the source package name out of the dpkg metadata when scanning an installed system. And then binary package names are not stable over time, for example libraries typically embed the version encoded in SONAME in their binary package names (e.g. libidn12). Also you can have multiple binary packages for a single source package (and the sets of binary packages can also evolve over time) which would really complicate things here IMO. source package name is the most stable identifier in Debian (but then it's not necessarily unique either, for example we have multiple copies of postgresql and we embed the major version in the source package name).
There was a problem hiding this comment.
@rhertzog I reckon that Debian tracks its security advisories at the source package level by release, but IMHO this creates an indirection that does not help actual users as they search, consume and install binary packages (that I can detect for instance with ScanCode.io and debian-inspector tools and ScanCode toolkit and lookup for vulnerabilities with VulnerableCode).
(but then it's not necessarily unique either, for example we have multiple copies of postgresql and we embed the major version in the source package name).
Since the major version is embedded, the source package name is unique then? Just to be sure as it would be news to me if Debian package names were not guaranteed to be unique 👼.And AFAIK the same is true for binary packages?
There was a problem hiding this comment.
this creates an indirection that does not help actual users as they search, consume and install binary packages
I agree with this but this indirection should be dynamically resolved by the tools for the benefits of the users. Changing the underlying data does not help except to introduce mistakes in the database because the binary package name for buster will not be the same as the one for bullseye.
Since the major version is embedded, the source package name is unique then?
Yes... but I wanted to say is that the mapping from vulnerability in "foo" affects source package "foo-in-debian" is not necessarily a one-to-one mapping.
There was a problem hiding this comment.
Sorry, I dropped the ball on this thread!
but IMHO this creates an indirection that does not help actual users as they search, consume and install binary packages
+++1 to this. The intention is for this schema to be usable by generic tools without having any knowledge of ecosystem intricacies. This indirection could introduce additional complexity for users who may be consuming this data in contexts where it's not easy to get the source package mapping.
I agree with this but this indirection should be dynamically resolved by the tools for the benefits of the users. Changing the underlying data does not help except to introduce mistakes in the database because the binary package name for buster will not be the same as the one for bullseye.
This does sound like a great benefit for Debian. Each affected package also has an ecosystem_specific field that would be perfect for this. For specialized Debian tooling, they can read the source package name from this field also, and possibly also auto-populate / expand the actual binary packages that are affected.
There was a problem hiding this comment.
What kind of generic tools are you referring too? How would they consume this data?
Do you expect Debian to do the mapping source to binary for all releases before injecting data in this new database? Do you know that this will greatly increase the size of the submitted data for dubious gain?
No description provided.