allow pinning shasum of imports #206
Comments
|
related discussion on #105 The feature itself sounds fine to me.
I am skeptical that this is really achievable in any real world scenario. People want to install packages, which invokes yum, which sets mtimes, atimes, etc. I think we could add support to umoci for discarding mtimes, but even then, if you allow invoking things like yum (or any other internet-related stuff that's not done through this import: guaranteed hash mechanism. |
Does something like this seem good? |
|
If I'm honest I don't know that I love the optionality for this. If people have specified a hash and it's different, then the build should fail. If the hash is expected to change, they should change the hash. I think that's what your patch in #211 did, so I'm going to go ahead and close this. |
|
@tych0 the extra flag was not to avoid checking hashes, but to tell stacker to fail the build during stackerfile parsing if it finds an import that does not have a hash specified in the file. we want to enforce a rule that all stackerfiles in a repo must specify hashes. |
|
I see, makes sense, thanks for the clarification. |
when stacker build is called with the flag --require-hash, it will fail the build if any remote import (http/https) doesn't have hash in its yaml entry. --require-hash require all remote imports to have a hash provided in stackerfiles It still allows local or stacker imports without the hash Closes project-stacker#206
when stacker build is called with the flag --require-hash, it will fail the build if any remote import (http/https) doesn't have hash in its yaml entry. --require-hash require all remote imports to have a hash provided in stackerfiles It still allows local or stacker imports without the hash Closes project-stacker#206
when stacker build is called with the flag --require-hash, it will fail the build if any remote import (http/https) doesn't have hash in its yaml entry. --require-hash require all remote imports to have a hash provided in stackerfiles It still allows local or stacker imports without the hash Closes project-stacker#206
when stacker build is called with the flag --require-hash, it will fail the build if any remote import (http/https) doesn't have hash in its yaml entry. --require-hash require all remote imports to have a hash provided in stackerfiles It still allows local or stacker imports without the hash Closes project-stacker#206
when stacker build is called with the flag --require-hash, it will fail the build if any remote import (http/https) doesn't have hash in its yaml entry. --require-hash require all remote imports to have a hash provided in stackerfiles It still allows local or stacker imports without the hash doc: add a line for --require-hash build flag Closes project-stacker#206
when stacker build is called with the flag --require-hash, it will fail the build if any remote import (http/https) doesn't have hash in its yaml entry. --require-hash require all remote imports to have a hash provided in stackerfiles It still allows local or stacker imports without the hash doc: add a line for --require-hash build flag Closes #206
Motivation: building with a given stackerfile should always produce the same results.
if
sha256exists, then we check it and fail the build if the source doesn't match it.we can also add a flag
--remote-input-hash-required(bad name) that fails the build if any remote imports do not have thesha256key. because local imports are likely to be built from the same commit that contains the stacker file, we do not want to force a commit between binary builds and image builds.we could try to be even smarter about what counts as a local import, where stacker would only count it as local if it's in the same git tree as the stacker file
we could also incorporate #41 along with this since we need to change the syntax anyway
The text was updated successfully, but these errors were encountered: