Summary

  • Starla’s pinned source has a workspace package version of 0.8.0, a firmware compatibility constant of 5120 and result measurement-code version 2.6.4. The result tuple does not uniquely identify the executable that produced it.
  • Registration explicitly includes Starla and its compiled package version. This is not a finding that the implementation is concealed from RIPE NCC, nor that any measurement is wrong.
  • The distinction matters when a consumer compares measurements across software changes. Compatibility, deployed-build identity, collection completeness and independent conformance need separate evidence rather than one overloaded version label.

Two version numbers can be correct and still identify the wrong thing for a reader’s purpose.

In Starla’s public source captured at commit 82bf0d9c42883bfe4d8a20d4ee444e7a0f8b55f1, dated 7 September 2026, the Cargo workspace declares package version 0.8.0. The shared firmware constant is 5120. A result formatter sets mver to 2.6.4, and the traceroute implementation writes that measurement-code version into its own full result line. These are not three competing estimates of how old one program is. They belong to different naming systems. Workspace version, result formatter.

The developer introduced Starla on the RIPE NCC forum on 9 April as a Rust rewrite of the RIPE Atlas Software Probe, presenting it as a drop-in replacement. That is a useful ambition. A compatible implementation can widen the set of environments in which people contribute observations. It can also make an established measuring system less dependent on one codebase. The claim of equivalent measurement behaviour, however, remains the developer’s claim here; this research did not independently test it. Developer announcement.

The source version is not an installed-fleet inventory. It does not establish which release a host downloaded, which options a distributor compiled or whether any particular Atlas result came from Starla. The narrower finding is sufficient: the compatibility numbers in these producer paths cannot, by themselves, name the actual implementation and build.

A parser’s answer is not a provenance answer

RIPE Atlas already has a measurement-code version field. Its official documentation describes fw as the probe firmware version and mver as the version of measurement code. The latter’s major, minor and patch components distinguish incompatible results, added fields and code changes that leave the output format unchanged. That is more than a bare JSON schema label. It is an existing attempt to tell consumers what changed underneath familiar fields. It should not be dismissed as absent. Official result-versioning documentation.

Starla illustrates a limit to treating those numbers as a globally unique description of the producer. Its shared source keeps the firmware constant separate from a version string derived from CARGO_PKG_VERSION. A developer comment explains the constant in terms of matching the reference probe for controller acceptance. The comment records the author’s rationale; it is not an independent test of current controller policy. Shared version definitions.

For an importer, a familiar tuple can be helpful. It suggests which fields and formats to expect. For an analyst asking whether a software change coincided with a change in observed latency, it is an incomplete answer. Two implementations can choose the same compatibility declaration while having different source histories. Even two builds of the same source can differ in relevant dependencies or options. None of that proves that their measurements differ. It establishes why a compatibility declaration cannot also serve as proof that they are the same instrument.

This is a namespace problem before it is a quality problem. A value has meaning within the convention that assigned it. Sharing that value does not merge every fact about the programs using it.

Registration supplies an important counterexample

Starla does not leave its own name out of everything it sends.

The inspected registration code constructs a sub-architecture string from operating-system identity, operating-system version, architecture, starla and the compiled package version. It includes that string in the initialization message alongside the firmware value. The registration surface therefore expressly distinguishes the implementation. Any account that describes Starla as wholly invisible to the registry would contradict this source. Registration identity construction.

What this investigation has not established is the historical association available to a downstream reader: whether the declared implementation and actual deployed artifact can be joined to a particular result at the time it was generated. That requires evidence about registration retention, changes of build, export enrichment and any public or restricted metadata interface. Examining Starla’s result-generation code is not an audit of all RIPE NCC internal records or all public probe metadata.

A current label would not necessarily answer the historical question. A host can upgrade while preserving its probe identity. A later description can correctly describe today’s executable while saying little about the one running during last month’s outage. A package version in a declaration is also not a digest of the actual binary. The useful unit for provenance is consequently an interval: this producer declaration and build applied to this period, with this degree of verification.

