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
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`
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.
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.
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...
@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
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:
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!
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:
Using an HTTP proxy (landed in Pkl 0.26)
Using the cache directory as a vendoring mechanism (see my previous comment on how to do this)
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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:
Could you please renew the certificate? Our CI pipelines will be very happy.
Thank you
@broguinn commented on GitHub (Jan 28, 2025):
Same here.
@bioball commented on GitHub (Jan 28, 2025):
We're looking into this
@jaskaur18 commented on GitHub (Jan 28, 2025):
:(
@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@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.
@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
@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.
@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
@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.2is a different package thanpackage://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:
And if you are directly importing packages via their absolute path, this works too:
You can also set the cache dir (via
--cache-dir, or within yourPklProject) 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 (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:
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.
@StefMa commented on GitHub (May 13, 2025):
Thanks for the update @bioball !
Regarding 3., is it already possible to mirror pkg.pkl-lang.org? 🤔