added mdns support breaks dpkg.list file parsing

[ogra1]

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 d2163f6
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]

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

[ogra1]

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]

@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]

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]

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]

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]

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]

Fwiw this is not happening on core24 base anymore

[alfonsosanchezbeato]

Neither on core22