Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#68669 - [avahi] Package is bloated, needs broken down

Attached to Project: Arch Linux
Opened by Chris (cs_95cc64dd) - Thursday, 19 November 2020, 15:18 GMT
Last edited by Eli Schwartz (eschwartz) - Thursday, 19 November 2020, 21:04 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I touched on this in https://bugs.archlinux.org/task/68524?project=1&string=gtk3, in short this package mixes daemons and libraries. Since it's been a couple weeks with no movement I wanted to try this package instead, since it's easier to fix. My proposal is simple:
1) Create package libavahi (provides libavahi-client.so=3-64, libavahi-common.so=3-64, libavahi-core.so=7-64, libavahi-glib.so=1-64, libavahi-gobject.so=0-64, libavahi-libevent.so=1-64, libavahi-qt5.so=1-64, libavahi-ui-gtk3.so=0-64, libdns_sd.so=1-64)
2) Create package avahi-{suffix} (server, service, daemon, whatever - it seems that only a few packages exist with either suffix in the svntogit-packages repo.)
3) Make avahi depend on libavahi and avahi-{suffix}


I personally believe it should be broken down further, debian does this nicely[1] but that would be a long term goal. The easy win for now is to split it into a library and service package. This will let GTK3 depend on the library packages which will allow installation of gtk3 without ending up with network listeners on public ports.


[1]https://packages.debian.org/search?keywords=avahi
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Thursday, 19 November 2020, 21:04 GMT
Reason for closing:  Won't implement
Additional comments about closing:  1.8 mb is not bloated, services aren't enabled automatically, and there's no compelling reason here to violate the soft rule "unlike debian, we generally don't split packages, because it's a violation of KISS".

Typically we only split packages if there is a practical, rather than ideological, reason.

You tried to argue that there is a practical reason here, but as per the first sentence of this closing comment, I am not convinced.
Comment by Chris (cs_95cc64dd) - Thursday, 19 November 2020, 15:58 GMT
An example of the impact of this is MPV:

https://www.archlinux.org/packages/community/x86_64/mpv/
-> https://www.archlinux.org/packages/extra/x86_64/smbclient/
-> https://www.archlinux.org/packages/extra/x86_64/libcups/
-> https://www.archlinux.org/packages/extra/x86_64/avahi/


I think most people can agree that a DNS server is not required to play a MP4, this change would allow libcups to depend on libavahi.
Comment by Morten Linderud (Foxboron) - Thursday, 19 November 2020, 16:04 GMT
This is only done when there is a clear attainable win for doing so. Whats the reason here? Calling it "bloated" doesn't mean anything.
Comment by Chris (cs_95cc64dd) - Thursday, 19 November 2020, 20:25 GMT
You can find more info in  FS#68524  and the details of this bug, perhaps my title should have been "Split avahi into two packages"? I use the word "bloated" to describe excessive software packages that add unnecessary surface area to my system. Consequently removing bloat improves my systems security, which I consider both the reason and the win. I suppose what I'm saying is calling a package bloated definitely means something, at least to me.

In avahi's case we avoid 70K~ lines of C code being exposed over the network[1] for a feature user may not need. Having avahi pkg contain both server and client components means I end up getting a full fledged mDNS/DNS-SD globbed to public interfaces just to play some music while I code because packages pull in smb**client** for protocol support because there is no libavahi-client package it can depend on.

[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=avahi
Comment by Jelle van der Waa (jelly) - Thursday, 19 November 2020, 20:35 GMT
Arch packages don't enable service by default, so I don't see how there is an extra attack surface?

[jelle@natrium][~/projects/infrastructure]%ps aux | grep avahi
jelle 20038 0.0 0.0 6388 2224 pts/4 S+ 21:34 0:00 grep --color=always avahi
[jelle@natrium][~/projects/infrastructure]%pacman -Q avahi
avahi 0.8+15+ge8a3dd0-1

[jelle@natrium][~/projects/infrastructure]%systemctl status avahi-daemon.service
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; disabled; vendor preset: disabled)
Active: inactive (dead)
TriggeredBy: ● avahi-daemon.socket
Comment by Morten Linderud (Foxboron) - Thursday, 19 November 2020, 20:45 GMT
>You can find more info in  FS#68524  and the details of this bug, perhaps my title should have been "Split avahi into two packages"? I use the word "bloated" to describe excessive software packages that add unnecessary surface area to my system. Consequently removing bloat improves my systems security, which I consider both the reason and the win. I suppose what I'm saying is calling a package bloated definitely means something, at least to me.

But we don't care what you mean with "surface area" and "bloat". You are trading convenience for complexity in package, and it needs to even out. Personal preferences doesn't matter (much). Some packages are split because the headers are a measurable difference in disk footprint, but that is not the case here.

>In avahi's case we avoid 70K~ lines of C code being exposed over the network[1] for a feature user may not need. Having avahi pkg contain both server and client components means I end up getting a full fledged mDNS/DNS-SD globbed to public interfaces just to play some music while I code because packages pull in smb**client** for protocol support because there is no libavahi-client package it can depend on.

avahi isn't enabled by default, as with any services provided in Arch. As for security issues, you link it to prove that it had 12 past vulns. But that isn't a lot considering the age of the software, so this doesn't matter.

A better argument would be that the lack of assigned CVEs implies a lack of security auditing of the software.

Loading...