search

canonical / core20

26 stars 32 forks source link

added mdns support breaks dpkg.list file parsing #104

Open ogra1 opened 3 years ago

ogra1 commented 3 years ago

We have several tools that use the dpkg.list file shipped under usr/share/snappy/dpkg.list inside all the core snaps as input for i.e. checking the sources a snap was built from or querying the CVE tracker (review-tools). With the merge of https://github.com/snapcore/core20/commit/d2163f62de8ffc9664a07b008107055a8cd35d06 this file now carries a fake "avahi-daemon" entry with package version "1000" (which is required to make the libnss packages installable as i understand from the PR code) ...

indeed such a version 1000 does not exist anywhere in the ubuntu archive, so any automatic parsing of the file (with package version lookups) fails. The line should be filtered out when dpkg.list gets generated.

ogra1 commented 3 years ago

the file is generated in https://github.com/snapcore/core20/blob/master/hooks/600-no-debian.chroot

ogra1 commented 3 years ago

a simple line in the above script like:

sed -i '/ii.*avahi-daemon.*1000.*/d' usr/share/snappy/dpkg.list

right after the file was created could serve as a workaround ...

xnox commented 3 years ago

@jhenstridge can we fake the right version of avahi? or should we instead switch to manual unpacking of the deb without satisfying dependencies (aka the --force options)?

It would be nice if the dpkg.list is always accurate, without any sort of post processing.

jhenstridge commented 3 years ago

We don't include any files from avahi-daemon, so if the intent is to e.g. match against USNs I don't think that would be useful: core20 won't be vulnerable to bugs in the version of Avahi it didn't include.

If that's the nature of the problem, then filtering dpkg.list might be the best option.

ogra1 commented 3 years ago

i agree that we should not include avahi-daemon in dpkg.list at all to not confuse CVE trackers and/or source collection tools ... @xnox do you have any better idea to prevent avahi-daemon from showing up in dpkg -l output ... like un-mangling the dpkg info db before it runs or some such ?

xnox commented 3 years ago

The best thing would be do downgrade the Depends to Recommends in the archive SRU. Thus we will not need to create a fake package with fake version which ends up as a fake thing in dpkg.list. Cause it is perfectly valid to use one, without the other, as demonstrated by snaps.

Meulengracht commented 3 years ago

The best thing would be do downgrade the Depends to Recommends in the archive SRU. Thus we will not need to create a fake package with fake version which ends up as a fake thing in dpkg.list. Cause it is perfectly valid to use one, without the other, as demonstrated by snaps.

Please correct me if I'm wrong, I just took a look at the nss-msdn repository and it was mentioned that the avahi-daemon is a hard dependency (but not a build requirement) for libnss-msdn. Wouldn't it be wrong to downgrade the avahi dependency, when libnss in facts relies on the daemon?

Please forgive me my ignorance here, but why are we including libnss if we just have a dummy version of avahi?

alfonsosanchezbeato commented 7 months ago

Fwiw this is not happening on core24 base anymore

alfonsosanchezbeato commented 7 months ago

Neither on core22