ooooh thanks!! do you mean latest_release in that last sentence?

Yes :) It was too early! I'll edit it.

Do you have CLOJARS_PASSWORD env var set to a valid deploy token? (not a password)

(and CLOJARS_USERNAME)

It should be, let me double check.

Yes to both, not changed since last time I did some deploys.

Hmm, that's the only thing I can think of right now...

I've been using this token since Jun 2020 AFAIK.

And slipset did create .asc files for the pom and jar as normal.

So I wonder if something's changed recently at clojars?

https://github.com/slipset/deps-deploy/issues/11 seems similar...?

"Determined that the bug is only present when signing jars."

Odd, been using the same version of slipset, and the build tool does rename the pom.

`

Authorization failed for  403 Forbidden - no checksums provided for pretty-1.4.jar.asc"

This is the validation on the clojars side expecting every file uploaded to have either an md5 or sha1 checksum file uploaded for each file. It runs the validations when the maven-metadata.xml file is uploaded, and throws on the first failure. Looking at the output, I don't see any sha1 or md5 files being uploaded, so that would cause this. I've never used deps-deploy, so don't know how to configure it/what it is supposed to do. I would think that aether would handle that for you though. I'll check the logs to see if any checksum files were uploaded, but not reported in the output.

There haven't been any recent changes to clojars that would effect this

It is sending md5 sums for the jar & pom, but not for the asc files;

50.220.102.134 - hlship [27/Mar/2023:22:15:37 +0000] "PUT /repo/io/aviso/pretty/1.4/pretty-1.4.jar.md5 HTTP/1.1" 201 5 "-" "Aether"
50.220.102.134 - hlship [27/Mar/2023:22:15:39 +0000] "PUT /repo/io/aviso/pretty/1.4/pretty-1.4.pom.md5 HTTP/1.1" 201 5 "-" "Aether"
50.220.102.134 - hlship [27/Mar/2023:22:17:38 +0000] "PUT /repo/io/aviso/pretty/1.4/pretty-1.4.jar.md5 HTTP/1.1" 201 5 "-" "Aether"
50.220.102.134 - hlship [27/Mar/2023:22:17:40 +0000] "PUT /repo/io/aviso/pretty/1.4/pretty-1.4.pom.md5 HTTP/1.1" 201 5 "-" "Aether"
50.220.102.134 - hlship [27/Mar/2023:22:44:01 +0000] "PUT /repo/io/aviso/pretty/1.4/pretty-1.4.jar.md5 HTTP/1.1" 201 5 "-" "Aether"
50.220.102.134 - hlship [27/Mar/2023:22:44:03 +0000] "PUT /repo/io/aviso/pretty/1.4/pretty-1.4.pom.md5 HTTP/1.1" 201 5 "-" "Aether"

Do you normally sign pretty releases @U04VDKC4G?

https://github.com/slipset/deps-deploy/commit/fd8ff2de9c4bda82a1c69c387d56217473b394be appears to be the fix for this (found via https://github.com/slipset/deps-deploy/pull/53), but it doesn't look like it is released.

Good detective work @U06SGCEHJ! Maybe this will encourage @U04V5VAUN to cut a release? But I guess you could depend on it via git coords to get past this @U04VDKC4G?

Great advice; I can tackle this tomorrow.

And, yes I GPG sign my uploads to all projects. I don’t get why I haven’t hit this before though.

Even using latest deps-deploy, I had to turn artifact signing off to deploy.

I’ll try to find some time to look into this. Out of curiosity, where do you publish your public signing key @U04VDKC4G ? Reason I’m asking is that I’m also signing stuff, but haven’t published my key anywhere, so it’s basically useless. Likewise, I would have no idea how to go about verifying any of your things if I were so inclined. Basically what I’m saying is that I find that there are some missing pieces of infrastructure which would make the signing of artifacts so more useful if it existed.

FWIW, I just published deps-deploy 0.2.1, signed:

erik@keep deps-deploy % env CLOJARS_USERNAME=erik CLOJARS_PASSWORD=CLOJARS_<redacted> clj -X:deploy
gpg passphrase:
gpg passphrase:
Deploying slipset/deps-deploy-0.2.1 to repository clojars as erik
Sending slipset/deps-deploy/0.2.1/deps-deploy-0.2.1.pom (2k)
    to 
Sending slipset/deps-deploy/0.2.1/deps-deploy-0.2.1.jar (8k)
    to 
Sending slipset/deps-deploy/0.2.1/deps-deploy-0.2.1.pom.asc (1k)
    to 
Sending slipset/deps-deploy/0.2.1/deps-deploy-0.2.1.jar.asc (1k)
    to 
Retrieving slipset/deps-deploy/maven-metadata.xml (1k)
    from 
Sending slipset/deps-deploy/maven-metadata.xml (1k)
    to 
done.

erik@keep deps-deploy %

I think I did a signing exchange at Apachecon once, maybe 20 years ago. I think I'm still using the same GPG key.

Good point about uploading the key somewhere so that the signing is actually useful.

I'm using deps-deploy-0.2.1 but still getting the error, but probably because of how I'm using it. To hack around the prompt for the GPG passphrase, I sign the file before calling aether/deploy. https://github.com/hlship/build-tools/blob/main/src/net/lewisship/build/jar.clj#L103

Hm. Maybe I can use some combination of these instead:

:username - username to log in with
      :password - password to log in with
      :passphrase - passphrase to log in wth
      :private-key-file - private key file to log in with

@U04VDKC4G I remember Phil (technomancy) encouraging folks to do key signing exchanges in person at Clojure/conj events many years ago, when he was trying to get artifact-signing on Clojars more widespread...