Applying OmniBOR to different contexts.

[alilleybrinker]

At the April 22nd meeting we had a good discussion about how OmniBOR can apply to different types of systems, prompted by the question of how best to engage with Docker.

• (DPP) has found time with Docker people; Docker already emits a SHA-256 on layer load. Potential concern with asking them to emit a GitOID on layer load.
  This ties back to the Artifact ID construction question
• (Ed) What does the graph of layers look like for Docker images?
• (DPP) Containers, Layers, Files, can reference each other
• (Ed) How to handle layer masking / layer composition
• (Andrew) I wonder if it would be useful to express OmniBOR manifest creation generically for “build systems” as they’re described in “Build Systems a la Carte”? This could then bring applicability to lots of build-system like things including Docker, cloud build systems like Buck, and others.
• (Ashley) Yes, may be useful to look at a variety of structures. May be useful to have lots of examples of the applicability of OmniBOR to different systems
  • Build systems
  • Bundles (tarballs, zips, iso images, things like that)
    May be useful to even express these things in a mind map
• (Frederick) For Docker specifically, it’s worthwhile to split out some things. docker history gives you the history of a container, and things like having a build container which copies into a release container, there’s a lot of room for losing information
• (Andrew) There’s also an operation for layer flattening (I forget the precise term Docker uses) which similarly loses information.
• (David) Attestation phase is also a “gating-phase” for “is OmniBOR information present”? If you’re doing a multi-stage build, you’d want to confirm the presence of an OmniBOR manifest at the end of each stage; basically require a manifest (attestation) at the end of any step after which information can’t be recovered.
• (Ed) Note: a docker image feels like more than just its layers. The same layers with a different manifest may have notable differences as a resulting image or running image.
• (Frederick) In the in-toto context, it’s becoming more common to see multiple phases for which attestations are being produced, and additional complexity creeping in from the inclusion of external things, details of which can’t be attested / guaranteed to be consistent over time. Hopeful for a longer-term simplification of build systems driven by the need to analyze / attest to things in the build system context.
• (Ashley) This also ties to the question of where to store OmniBOR data. Generally, expect to always see build systems fetching things from the internet. So we need to make sure the OmniBOR data can always sit alongside the artifacts they’re describing so they become easy to gather / distribute.
• (Ed) Do you mean just the Artifact Identifier, the Artifact Input Manifest, or the full recursive closure of manifests for all dependencies?
• (Ashley) Purposefully generic to avoid pre-determining the right outcome. Generally want to ensure things are easy for adopters to gather the right data, while also avoiding problems arising from stuffing large amounts of metadata into artifacts themselves.
• (Ashley) General concern about systems encouraging people to vendor their dependencies / move away from downloading external artifacts. Ideally, people can get artifacts remotely, and also the metadata necessary for doing OmniBOR-based analysis from the easiest possible place.
• (Frederick) nixpkgs have nice prior art, where they distribute metadata in manifests alongside their package contents.
• (Ashley) For Axo, their tooling also creates manifests which sit alongside releases.
• (Ed) GitHub previously slightly changed how they distributed release information in ways that broke lots of systems, but did not break Nix because they’d anticipated it.
• (David) This also implies that we want to think about content-addressable storage; asking for something by its identifier. Want the identifier to at all times be able to be validated against the thing that’s been retrieved.
• (Andrew) This sounds like a constraint we can include in the Artifact ID goals discussion!
• (Andrew) Only semi-related, I like the term “independently reproducible” instead of “content-addressable”.
• (Ashley) I like focusing terms around URL’s “letting the internet do what it’s good at” instead of focusing on content-addressability as a term, or on content-addressable storage (CAS)
• (David) Timeline is also important. Ultimately, we need to figure out how to bootstrap the industry into using OmniBOR. It will take progression, we want to think about how to sequence stuff to get to adoption.
• (Ashley) This gets into the go-to-market discussion. (see later in meeting agenda)