-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Justification for registries.d complexity #133
Comments
Basically because transports and their configuration, and signature verification are conceptually quite separate things, and because In more detail:
OTOH, the In practical terms,
Of course this is all just code and data structures, and we can define any number of equivalent formulations of data structures, and any number of serializations, so we could have an all-in-one integrated config file which contains signature verification policies and CA keys and hostname overrides and “use older protocol version” overrides and… perhaps something like {
"transports": {
"docker": {
"docker-registries": {
"docker.io": {
"insecure": false,
"ca-certificate": "$base64-data",
"v1-fallback": false,
"enforce-atomic-signatures": true,
},
"namespaces": {
"docker.io/library/busybox": {
"sigstore": "$url",
"sigstore-staging": "$url2",
"policyRequirements": [{
"type": "signedBy",
// …
}]
}
}
} and similarly keep CAs and what not for Also writing tools like |
add possibility to download to OCI image-layout
I'm confused why the sigstore configuration is not part of policy.json data structure. These things naturally go together. Our registries.d scheme seems to unnecessarily complicate matters.
Example:
The text was updated successfully, but these errors were encountered: