Does anyone know what the purpose of the ID field printed in the output of docker sytem info is? If you install Docker/Moby in a template, every AppVM based on it has the same ID. What’s the security and privacy issues for that? What is that code used for, collected by, or reported to? It doesn’t seem to be documented or mentioned anywhere in Docker’s documentation.
Hi,
I checked - after entering the “docker system info” command, the terminal returned docker configuration information.
I suspect that “ID” is the ID number of the docker installation and may have a mainly telemetry purpose.
What privacy risks does this carry? Well - I think none.
However, you can clone a fedora template a dozen times and then install docker on each template.
Next, for each docker template, you can create a separate appvm.
However, for privacy this has no meaning.
A lot of applications have such an “ID” and it has nothing to do with the topic of privacy risks; rather, the developer needs the installation ID information in case you report a problem.
The ID number may have an encrypted version about the docker version, architecture - sort of like an MD5 checksum confirming the technical information in the report you described.
daemon/daemon.go:
d := &Daemon
d.ID = trustKey.PublicKey().KeyID()
trustKey, err := loadOrCreateTrustKey(config.TrustKeyPath)
conf.TrustKeyPath = filepath.Join(daemonConfDir, defaultTrustKeyFile)
cmd/dockerd/config.go:
// defaultTrustKeyFile is the default filename for the trust key
const defaultTrustKeyFile = "key.json"
daemon/trustkey.go:
// LoadOrCreateTrustKey attempts to load the libtrust key at the given path,
// otherwise generates a new one
// TODO: this should use more of libtrust.LoadOrCreateTrustKey which may need
// a refactor or this function to be moved into libtrust
docker libtrust:
Primitives for identity and authorization
config/config.go:
// TrustKeyPath is used to generate the daemon ID and for signing schema 1 manifests
// when pushing to a registry which does not support schema 2. This field is marked as
// deprecated because schema 1 manifests are deprecated in favor of schema 2 and the
// daemon ID will use a dedicated identifier not shared with exported signatures.