I'm developing update4j, a Java based update and launch framework. I recently had a small dispute with a fellow contributor and I want to straighten things out.

I as few words possible; there is a client side updater that reads a remote "configuration" file. That file contains all information required to download the application files.

Additionally, there's an opt-in feature to sign files and verify each download against a public key. This should prevent hackers from changing files in the configuration or modify actual remote application files. In the config, next to each file a signature field is added and used by the client-side updater to verify against a known public key provided at installation.

Now, I considered developer opt-in if the certificate/public key is used in the updater when requesting to perform an update. Otherwise, the updater completely ignores the signature field. But they claim that if the config contains signatures, this by itself is considered opt-in and should force the updater to verify, and if the updater was never aware of any public keys and never asked for it, it should fail.

To quote:

No local certificate provided

If the config contains signatures (so the provider intends to secure the update), but no local certificate is provided, update4j downloads the configuration, the files and runs it. In my opinion, this is not secure. See src/test/java/org.update4j.integration.SigningTest.noCertificateWithSignatureTest()

From my perspective this feels unnecessary. The "provider" is usually the same development team of the client-side updater (at least they decided how to set up the updater). If a hacker could access files or the config itself and modify it, the "provider" no longer seeks security. If they change things knowingly that the updater never requires any signatures, why in the world would that hacker add the signature field? Additionally, it makes it really hard to add security for only some installations (say a testing feature) since you would have to add a signature but now it will blow up the old clients.

The only case I could agree would be unsecured is where the config itself was not hacked, only the remote files. Here the provider would still want to verify the files. But remember, the dev team never looked for security since they didn't configure the updater to check for signatures.

How would you handle such a case?


I would provide a user-side configuration option to control what to do, with three possible settings:

  • Check only if a signature field is present. This option should be the default, and lets the user defer to the publisher as to whether or not to check the signature if present.
  • Always check, and issue an error if there is no signature field. This option is for those users who want (or need) to ensure code integrity, and don't trust the publisher to require it.
  • Never check. This option is mostly for developers or internal usage, and should probably have a big warning on it.

Most users will leave things at the default, and therefore will get checking if the update provides a signature, and none if it doesn't, while those who need to force enable or disable checking can do so.

You might additionally consider providing something equivalent to the Strict-Transport-Security header in HTTP. Essentially, if some flag is set in an update that's been signed, future updates for that same piece of data must also be signed or they won't be accepted, even if they don't have a valid signature field.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.