Summary

  • RIPE Atlas firmware 5130 adds an openwrt-hwprobe architecture intended to enable next-generation firmware on existing hardware probes, while RIPE NCC’s Q3 plan still describes the broader OpenWrt packaging work as in progress.
  • Public documentation exposes meaningful controls: a production branch, a production-version convention, generation-specific public-key files, release notes, checksum-aware update debugging and a firmware-version field on probe records.
  • Those controls do not make a version label equivalent to a build or rollout receipt. A reviewer still needs immutable joins among source, toolchain, artifact, signature, hardware eligibility, deployment outcome and rollback.
  • No compromised build, bad signature, failed update, outage or measurement error is alleged. RIPE NCC should publish an aggregate, machine-verifiable release manifest backed by a protected device-level deployment ledger.

One number, several different facts

A probe wakes, connects to the RIPE Atlas infrastructure and reports a firmware version. The number is compact and useful. It lets a host see whether a device appears current. It lets an API user filter probe records. It lets a researcher place an observation on one side or the other of a documented code change. In routine work, that label feels close enough to provenance that the distinction disappears.

Firmware 5130 shows why it should not disappear. Its release note spans all platforms, hardware probes, software probes and continuous integration. It fixes an NTP offset regression, changes registration infrastructure, adds package tests and introduces the openwrt-hwprobe architecture. Inside the hardware section, it says the new architecture allows next-generation firmware on existing hardware probes. It replaces a split-base design with a common base, adds checksum output for debugging update files, fixes an application-upgrade bug and changes how saved static network configuration is recovered.

Those are not one fact. They are a source change, a build choice, an artifact, an authorization event, an eligibility decision, a delivery attempt, a device transition and an observable runtime state. “5130” is a name shared by those facts. It is not proof that all of them occurred for a particular probe.

This matters even when everything works. A measurement platform is an evidence system. Its hardware sits in networks it does not control, performs tests selected by other parties and contributes results that may be used years later. If a result is questioned, the relevant inquiry is rarely only “what version did the probe report?” It may be “which 5130 artifact was this, built from which exact inputs, accepted by which hardware generation, after what update path, and under what exception or rollback state?”

The public record currently provides several pieces of that answer. It does not yet join them into one portable receipt.

The roadmap became running code

RIPE NCC’s Q3 2026 RIPE Atlas plan says the organisation is streamlining the probe-firmware process and is working on OpenWRT for hardware probes. The status is “in progress”. That wording is appropriately cautious. It describes a programme, not a fleet verdict.

The 5130 note is more concrete. An architecture named openwrt-hwprobe is now in the released codebase. It is said to enable next-generation firmware on existing hardware probes. The difference between those two public statements is useful. A plan can remain in progress while a code path has already crossed a release boundary. Conversely, a released architecture does not prove that every intended device has received, accepted or remained on the resulting firmware.

The temptation is to turn one layer into the other: the code exists, therefore the migration happened; or the programme remains in progress, therefore nothing operational has changed. Both shortcuts destroy information. Delivery systems advance by partial states. Source can be merged before a package is approved. A package can be signed before a cohort is eligible. A cohort can be eligible before a device connects. A device can install before it passes checks. A successful canary can precede a wider pause. A rollback can return a device to an earlier state while its earlier measurement rows remain valid historical records.

The public description should preserve those states instead of asking “released” to carry all of them.

The repository contains controls worth keeping distinct

The pinned public BUILD guide describes master as production-ready and says hardware-probe firmware is built from that branch. It distinguishes testing, devel and ticket branches. It also gives a versioning convention: numbers divisible by ten are production releases. For OpenWrt, the guide says the feed defaults to master, while a builder can instead pin a branch or commit.

These are real safeguards against casual ambiguity. Branch separation communicates maturity. The version rule tells an operator which labels are meant for production. Commit pinning provides a way to stop a moving branch from changing beneath a build. None should be dismissed merely because it is not the whole chain.

The pinned OpenWrt Makefile adds more boundaries. It derives the package version from the repository’s VERSION file. It copies the source tree into the OpenWrt build directory. It carries development, production and test public-key files for hardware-probe generations v3, v4 and v5. The hardware package is marked for installation only at RIPE NCC’s direction.

That is a legible architecture of authority. A branch describes code maturity. A version describes a release family. A public-key file lets a device distinguish an authorised update class. A hardware target describes compatibility. RIPE NCC’s direction describes operational permission. They are related, but they are not interchangeable.

A weak account of the release would compress them into “the probe runs 5130”. A stronger one would retain the exact source commit; the OpenWrt release, SDK and dependency lock; the target profile; the artifact digest; the production signing-key fingerprint or class; the approval; and the release-note identity. The private key must never be published. The proof that a named, approved public key class signed a particular digest can be retained without revealing it.

A moving branch is a direction, not a reconstruction key

Calling master production-ready is a policy about the branch. It does not make the word master immutable. The branch moved before this article was written and will move again. A researcher attempting to reconstruct a past build therefore needs the commit that the build actually consumed, not the branch that was generally designated for production.

The BUILD guide already acknowledges this distinction by showing how an OpenWrt feed can be pinned with ^commit. The missing step is to make that pin part of the release identity every time. It should not depend on a later operator remembering which checkout was used.

The same discipline applies below the repository. An OpenWrt build is also a selection of upstream source, target definition, compiler, package feeds, patches and configuration. Two builds can begin with the same application commit and still produce different bytes because another input moved. A reproducible manifest need not promise byte-for-byte reproducibility under every environment. It should at least disclose enough immutable inputs and output digests to tell whether two artifacts are intended to be the same.

Firmware supply chains often fail audits at this mundane boundary. The code review is documented. The release note is documented. The device version is documented. What is missing is the join that says this reviewed code, combined with these locked inputs, produced this digest, which this signing authority approved for these hardware profiles.

Nothing in the reviewed record proves that RIPE NCC lacks that join internally. The question is what minimum form should travel with the public release claim.

A probe version is observable after several decisions

RIPE Atlas’s probe-management documentation says that a probe connecting to the infrastructure will most likely upgrade to the newest firmware and begin predefined measurements. It also says the probe detail page shows the firmware version. The public probes API includes a firmware_version filter.

This observability is valuable. It means the platform does not treat software state as entirely hidden. But the words “most likely” preserve a crucial uncertainty. A hardware fleet is not one simultaneous transaction. A probe may be offline. It may reconnect late. It may not be eligible. An update may be deferred. The device may accept the artifact but fail a later health check. The platform may pause a cohort or authorise a rollback. A version field can report the state eventually observed; it cannot explain every decision that led there.

Nor should the public API expose each host’s operational history. Probe locations and networks can be sensitive. An adversary does not need a device-by-device list of failed updates, timing and hardware weaknesses. The answer is a two-layer record.

The protected layer should bind a device identifier to its before and after versions, artifact digest, eligibility basis, attempt and acknowledgement times, verification result, connection and measurement smoke tests, error class, retry state, rollback authorization and exception reason. Access and retention should be limited.

The public layer should aggregate the same state machine by hardware generation or safely sized cohort: eligible, attempted, succeeded, deferred, failed and rolled back. It should identify the rollout window, test threshold, exception classes and whether the release was active, paused, superseded or withdrawn. That is enough to make a release claim testable without publishing a map of vulnerable or unavailable probes.

The receipt should start before the binary and end after the update

A useful chain-of-custody receipt can be compact. It needs an immutable source commit; an OpenWrt release and SDK identifier; locked dependency or feed identities; build configuration and target profiles; output and manifest digests; the production signing-key fingerprint or non-secret key class; approving role; release number and note; cohort rule; rollout start and end; aggregate outcomes; smoke-test suite; rollback threshold; decision state; exceptions; superseding release; and correction history.

Several fields already have public counterparts. Firmware 5130 has a release page. The public repository has a commit history and a release object. The Makefile has explicit hardware-generation key classes. Probe records have a version. The work is not to invent a new governance theatre around engineering. It is to connect existing engineering evidence across the places where custody changes.

The receipt should also resist false precision. An aggregate success count must name its denominator. “Ninety-nine per cent updated” means little if the eligible population, observation time and treatment of offline devices are unspecified. “No failures” is ambiguous if deferred devices are omitted. “Rolled out” is ambiguous if devices installed the package but did not complete a representative measurement check.

The acceptance test should therefore include more than boot. A hardware probe’s purpose is measurement. The relevant suite can test controller reconnection, identity continuity, clock behaviour, DNS, ping, traceroute and any platform-specific functions affected by the release. It need not publish targets or thresholds that would create abuse opportunities. It should publish the suite version, pass rule and aggregate result so that “installed” is not silently promoted to “fit for measurement”.

The strongest objection is operational, and it is valid

Release engineers may object that a detailed public manifest adds work to a process already designed to reduce packaging friction. Hardware generations differ. Dependencies move. Emergency fixes should not wait for a communications exercise. Device-level rollout detail can expose operational weakness. A rigid disclosure template may become obsolete faster than the firmware it describes.

That defence deserves weight. The objective is not to make incident response wait for prose. The manifest should be generated from build and deployment systems, not written by hand after the fact. Sensitive fields belong in the protected layer. Emergency authority should allow a release to begin with a minimal signed identity, followed by a bounded completion window for aggregate outcomes and reasons.

The more important answer is that streamlined packaging increases the value of an automatic record. A common base can reduce duplicated engineering paths. It can also make one shared mistake travel farther. Faster, more consistent releases are desirable precisely when the evidence of what moved becomes cheaper to capture and harder to reconstruct later.

The public source already demonstrates an appetite for explicit versions, branches, key classes and release notes. A chain-of-custody receipt extends that grammar across the deployment boundary. It is not a rival to engineering speed. It is how speed remains explainable.

Sources