slackapi
New release key not mentioned in release notes?
When migrating from 1.45.0 to 1.45.1 the release key changed without this being mentioned in the release notes. Is this expected?
- On artifact slack-api-client-1.45.1.pom (com.slack.api:slack-api-client:1.45.1) in repository 'MavenRepo':
Artifact was signed with key '8E05CCB0D18336A9' but it wasn't found in any key server so it couldn't be verified
- On artifact slack-api-client-kotlin-extension-1.45.1.pom (com.slack.api:slack-api-client-kotlin-extension:1.45.1) in repository 'MavenRepo':
Artifact was signed with key '8E05CCB0D18336A9' but it wasn't found in any key server so it couldn't be verified
- On artifact slack-api-model-1.45.1.pom (com.slack.api:slack-api-model:1.45.1) in repository 'MavenRepo':
Artifact was signed with key '8E05CCB0D18336A9' but it wasn't found in any key server so it couldn't be verified
- On artifact slack-api-model-kotlin-extension-1.45.1.pom (com.slack.api:slack-api-model-kotlin-extension:1.45.1) in repository 'MavenRepo':
Artifact was signed with key '8E05CCB0D18336A9' but it wasn't found in any key server so it couldn't be verified
- On artifact slack-sdk-parent-1.45.1.pom (com.slack.api:slack-sdk-parent:1.45.1) in repository 'MavenRepo':
Artifact was signed with key '8E05CCB0D18336A9' but it wasn't found in any key server so it couldn't be verified
(I'm saving keys locally, thus the comment about not found on key server)
Hi @dsvensson, thanks for asking the question. Indeed, I used a different GPG key to publish the artifacts to oss.sonatype.org / Maven Central repo, but the key was published at least to keyserver.ubuntu.com. Also, the Maven Central repo successfully accepted the signed artifacts. This means there should not be any issues for artifact users. You can read https://central.sonatype.org/publish/requirements/gpg/ for more details of the publishing operations.
I am not sure what the desired state for you is, but I just published the same key to keys.openpgp.org and pgp.mit.edu as well. Hope this makes things better for you.
My desired state would be for the release key to be documented in the release notes when it changes as with other projects, and that it's stable with a reasonable key rotation cycle, other projects change perhaps yearly, or every other year or so. The purpose of the signing is to establish trust as best as possible, and having clear communication inches one step closer to the unreachable full trust.
Thanks for your quick reply. I understand your point. We will consider including the information in future release announcements.
It would also be very valuable if the previous release key signed the new release key (and vice versa) so there would be a bridging of trust of the keys on rotation.
Seems like the key switched again? FE50E975FB1EDD6C923CAC9BC57D661E64800FA5 ... could you perhaps update the README with the list of keys allowed to be used for official releases? Or just like other projects use a designated trusted release key?
Indeed, the release used a different key, which we had used in the past. I apologize for any disruption this caused.
A quick update: I will be leaving Slack soon and have asked the rest of the team to improve this release operation for your use case. The next release will use another different key (since future releases won't use any of the keys I have used previously). However, moving forward, the key will be more consistent, and our release notes will mention any changes.
It's not my use-case specifically, it's simply about trust. The current approach to trust feels a bit YOLO. It feels more like "ooof, gotta use a release key because system $X requires it", rather than using a release key and a procedure around it because it's the right thing to do to convey trust in releases.
Thank you for your input. I'm not opposing you, but I'd like to share my thoughts on this before I leave this project.
Before reading, please understand that I don't mean we should agree on the general consensus about this topic here, but I wanted to share what I actually think and why I haven't taken the actions you've requested here (say, it's more than 15 years for all the Java OSS projects I've been involved; not just this project).
From what I understand, most library users in the Java ecosystem don't generally share your concern about the key used for artifacts, as they don't typically need to verify it themselves. This is because the Maven Central repository ensures that the publishing user is authorized to make releases under a groupId, and also its final step before making jar files available verifies that the used key is available on publicly accessible key servers, along with the user information associated with the authorized user. Moreover, popular build tools like Maven and Gradle do not raise warnings/errors about changes to the signing key (at least not by default). If a library is published outside of Maven Central, indeed security-conscious users may need to verify its safety. However, for those hosted on Maven Central, it generally isn't necessary to go to such lengths due to the above reasons. This is my general understanding of the situation.
That being said, given the business criticality of SDK projects released by a company for its users, I understand your concerns that inconsistencies with artifact signing keys could potentially affect user trust. Also, I can imagine some security verification tools/services could raise concerns about key changes for safety. Therefore, I am on the same page that it's important for this project to improve this aspect of releases.
Thank you once again for your patience. If I may ask, could you share a few excellent examples of projects that excel in this aspect? I no longer have enough time to take action on this myself, but the rest of the team can learn from these examples to improve our project.
Here are some high profile Java samples:
https://hibernate.org/community/keys/ https://github.com/FasterXML/jackson?tab=security-ov-file https://github.com/junit-team/junit-framework?tab=security-ov-file
I think the reason for why the community has been fostered into not caring about signatures is because it hasn't been mandatory for that many years - and still isn't in some maven repositories, and tooling has been in a bad state - which is no longer the case.
If you look into the broader open source ecosystem it's very common for open source projects to release signed artifacts, with clear instructions on how to verify.
Linux Kernel for example uses multiple release key, but documents this: https://www.kernel.org/category/signatures.html
Key-signing parties at conferences to strengthen the trust in the key are a thing.
While not a Java project, I'm sure you're familiar with the AWS CLI utility, which also provides the user with means of validating the authenticity of the release artifact:
https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
If you scroll down a bit and for example expand the Linux section, you see in step 2 how to validate the release artifact against their key.
Just because a new release is signed with the same key doesn't guarantee trust ofc, as the key could have been stolen, but it's one more step to inch closer towards higher trust.
In contrast to the previous release keys, the latest key at least mentions an @slack.com email. Hope this one sticks until ~2028-10-07, and maybe gets added to a future https://github.com/slackapi/java-slack-sdk/blob/main/SECURITY.md 🤞.
pub ed25519 2025-10-08 [SC] [expires: 2028-10-07]
F5BA05621CF0D201507107CBB1A65A4FBAFC507F
uid slackhq <[email protected]>
sub cv25519 2025-10-08 [E] [expires: 2028-10-07]