Pencil: Add code signature (Mac OS)

[apizz]

Issue Summary

Currently, the Pencil2D app is not code signed at all. This would be valuable to ensure it hasn't been modified by bad actors.

Actual Results

When I run codesign -dr- /path/to/Pencil2D.app it says not signed at all.

Expected Results

A valid codesignature

System Information

• Pencil2D Version: 0.6.4

• Operating System: macOS 10.14.6

• RAM Size: N/A

• Graphics Tablet: N/A

[CandyFace]

A self signed code-signature could be made, however it won't be "valid" In the same way that it would be if Apple code-signed it, so there's no benefit except seeing it's signed.

To codesign it properly (ie. remove gatekeeper) would require apple developer membership that is paid annually + we'd have to go through the Apple's review process and the like.

Since our organisation is non-profit, I don't see this happening any time soon. if ever.

[apizz]

@CandyFace for my purposes, that would be OK. One of our teachers uses this with his students and I use https://github.com/autopkg/autopkg to auto download and bring these into our environment for deployment. The codesignature would be to make sure what ultimately gets downloaded is what we expect to receive before it gets distributed.

[apizz]

Thanks, all!

[apizz]

Any updates here?

[Jose-Moreno]

@apizz Hey. Unfortunately no. The thing is, we don't have an incorporated entity (nor the requried budget) to register the appropriate developer account in order to get either Windows nor macOS signed apps.

We understand this is actually a necessity with the latest security protocol modifications, such as notarization in macOSX "Catalina".

What I personally believe, and this might not be shared by the Pencil2D team, is that once Pencil2D reaches 1.0 it will stop being considered a "beta" version, and only then we can try to find a way to sign the app.

Right now due to all the critical issues Pencil2D faces we really can't consider finding a third party to sign Pencil2D until we're sure the app is rock solid and stable for modern systems. This is also the same reasoning why we don't ask for donations or money of any kind to our users, despite the major benefits this could bring.

Note that I'm not saying this won't happen, but I'm saying that this will likely happen after a long time. If this is a pain point for you, I'm honestly extremely sorry, but with the development fees and requirements for app signing there's little we can do to improve this until the application "just works"

I'd like to hear what @pencil2d/developers have to say about this, or if someone else has an alternate proposal to improve on these issues which surely affect regular users due to aggressive security protocols implemented during the last year for proprietary OS.

[J5lx]

I don’t see any easy way to solve the issues with actual macOS code signing, but if @apizz’s main concern is verifying that what they download is what they expect to receive, we could probably sign our releases with PGP for the time being. That won’t help with Apple’s security protocols, but it would allow @apizz and other users to verify that the downloads haven’t been tampered with since we released them – not just the macOS builds, but also the Linux and Windows builds and potentially source tarballs.

[apizz]

^^ That's all I'm looking for. Because we're using management tools to deploy the software, it's more needing to verify the software when we download it.

[davidlamhauge]

I agree that we currently can't afford to sign our code, but the above sounds like a good, preliminary solution.
I wouldn't know how to do it, but if it is fairly simple to sign our releases with PGP, I'll suggest that we do that from now.
Is it so easy to do, that the nightly builds can be signed to?

[apizz]

I'm not familiar with the process of signing w/ PGP and how that differs from using a certificate, but as long as when you run codesign on the app itself you get some output that can be compared against that's 🆗. In autopkg I just specify the code signature I'm expecting and so long as it matches it imports into our software distribution mechanism.

Below is a third-party app called Daisy Disk. Granted, they are using an Apple Dev cert, but it illustrates the point.

codesign -dr- /Applications/DaisyDisk.app
Executable=/Applications/DaisyDisk.app/Contents/MacOS/DaisyDisk
designated => anchor apple generic and identifier "com.daisydiskapp.DaisyDiskStandAlone" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "4CBU3JHV97")

[scribblemaniac]

I'm not against GPG/PGP signing, after all we're already using it to validate some of our dependencies so it probably would not be too much more work to sign the binaries. However, none of this is really necessary for what you want @apizz. If all you need to do is verify the download hasn't changed and has downloaded correctly, compare the checksum of the downloaded file to a known good checksum. If you don't trust your own download of the program, you can use the checksum from Homebrew Cask which should be considered semi-official since we help maintain it. If you are worried about malicious modifications, the only companies that are in a position to do such a thing for the macOS builds are Travis and GitHub. If we were to sign our automated builds, they would both have access to the private keys so it would not be much more secure than not signing it at all.

[apizz]

The code signature shouldn't change across builds, so that's one thing to know and check on each release. Always wary of checksums because should any website become compromised the bad actors can change the download and the checksum. The whole purpose of the code signature is it can't be faked without the private key.

[J5lx]

@davidlamhauge It’s possible, but if you’re talking about automatic signatures, I’ll have to second scribblemaniac. In addition, the existence of a (valid) PGP signature could potentially make the builds appear more trustworthy than they actually are, creating an illusion of security. If you’re talking about manual signatures on the other hand, it would depend mainly on how much effort Matt is willing to spend on the builds.

@scribblemaniac I agree with @apizz here. Checksums do have their purpose, but we’re talking about a surrogate for code signatures here, and I believe PGP is better suited to that. You’re also forgetting that releases can be tampered with not only by Travis and GitHub, but by anyone with write access to the repo – or anyone who can obtain access to the account of such a person.

[scribblemaniac]

The whole purpose of the code signature is it can't be faked without the private key.

Which is why it's pointless when we need to upload our private key to Travis (which GitHub has access to) to sign the automated builds. The code signature can also be faked by providing a different public key to validate against.

Always wary of checksums because should any website become compromised the bad actors can change the download and the checksum.

Yes of course, but a) they can't change the checksum after you've put it in your script. b) these same bad actors can also use our private key as I already mentioned, or they can change the public key to their own key just as easily as changing the checksum. The advantage of a code signature over a checksum is that ideally we use the same key to sign all the builds so it would remain consistent between releases as I think you were trying to say, which is valid, but not always desired as I will elaborate on below.

You’re also forgetting that releases can be tampered with not only by Travis and GitHub, but by anyone with write access to the repo

I did not forget, but I'll admit I was simplifying things. You have to trust people with write access to to repository. If you don't then go build your own animation application from scratch. And even then you have to trust the compiler, and the libraries, and the operating system, and the hardware used to make and run your program, so go build all of those things from scratch too :wink:

If someone wanted to make a malicious download, they could either modify an existing release, modify the source code, or create a new release. Modifying the source code would be immediately noticeable to us with git, and would affect nightly builds until we address the issue. Modifying an existing release would also be very visible since Homebrew Cask users would start reporting issues with the checksum. Creating a new release would not have this issue but would be even more noticeable as it sends an email to everyone watching the repository. In all cases, a code signing could be faked if the attacker has access to the private key, but the attacker cannot create the same checksum (at least with any modern hashing algorithm). So the point I'm trying to make here is that a checksum, while more work from a maintenance perspective, has it's own value because if a download is tampered with, you can check on our various communication channels to see what's up instead of blindly downloading the new/modified version if the attacker correctly signs it. Code signing is good for verifying releases initially, among other things, but it can't be viewed as some catch-all solution.

[J5lx]

Going through this thread again, I’m starting to wonder why we even argued about this. I think I might have kicked that off by taking this comment of yours a little to seriously – sorry about that! Back then you said you were not opposed to to PGP signing, @scribblemaniac, so with @apizz’s and my comments taken into account as well, don’t we actually have a quasi-consesus among the three of us that PGP signatures are preferable, but checksums would still allow for basic integrity checking?

Edit: And also that signatures for nightly builds are pointless.