Code Signing certificate rollover

[stoecker]

At 2023-09-12 our code signing certificate ends. Sectigo seems to have trippled prices to about 300€/year. SSL.com is still in the range 100€/year.

• ​https://www.ssl.com/certificates/code-signing/buy/

According to this table it should also work for Java

• ​https://www.sslshopper.com/java-code-signing-certificates.html

Would be fine if we could somehow verify if that's true before ordering a new certificate.

[taylor.smock]

From looking at ​https://www.ssl.com/article/ssl-com-root-certificates/ (last updated 2015-06-03), maybe? It kind of depends upon which root is used.

The JDK does have 3 certs from SSL.com built-in (see ​https://github.com/openjdk/jdk/blob/master/src/java.base/share/data/cacerts/sslrootevrsaca, ​https://github.com/openjdk/jdk/blob/master/src/java.base/share/data/cacerts/sslrooteccca, and ​https://github.com/openjdk/jdk/blob/master/src/java.base/share/data/cacerts/sslrootrsaca ). All were added in 2020 to OpenJDK, and all were generated after the last update of the root certificates help article.

[stoecker]

So it will not work with java version before 2020, it could work for >= 2020. Should be fine with me when that saves 600€.

[Don-vip]

Nobody should run in 2023 a Java < 2020 so that's even a good choice if it forces users to upgrade a vulnerable version of Java.

[Frederik Ramm]

Do we still need this code-signing stuff at all? Even if we get FOSSGIS to sponsor it, we're still burning > EUR 200/year of donation money to feed the certificate gatekeepers... and for what?

[taylor.smock]

Do we still need this code-signing stuff at all?

The last ticket where we had to update the code signing certificate was #12115, and I was unable to find any other tickets where we discussed why we needed/wanted a code signing certificate.

I don't think we really need the code signing certificate for the installers for Mac/Windows, since I think both of those get signed separately using separate keys, but I could be wrong -- we could be reusing the code signing key for those.

With that said, we use distribute JNLP files; this is where we might need/want the code signing certificate.

As a specific example, OpenWebStart will show the user a "Security Approval Required" window. In that window, it says "The digital signature has been validated by a trusted source". I don't remember what Oracle webstart does, but I think it either skips showing the user a dialog entirely, or says something similar.

We have been pushing users to move to OpenWebStart from Oracle Webstart for quite some time now, and we want to move to Java 11 or Java 17 (see #17858), so a different option would be to use a self-signed certificate. It looks like OpenWebStart will accept that, although an system administrator can prevent users from granting permissions to content from an untrusted authority.

Even if we get FOSSGIS to sponsor it

If FOSSGIS doesn't sponsor it, we can probably get OSMF to sponsor it (the EWG wants to use 50% of their budget for core OSM software). Although there might be some red tape we don't want to deal with.

[stoecker]

Currently we sign the jar (for WebStart). Winows MSI and Exe are both signed with the same Cert (I'm not sure if the Java Sign is passed through or it's signed directly again).

[stoecker]

Hmm, very likely the MacOS variant is also signed with the same cert. I don't know how to retrieve the values from GitHub. It seems I can only change them.

[stoecker]

So essentially we sign everything. Only Linux doesn't need signatures. I suggest everybody drops these proprietary vendor-locked in operating systems!

Today I had to reboot my Linux because the system upgrade prevented new network connections. It's something I can't even start to explain to Windows users that I really get angry when I'm forced to reboot my system... Windows (MacOS no less) is so bad and still people use it. Strange.

[taylor.smock]

Linux might need signatures to avoid scary warnings for the JNLP files. It depends upon the Webstart implementation.

Otherwise, it is typically up to the distribution to do the verification. Many build from source, some do not.

I do know that everything that uses the josm gradle plugin (maintained by floscher, not us) will need to update their compile version, since the test jar will have a different signature from the application jar. This will be the case regardless of whether or not we renew the signature.

[taylor.smock]

Ticket retargeted after milestone closed

[taylor.smock]

Signing the Windows installers is now failing: ​https://github.com/JOSM/josm/actions/runs/6236521091/job/16928040720

SignTool Error: No certificates were found that met all the given criteria.

Have we gotten a new certificate, or do we need to remove the signing steps from the GitHub CI?

[stoecker]

Replying to taylor.smock:

Signing the Windows installers is now failing: ​https://github.com/JOSM/josm/actions/runs/6236521091/job/16928040720

SignTool Error: No certificates were found that met all the given criteria.

Have we gotten a new certificate, or do we need to remove the signing steps from the GitHub CI?

Not yet. But we will. I tried a cheaper solution, but didn't get permission to use the certificate. That delayed renewal a bit :-)

[taylor.smock]

Ticket retargeted after milestone deleted

[stoecker]

Ticket #23217 has been marked as a duplicate of this ticket.

[SekeRob]

OT\ Re "So it will not work with java version before 2020" and other drives to get user to upgrade to a newer JAVA release, I recently updatedg the Java install on my machine to the latest latest v17 stable but not seeing it reflected in the startup of JOSM. Went to read and discovered that OpenWebStart installs it's own v17 which is slightly behind the one I manually installed. Their argument being them not wanting to break other app dependencies. And they're not the only one doing so, found I have 3 Java installs on the system. /OT

[taylor.smock]

Java 17 was ​released on 2021-09-11.

I have opened a ticket on the OWS github for automatically updating the ​jvms.json file. I didn't see any arguments in my search about them not wanting to break other app dependencies (unless they were talking about the version of java they build and distribute for OWS itself; this specifically is not a system installation of Java).

[taylor.smock]

Should I start planning on skipping the 23.10 release?

[stoecker]

Let's hope not to.

[taylor.smock]

I hope not as well. What I might end up doing is assume that the time before we get a new certificate is undefined, and just plan on doing a release a week after we get the new certificate. I am assuming I can get all the installers built via the GH action (macOS notarization might be a problem, see #23125).

[stoecker]

Replying to taylor.smock:

I hope not as well. What I might end up doing is assume that the time before we get a new certificate is undefined, and just plan on doing a release a week after we get the new certificate. I am assuming I can get all the installers built via the GH action (macOS notarization might be a problem, see #23125).

Uh. October release will also fail. Certificate rollover is combined with more bullshit than expected. Seems since the rule changes in Q1 this year they went amok.

[taylor.smock]

Thank you for letting me know. I didn't know there were rule changes this year.

It looks like we will need a physical device to store the key on ("FIPS 140-2 Level 2" or "Common Criteria EAL 4+"). I don't think that will work for either Jenkins or GitHub CI, but I could be wrong.

The alternative would be to use one of the cloud HSMs mentioned in the ​SSL.com guide (AWS, Azure, and Google). I don't think we can realistically do BYOA.
The problem being I don't understand their pricing scheme. I assume it is per hour that the key is on their servers, which make all of them a no-op.

I'm looking into alternatives. One I just found (and am looking into) is ​https://www.sigstore.dev/ . Which is allegedly for OSS applications. I found it from ​https://security.googleblog.com/2021/03/introducing-sigstore-easy-code-signing.html via a search for open source code signing.

[stoecker]

I wouldn't like that physical device much, but that probably will be a possible solution. I could attach it to one of our office servers and setup a signing service called from our JOSM instances. Maybe it's even possible to attach to the server at Hetzner.

[taylor.smock]

Fair enough. I doubt that we will be able to attach it to the server at Hetzner though -- I suspect that all supported devices require a physical action (e.g. a keypress).

[stoecker]

Replying to taylor.smock:

Fair enough. I doubt that we will be able to attach it to the server at Hetzner though -- I suspect that all supported devices require a physical action (e.g. a keypress).

Well, I'll for sure not get up each night a 0:00 to press a button in our office ;-)

[taylor.smock]

Ticket retargeted after milestone deleted

[stoecker]

Signstore seems not to provide any code signing for Windows, MacOS or Java. The hardware tokens require a key press for each signing, making them worthless.

Actually after I now tried myself to get deeper into the topic I tend to drop signing completely. It's simply

• expensive and
• no longer automatable

Users will simply have to live with the warnings.

[stoecker]

What we could do is provide and use an own certificate. That way it's possible to verify if the software was made by us. But no official certificate seems usable anymore.

[taylor.smock]

I'll do a deeper dive into sigstore -- there is a maven ​plugin that can do jarsigning.

[stoecker]

I disabled signing for all releases (hopefully), so we can do releases again independent from the fact if we ever sign them again or not. But I'll stop the hold, so that 23.11 should go out signed or not.

[taylor.smock]

It looks like the maven plugin is currently borked for jarsigning. I've filed a ​ticket.

[taylor.smock]

Fairly minimal pom.xml for generating a signed jar. Currently does not work for jarsigning, see comment:31.

[taylor.smock]

OpenWebStart really doesn't like unsigned jars (you can test with the josm-latest.jnlp).

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:592)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:373)
	at net.sourceforge.jnlp.Launcher.access$300(Launcher.java:71)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:660)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed.
	at net.sourceforge.jnlp.runtime.classloader.SecurityDelegateImpl.getClassLoaderSecurity(SecurityDelegateImpl.java:102)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.setSecurity(JNLPClassLoader.java:387)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.initializeResources(JNLPClassLoader.java:776)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.<init>(JNLPClassLoader.java:350)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.createInstance(JNLPClassLoader.java:423)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.getInstance(JNLPClassLoader.java:495)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.getInstance(JNLPClassLoader.java:468)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:584)
	... 3 more

We might be able to work around that, but I'm not certain about that.
The most likely way to work around that would be to self-sign the jar. Users will probably still get a warning, but it might be enough for OWS to start.

[stoecker]

Signing is no issue. I have even a CA cert available: ​https://www.dstoecker.eu/cert.html

Only issue is that nobody except me trusts it ;-)

[stoecker]

I'll try tomorrow if it helps.

[gaben]

I'm getting with Java 8 JNLP the following startup error on Windows:

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:846)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:531)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:969)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed.
	at net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.getClassLoaderSecurity(JNLPClassLoader.java:2496)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:384)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:812)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:337)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:420)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:494)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:467)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:838)
	... 2 more

[taylor.smock]

I found another alternative "for OSS projects" via ​https://github.com/sigstore/fulcio/issues/250: ​https://about.signpath.io/product/open-source . They claim to support jar files.

@gaben: It doesn't look like stoecker signed josm-latest.jar over the weekend, or at least the current https://josm.openstreetmap.de/download/josm-latest.jar wasn't signed.

EDIT: The signpath certificate is currently OV not EV. The linked fulcio ticket has someone who claims to work at sigstore saying that they are considering EV certificates for OSS.

[stoecker]

Sorry. Had no time. It's not forgotten.

[stoecker]

Could someone test please: download/josm-test.jnlp. Seems my Linux doesn't support Webstart anymore without effort ;-)

[taylor.smock]

Looks like that works for me.

There is a warning message. I'll upload a screenshot.

EDIT:

[stoecker]

I enabled it for latest. We'll see when next latest is build.

[stoecker]

Question remains what to do with MacOS and Windows. No signing? Use this Key?

[taylor.smock]

I think we're OK for mac. I'll double-check that.

Windows: There is some kind of reputational score, so it may take some time before users stop seeing a "scary" warning. We'll want to start signing Windows installers with a new key a few months before the old one expires -- this will build the reputation score for the new key (from what I've read). Probably not an issue for awhile though:

Validity: [From: Wed Nov 15 10:16:21 MST 2023,

To: Tue Nov 15 10:16:21 MST 2033]

Root CA might be a problem -- I'm not certain how expired root certificates with unexpired issued certificates will be handled.

Validity: [From: Fri Dec 04 09:43:22 MST 2015,

To: Thu Dec 04 09:43:22 MST 2025]

[taylor.smock]

Nevermind. I can't check. See ​https://github.com/JOSM/josm/actions/runs/6870457327/job/18685391242 .

[stoecker]

Hmm,

Validity: [From: Fri Dec 04 09:43:22 MST 2015,

To: Thu Dec 04 09:43:22 MST 2025]

Maybe It's time to renew my root. It aged a bit ;-) ...at the weekend...

[taylor.smock]

Max Ericson mentioned ​https://www.yubico.com/store/yubihsm-2-series/ -- he thinks that the descriptions don't read like they need physical interaction. I tend to agree -- one of the images seems to indicate that you can put it in a server case (on a motherboard USB port).

Unfortunately, the cost is significant -- $950. Maybe we can poke the OSM ​EWG for funding?

We'll probably have to either install a github runner on our server or pull the installers and sign them after the GH run.

• ​https://github.com/YubicoLabs/yubihsm-java-enrollment

EDIT: It looks like josm-latest isn't updating.

[stoecker]

If it would work and not be obsolete in 2 years and we get it paid (and additionally the cert) I still don't want this. Such methods are the death of free OpenSource and I don't want to contribute to that.

EDIT: It looks like josm-latest isn't updating.

Permissions issue ;-)

[stoecker]

Replying to stoecker:

If it would work and not be obsolete in 2 years and we get it paid (and additionally the cert) I still don't want this. Such methods are the death of free OpenSource and I don't want to contribute to that.

EDIT: It looks like josm-latest isn't updating.

Permissions issue ;-)

It helps to set permissions for the correct file. Tomorrow again...

[taylor.smock]

Ticket retargeted after milestone closed