chore: drop unused image files and the perl build dependency, restrict /dev/crypto

[JanZachmann]

Summary

• openssl bbappend: delete c_rehash and ${libdir}/ssl-3/misc
• nss bbappend: restrict FILES:${PN} to the libraries, the config and shlibsign, and move the rest of ${bindir} into a new nss-tools package that no image installs
• omnect-os-distro.conf: RDEPENDS:nspr-dev:remove = "perl"
• cryptodev-udev: new file-only recipe shipping 10-cryptodev.rules, which gives /dev/crypto mode 0600; installed on tauril2 through the machine include. The module itself stays in the image.

Reason

omnect-os-distro.conf already drops openssl-misc and nss-smime from PACKAGES to keep perl out of the image, but PACKAGES:remove only removes the package - the files move into the respective main package and still ship, as perl scripts in an image without a perl interpreter.

nss is the bigger case: the recipe has FILES:${PN} = "... ${bindir} ...", so 49 tools ship (certutil, pk12util, selfserv, tstclnt, ssltap, signtool, the test binaries, ...) although nothing in the image references any of them - networkmanager pulls nss in for the libraries only. Restricting the package and collecting the tools in nss-tools keeps them buildable for a debug image and takes them out of the release image, including smime, so no single-file removals are needed there. shlibsign stays in the main package because the nss postinst calls it, and that postinst can end up running on first boot. openssl keeps the file removal: upstream splits those two paths into openssl-misc and the main package claims them only because the distro drops that package.

perl itself shows up in the image SBOM although no perl file is in the image: the SBOM is written per built recipe, and the only recipe pulling target perl into the build is nspr (RDEPENDS:${PN}-dev += "perl", nspr comes in via networkmanager -> nss -> nspr). Dev packages are never installed, so dropping that dependency changes nothing in the image while taking perl out of the build and out of the SBOM - four high/critical findings less to moderate per release.

On tauril2 the imx BSP installs the cryptodev module, it is loaded at boot, and the driver creates /dev/crypto world read/write, while upstream has no fix for CVE-2026-28529 (use-after-free in get_userbuf(), local privilege escalation). The module stays available for applications; the udev rule takes away the world read/write default, and its low number lets a customer rule override the mode.

No other BSP ships cryptodev, and no script, unit or binary in the 6.0.2 images references the removed files or /dev/crypto.

[JanZachmann]

No, and this is the same question you raised on #688 - answer repeated here so this PR stands on its own. Checked in this release's oe-core (meta/lib/oe/package.py), not from memory:

• populate_packages() walks PACKAGES in order with one global seen list and does if file in seen: continue before claiming a path. First matching package wins; no later package can take the same path.
• nss comes before nss-tools (the bbappend uses PACKAGES:append), so ${bindir}/shlibsign is claimed by nss.
• When nss-tools is processed, files_from_filevars() expands the directory entry to its children (if cpath.isdir(f): files += [os.path.join(f, x) for x in os.listdir(f)]). ./usr/bin itself is already in seen (it was created while packaging shlibsign) and is skipped, shlibsign is skipped for the same reason, and the remaining binaries go to nss-tools.
• So no file is in both packages, and no installed path stays unpackaged either - hence no installed-vs-shipped.
• The /usr/bin directory node exists in both packages; mkdir_recurse() creates it per package. Shared directories are not a conflict for ipk/rpm, only identical files would be.
• The recipe already relies on the same rule in the other direction: FILES:${PN}-smime = "${bindir}/smime" next to FILES:${PN} = "... ${bindir} ...", with nss-smime prepended.

One correction on the count: FILES:${PN} has a single ${bindir} entry (shlibsign); the other three entries are ${sysconfdir} and the two ${libdir}/lib* globs.

Since the line has now prompted the question twice, 1ee9be3 writes the rule into the file:

# PACKAGES order decides who claims a file first: nss takes shlibsign, nss-tools
# the rest of bindir. No file ends up in both.
FILES:${PN}-tools = "${bindir}"

The only alternative that removes the implicit ordering would be listing all ~49 tool names in FILES:${PN}-tools and putting that package before ${PN} (the upstream nss-smime pattern). I would not do that for 49 names, but say so if you disagree.

Limitation unchanged: this is from reading the packaging code, not from a build - CI still has to show the split and that no QA warning appears.

@mlilien your approval was on 86113fc7 and main requires approval of the last push, so the comment commit above invalidated it - re-requesting.