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.
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
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?