pkg.pkl-lang.org SSL certificate expired #268

Closed
opened 2025-12-30 01:23:00 +01:00 by adam · 11 comments
Owner

Originally created by @fretb on GitHub (Jan 28, 2025).

Hi everyone,

Not sure if this is the right place to inform you, but it seems the SSL certificate at pkg.pkl-lang.org has recently expired:

❯ openssl s_client -connect pkg.pkl-lang.org:443 </dev/null | openssl x509 -noout -subject -dates
Connecting to 17.145.8.65
depth=2 C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
verify return:1
depth=1 CN=Apple Public Server RSA CA 12 - G1, O=Apple Inc., ST=California, C=US
verify return:1
depth=0 C=US, ST=California, O=Apple Inc., CN=pkg.pkl-lang.org
verify error:num=10:certificate has expired
notAfter=Jan 28 16:28:48 2025 GMT
verify return:1
depth=0 C=US, ST=California, O=Apple Inc., CN=pkg.pkl-lang.org
notAfter=Jan 28 16:28:48 2025 GMT
verify return:1
DONE
subject=C=US, ST=California, O=Apple Inc., CN=pkg.pkl-lang.org
notBefore=Jan 29 16:18:48 2024 GMT
notAfter=Jan 28 16:28:48 2025 GMT

Could you please renew the certificate? Our CI pipelines will be very happy.

Thank you

Originally created by @fretb on GitHub (Jan 28, 2025). Hi everyone, Not sure if this is the right place to inform you, but it seems the SSL certificate at pkg.pkl-lang.org has recently expired: ``` ❯ openssl s_client -connect pkg.pkl-lang.org:443 </dev/null | openssl x509 -noout -subject -dates Connecting to 17.145.8.65 depth=2 C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services verify return:1 depth=1 CN=Apple Public Server RSA CA 12 - G1, O=Apple Inc., ST=California, C=US verify return:1 depth=0 C=US, ST=California, O=Apple Inc., CN=pkg.pkl-lang.org verify error:num=10:certificate has expired notAfter=Jan 28 16:28:48 2025 GMT verify return:1 depth=0 C=US, ST=California, O=Apple Inc., CN=pkg.pkl-lang.org notAfter=Jan 28 16:28:48 2025 GMT verify return:1 DONE subject=C=US, ST=California, O=Apple Inc., CN=pkg.pkl-lang.org notBefore=Jan 29 16:18:48 2024 GMT notAfter=Jan 28 16:28:48 2025 GMT ``` Could you please renew the certificate? Our CI pipelines will be very happy. Thank you
adam closed this issue 2025-12-30 01:23:00 +01:00
Author
Owner

@broguinn commented on GitHub (Jan 28, 2025):

Same here.

@broguinn commented on GitHub (Jan 28, 2025): Same here.
Author
Owner

@bioball commented on GitHub (Jan 28, 2025):

We're looking into this

@bioball commented on GitHub (Jan 28, 2025): We're looking into this
Author
Owner

@jaskaur18 commented on GitHub (Jan 28, 2025):

