manifest types / naming / cleanup

[smoser]

Background

Users will create lists of images to use on a system. They need to specify

• import urls from which to "import" the layer
• internal reference by which to know the name

The import url is a classic docker or oci url in skopeo format. This source url is needed by the builder tool (mosb) which creates an system manifest, but is no longer needed once it has been imported.

Internally the install and update code will use ServiceName and digest to locate images.

Terms

• import manifest: User-specified manifest which mosb parses to generate an system manifest and/or a full install medium (like an ISO).
• system manifest: A list of targets to activate. A running system is
  defined by a system manifest and configuration. A system manifest is signed.
• import url: oci:ocidir:name:tag, or docker://host/name:tag. A layer specified in import manifest will be fetched from this URL. This url is not retained.
• reproducible json: JSON with sorted dictionary keys no formatting.

Examples

• import manifest:

  version: 200
  mediatype: "application/vnd.mos.import.manifest.v1"
  image_type: iso
  product: de6c82c5-2e01-4c92-949b-a6545d30fc06
  targets:
    hostfs:
      url: "docker://some.url/puzzlefs/hostfs:latest"
      version: 0.0.1
      service_type: "hostfs"
      network:
        type: host
      nsgroup: ""
      mounts: []
    ran-http:
      url: "oci://tmp/build.d/oci.d:ran:latest"
      version: 2.9.2
      service_type: "container"
      network:
        type: host
  storage_type: atomfs

  • The 'version' above is the version of this system. To protect against replay attack, downgrades are not allowed. Version must be supplied by the user.
  • The mediaType should not need to be provided by the user until which point as there is a 'version 2' needed.

• system manifest: system manifest is a signed document indicating what services are running on a system. The system manifest is shown below formated, but it is stored and signed as reproducible JSON.

  {
   "mediatype": "application/vnd.mos.system.manifest.v1",
   "product": "de6c82c5-2e01-4c92-949b-a6545d30fc06",
   "targets": {
    "hostfs": {
     "mounts": [],
     "network": {"type": "host"},
     "nsgroup": "",
     "service_type": "hostfs",
     "digest": "sha256:HASH1",
     "size": 3993,
     "version": "0.0.1"
    },
    "ran-http": {
     "network": {"type": "host"},
     "service_type": "container",
     "digest": "sha256:HASH2",
     "size": 2038,
     "version": "2.9.2"
    }
   },
   "version": 200,
  }

  • An upgrade media or system that is to apply/run the system manifest above would have the following names registered in its oci database:

    • mos/images/hostfs:sha256/HASH1 - HASH1 is the hash of the oci manifest that is used for the hostfs layer. 'size' above is its size.
    • mos/images/ran-http:sha256/HASH2 - HASH2 and size are the hash and size of the oci manifest for the ran-http layer.
    • mos/system/system:sha256/HASH3 - hash3 is the hash of the system
      manifest above . It is not necessary to store the system manifest in the oci repository. more thought is needed here as to whether we want it or not. There is a need to store it somewhere and the signed document as well, but that doesn't necessarily have to be the oci registry.

changes

A list of changes from what is currently present in mos.

• No downgrades allowed - the 'version' is required to always increase
• No partial updates - The simplification means the entire system is signed by the product owner.
• targets are a dictionary by service name rather than a list. This ensures no duplicates and forces user to provide a file-wide unique name.

[hallyn]

A few points -

1. in the description you mentioned ImagePath, but you're dropping that, right, in favor of using the image/SHA:shasum name? The internal reference becomes nicely simplified.
2. you didn't mention tying the 'version' to a TPM counter, but I think that's integral to preventing replay attacks, which was the primary justification for dropping partial updates in my mind.

[smoser]

A few points -

1. in the description you mentioned ImagePath, but you're dropping that,
   right, in favor of using the image/SHA:shasum name? The internal
   reference becomes nicely simplified.

reference to imagepath removed.

2. you didn't mention tying the 'version' to a TPM counter,
   but I think that's integral to preventing replay attacks,
   which was the primary justification for dropping
   partial updates in my mind.

+1

[hallyn]

Thanks, Scott, looks good.