Package: ieee-data Version: 20240722 Severity: important File: /usr/sbin/update-ieee-data Tags: newcomer X-Debbugs-Cc: [email protected]
Dear Maintainer, When initially installed, package 'ieee-data' puts its data files in /usr/share/ieee-data, with individual links in /var/lib/ieee-data/. The updater script update-ieee-data(8) breaks these links, writing its updated files directly into /var/lib/ieee-data, while not updating the original package files in /usr/share/ieee-data/. When I first started writing this report, I thought that was just a bug. Then I realized that this was a deliberate choice by some package maintainer in the past, making it so that the files delivered in the package are not modified, yet the on-system data *can* be modified. Great! Except there are some severe implementation defects, so after further investigation I've come back to the feeling that it's wrong and needs to be redone. `apt-cache rdepends ieee-data` finds 14 such packages known to my system. Of these, 5 don't actually seem to use the files, 1 is just a Suggests, 2 use the files correctly, 1 uses them correctly almost by mistake, and 5 use them wrong. So 5-or-6-of-8 which actually directly use the files, look in the wrong place and will not be updated when the admin runs `update-ieee-data`. This could be looked at as a notice to fix those 5-or-6 packages. But I think it really shows that the packaging is wrong, error prone and leads to bad situations. These packages feel like they assume that the two directories are equivalent. I think things would work better if that were true. Make one of [ /var/lib/ieee-data, /usr/share/ieee-data ] a real directory containing real data files, and the other a directory-level symlink. It should be possible to do this with dpkg, perhaps by making those files conffiles? If the current arrangement is to persist, those 5-6 packages should be fixed, and a README should be put in BOTH directories explaining their relationship. Which is: - either or both of these directories may exist on various systems - individual files may or may not exist - if both exist, prefer /var/lib/ieee-data, as it is updated from IEEE master files NOTE: I initially tagged this 'newcomer', thinking it would just be a matter of making the directory-level symlink. Now it gets into arcana of mutable vs immutable package files and stuff like that, I am less certain.. ===== DETAILED details of the 14 relevant packages: Summary: Of 14 packages mentioning some level of dependency on ieee-data: - 5 (arpalert, fwupd-tests, python3-netaddr, python3-pyric, ruby-packetfu) don't appear to directly use the files; dependency could be reduced to Recommends or Suggests - 5 (arpwatch, btscanner, hcxtools, ocsinventory-reports, wifite) refer to WRONG paths and will not be updated if these data files are updated - 2 (arp-scan, ipv6toolkit) use the RIGHT paths and are fine - 1 (aircrack-ng) looks for both WRONG and RIGHT paths, and gets lucky (alternate implementation in the source, but not used in the Debian package, gets it WRONG) - 1 (isc-dhcp-server) merely Suggests ieee-data DETAILS: Package: aircrack-ng - binary usr/sbin/airodump-ng mentions /var/lib/ieee-data/oui.txt and usr/share/ieee-data/oui.txt in that order. Does it stop at the first one that exists (thus gets the right one)? Last one seen? Something else? Checking the source, it appears that it will get the RIGHT one, almost by chance. It stops at the first file found to exist. The source also has a Python implementation (which is apparently not used in Debian) -- which scans the same list in the same order, but returns the *last* found file, so would get the WRONG one. Package: arpalert - no apparent direct use; demote from Depends to Recommends or Suggests? Package: arp-scan - usr/sbin/get-oui scrips uses /var/lib/ieee-data/* -- RIGHT - man page get-oui(1) mentions /var/lib/ieee-data/* -- RIGHT Package: arpwatch - control/postinst & control/triggers arrange to watch for updates to /usr/share/ieee-data/oui.txt (WRONG); if updated, runs its script /var/lib/ieee-data/update.d/arpwatch to update from /var/lib/ieee-data/oui.txt (RIGHT, but presumably never triggered) Package: btscanner - control/postinst & control/triggers arrange to watch for and absorb updates to /usr/share/ieee-data/oui.txt (WRONG) Package: fwupd-tests - no apparent direct use; demote from Depends to Recommends or Suggests? Package: hcxtools - usr/bin/hcxhashtool binary mentions /usr/share/ieee-data/oui.txt (only; WRONG) - usr/bin/whoismac binary mentions /usr/share/ieee-data/oui.txt (only; WRONG) - usr/share/doc/hcxtools/changelog.gz refers to WRONG path Package: ipv6toolkit - etc/ipv6toolkit.conf uses /var/lib/ieee-data/oui.txt (RIGHT) Package: isc-dhcp-server - Suggests: ieee-data (fine) Package: ocsinventory-reports - usr/share/ocsinventory-reports/var.php uses /usr/share/ieee-data/oui.txt (WRONG) Package: python3-netaddr - no apparent direct use; demote from Depends to Recommends or Suggests? Package: python3-pyric - no apparent direct use; demote from Depends to Recommends or Suggests? Package: ruby-packetfu - no apparent direct use; demote from Depends to Recommends or Suggests? Package: wifite - usr/lib/python3/dist-packages/wifite/config.py uses /usr/share/ieee-data/oui.txt (WRONG) - usr/share/doc/wifite/changelog.Debian.gz refers to WRONG path ===== -- System Information: Debian Release: forky/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.17.13+deb14-amd64 (SMP w/14 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ieee-data depends on: ii curl 8.18.0-1 ii libwww-perl 6.81-1 ii wget 1.25.0-2 ieee-data recommends no packages. ieee-data suggests no packages. -- no debconf information
