paketo-buildpacks/ca-certificates

A Cloud Native Buildpack that adds custom CA certificates to a build and a created image

gcr.io/paketo-buildpacks/ca-certificates

The Paketo Buildpack for CA Certificates is a Cloud Native Buildpack that adds CA certificates to the system truststore at build and runtime.

Behavior

This buildpack always participates.

The buildpack will do the following:

• At build time:
  • If $BP_RUNTIME_CERT_BINDING_DISABLED is false, it contributes the ca-cert-helper to the application image. Default is false.
  • If one or more bindings with type of ca-certificates exists, it adds all CA certificates from the bindings to the system truststore.
  • If another buildpack provides an entry of type ca-certificates in the build plan with metadata.paths containing an array of certificate paths, it adds all CA certificates from the given paths to the system truststore.
  • If $BP_EMBED_CERTS is true, it includes the layer with all of the CA certificates into the application image.
• At runtime:
  • If one or more bindings with type of ca-certificates exists, the ca-cert-helper adds all CA certificates from the bindings to the system truststore.

The buildpack configures trusted certs at both build and runtime by:

1. Creating a directory.
2. Creating symlinks within the directory pointing to any additional requested certificate files.
3. Appending the directory to the SSL_CERT_DIR environment variable.
4. Setting SSL_CERT_FILE to the default system CA file, if it was previously unset.

To learn about the conventional meaning of SSL_CERT_DIR and SSL_CERT_FILE environment variables see the OpenSSL documentation for SSL_CTX_load_verify_locations. This buildpack may not work with tools that do not respect these environment variables.

Runtime Environment Support

Feature	Supported	Detail
read-only runtime container	No	Symlinks and/or new files are written for certificates provided via binding at runtime. A read-only container will run if no cert bindings are present at runtime.
run as custom user	Yes	The custom user must be a member of the CNB group

Bindings

The buildpack optionally accepts the following bindings:

Type: ca-certificates

Key	Value	Description
<certificate-name>	<certificate>	CA certificate to trust. Should contain exactly one PEM encoded certificate.

Configuration

Environment Variable	Description
$BP_EMBED_CERTS	Embed all CA certificate bindings present at buildtime into the application image. This removes the need to have any embedded CA certificate bindings present at runtime. Default is false.
$BP_RUNTIME_CERT_BINDING_DISABLED	Disable the helper that adds certificates at runtime. This means any provided CA certificates will not be included. Default to false, which means certificates are loaded by default.
$BP_ENABLE_RUNTIME_CERT_BINDING	Deprecated in favour of $BP_RUNTIME_CERT_BINDING_DISABLED. Enable/disable the ability to set certificates at runtime via the certificate helper layer. Default is true.

License

This buildpack is released under version 2.0 of the Apache License.

ca-certificates's Issues

ERROR: failed to build: downloading buildpack

Expected Behavior

As per docs I'm using command the command from https://paketo.io/docs/howto/java/#use-an-alternative-jvm

pack build foo --buildpack paketo-buildpacks/ca-certificates --buildpack paketo-buildpacks/azul-zulu --buildpack paketo-buildpacks/java

But I hit error

ERROR: failed to build: processing buildpacks order: unable to resolve version: multiple versions of paketo-buildpacks/ca-certificates - must specify an explicit version

Verbose logs

