Cura: Retail Builds of Cura are not digitally signed

[seanmcne]

When installing Cura I'm prompted with a dialog stating the software is not digitally signed and may not be safe.

[Ghostkeeper]

Oh, but we do sign them! Could some second person with a Windows 10 computer perhaps test this using the 2.5 release?

[seanmcne]

Here is the MD5 of a download from last week from the ultimaker website and the hash is identical to a file I just downloaded from the site here: https://software.ultimaker.com/?show=

Get-FileHash -Algorithm MD5 -Path '.\Cura-2.5.0-win64 (1).exe'
Algorithm       Hash                                                              
---------       ----                                                                   
MD5             25C400B63E6CD9DA41E02D41B9160DDA

And a double check with get-authenticodeSignature outputs:
``` powershell
Get-AuthenticodeSignature -FilePath '.Cura-2.5.0-win64 (1).exe' -Verbose
Directory: C:Users***Downloads
SignerCertificate Status Path
----------------- ------ ----
NotSigned Cura-2.5.0-win64 (1).exe
````

[seanmcne]

And I just tested 2.1.2 x64 & Cura-2.3.1-win32.exe both result in: "NotSigned" after downloading from the above site via Chrome.

[Ghostkeeper]

I think we started signing the Windows and OSX builds from 2.4 onwards. The Linux builds were signed from whenever we started with that AppImage distribution method.

[nallath]

It is weird that our 2.5 (and 2.6) builds are not signed. I guess it's an issue with our build system...

[Ghostkeeper]

Just clarified this. Apparently we've never done this kind of signing. The singing we had was a different kind of signing that was required to get in the Windows Store.

Why there are two kinds of signing with Microsoft, I wouldn't know.

[seanmcne]

Looking at this a bit more this morning - the installation exe isn't signed nor is cura.exe. When your installation is packaged for the MSFT store the appx is signed with the files in it but its done differently as it's distribution is via the store submission process. Once submitted, the appx/package will undergo certification from Microsoft and then it's made available via the store where windows/Microsoft handles the installation process. The signing that's done for windows store applies to all files in the appx as it's installed/managed by the store and by MSFT (this type of verification will apply to files that don't natively support code signing and allow those files be verified when housed in an appx).

Regarding the .exe installations and typical code signing, the installer and resulting cura.exe aren't code signed with a cert from a public CA (such as: https://www.digicert.com/code-signing/support/). The cert obtained from a verified CA would apply not only to Windows but also to packages built for other platforms such as Adobe, Java, and Apple. Some more info for reference: https://en.wikipedia.org/wiki/Code_signing

A little more context: since Cura is provided as part of a commercial product I was just concerned when windows warned about the app not being signed. My expectation was that you'd probably use code signing to ensure there's no tampering with the installer package and your executable files distributed. It's not the end of the world and by having it available in the store that's a great way to ensure the user is getting the files you built as they were intended to be received.

It's possible that since the audience for this app is primarily tinkerers who may not care if the app is digitally signed or may be comfortable with clicking through and not knowing if the package is provided exactly as it was built or if it's been modified. Personally, I feel there's piece of mind when installing an app that's been digitally signed from a certificate authority. In this case that authority has verified you are who you say you are but it also prevents any modifications to those files after they've been signed (meaning if your install exe was signed nobody could patch or modify anything in that file without re-signing it with your private key).

[Ghostkeeper]

I think tinkerers care more about security and transparency (and therefore open source) than the average Joe, and therefore also care more about signing :wink:

I have a question. Not that it's really doable to reproduce a 100% equivalent binary, since the build process for Cura is so involved... But do you happen to know how signing with a private key influences the reproducibility of binaries? You'd need a private key to build it, after all.

In any case, I'm making an issue for this in our internal tracker so that perhaps it can get done some day. I think €178 a year is disposable for Ultimaker if it means that our users get fewer warnings about security when installing or opening Cura.

[seanmcne]

Thanks for the prompt replies! I've used a cert to sign powershell scripts as well as .NET assemblies in the past but haven't used the tooling for native code projects. Additionally, it's usually pretty common to have debug builds and potentially pre-releases not undergo code signing. As far as comparing two identical builds that have each been code signed - it seems like that would work but I'd defer to testing. Here's an article with some of the tools that allow you to create test certs and sign assemblies: https://msdn.microsoft.com/en-us/library/ms537364(v=vs.85).aspx

[ianpaschal]

@LipuFei this is no longer an issue, correct?

[LipuFei]

@ianpaschal No longer an issue. The installers are now signed.

[seanmcne]

Excellent, thanks for doing this!