On Fri, May 31, 2019 at 12:09:19PM +0200, Thomas Schmitt wrote: > > Not every filesystem supported by Debian > > implements extended attributes needed for capabilities. > > Off the top of my head it's NFS and JFFS2. > > It is about the filesystem which holds the /bin directory. I would deem it > extra-expert to use a partly incapable filesystem for that.
Please. NFS-for-root is decades old. JFFS2 is wildly popular for DIY solutions. Calling everyone who bought $20 ARM board on AliExpress an 'expert' seems overstretched. > Whatever, the maintainer's reasoning was a then valid quote from the > policy manual ... > It became not a decisive argument against dependency. It's really sad to see a maintainer who resorts to lawyering instead of considering real technical limitations of the "solution" proposed. > > Upgrading this particular dependency leads > > only to a dependency bloat, and Default Users™ (i.e. ones that are > > installing Recommends by default) aren't affected anyway. > > Currently the Default User depends on assumptions about local package > management which are not obviously related to security. So? The end result justifies a current situation. > That's a future pitfall which just needs its unintentional cover removed. The way I see it, the "problematic" package got that Important priority already. A potential pitfall is closed. > To skip a security improvement in order to save 111 kB of installed size > seems daring. (Size for amd64 taken from end of > https://packages.debian.org/unstable/libcap2-bin > ) Replacing a working fallback mechanism with one-size-fits-all "everyone are using ext4 on amd64 and Linux" is hardly an improvement. Reco
