Hi Vladimir, On 10.11.2025 15:00, Vladimir Sitnikov wrote: >> Signing the new key with your old key (86fdc7e2a11262cb), > > What is the purpose? Who validates such signatures? Which tools validate > such signatures?
As far as I know, only humans do. ;-) Gradle includes a Dependency Verification mechanism that can automatically check signatures on downloaded artifacts [1]. In security-conscious environments, a dependency upgrade will fail if the signing key has changed, triggering a manual verification. Finding a signature from the old key on the new one serves as evidence that the change was *intentional*. Gradle’s bootstrapping mechanism [2] follows a Trust On First Use, so new adopters will not suffer from the key change, but users who bootstrapped verification years ago would naturally question an unexpected key change. > What if the access to the old key was lost? > What if the old key was compromised? In that case, signing anything with it > would make no sense. That would be an entirely different situation, but you’re right to point it out. It might be good practice to store a revocation certificate for the <[email protected]> UID of the new key (not the Gmail one) somewhere accessible to INFRA or the PMC. Such a revocation certificate would be used if there were proof that the key was compromised *and* Gary was unreachable. As for the old key, it could be revoked after a couple of months to mark its retirement. In the Logging Services PMC we *don't* have direct access to our release signing key (only GitHub and INFRA does), but we have access to a revocation certificate. > We'd better move towards Sigstore rather than invent new processes with PGP. I agree that PGP is not the future, but right now it’s what we have, and we should keep it alive for backward compatibility with users who still rely on it. Build attestations may indeed be the future, but in the current Commons release model, where releases are built on PMC-member hardware, they offer fewer guarantees than PGP. Attestations only confirm that the release manager has access to their ASF account; they don’t provide a second factor such as access to a GPG key. This will likely improve once MFA is fully deployed at the ASF, but for now we should make sure that changes to release manager keys are properly communicated to our users. Piotr [1] https://docs.gradle.org/current/userguide/dependency_verification.html#sec:signature-verification [2] https://docs.gradle.org/current/userguide/dependency_verification.html#sec:bootstrapping-signature-verification --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
