Hi, On Thu, 28 May 2020 11:26:09 +0200 Jean-Jacques Brucker <jeanjacquesbruc...@gmail.com> wrote: > Source: vsftpd > Severity: critical > Tags: ipv6 > Justification: breaks the whole system > > Dear Maintainer, > > In some case (eg. embeded devices or private network), it sounds good to > desactivate ipv6. > > But when ipv6 is desactivated, for exemple with "ipv6.disable=1" into the > GRUB_CMDLINE_LINUX, > the vsftpd package can't be use, but also can't be installed, or reinstalled, > since installation fail when postinst fail to start vsftpd service.
It is a widespread and imho completely acceptable solution to support IPv6 by binding to [::] (which usually binds both IPv4 and IPv6), and to do this by default. If you decide to brick your local IPv6, it is up to you to fix the config files of all the network daemons. (In this case simply enable "listen" instead of "listen_ipv6" in the config.) If you can't figure this out: don't disable IPv6 (or perhaps try to only disable IPv6 addresses on your network adapters instead of killing the address family). You already should have noticed when installing vsftpd that you need to fix this, so it is your fault the package management is in a bad state. > Fail during package install/upgrade is critical because it may leave the > system in a brocken > state (cf. "apt-get check"). If you think postinst failures breaking "apt-get check" are such a big problem I suggest you file a bug with apt. Or with debhelper. This certainly isn't a vsftpd-only issue. Lots of post-inst scripts break if the config files are broken. > To at least decrease the severity of the bug, a workaround could be to NOT > start or restart > vsftpd service during install or upgrade, or maybe better : to check ipv6 > (somewhere in /proc) > before to start or restart service in postinst. It is ridiculous to ask your completely non-standard setup to be supported out of the box. (Also I doubt such changes would ever get backported to stable, much less oldstable.) Also your chosen severity level led to this: > Version 3.0.3-12 of vsftpd is marked for autoremoval from testing on > Fri 26 Jun 2020. which is completely unreasonable. I'm going to degrade the severity to normal; although if I were the maintainer I'd probably go for "wishlist" and close it with a "wontfix" tag. regards, Stefan
