Repository navigation
New release key not mentioned in release notes or SECURITY.md? #1422
Description
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)
Activity
seratch commentedon Jan 14, 2025
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.
dsvensson commentedon Jan 14, 2025
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.
seratch commentedon Jan 14, 2025
Thanks for your quick reply. I understand your point. We will consider including the information in future release announcements.
dsvensson commentedon Jan 14, 2025
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.
dsvensson commentedon Jan 31, 2025
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?
seratch commentedon Feb 3, 2025
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.
dsvensson commentedon Feb 3, 2025
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.
seratch commentedon Feb 3, 2025
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.
dsvensson commentedon Feb 3, 2025
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.
dsvensson commentedon Nov 4, 2025
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 🤞.
dsvensson commentedon Feb 5, 2026
This time they seem to have regressed to a non-slack.com email key:
Is this expected @seratch ? Guess it's just a delayed effect from the acquisition a few years back. Would be nice to see this reflected in a https://github.com/slackapi/java-slack-sdk/blob/main/SECURITY.md
dsvensson commentedon Mar 31, 2026
0529A2556B510619FE68B6393EFE6B4A56071E83I guess? Wouldn't it be nice with a stable, documented, release key?dsvensson commentedon Apr 21, 2026
@zimeg So is the new strategy for mentioning PGP key used to just mention it in release PR's instead of adding the release key fingerprint to SECURITY.md like so many other projects already have done?
zimeg commentedon Apr 21, 2026
👋 Hey @dsvensson! I understand the surprise at changing keys and wanted to share the most recent
v1.48.1repeats this with a new key:But we're hoping to keep this one stable in CI for ongoing releases! We'll explore documenting this key in upcoming project maintenance in
SECURITY.mdbut for now I closed this issue.dsvensson commentedon Apr 21, 2026
Thanks, looking forward to it! Unclear why the issue was closed though. It's not mentioned in the release, and no SECURITY.md (preferrable as it's stable) added, just the PR that happened to start the release I guess. Would imho be better to keep the issue open.
[-]New release key not mentioned in release notes?[/-][+]New release key not mentioned in release notes or SECURITY.md?[/+]