ripe-atlas: restore libopenssl dependency and migrate state from atlas-sw-probe

[BKPepe]

Two follow-ups on top of your ripe-atlas-followup branch, targeted at it rather than at master so they land together with openwrt#30067.

1. Keep the direct libopenssl dependency

This reverts ripe-atlas: drop redundant libopenssl. The Atlas busybox links OpenSSL itself, it does not just inherit it from the ssh tools:

$ readelf -d usr/lib/ripe-atlas/measurement/busybox | grep NEEDED
 0x00000001 (NEEDED)  Shared library: [libcrypto.so.3]
 0x00000001 (NEEDED)  Shared library: [libssl.so.3]
 0x00000001 (NEEDED)  Shared library: [libc.so]

openssh-client and openssh-keygen do pull libopenssl in today, which is why CheckDependencies stays quiet - .provides is accumulated over the whole dependency closure, so a transitively reachable libcrypto.so.3 satisfies it. That makes the build agree with the drop, but the package now links a library it does not depend on, and the day openssh stops needing libopenssl this breaks at runtime instead of at build time.

2. Migrate probe key and config from atlas-sw-probe

ripe-atlas-probe provides atlas-sw-probe and ripe-atlas-common provides atlas-probe, so an existing installation resolves onto ripe-atlas on the next update. That settles the dependency, but carries no state across, and the two packages share nothing:

atlas-sw-probe	ripe-atlas-common
/etc/atlas/probe_key	/etc/ripe-atlas/probe_key
/etc/atlas/probe_key.pub	/etc/ripe-atlas/probe_key.pub
/etc/config/atlas	/etc/config/ripe-atlas
user atlas (444)	user ripe-atlas (445)

A probe is identified by its ssh key, and generic-ATLAS.sh generates a fresh one whenever $ATLAS_SYSCONFDIR/probe_key is missing. As it stands, every upgraded probe silently re-registers as a new one and loses its probe ID, measurement history and credits, with no way back - the old ID stays bound to a key the probe no longer presents.

The uci-defaults script copies the key over, tightening the private key to 0600 (atlas-sw-probe kept it at 0644), and carries the uci settings across. An existing key is never overwritten.

It also stops and disables the old init script if it is still present. OpenWrt has no Replaces:, and the paths do not overlap, so nothing forces atlas-sw-probe out on a plain opkg upgrade; leaving it enabled would have two probes presenting the same key to the registration servers. Happy to drop that hunk if you would rather not touch another package's init from here.

Run tested

Turris 1.x build tree (OpenWrt 24.10, mpc85xx/p2020, powerpc_8548, gcc 13.3.0, musl). Builds clean, and the resulting control file is back to:

Package: ripe-atlas-common
Depends: libc, jsonfilter, openssh-client, openssh-keygen, libopenssl
Provides: atlas-probe
Require-User: ripe-atlas=445:ripe-atlas=445

The migration script was exercised against a staged /etc/atlas for all three paths: migration (key copied 0600, rxtxrpt mapped to rxtx_report, old init stopped and disabled), fresh install (no-op), and an already-registered probe (existing key left untouched).

Unrelated note on the LDFLAGS commit

I could not reproduce openwrt#30083 on 24.10, with or without MAKE_FLAGS += LD=.... Without it the build still succeeds, and probe-busybox/applets/.built-in.o.cmd shows what actually linked:

cmd_applets/built-in.o :=  ccache powerpc-openwrt-linux-musl-gcc -nostdlib -nostdlib \
  -L... -fuse-ld=bfd -DPIC -fPIC -specs=.../hardened-ld-pie.specs -znow -zrelro -r -o applets/built-in.o

So LD stayed busybox's own $(CC) -nostdlib from probe-busybox/Makefile; OpenWrt's LD="$(TARGET_LD)" from TARGET_CONFIGURE_OPTS never reached the busybox sub-make here, even though CC did. LDFLAGS does carry -fuse-ld=bfd and -specs=, so it would certainly have failed had ld.bfd been used.

The change is harmless either way, but on this tree it is a no-op, so whatever the reporter hit on snapshot with gcc 16.1 may have another cause. Worth a second look before the Fixes: line goes in - and the other half of that issue, the wrapped //config: comments in eperd/evtdig.c, is not covered by this PR at all.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.