Thomas Neidhart
Thomas Neidhart
I continued reproducing the issue, this time I tried to instantiate the class in kotlin and access the typed method, the resulting byte code is like that: ``` 47: invokeinterface...
Fixed on main with this commit: https://github.com/google/jsonnet/commit/108e5d7ba7de3dfa42468461acbb3b1385aed629
A version of the authenticode signing service for Windows that supports multiple timestamp servers has been deployed to staging and been successfully tested to work as expected. It will be...
improved windows signing service is now deployed to production.
You can assign permissions to jobs: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
Tested that with different versions of jsonnet (0.18.0, 0.19.0, 0.19.1, latest version a3a1f0914dc3d2a6fd851edc8e5dc1ef52e372f7) and they all produce in the same correct result. Tested on ubuntu 22.04.
I did test it with my fork and the tag v1.0.1-java, but the slsa-verifier does allow this pattern only for the jreleaser/release-action repo: ``` Verifying artifact macos-notarization-service-1.3.0.zip: FAILED: invalid ref:...
What I wanted to say, the slsa-verifier has the jreleaser/release-action hardcoded in its code, such that the convention (vX.Y.Z-something) only is accepted for a builder coming from this repo.
The builder seems to be accepted now by the slsa-verifier, but unfortunately I have run into another problem: ``` tn@proteus:~/workspace/eclipse/eclipse-cbi/cbi-macos-notarization-service$ ./download-github-release.sh -v 1.3.0 REPO = eclipse-cbi/macos-notarization-service VERSION = 1.3.0 ARTIFACT...
Upon debugging slsa-verifier I see that he extracts the tag from the sourceURI. In the case of my project it is resolved as: `git+https://github.com/eclipse-cbi/macos-notarization-service@refs/heads/main` Resulting in an empty ref as...