Add PGP keys used by scala-lang to the security policy

[hamzaremmal]

No description provided.

[lrytz]

there's also https://keys.openpgp.org/search?q=C478A820AD150412FF2860C563426A08B91ED6B0

[SethTisue]

@hamzaremmal shall we try to finish this one up?

[hamzaremmal]

@hamzaremmal shall we try to finish this one up?

Yes !!

[SethTisue]

@hamzaremmal okay, so, what remains to be done?

one question is whether org.scala-lang.modules is supposed to be covered. ideally of course it would be, but I suggest we finish up this PR for toplevel org.scala-lang first, and then consider whether we want to go on and worry about the modules in a next phase of work. if you agree, then I would suggest adding some wording to this PR such as a simple "(but not org.scala-lang.modules")

[SethTisue]

it seems I have been signing Scala 2 releases with an expired personal key of mine for some years now? I think I made the key all the way back in 2016 UPDATE: no, I don't think this was me

a fellow wrote me a few months ago and said he noticed the expired key:

$ gpg org/scala-lang/scala-library/2.13.15/scala-library-2.13.15.jar.asc
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: assuming signed data in
'org/scala-lang/scala-library/2.13.15/scala-library-2.13.15.jar'
gpg: Signature made Fri 20 Sep 2024 21:25:28 CEST
gpg:                using RSA key C03EF1D7D692BCFF
gpg: Good signature from "Scala Project <[[email protected]](mailto:[email protected])>" [expired]
gpg: Note: This key has expired!
Primary key fingerprint: 86DA 41A5 E169 9C9C EBE9  64A8 A905 2B1B 6D92 E560
     Subkey fingerprint: 1FA8 68A3 4871 9E88 B6D0  DE24 C03E F1D7 D692 BCFF

I tried the same thing on my Mac and got:

% curl -O -L 'https://repo1.maven.org/maven2/org/scala-lang/scala-compiler/2.13.15/scala-compiler-2.13.15.jar.asc'
...
% gpg scala-compiler-2.13.15.jar.asc
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: assuming signed data in 'scala-compiler-2.13.15.jar'
gpg: Signature made Fri Sep 20 12:32:22 2024 PDT
gpg:                using RSA key C03EF1D7D692BCFF
gpg: Can't check signature: No public key

I have very little knowledge of this stuff and I'm not sure how to proceed. I could try to research this stuff and educate myself but tbh I'm sort of hoping you'll just tell me what I should do. either here, or on a shared video call

I guess I should generate a new key, start using it to sign Scala 2 releases, and add it to this page at the time we publish 2.13.16? UPDATE: no, we should just move the expiration date on the existing key forward

but that's future work, that doesn't affect the mergeability of this PR, right?

[SethTisue]

@hamzaremmal oh, I just found this Slack message from you:

I've updated the scala/scala3 PGP key with : https://keyserver.ubuntu.com/pks/lookup?search=2A5E8B338438CAC7033F9D8FB8A045C0A6EC398E&fingerprint=on&op=index. It will expire on 2027-07-18.

so that's what I should start using for Scala 2 releases as well?

[pzygielo]

As mentioned by @SethTisue - this key - which expired:

$ gpg --list-public-keys C03EF1D7D692BCFF
pub   rsa4096 2018-02-13 [SC] [expired: 2020-02-13]
      86DA41A5E1699C9CEBE964A8A9052B1B6D92E560
uid           [ expired] Scala Project <[email protected]>
sub   rsa4096 2018-02-13 [E] [expired: 2020-02-13]
sub   rsa4096 2018-02-14 [S] [expired: 2020-02-13]

was used to create signature:

$ gpg --verify org/scala-lang/scala-library/2.13.15/scala-library-2.13.15.pom.asc org/scala-lang/scala-library/2.13.15/scala-library-2.13.15.pom
gpg: Signature made Fri 20 Sep 2024 21:25:22 CEST
gpg:                using RSA key C03EF1D7D692BCFF
gpg: Good signature from "Scala Project <[email protected]>" [expired]

after expiration time.

So either the signing tool was forced to use expired key, or the key at signature creation place was updated and not expired at the time. In the latter case - may I ask for that key to be sent to keyservers, please?

[SethTisue]

aha, okay, updating the expiration date on 86DA41A5E1699C9CEBE964A8A9052B1B6D92E560, as @pzygielo suggests, seems like something we should go ahead and do

I found some instructions at https://superuser.com/a/1141251

so, I downloaded https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x86da41a5e1699c9cebe964a8a9052b1b6d92e560 which gave me an .asc file

then I did gpg --import on that file

then gpg --edit-key 86DA41A5E1699C9CEBE964A8A9052B1B6D92E560

then at the prompt I did expire, but it said:

Need the secret key to do this.

I don't think I am in possession of the secret key for this public key, in order to proceed further. @lrytz @hamzaremmal do either of you have it?

[pzygielo]

aha, okay, updating the expiration date on 86DA41A5E1699C9CEBE964A8A9052B1B6D92E560, as @pzygielo suggests, seems like something we should go ahead and do

I meant that it had probably been done already, given the key was used to create signatures after expiration time of published key. (As GPG will by default refuse to sign with expired key, I suppose expiration time was changed at the place where secret key is available.)
Just the updated version of public key was not published.

[SethTisue]

As GPG will by default refuse to sign with expired key, I suppose expiration time was changed at the place where secret key is available

hmm.... I don't see any evidence of anything like that occurring at https://app.travis-ci.com/github/scala/scala/jobs/627511892 , and there's nothing about it in our build scripts that I can see

we use https://github.com/sbt/sbt-pgp for signing, and it's a quite old version of the plugin, https://github.com/sbt/sbt-pgp/releases/tag/v1.1.0 . if I understand correctly, it uses BouncyCastle rather than command-line gpg

at sbt/sbt-pgp#158 (comment) one person wrote:

it turned out my key had expired. The earlier version (1.x) didn't mind.

so that seems to confirm that the behavior (of ignoring that the key is expired) is coming from BouncyCastle (and perhaps from some antiquated version of it)

[pzygielo]

if I understand correctly, it uses BouncyCastle rather than command-line gpg

BC could work differently, true.

I was somehow influenced by:

To ensure the integrity of all the releases, our organization uses [PGP]/(https://gnupg.org/) keys for cryptographic signing.

Only now I've found that Maven Central has section dealing-with-expired-keys, so this might happen quite often...

Thanks for checking this expiration case anyway 👍