Question regarding "No signing certs, not verifying [file]"
Closed this issue · 2 comments
Sorry if this has been answered before, but I couldn't find the info: Reading the file "launcher.log" I found the text "No signing certs, not verifying [file]" several times. I want to think there is a way for Getdown to verify the signature of a "[file]". Is there a way to do this with Getdown? If so, were can I find more information. Thanks in advance.
This feature was more important when it was possible to run Getdown as a signed applet, but it could conceivably still be of interest to users of Getdown today, where it must run as a standalone application.
Essentially, you can sign the getdown.jar file with a signing certificate and then sign the getdown.txt and digest.txt files created to describe your application and if the signatures do not match, Getdown will refuse to install or run the application defined by those files.
This was essential when Getdown was run as a signed applet because the user would grant privileges to the Getdown code delivered by a legal entity (usually a company), and then Getdown would turn around and download and run other code. So we had to ensure the other code being run by Getdown was guaranteed to also come from that company. Otherwise some malicious third party could take the signed Getdown jar file and use it to deploy applications of their choosing, even though the user only granted privileges to the original entity.
When Getdown is run as an application rather than an applet, this isn't really an issue. There's no benefit to "stealing" a signed getdown.jar and then using it to deploy your own application because the trust granted by the user to the initial company was done when they downloaded and installed the app from that company. A new company or individual would have to convince the user to download and install a new app, at which point they've established their own trust. They're not piggy backing on an existing trust relationship, like they could with an applet.
The signing process does provide yet a further layer of integrity checking, but it's not particularly necessary. The digest.txt file already contains a cryptographic hash of the getdown.txt file, so any attempt to tamper with the getdown.txt file would result in the original being redownloaded. But even in this case, any technically sophisticated user can do whatever they want on their own computer, so it's not entirely clear what you would even be protecting against.