Comments (6)
Thanks for your report.
Structurally, as to “where to file this”, we’ve made a mess of things: see #1726 .
WRT the idea itself, I’m generally wary of adding any variability to signature enforcement. Admittedly there already is a precedent in looking for per-user files, and the /etc
vs. /usr
thing is a reasonably established pattern…
I ran into one such case in osbuild/osbuild#1410 where /usr/ gets mounted in from the "host" but /etc/ doesn't.
… but I don’t see this as a strong argument; there are infinite ways to create a broken system.
Actually, “the policy file got somehow lost” is exactly a good reason to “fail closed” and not fall back to some other policy. The default policy in /usr
would, I think, have to be pretty permissive (maybe restricting repositories where the OS provider ships code, to be signed by keys from that OS provider) — so falling back from a site-wide strict policy to the built-in fairly permissive one could be a problem.
from image.
maybe restricting repositories where the OS provider ships code, to be signed by keys from that OS provider
That's what we do today. We (the OS provider being Fedora/Red Hat) ships:
"transports": {
"docker": {
"registry.access.redhat.com": [
{
"type": "signedBy",
"keyType": "GPGKeys",
"keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
}
],
"registry.redhat.io": [
{
"type": "signedBy",
"keyType": "GPGKeys",
"keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
}
]
},
but we ship it in /etc/
and not /usr/
like we probably should.
I guess there's another argument to make here being that the keys referenced in that config are also in /etc/
.
from image.
Yes, but if that file is “lost” then we don’t fall back to any other policy, we just fail and force the user to provide a policy.
(Admittedly if the user sets up the policy with something valid but not what was intended, there is no way for policy consumers to tell — and I don’t have a strong argument that “forgot to provide a policy” is a more important failure case than “provided the wrong one”. But still, if we can’t do better in some cases, I don’t think that means we should give up on doing better in other cases.)
from image.
Thanks for the discussion.
from image.
I very much appreciate the irony that just filing a “also read from /usr
” issue without more justification would probably have had a smoother path; and that adding a real-world use case is what triggered my “oh, wait, this is actually good not to do” reaction.
I don’t really know what’s the best path forward here. It’s definitely valuable to have an issue filed, so that the decision can be centralized and tracked.
from image.
I think we should move the c/i config files to usr and overrride in /etc for consistency, and then users can just blow away /etc/ to get back to default configuration.
from image.
Related Issues (20)
- Copies don’t set OCI1InstanceAnnotationCompressionZSTD on Zstd:chunked HOT 1
- insecure registry with http-only HOT 3
- Copy fails with "use of closed network connection" error when using a slow proxy HOT 9
- Use OCI Go constants in the OCI transport
- [doc] fix warning when generating man pages with go-md2man HOT 3
- support for url path's in registries.conf unqualified-search-registries HOT 9
- Conversion to schema1 does not fail with Zstd layers, making it uncertain we correctly convert to OCI HOT 1
- Copies of originally-compressed images from c/storage to uncompressed destinations don’t trigger MIME type updates HOT 1
- Converting a SIF image should not require fakeroot HOT 4
- Zstd(:chunked) work tracking checklist HOT 2
- Copies with Zstd compression to schema-agnostic transports don’t trigger schema conversion HOT 2
- TemporaryDirectoryForBigFiles() can still ignore $TMPDIR HOT 2
- isManifestUnknownError fails against Harbor registries, breaking sigstore signature upload HOT 15
- Blob reuse decisions do not take into account manifest support HOT 1
- Cannot copy buildkit cache images HOT 2
- Support for structured logging (using `log/slog`) HOT 5
- proposal: Support append images into docker archive HOT 1
- Make a new release HOT 2
- Docker client code can no longer talk to the latest verson of the docker daemon 25.0.0 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from image.