:(

@jaskaur18 commented on GitHub (Jan 28, 2025): :(
Author
Owner

@all2ham commented on GitHub (Jan 28, 2025):

FYI we're not just down in CICD, all of our prod deployments are at risk as every new container that boots up attempts to download pkg.pkl-lang.org/pkl-go/pkl.golang@0.8.1#/go.pkl

@all2ham commented on GitHub (Jan 28, 2025): FYI we're not just down in CICD, all of our prod deployments are at risk as every new container that boots up attempts to download `pkg.pkl-lang.org/pkl-go/pkl.golang@0.8.1#/go.pkl`
Author
Owner

@bioball commented on GitHub (Jan 28, 2025):

This is now resolved; everything should be working again. Apologies for this; we'll provide an update on details here soon.

@bioball commented on GitHub (Jan 28, 2025): This is now resolved; everything should be working again. Apologies for this; we'll provide an update on details here soon.
Author
Owner

@all2ham commented on GitHub (Jan 28, 2025):

we've resolved this by pulling 0.8.0 out of our pkl cache dir and committing it directly into our repo

@all2ham commented on GitHub (Jan 28, 2025): we've resolved this by pulling 0.8.0 out of our pkl cache dir and committing it directly into our repo
Author
Owner

@broguinn commented on GitHub (Jan 28, 2025):

I'd love to know how we can make pkl-lang.org not be a hard dependency for package inclusion in the future.

@broguinn commented on GitHub (Jan 28, 2025): I'd love to know how we can make pkl-lang.org not be a hard dependency for package inclusion in the future.
Author
Owner

@StefMa commented on GitHub (Jan 28, 2025):

Hmm.. Basically pkl-lang.org is just redirecting to the public packages published via github releases, right? 🤔
Should be quite easy to spin off such a thing on any hosting provider of your choice...

Still I guess a real mirror would be great. Looking at you https://github.com/apple/pkl-evolution/pull/4 and https://github.com/apple/pkl/issues/420

@StefMa commented on GitHub (Jan 28, 2025): Hmm.. Basically pkl-lang.org is just redirecting to the public packages published via github releases, right? 🤔 Should be quite easy to spin off such a thing on any hosting provider of your choice... Still I guess a real mirror would be great. Looking at you https://github.com/apple/pkl-evolution/pull/4 and https://github.com/apple/pkl/issues/420
Author
Owner

@bioball commented on GitHub (Jan 28, 2025):

It indeed is just a redirect to GitHub releases. However, it also affects the identity of the package. For example, the package://pkg.pkl-lang.org/pkl-k8s/k8s@1.1.2 is a different package than package://github.com/apple/pkl-k8s/releases/download/k8s@1.1.2/k8s@1.1.2.

But, you're right that the mirroring feature would help avoid a hard dependency on pkl-lang.org. This is something we're planning on looking into this year.

Also: if you are using projects, you can also avoid the network dependency by pre-seeding the cache directory, for example, with something like:

cat PklProject.deps.json \
  | jq -c -r '.resolvedDependencies[] | select(.type == "remote") | (.uri[7:] + "::sha256:" + .checksums.sha256)' \
  | xargs -I {} pkl download-package --no-transitive {} # exclude transitive deps because PklProject.deps.json is the full set of dependencies already

And if you are directly importing packages via their absolute path, this works too:

pkl analyze imports path/to/entrypoint.pkl \
  | jq -c -r '.resolvedImports[] | select(startswith("package:"))' \
  | xargs -I {} pkl download-package {}

You can also set the cache dir (via --cache-dir, or within your PklProject) to a path within your repo as a way to vendor your dependencies.

I'm closing this issue now that the problem is resolved. And we'll follow up with more details soon!

@bioball commented on GitHub (Jan 28, 2025): It indeed is just a redirect to GitHub releases. However, it also affects the _identity_ of the package. For example, the `package://pkg.pkl-lang.org/pkl-k8s/k8s@1.1.2` is a different package than `package://github.com/apple/pkl-k8s/releases/download/k8s@1.1.2/k8s@1.1.2`. But, you're right that the mirroring feature would help avoid a hard dependency on pkl-lang.org. This is something we're planning on looking into this year. Also: if you are using projects, you can also avoid the network dependency by pre-seeding the cache directory, for example, with something like: ```sh cat PklProject.deps.json \ | jq -c -r '.resolvedDependencies[] | select(.type == "remote") | (.uri[7:] + "::sha256:" + .checksums.sha256)' \ | xargs -I {} pkl download-package --no-transitive {} # exclude transitive deps because PklProject.deps.json is the full set of dependencies already ``` And if you are directly importing packages via their absolute path, this works too: ```sh pkl analyze imports path/to/entrypoint.pkl \ | jq -c -r '.resolvedImports[] | select(startswith("package:"))' \ | xargs -I {} pkl download-package {} ``` You can also set the cache dir (via `--cache-dir`, or within your `PklProject`) to a path within your repo as a way to vendor your dependencies. I'm closing this issue now that the problem is resolved. And we'll follow up with more details soon!
Author
Owner

@bioball commented on GitHub (May 13, 2025):

Following up with a quite belated comment here:

We've improved the monitoring around our certificates; we don't expect this to happen again going forward.

We're also working on a new feature, which allows users to avoid depending on pkg.pkl-lang.org in http-rewrites.

After that feature has landed, there will be multiple ways to avoid connecting the pkg.pkl-lang.org:

  1. Using an HTTP proxy (landed in Pkl 0.26)
  2. Using the cache directory as a vendoring mechanism (see my previous comment on how to do this)
  3. Using HTTP rewrites to a mirror server

In the future, it might also make sense to promote vendoring to a first-class citizen, to make the experience a little easier on users.

@bioball commented on GitHub (May 13, 2025): Following up with a quite belated comment here: We've improved the monitoring around our certificates; we don't expect this to happen again going forward. We're also working on a new feature, which allows users to avoid depending on pkg.pkl-lang.org in [http-rewrites](https://github.com/apple/pkl-evolution/pull/17). After that feature has landed, there will be multiple ways to avoid connecting the pkg.pkl-lang.org: 1. Using an HTTP proxy (landed in Pkl 0.26) 2. Using the cache directory as a vendoring mechanism (see my previous comment on how to do this) 3. Using HTTP rewrites to a mirror server In the future, it might also make sense to promote vendoring to a first-class citizen, to make the experience a little easier on users.
Author
Owner

@StefMa commented on GitHub (May 13, 2025):

Thanks for the update @bioball !

Regarding 3., is it already possible to mirror pkg.pkl-lang.org? 🤔

@StefMa commented on GitHub (May 13, 2025): Thanks for the update @bioball ! Regarding 3., is it already possible to mirror pkg.pkl-lang.org? 🤔
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pkl#268