Requiring semver does not allow for build versioning

[npmccallum]

Software supply chain flows from upstream(s) through a builder and into a binary artifacts repository (i.e. Bindle). Both the upstream source and the builder can provide versioning information. Bindle's requirement that bindle names must be semver forces an assumption that each upstream source version has exactly one corresponding build. This assumption doesn't play out in practice.

In any sufficiently large software supply chain, one upstream source may produce many builds. For example, a compiler bug may produce a vulnerability during build (this happens with unfortunate frequency). Thus, one can resolve a security vulnerability by producing a new build but without modifying the source code. Compiler bugs, toolchain bugs build system bugs and even metadata bugs are all unfortunate realities that are produced by the build process.

In some limited cases, it might be possible to force the upstream source to change its source code version for every build. But this is not a common case. In fact, in open source, it is almost never the case since the upstream and builder are two distinct entities.

Put simply, for any given binary artifact there are two versions: the upstream source version and the build version. I don't see any way for Bindle to represent that today.

[npmccallum]

Specifically, this problem arises when upstreams already use the build field of semver. For example, https://crates.io/crates/rdkafka-sys whose current upstream version is 4.2.0+1.8.2.

[radu-matei]

If I understand this correctly, the ask here would be to relax the reference convention in Bindle so that the segment following the name would be an arbitrary string, very much like the tag of a container image.

So instead of:

Version MUST be a valid SemVer 2 version

we would have

Version MAY be a valid SemVer 2 version

Is this a reasonable reading of your ask?

What would be the convention for representing upstream source version and build version in Bindle if the change above were permitted (and the upstream version already included the build field)?

Have you considered expanding the invoice / label specs to include (potentially optional) fields for the various versions mentioned here, and keep the top level version field for the bindle itself?

My worry is that if we allow arbitrary strings in the reference, we would end up with either an underused (and potentially non-standard) way of specifying the various versions, and open up the possibility for using tags the way they are currently used in OCI today (for example).

[npmccallum]

@radu-matei I'm not sure I'm actually making an ask here. If I were to rephrase this issue, the problem is that while semver allows for build metadata, this metadata is widely abused for things other than build. A great example is a crate near and dear to our hearts: https://crates.io/crates/wasi. Upstream is using the build metadata field of semver to refer to properties of the source code.

Perhaps we can close this issue once people are aware of the problem.

[technosophos]

In Helm, we went over this for epicycle upon epicycle. What we did there was add a second version field (appVersion) that captured the version of the upstream source: https://helm.sh/docs/topics/charts/

By separating the package version from the app version, you get the additional ability to reason about the version of the app (assuming the app version is in some way meaningful).

Clarification: So the main Helm chart version is a SemVer. The appVersion is an opaque string that can be used to store the version of the upstream source. That way, we can reason about chart version (including reasoning about any build metadata supplied there) separately from our reasoning about the upstream appVersion. And we can make much stronger assertions about what version means because it follows the spec.

[thomastaylor312]

Yeah, I agree with @technosophos here. If anything, having a separate field (or just leveraging annotations) would also solve the concern in #265