Add new Release Manager PGP key to KEYS

[JinwooHwang]

Summary

• This PR appends the Release Manager’s PGP public key to the KEYS file so that upcoming source release artifacts can be verified by end users and downstream packagers.

Added Key

• uid: Jinwoo Hwang [email protected]
• Fingerprint: 5C3D A8FB B105 2F4D F1DE B1EF 62F7 DA41 B7D8 F26C
• Created: 2025-08-28
• Expires: 2029-08-28

Rationale

• Enables signature verification (.asc) for the next release cycle.
• Keeps the project compliant with ASF release policy (all signing keys must be published in KEYS).
• Ensures build consumers can establish a trust path before validating release artifacts.

Verification Steps (Reviewer)

1. Pull branch and inspect only appended block at end of KEYS.
2. Confirm no prior key material modified (e.g. git diff -w KEYS).
3. Extract and verify fingerprint locally:
   gpg --import KEYS
   gpg --fingerprint 5C3DA8FBB1052F4DF1DEB1EF62F7DA41B7D8F26C
4. (Optional) Check key on public keyservers / WKD if published:
   gpg --keyserver keys.openpgp.org --recv-keys 62F7DA41B7D8F26C
5. Dry‑run tag verification example (after a release tag exists):
   gpg --verify apache---src.tar.gz.asc

Release Manager Action After Merge

• Ensure the key is also uploaded to at least one public keyserver (if not already).
• Use this key exclusively (or document any key rotation) for signing the release artifacts and staged Maven artifacts (if applicable).
• Announce fingerprint in the VOTE and RESULT e‑mails.

Integrity Considerations

• No removal or alteration of existing keys.
• Single, properly delimited ASCII armored block (-----BEGIN PGP PUBLIC KEY BLOCK----- … -----END PGP PUBLIC KEY BLOCK-----).
• Fingerprint line in summary matches gpg output.

Request

• Approve & merge before starting the release vote so voters can pre‑import the key.

For all changes:

• Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

• Has your PR been rebased against the latest commit within the target branch (typically develop)?

• Is your initial contribution a single, squashed commit?

• Does gradlew build run cleanly?

• Have you written or updated unit tests to verify your changes?

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

[CalvinKirs]

I’ve already uploaded your key to https://downloads.apache.org/geode/KEYS (it may take a little time to sync). This is the way we usually handle it. I also noticed the release documentation follows the same process.

So I’m not sure if we really need to maintain a redundant copy here.

[JinwooHwang]

Thank you so much for taking care of uploading my key and for explaining the process, @CalvinKirs. I really appreciate your help and the clarification. My apologies for the confusion on my side — it makes perfect sense that we don’t need to maintain a redundant copy. I’ll be sure to follow this process going forward.

[raboof]

I’ve already uploaded your key to https://downloads.apache.org/geode/KEYS (it may take a little time to sync). This is the way we usually handle it. I also noticed the release documentation follows the same process.

https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode does also have "Add the release manager's public key block to the KEYS file in develop branch"

So I’m not sure if we really need to maintain a redundant copy here.

I kinda like having the git history of the KEYS file in 'regular' version control, so there's a trail explaining when/by who/why a key was added to the store - but I'm not aware of any ASF policy that says it must be here. If we're not updating it, perhaps we should remove it entirely?

[JinwooHwang]

@raboof . That makes sense — having the KEYS file in version control does provide a helpful audit trail, especially when tracking who added what and why. Even if it's not mandated by ASF policy, that traceability can be valuable. If we’re no longer maintaining it, though, removing it might help reduce confusion or the illusion of active use. Maybe we could document the rationale somewhere if we do remove it, just to preserve context? Any thoughts, @CalvinKirs ?