Don't enforce container sigpolicy by default

[cgwalters]

(Draft for discussion, also this depends on #229 )

--

Don't enforce container sigpolicy by default

Closes: #218

Basically this effort has not been really successful and adds
more pain than it solves. We need to have a solution that works
for podman too.

In many scenarios, TLS is sufficient - or at least, we're far
from the only thing that if fetched from a compromised server
would result in a compromised system (e.g. privileged containers).

Signed-off-by: Colin Walters walters@verbum.org

---

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[cgwalters]

/test all

[cgwalters]

/retest

[sallyom]

I agree enforcing signature verification by default is causing more pain than good at this stage (and afaict everybody using bootc currently adds the --target-no-signature-verification). There's this rpm-ostree issue and general confusion about how to sign & verify. It's still easy enough to configure enforcing signature verification. This should be opt-in for now and enforcing by default should include clear documentation about how to correctly sign and verify (GPG, sigstore, keys, keyless).

[cgwalters]

/test all

[vrothberg]

I am not fan of opt-in security (signature verification). Why would bootc behave differently than other github.com/containers tools? If /etc/containers/policy.json is configured, I expect all tools to adhere to it. So this change worries me.

[cgwalters]

Why would bootc behave differently than other github.com/containers tools? If /etc/containers/policy.json is configured, I expect all tools to adhere to it. So this change worries me.

That's exactly it - currently (before this change) bootc does explicitly behave differently (to try to enforce a policy is enabled by default). After, it doesn't, it behaves the same way podman (and docker still AFAIK) do with podman|docker pull.

[cgwalters]

OK passing CI, and we now also drop this new default value out of the spec/status struct.

[vrothberg]

Thanks, @cgwalters ! I must have misread the code.

[jmpolom]

There's coreos/rpm-ostree#4272 and general confusion about how to sign & verify.

As someone who's tried to walk the path to adopt hands off automated container signing in a CI workflow I can say a lot of the "confusion" is really just a lack of good documentation issue. The upstream cosign docs are not great really. Improvements on that end whether directly to the upstream docs or if there were examples in bootc docs would be very helpful to golden path this for users and also show that this is possible today.

The entire way that "keyless" cosign signing works seems good but it seems few people understand how to do it (probably because it is poorly documented) and therefore it is not well tested in many applications. It would be wise to call out signing with static keys and github access tokens as major anti-patterns when using cosign in a CI environment.