The registry need not publish private keys or identify the person hosting a probe to make that distinction useful. Instrument history and personal identity are different disclosures. Some build evidence may sensibly remain available only to authorised researchers. The important thing is that the limits of the association are stated.

An alternative backend is not a deployed finding

The ping implementation has two execution alternatives: its in-process Native path and a Scamper path available on Linux. After choosing the branch, it puts the shared firmware value into the returned measurement. Traceroute also contains Native and Scamper alternatives and constructs a result using the shared firmware constant and mver=2.6.4. The inspected output construction does not turn that tuple into a backend identifier. Ping implementation, traceroute implementation.

There is a consequential restriction. In the pinned scheduler, ordinary ping and traceroute jobs are converted into executable measurements with backend: Default::default(). Native is the default. The existence of the library alternative is therefore not evidence that the ordinary controller job path selects Scamper, that a public Atlas measurement has used it or that changing the backend changes a result. Scheduler job conversion.

That qualification strengthens the argument. The task is to describe what actually ran, not every capability that a repository contains. Provenance based only on a feature list can be as misleading as provenance based only on a compatibility number. A useful declaration would identify the executed method and configuration where they matter, without presenting an unused alternative as an observed treatment.

Nor would a binary digest settle scientific equivalence. It would identify an artifact, not prove its timing, packet construction or error handling matches another artifact. Conformance needs its own test evidence and scope. Separating these questions avoids making a software label do the work of an experiment.

The sample also has a collection history

An instrument’s implementation affects more than the fields attached to a successful observation. It can affect which observations survive to be uploaded.

Starla’s bounded in-memory queue removes its oldest item when admitting a new result at capacity. Failed-upload requeue uses a different order: it restores work at the front and trims the back when necessary. The result handler separately applies age and retry limits. Its defaults include a 10,000-result queue and a maximum result age of 3,600 seconds. These are source defaults and branches, not verified live settings or an observed loss event. Queue behaviour, handler defaults and cleanup.

Bounding a queue is defensible. A volunteer host should not have to accept unlimited memory use because an upload endpoint is unavailable. Retrying indefinitely can also keep stale work alive at the expense of new observations. The trade-off is that a collection may describe the measurements successfully retained, not every measurement attempted.

That difference matters especially during stress. A gap in the uploaded series could be related to scheduling, local retention, transport or something else. It cannot automatically be read as a destination failing to answer. Conversely, these source branches are no evidence that a particular gap was caused by queue pressure. Without an attempt inventory or safe omission counters, the reason may remain unknown.

Producer history and completeness history are thus related but not interchangeable. The former helps identify the method. The latter helps interpret the sample that reached the reader. Neither justifies calling an old result false because its metadata is incomplete.

Preserve the evidence and narrow the claim

The first operational response should be additive. Keep the existing result and its original fields. Where a historic producer association is known, attach it with a date and provenance. Where it is not known, mark that uncertainty rather than silently inferring Starla, a reference implementation or a particular build from 5120 and 2.6.4.

A consumer comparing observations can then decide whether implementation epochs are relevant to the question. Routine reachability monitoring may need no binary-level comparison. A study attributing a small performance shift to a network change has a stronger reason to stratify by producer history or obtain a controlled comparison. A compatibility declaration is still useful in both cases. It simply stops pretending to be all the evidence.

Starla’s contribution is not discredited by naming this boundary. The source makes the boundary inspectable, the registration already identifies the implementation, and the existing Atlas version fields remain useful. The missing proof in any particular analysis is a narrower matter: that the apparent continuity of a version tuple corresponds to the instrument continuity the analysis assumes.

Sources

The linked evidence consists of nine Starla source files pinned to the 7 September commit, the developer’s April forum announcement and RIPE Atlas’s official result-versioning documentation captured on 14 September. Source inspection establishes the described code paths, not their deployment. No probe was installed, registered or run, and no paid measurement or independent conformance test was performed.