Builder paketobuildpacks/builder-jammy-base is now the default builder
Builder paketobuildpacks/builder-jammy-base is untrusted
As a result, the phases of the lifecycle which require root access will be run in separate trusted ephemeral containers.
For more information, see https://medium.com/buildpacks/faster-more-secure-builds-with-pack-0-11-0-4d0c633ca619
Pulling image index.docker.io/paketobuildpacks/builder-jammy-base:latest
latest: Pulling from paketobuildpacks/builder-jammy-base
Digest: sha256:011eb715c30aa716642b8659f1ca9647de6f1c8fbd7be6c97e3e52b21a3382bb
Status: Image is up to date for paketobuildpacks/builder-jammy-base:latest     
Selected run image index.docker.io/paketobuildpacks/run-jammy-base:latest
Pulling image index.docker.io/paketobuildpacks/run-jammy-base:latest     
latest: Pulling from paketobuildpacks/run-jammy-base
Digest: sha256:be469f0808bd338280f7e6f75a37ae7804e002a54ee100f104686dc148bb43a0
Status: Image is up to date for paketobuildpacks/run-jammy-base:latest
Downloading buildpack from registry: paketo-buildpacks/azul-zulu   
Refreshing registry cache for github.com//buildpacks/registry-index
Validating registry cache for github.com//buildpacks/registry-index
Creating registry cache for github.com//buildpacks/registry-index
Pulling image docker.io/paketobuildpacks/azul-zulu@sha256:79419af00c95f85c088e68808f61b2486c39a7e12a0033995970c97e95408069
docker.io/paketobuildpacks/azul-zulu@sha256:79419af00c95f85c088e68808f61b2486c39a7e12a0033995970c97e95408069: Pulling from paketobuildpacks/azul-zulu
Digest: sha256:79419af00c95f85c088e68808f61b2486c39a7e12a0033995970c97e95408069
Status: Image is up to date for paketobuildpacks/azul-zulu@sha256:79419af00c95f85c088e68808f61b2486c39a7e12a0033995970c97e95408069
Adding buildpack paketo-buildpacks/azul-zulu version 10.1.5 to builder
Setting custom order
Creating builder with the following buildpacks:
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
Adding buildpack paketo-buildpacks/[email protected] (diffID=sha256:13c862b30ccfa2559c47d0feadf32f7470b5f1c91953f8ae3bb39c0bb61a3654)
ERROR: failed to build: processing buildpacks order: unable to resolve version: multiple versions of paketo-buildpacks/ca-certificates - must specify an explicit version

Enable certs to be loaded from a remote resource

At present, a binding must exist or a buildplan entry must exist to specify a cert that should be added. It would be helpful if certificates could be loaded remotely. Perhaps through a URL to either a certificate file or a zip of certificate files.

Unresolved questions:

• are there security implications to consider loading them remotely?
• do we need to take the expected sha256 hash of the cert, and validate before loading the remote cert?
• do we use a binding to specify the URL or env variable?
• do we need to support auth? (if that's the case, then we'd need to use a binding)

bom table isn't supported in this buildpack api version

What happened?

Was running through this demo of kpack leveraging paketo-buildpacks here
and what went wrong. -->
I can see their demo worked with version 3.0.2 of paketo-buildpacks

However, my attempt to run this same job is failing with version 3.1.0

Successfully cloned "https://github.com/ciberkleid/go-sample-app.git" @ "edd446bc43d2042dfc0045766340ce81a0a4f33f" in path "/workspace"
===> ANALYZE
Previous image with name "harbor.mydomain.com/demo/hello-world" not found
===> DETECT
5 of 9 buildpacks participating
paketo-buildpacks/ca-certificates 3.1.0
paketo-buildpacks/go-dist         1.0.1
paketo-buildpacks/git             0.4.1
paketo-buildpacks/go-mod-vendor   0.5.0
paketo-buildpacks/go-build        1.0.2
===> RESTORE
===> BUILD

Paketo CA Certificates Buildpack 3.1.0
  https://github.com/paketo-buildpacks/ca-certificates
  Launch Helper: Contributing to layer
    Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper
ERROR: failed to build: bom table isn't supported in this buildpack api version. The BOM should be written to <layer>.sbom.<ext>, launch.sbom.<ext>, or build.sbom.<ext>

• What were you attempting to do?
  Running a build for a simple hello-world go image, as per here: https://github.com/ciberkleid/go-sample-app
• What did you expect to happen?
  The build to complete
