Feature request: checking/comparing digital signature details

[teknowledgist]

I have a package (hashtab) that the publisher apparently changes the downloadable installer without changing the version or any indication of changes. When I expressed concern about the changing checksums without a corresponding changelog or version, they responded that their installer is digitally signed and that is the best way to know it is safe.

I can always manually increment using $AU_Force = $true, but it would be great if the download check/compare the signature were automated. Thus, it would be super useful if there were an easy way to optionally have an additional function in AU that would:

1. download an installer
2. use SysInternals' SigCheck to collect signature details
3. Verify the installer is signed by the expected publisher
4. Compare the signing date with the previous version
5. If newer, increment the package version as with AU_Force

Not only would the ability to check the signature of an installer be useful for situations like HashTab, but (for publishers who sign) it could provide one additional security check against hacked websites and hijacked downloads.

Anyway, thanks for a great utility.

[ferventcoder]

Sign timestamp could be helpful, but that is validating something a user would need to trust. Dare I bring up the CCleaner example that was also authenticode signed but had malware baked into it? The checksum is able to be validated easily for us against all checks and provides a single point in time of a piece of software - that is what gets checked against VirusTotal, that is what gets validated and verified by our moderation tools.

How all of the above translates to checking this for changes, how is this the same or different from reverifying the checksum? As in, is there some way not to have to download it again? What benefit do you perceive of this method versus verifying the checksum again?

[ferventcoder]

For more details in understanding our moderation process - https://chocolatey.org/security#chocolatey-community-package-repository and https://chocolatey.org/docs/moderation.

That said, maybe this moves to bigger picture where we are talking about AU in organizational use where there is not a deployment to a community repo that provides all of that safety checking.

[teknowledgist]

I feel like there are two possible useful paths for this:

1. If packages are auto-updated, how can we be (more) sure they are legitimate? The moderation process checks for process errors and known malware, but the auto-update process is trusting that the download is safe in all other ways. Getting an authentic digital signature attached to a rogue installer is more difficult than hacking the website to indicate a new version and/or hash, so an optional and automatic check for a specific, trusted signature just adds an additional layer of assurance. Thus, I see AU returning warnings for packages that don't have a valid digital signature (if asked to check) as a good thing.
2. Having a means of testing for changed installers built into Auto-updater beyond just scraping webpages for version numbers would be useful. Comparing checksums tells the maintainer there has been a change, but checking the signatures tells the maintainer there has been an official/authorized change. (Side note: Is there already a way to have AU compare checksums in the global:au_GetLatest function?) I'm sure this is possible now by writing a function to do it, I'm just not sure I'm skilled enough (or I'm too lazy 😄 ). This function to download and check signatures for the purpose of identifying updates would be essentially the same function as (1), but it would be used in an earlier step in the process.

Hope that makes sense and I'm not being too naive here.

[majkinetor]

Checksum compare example is given here:

https://github.com/majkinetor/au-packages/blob/4cdc0bb0cde8f43df03a039432e5a1e772423cb0/cpu-z.install/update.ps1#L27-L34

Similar, albeit a bit more complicated solution, can be done for digital signature and moved to function. Making it generalized and not depending on package style would require more work.

This definitely should belong to core AU features given its scope. Usage of such feature in FOSS ecosystem would be IMO low however,

[ferventcoder]

Thank you @teknowledgist - I was only wanting to tease out the aspects of where things were different. Like @majkinetor, I think it would be a good thing to have. Would you see having something local that would check the thumbprint to be sure they are the same also having a great effect? Because even malware folks can provide something with an authenticode signature (even in a trusted chain), so you would need to have something local that would first check that the signatures are what you expect before you check if things are different.

Moreover I see something like this in core Chocolatey and we've discussed that as well - chocolatey/choco#643

[teknowledgist]

Would you see having something local that would check the thumbprint to be sure they are the same also having a great effect?

@ferventcoder - I'm not sure I know enough about signatures to guess. Obviously, if a malicious actor gets hold of the private cert of the publisher, all bets are off, but I guess I was assuming we (the maintainers/moderators -- not users) would/could definitively ID the signature thumbprint to the publisher's, not just check that it is a trusted chain. I don't know if those thumbprints are public, but if they are at least static, the maintainer could store one with/in the package when they originally build/test the package, and it should only be updated after manual verification of a change (i.e. not automatically).

I was thinking about it as a local thing for maintainers using AU because we can follow up on issues before the repository/moderators need to, and it could help with local repositories since (in my use) those packages are more likely commercial software that will be signed.

[ferventcoder]

@teknowledgist the thumbprint is static. For instance, if you take a look here, you can see what choco.exe's thumbprint is - https://chocolatey.org/security#chocolatey-binaries-and-the-chocolatey-package

[ferventcoder]

Although, this brings up a good point - the thumbprint does change when we update our certificate (which we just did for 0.10.10) - 4BF7DCBC06F6D0BDFA8A0A78DE0EFB62563C4D87 is the thumbprint for it.

[ferventcoder]

Updated just now at https://github.com/chocolatey/choco/wiki/Security#chocolatey-binaries-and-the-chocolatey-package (will be pushed over to the site on next site deploy).