rather than using the default suggested `v1` names for some imports, we
use more descriptive names
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
when on temp target, the object being verified will still be written and
so a second invocation of `make tools` will succeed and install an
unverified version
For more information see attached issue
Fixes#4678
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
Includes targets for:
- all "server" binaries, for all arches
- all containers for all server binaries for all arches
- all client binaries (kubectl plugin / cmctl) for all arches
- the cert-manager helm chart + signature
- the cert-manager static manifests + CRDs
- tools which bazel would download, with checksum verification
- (commented out) a signed SHA256SUM file for client binaries
Upgrades from the bazel flow include that:
- we use OS-specific base images rather than just using amd64 everywhere
- we easily add support for signing artifacts at build time
- we add ".exe" to the end of windows executables
- we add a zip file for windows executables, for easier consumption
- we concatenate YAML files more robustly
- staging a full release should be much faster
- hopefully, it's easier to change things!
- licenses are trimmed down to reduce bloat in images (the license
bundle was 1.4MB in size alone)
Changes from the bazel flow include:
- containers no longer have a symlink to the binary at an unusual
path, but instead just have the binary at a more predictable path
(e.g. /app/cmd/webhook/webhook instead of
/app/cmd/webhook/webhook.runfiles/com_github_jetstack_cert_manager/cmd/webhook/webhook_/webhook)
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
hash.sh returns just the sha256sum of its input file
checkhash.sh uses ha.sh to get the sha256sum of its first argument and
then validates that the checksum matches the value provided in its
second argument
hash.sh isn't currently fully portable since sha256sum isn't present
by default on macOS, but it provides a single point around which we can
do hashing to validate checksums
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
this works around a limit on file descriptors which we encounter in kind
in CI. newer kind images impose a limit of 1024 file descriptors which
isn't trivial to change; haproxy seems to try to request just over 2*n
file descriptors where n is the max number of connections; as such, if
we limit max-connections to 250 we should be comfortably within the
limit
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
also adds a variable for the network name, potentially making it easier
to change in the future if kind improves its support for this kind of
thing
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
the script will need to be manually updated if we want to add a new
k8s version, but it should be trivial to do that
the actual kind image SHAsums aren't updated, so that the addition of
the script can be separate from the act of updating the images
also adds a make target for creating a kind cluster with CI deps
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
this repo isn't the source of truth for release notes, and if these are
drafts anyway they don't need to be kept around
(and they will still be available in git history anyway!)
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
reg isn't trivially installable with `go install`, and `go get` now has a
deprecation warning. `crane` solves this issue!
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
github actions is pretty flawed in several ways, and it's missing
features which would make it usable for us.
we want to trigger our krew automation when a new stable release of our
latest supported cert-manager release is published. github has all this
information, but it's not easy to _use_ that information when triggering
a github action.
we also only want to trigger the action on the main repo and not on
forks.
if we end up having to write custom code to do this, we might as well
add that code into cmrel and not have to deal with the flaws in gh
actions.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
roots are handled differently because they're their own CAs
also adds test cases for each of:
- a lone leaf
- a lone intermediate
- a lone root
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
see also https://github.com/jetstack/cert-manager/issues/4142
EncodeX509Chain checked for self-signed certs by comparing the subject
and issuer of the cert in question, which is invalid since it's
perfectly fine for those to match.
the correct behavior is to use cert.CheckSignatureFrom(cert). this bug
was exposed in 1.4 when ParseSingleCertificateChain started using
EncodeX509Chain in the critical path of several issuers; when end-users
had leaf certificates with subjects matching their issuer's subject, the
bug was triggered.
includes newly written tests for EncodeX509Chain and a test for
ParseSingleCertificateChain
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
this is disabled for all issuers except selfsigned and CA. the intention
is to pave the way for adding maxPathLen support later.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
this function doesn't appear to be used anywhere, which makes it a
little confusing when trying to work out how the checks are done in the
e2e tests.
given that we encourage people not to import cert-manager as a module
and that anyone who does is likely not to use functions in the test
directory, it seems safe enough to remove this rather than deprecating
it.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
there seems to be justification for setting GOSUMDB to a universal value
here, but setting GOPROXY doesn't seem to provide value here
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
having .PHONY next to the target which it's marking
helps with identifying which targets have been marked and makes it
easier to spot a missing .PHONY
also tweaks the find command to avoid piping, and cleans up a duplicated
ctl target
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
pkg/ctl/scheme.go:17:1: package comment should be of the form "Package ctl ..."
pkg/issuer/acme/dns/acmedns/acmedns.go:43:2: var accountJson should be accountJSON
pkg/issuer/acme/dns/acmedns/acmedns.go:50:43: func parameter accountJson should be accountJSON
pkg/controller/certificates/trigger/policies/policies.go:57:1: comment on exported type Chain should be of the form "Chain ..." (with optional leading article)
pkg/controller/ingress-shim/sync.go:36:2: package "github.com/jetstack/cert-manager/pkg/logs" is being imported more than once (ST1019)
pkg/controller/ingress-shim/sync.go:37:2: other import of "github.com/jetstack/cert-manager/pkg/logs"
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
pkg/internal/apis/certmanager/validation/certificate_for_issuer_test.go:34:2 deadcode `defaultTestCrtName` is unused
pkg/issuer/acme/dns/rfc2136/provider_test.go:42:23 errcheck Error return value of `server.Shutdown` is not checked
pkg/issuer/acme/dns/rfc2136/provider_test.go:77:23 errcheck Error return value of `server.Shutdown` is not checked
pkg/issuer/vault/setup.go:37:2 deadcode `messageVaultHealthCheckFailed` is unused
pkg/issuer/venafi/client/request.go:143:5 gosimple S1023: redundant break statement
pkg/logs/logs.go:68:8 errcheck Error return value of `fs.Set` is not checked
the following fixes introduce a panic when the returned error is
non-nil, which could be a breaking change but was deemed to be worth it
pkg/webhook/server/server.go:58:30 errcheck Error return value is not checked
pkg/webhook/server/server.go:59:25 errcheck Error return value is not checked
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
fixes the following issues:
pkg/controller/acmeorders/util.go:84:6 deadcode `hashChallenge` is unused
pkg/controller/certificaterequests/approver/approver.go:72:14 staticcheck SA4021: x = append(y) is equivalent to x = y
pkg/controller/certificaterequests/vault/vault_test.go:535:21 errcheck Error return value of `controller.Register` is not checked
pkg/controller/certificates/trigger/policies/policies.go:121:26 gosimple S1039: unnecessary use of fmt.Sprintf
pkg/controller/clusterissuers/sync_test.go:55:12 errcheck Error return value of `c.Register` is not checked
pkg/controller/ingress-shim/sync.go:301:2 gosimple S1005: unnecessary assignment to the blank identifier
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
1.17 is no longer supported by upstream, and 1.21 didn't work with just
a trivial version change, suggesting more work may need to be done
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
also adds/improves doc comments on related functions, and adds tests of
comparisons RSA keys and ECDSA keys. these tests failed as expected
before the function was changed, e.g.:
```text
Executing tests from //pkg/util/pki:go_default_test
---------------------------------------------------
--- FAIL: TestPublicKeysEqualECDSA (0.00s)
generate_test.go:492: got an incorrect match from different curves:
pub1 type: "P-256"
pub2 type: "P-521"
--- FAIL: TestPublicKeysEqualRSA (0.00s)
generate_test.go:560: got an incorrect match from different RSA keys:
pub1: &rsa.PublicKey{N:2293...<snip>...8869, E:65537}
pub2: &rsa.PublicKey{N:2293...<snip>...8869, E:3}
```
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
Ideally, SECURITY.md will be the central source of truth to answer the
question "How do I report a security vulnerability in a cert-manager
project?"
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
as raised in#3634 - RFC 5280 states that the issuer field cannot be
empty, but this could easily happen with selfsigned certs which had
an empty subject (as the issuer matches the subject when the cert is
self signed)
this commit detects when a cert would be issued selfsigned with an
empty subject DN and emits a warning event, allowing cluster operators
to detect the warning and potentially either re-issue to generate a
compliant cert, or else accept the risk.
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
it's conceivable that in the future we could have Ed25519 certs,
which would also have a key size of 256 but would be a new named entry
here
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
If gcloud hasn't been installed, or if it has but the default application credential file
at .config/gcloud/application_default_credentials.json hasn't been configured, this test
would segfault since the assertion at the start fails but doesn't stop the test
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
Ashley Davis