• What was the actual behavior? Please provide log output, if possible.
  It errored out, as per above

Build Configuration

Running on tanzu-community-edition cluster on AWS

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.
  kpack, part of TCE (tanzu-community-edition) .. version 0.5.0
• What buildpacks are you using? Please include versions.
  using kp clusterstore save default -b gcr.io/paketo-buildpacks/java:6.13.0 -b gcr.io/paketo-buildpacks/go:1.0.0
• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?
  NA
• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?
  NA

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Allow to avoid certificates splitting into multiple files

Describe the Enhancement

Currently, builpdack splits the certificate into multiple files when a .pem file contains multiple entries. I would like to introduce an option that will allow us to preserve the original .pem format and ignore splitting behavior.

Possible Solution

The proposed solution is to introduce a new environment variable BP_EMBED_CERTS_SKIP_SPLITTING which will ignore certificate splitting when supplied in the build parameters. I noticed that multi-certificates file is not supported by helper (#100) so we can always ignore BP_EMBED_CERTS_SKIP_SPLITTING value unless BP_RUNTIME_CERT_BINDING_DISABLED is set a true value.

Motivation

In my scenario, I'm using ca-certificates buildpack to only add certificates to a layer and make them available during runtime (BP_EMBED_CERTS=true and BP_RUNTIME_CERT_BINDING_DISABLED=true) which is later specified in sslrootcert PostgreSQL connection parameters. Current splitting behavior makes it difficult to execute certificate rotation as sslrootcert accepts only a single file value so preserving multiple certificates will make it easier to perform certificate rotation.

---

Please let me know if the proposed solution is fine with you. I'm going to work on PR If this is something you are ready to accept.

labels on this repo?

What happened?

• What were you attempting to do?

Attempting to find non-language family buildpacks on github by searching repos with the cnb and all-applications.

• What did you expect to happen?

I expected this repo to show up.

Am I in correct or should this repo have the cnb and all-applications labels?

Go should be upgraded; currently using 1.20 which is EOL and has security issues

Expected Behavior

This project currently uses go 1.20 which is EOL and unsupported, see https://go.dev/doc/devel/release It also has security vulnerabilities which scanners such as Trivy report.

Therefore, I believe that this project should upgrade go to 1.21 or better yet 1.22.

Current Behavior

Trivy reports some vulnerabilities, all of which can be addressed by using the latest version of go.

$ docker run -it aquasec/trivy:0.51.1 image gcr.io/paketo-buildpacks/ca-certificates
2024-05-15T16:59:08Z	INFO	Need to update DB
2024-05-15T16:59:08Z	INFO	Downloading DB...	repository="ghcr.io/aquasecurity/trivy-db:2"
46.24 MiB / 46.24 MiB [-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------] 100.00% 10.23 MiB p/s 4.7s
2024-05-15T16:59:13Z	INFO	Vulnerability scanning is enabled
2024-05-15T16:59:13Z	INFO	Secret scanning is enabled
2024-05-15T16:59:13Z	INFO	If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2024-05-15T16:59:13Z	INFO	Please see also https://aquasecurity.github.io/trivy/v0.51/docs/scanner/secret/#recommendation for faster secret detection
2024-05-15T16:59:14Z	INFO	Number of language-specific files	num=2
2024-05-15T16:59:14Z	INFO	[gobinary] Detecting vulnerabilities...

cnb/buildpacks/paketo-buildpacks_ca-certificates/3.7.0/bin/helper (gobinary)

Total: 6 (UNKNOWN: 0, LOW: 0, MEDIUM: 5, HIGH: 1, CRITICAL: 0)

┌─────────┬────────────────┬──────────┬────────┬───────────────────┬────────────────┬─────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability  │ Severity │ Status │ Installed Version │ Fixed Version  │                            Title                            │
├─────────┼────────────────┼──────────┼────────┼───────────────────┼────────────────┼─────────────────────────────────────────────────────────────┤
│ stdlib  │ CVE-2023-45288 │ HIGH     │ fixed  │ 1.20.14           │ 1.21.9, 1.22.2 │ golang: net/http, x/net/http2: unlimited number of          │
│         │                │          │        │                   │                │ CONTINUATION frames causes DoS                              │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2023-45288                  │
│         ├────────────────┼──────────┤        │                   ├────────────────┼─────────────────────────────────────────────────────────────┤
│         │ CVE-2023-45289 │ MEDIUM   │        │                   │ 1.21.8, 1.22.1 │ golang: net/http/cookiejar: incorrect forwarding of         │
│         │                │          │        │                   │                │ sensitive headers and cookies on HTTP redirect...           │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2023-45289                  │
│         ├────────────────┤          │        │                   │                ├─────────────────────────────────────────────────────────────┤
│         │ CVE-2023-45290 │          │        │                   │                │ golang: net/http: memory exhaustion in                      │
│         │                │          │        │                   │                │ Request.ParseMultipartForm                                  │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2023-45290                  │
│         ├────────────────┤          │        │                   │                ├─────────────────────────────────────────────────────────────┤
│         │ CVE-2024-24783 │          │        │                   │                │ golang: crypto/x509: Verify panics on certificates with an  │
│         │                │          │        │                   │                │ unknown public key algorithm...                             │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2024-24783                  │
│         ├────────────────┤          │        │                   │                ├─────────────────────────────────────────────────────────────┤
│         │ CVE-2024-24784 │          │        │                   │                │ golang: net/mail: comments in display names are incorrectly │
│         │                │          │        │                   │                │ handled                                                     │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2024-24784                  │
│         ├────────────────┤          │        │                   │                ├─────────────────────────────────────────────────────────────┤
│         │ CVE-2024-24785 │          │        │                   │                │ golang: html/template: errors returned from MarshalJSON     │
│         │                │          │        │                   │                │ methods may break template escaping                         │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2024-24785                  │
└─────────┴────────────────┴──────────┴────────┴───────────────────┴────────────────┴─────────────────────────────────────────────────────────────┘

cnb/buildpacks/paketo-buildpacks_ca-certificates/3.7.0/bin/main (gobinary)

Total: 6 (UNKNOWN: 0, LOW: 0, MEDIUM: 5, HIGH: 1, CRITICAL: 0)

┌─────────┬────────────────┬──────────┬────────┬───────────────────┬────────────────┬─────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability  │ Severity │ Status │ Installed Version │ Fixed Version  │                            Title                            │
├─────────┼────────────────┼──────────┼────────┼───────────────────┼────────────────┼─────────────────────────────────────────────────────────────┤
│ stdlib  │ CVE-2023-45288 │ HIGH     │ fixed  │ 1.20.14           │ 1.21.9, 1.22.2 │ golang: net/http, x/net/http2: unlimited number of          │
│         │                │          │        │                   │                │ CONTINUATION frames causes DoS                              │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2023-45288                  │
│         ├────────────────┼──────────┤        │                   ├────────────────┼─────────────────────────────────────────────────────────────┤
│         │ CVE-2023-45289 │ MEDIUM   │        │                   │ 1.21.8, 1.22.1 │ golang: net/http/cookiejar: incorrect forwarding of         │
│         │                │          │        │                   │                │ sensitive headers and cookies on HTTP redirect...           │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2023-45289                  │
│         ├────────────────┤          │        │                   │                ├─────────────────────────────────────────────────────────────┤
│         │ CVE-2023-45290 │          │        │                   │                │ golang: net/http: memory exhaustion in                      │
│         │                │          │        │                   │                │ Request.ParseMultipartForm                                  │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2023-45290                  │
│         ├────────────────┤          │        │                   │                ├─────────────────────────────────────────────────────────────┤
│         │ CVE-2024-24783 │          │        │                   │                │ golang: crypto/x509: Verify panics on certificates with an  │
│         │                │          │        │                   │                │ unknown public key algorithm...                             │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2024-24783                  │
│         ├────────────────┤          │        │                   │                ├─────────────────────────────────────────────────────────────┤
│         │ CVE-2024-24784 │          │        │                   │                │ golang: net/mail: comments in display names are incorrectly │
│         │                │          │        │                   │                │ handled                                                     │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2024-24784                  │
│         ├────────────────┤          │        │                   │                ├─────────────────────────────────────────────────────────────┤
│         │ CVE-2024-24785 │          │        │                   │                │ golang: html/template: errors returned from MarshalJSON     │
│         │                │          │        │                   │                │ methods may break template escaping                         │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2024-24785                  │
└─────────┴────────────────┴──────────┴────────┴───────────────────┴────────────────┴─────────────────────────────────────────────────────────────┘

Possible Solution

I suggest that the version of go be updated to the latest version (currently 1.22.3).

Steps to Reproduce

1. docker run -it aquasec/trivy:0.51.1 image gcr.io/paketo-buildpacks/ca-certificates

Motivations

I don't think these vulnerabilities are exploitable, but they're still present which isn't great. And their presence causes a lot of trouble for those who use automated security scanning systems as such users must suppress these findings.

`ca-certificates` does not `require` buildpacks who provide `ca-certificates` paths

Expected Behavior

Based on the documentation in the README, specifically this section:

If another buildpack provides an entry of type ca-certificates in the build plan with metadata.paths containing an array of certificate paths, it adds all CA certificates from the given paths to the system truststore.

I would expect a buildpack who provides a build plan during the detection phase, to become required by this buildpack. (note that the docs are wrongly stating that it requires a type when the code expects name)
https://github.com/paketo-buildpacks/ca-certificates/blob/main/cacerts/build.go#L58

Build Plan:

[[provides]]
name = "ca-certificates"
[provides.metadata]
paths = ["my-cert.pem"]

Unfortunately this doesn't seem to be the case and you get an error from the Pack CLI during detect that no buildpacks require ca-certificates.

Current Behavior

You get an error that ca-certificates is not required by any buildpacks

Possible Solution

I noticed that detection seems to only add a require if a platform binding is provided, which would not be the case here unless I'm misunderstanding the docs: https://github.com/paketo-buildpacks/ca-certificates/blob/main/cacerts/detect.go#L55

Steps to Reproduce

1. Create a simple buildpack with a detect phase of

#!/bin/bash

cat >${CNB_BUILD_PLAN_PATH} <<EOF
[[provides]]
name = "ca-certificates"
[provides.metadata]
paths = ["my-cert.pem"]
EOF

2. Run pack build example --path ./sample-app --buildpack ./example-buildpack --buildpack paketobuildpacks/ca-certificates
3. Note the error during detect phase

Motivations

I am creating a custom meta buildpack and would like to include custom CA's during the build phase that are bundled within the buildpack itself rather than at runtime.

I'm fairly new to creating buildpacks so it's possible I misunderstood something about the docs.

Allow ca-certificates to add truststore.jks or keystore.jks to the expected Java trust store locations

Describe the Enhancement

CA certificates generally exist in the format of PEM encoded certificates, there is also sometimes a strong requirement for Java (or other JVM originating languages) to have their certificates stored in another format and in another location.

Possible Solution

In containers you can achieve this by importing the associated JKS files into the existing trustore -- if it exists these trust stores are stored in well known locations generally (which should be almost a guarantee in the case of buildpacks.

Motivation

Inside of a Java application sometimes you are making HTTP calls that require TLS, and these certificates that exist in the ca-certificates are not looked at, instead it looks at the files in the Java trust store.

Buildpack is not adding custom ca-certificates into /etc/ssl/certs/ca-certificates.crt

Buildpack is not adding custom ca-certificates into /etc/ssl/certs/ca-certificates.crt

Expected Behavior

Custom ca-certificates should be added to the system truststore in /etc/ssl/certs/ca-certificates.crt

Current Behavior

SSL_CERT_DIR is set to /layers/paketo-buildpacks_ca-certificates/ca-certificates/ca-certificates (custom certs location)
SSL_CERT_FILE is set to /etc/ssl/certs/ca-certificates.crt (default certs)

Steps to Reproduce

Note: I'm running in an air-gapped network and thus have no use for all the default certs provided

1. Create a python app and call a URL that is signed internally using httpx library.
2. App failed to run because SSL_CERT_FILE does not contain custom certs.
3. The docs of httpx library from Python mentions that it supports SSL_CERT_FILE and SSL_CERT_DIR. I suspects that SSL_CERT_FILE take precedence because once I delete the SSL_CERT_FILE, the call become successful)

Support a binding with multiple certs concatenated together

What happened?

Providing a binding with multiple certs concatted together errors and exits preventing the application from starting (and using the multiple certs)

failed to generate CA certficate symlinks
failed to decode certificate from file at path "/bindings/ca-certificates/certificates"
found multiple PEM blocks, expected exactly one
ERROR: failed to launch: exec.d: failed to execute exec.d file at path '/layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper': exit status 1

• What did you expect to happen?
  It would be ideal to support multiple certs concatenated in a single binding. This is expected for certs provided in multple tanzu products that make us of this buildpack: https://github.com/vmware-tanzu/community-edition and https://docs.vmware.com/en/VMware-Tanzu-Application-Platform/index.html.

Implement RFC0044: Disable SBOM

Describe the Enhancement

This buildpack should opt-in to allowing users to disable SBOM generation. In doing so, it should conform to RFC044.

When BP_DISABLE_SBOM is set to true, buildpacks that allow SBOM to be omitted from their output should refrain from generating or attaching an SBOM in their outputs. This would apply to both new (Syft, CycloneDX, and SPDX formats) and old (label) SBOM outputs.

Additionally, when this variable is set to true a buildpack should set an image label of io.paketo.sbom.disabled to true. This label interface would allow downstream consumers of the image to understand that SBOM generation had been explicitly disabled.

Possible Solution

Motivation

SBOM generation can take substantial time. There may also be other reasons for wanting this functionality to be disabled.

Enable CA certificates to be baked into an image

What happened?

Right now you need to pass ca-certificates bindings at build and at runtime. The buildpack will add a helper which loads the certs in the runtime environment. You need to have the certs present at runtime though so the helper can load them.

It's annoying to have to specify them twice.

We should support a more flexible configuration:

1. No build ca certs required to enable the helper. If you just need certs at runtime, then just set them at runtime. (this already works this way, it's enabled by default but you can opt-out and disable it).
2. Embed ca certs into the image. CA certs are public certs, they are not secrets and we could include them in the image. It's just less flexible because you can't change the certs included at runtime. There is still utility in this though and we should allow it.

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

certificate not work in build phase

From the README, I think ca certificate both work for build and runtime phase right?
I verify the ca-certificate can work in run phase, but it didn't work in build phase, so I'm not sure if I didn't use it successfully.

I config my domain name with self-signed cert, and monitor in my local env,

• When I didn't add cert into system trust store, then the response like this:

> wget https://fenzho-0805-test.azdmss-test.net
--2022-08-09 22:48:26--  https://fenzho-0805-test.azdmss-test.net/
Resolving fenzho-0805-test.azdmss-test.net (fenzho-0805-test.azdmss-test.net)... 52.152.205.223
Connecting to fenzho-0805-test.azdmss-test.net (fenzho-0805-test.azdmss-test.net)|52.152.205.223|:443... connected.
ERROR: cannot verify fenzho-0805-test.azdmss-test.net's certificate, issued by ‘CN=fenzho-0805-test.azdmss-test.net’:
  Unable to locally verify the issuer's authority.
To connect to fenzho-0805-test.azdmss-test.net insecurely, use `--no-check-certificate'.

• When I add cert into system trust store, it can be accessed and then the response like this:

> wget -O- https://fenzho-0805-test.azdmss-test.net
--2022-08-09 16:02:07--  https://fenzho-0805-test.azdmss-test.net/
Resolving fenzho-0805-test.azdmss-test.net (fenzho-0805-test.azdmss-test.net)... 52.152.205.223
Connecting to fenzho-0805-test.azdmss-test.net (fenzho-0805-test.azdmss-test.net)|52.152.205.223|:443... connected.
HTTP request sent, awaiting response... 404 Not Found  // 404 is ok because my path "/" will return 404
2022-08-09 16:02:08 ERROR 404: Not Found.

So I want to simulate it in the build phase, I saw the cert is already added into the system trust store, but I still can access https://xxxxx

> pack build test-ruby-app --path ./ruby-sample-app --buildpack paketo-buildpacks/ca-certificates --buildpack ./ruby-buildpack --volume "/home/fenzho/test/ca-certificate-test/buildpacks/ruby-buildpack/binding/fenzho-ca/:/platform/bindings/ca-certificates"
bionic: Pulling from cnbs/sample-builder
Digest: sha256:56374ce0ff75bac39349b4661019ac8810a845b13475a3f375017773b7bc36aa
Status: Image is up to date for cnbs/sample-builder:bionic
bionic: Pulling from cnbs/sample-stack-run
Digest: sha256:30b94903108f49003cfca4515747d7fd6c62d3ba8b9c51d997ef905863d69c46
Status: Image is up to date for cnbs/sample-stack-run:bionic
gcr.io/paketo-buildpacks/ca-certificates@sha256:6a50321d30d042e24a57d4e88e6e301d5a50d9c52eee56ccacb7bb874ce907f7: Pulling from paketo-buildpacks/ca-certificates
Digest: sha256:6a50321d30d042e24a57d4e88e6e301d5a50d9c52eee56ccacb7bb874ce907f7
Status: Image is up to date for gcr.io/paketo-buildpacks/ca-certificates@sha256:6a50321d30d042e24a57d4e88e6e301d5a50d9c52eee56ccacb7bb874ce907f7
===> DETECTING
paketo-buildpacks/ca-certificates 3.2.5
examples/cacert-test              0.0.1
===> RESTORING
===> BUILDING

Paketo CA Certificates Buildpack 3.2.5
  https://github.com/paketo-buildpacks/ca-certificates
  Launch Helper: Contributing to layer
    Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper
  CA Certificates: Contributing to layer
    Added 1 additional CA certificate(s) to system truststore
    Writing env.build/SSL_CERT_DIR.append
    Writing env.build/SSL_CERT_DIR.delim
    Writing env.build/SSL_CERT_FILE.default
=====start=====
--2022-08-09 14:46:24--  https://fenzho-0805-test.azdmss-test.net/
Resolving fenzho-0805-test.azdmss-test.net (fenzho-0805-test.azdmss-test.net)... 52.152.205.223
Connecting to fenzho-0805-test.azdmss-test.net (fenzho-0805-test.azdmss-test.net)|52.152.205.223|:443... connected.
ERROR: cannot verify fenzho-0805-test.azdmss-test.net's certificate, issued by 'CN=fenzho-0805-test.azdmss-test.net':
  Unable to locally verify the issuer's authority.
To connect to fenzho-0805-test.azdmss-test.net insecurely, use `--no-check-certificate'.
ERROR: failed to build: exit status 5
ERROR: failed to build: executing lifecycle: failed with status code: 51

From the logs above, it seems the cert added into the system trust store doesn't work?

Expected Behavior

the logs should shows

Paketo CA Certificates Buildpack 3.2.5
  https://github.com/paketo-buildpacks/ca-certificates
  Launch Helper: Contributing to layer
    Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper
  CA Certificates: Contributing to layer
    Added 1 additional CA certificate(s) to system truststore
    Writing env.build/SSL_CERT_DIR.append
    Writing env.build/SSL_CERT_DIR.delim
    Writing env.build/SSL_CERT_FILE.default
=====start=====
--2022-08-09 16:02:07--  https://fenzho-0805-test.azdmss-test.net/
Resolving fenzho-0805-test.azdmss-test.net (fenzho-0805-test.azdmss-test.net)... 52.152.205.223
Connecting to fenzho-0805-test.azdmss-test.net (fenzho-0805-test.azdmss-test.net)|52.152.205.223|:443... connected.
HTTP request sent, awaiting response... 404 Not Found  // 404 is ok because my path "/" will return 404
2022-08-09 16:02:08 ERROR 404: Not Found.
......

Current Behavior

the logs shows:

......
=====start=====
--2022-08-09 14:46:24--  https://fenzho-0805-test.azdmss-test.net/
Resolving fenzho-0805-test.azdmss-test.net (fenzho-0805-test.azdmss-test.net)... 52.152.205.223
Connecting to fenzho-0805-test.azdmss-test.net (fenzho-0805-test.azdmss-test.net)|52.152.205.223|:443... connected.
ERROR: cannot verify fenzho-0805-test.azdmss-test.net's certificate, issued by 'CN=fenzho-0805-test.azdmss-test.net':
  Unable to locally verify the issuer's authority.
To connect to fenzho-0805-test.azdmss-test.net insecurely, use `--no-check-certificate'.

......

Possible Solution

Steps to Reproduce

1. prepare cert
   type: ca-certificates
   provider: xxx
   mysecret: xxxx

2. write a buildpack to curl a host with self-signed cert, like this:
   

Motivations

I want to double check if it works in build phase or how to check it works in build phase easily

Allow users to opt out of the CA Certificates buildpack

What happened?

• What were you attempting to do?

pack build a Node.js application with no CA Certificates (the Node.js language family buildpack has CA Certificates buildpack as an optional order group in the buildpack.toml)

• What did you expect to happen?

I initially would've expected build output that only contained logs from node-engine, yarn-install', yarn, and yarn-start`.

• What was the actual behavior? Please provide log output, if possible.

The build output contained logs from the CA Certificates buildpack, which was misleading since I didn't want to use CA certificates with my app.

Users should have an option to opt out of using the CA certificate buildpack all together. The default behaviour is to always detect, but users should have an option to turn this behaviour off if they know they won't need it.

I'm in agreement that the current behaviour where the buildpack always detects is something we should keep, because as @ekcasey has said, it allows certificates to be dynamically added at runtime without having to specify anything at build time.

The issue lies in the fact that some users may not want CA certificates at all, and have no simple way to turn this behaviour off. This clutters logs with CA Certificate buildpack output, and also unnecessarily creates a layer when a user knows they won't want CA certificates.

I propose some new environment variable (such as BP_CA_CERTS_LAUNCH) that can be set to false at build-time if a user does not want the buildpack to detect. The default will be true, and the buildpack will proceed normally in this case.

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Loading CA certificates fails since #103 was merged

What happened?

When #103 was merged this created a need to write temporary files. The bindings with multiple CA certificates need to be split into individual files. This breaks execution in environments where there is a read-only filesystem at runtime.

While we cannot fix this issue if a binding has multiple CA certificates, we should still be able to support read-only filesystems so long as bindings on have a single CA certificate.

Presently we write the temporary files by creating a temporary directory and then splitting the files into the temporary directory following a particular naming schema. What I think we can do instead is to use os.CreateTemp and create a new temp file for each CA file that we need to split out. We just need to delay creating any temp files until we know if we need to split the binding into multiple CA certificates. That way we're not creating temp files for the case where there is only one CA certificate in the binding.