Open xarkes opened 6 years ago
I guess you're meaning a code signing certificate rather than developer GPG signatures?
In this case yes, but I think having developer GPG signature is also a good practice.
There's a good how-to guide for signing Windows binaries here, but someone's gonna have to pony up $$$ for a certificate https://learn.adafruit.com/how-to-sign-windows-drivers-installer/overview
Could we get GPG signatures distributed with the releases first? Authenticode signing feels a bit fluffy.
@wst-ci, That's unrelated. The goal of having a code signature is to allow the debugger on Mac OS to work. GPG signature will require radare2, sdb and capstone between many dependancies, to be signed too.
GPG signature will require radare2, sdb and capstone between many dependancies, to be signed too
Why will it require this? Just get all the devs to create a detached signature for Cutter.zip, Cutter.dmg and Cutter.AppImage?
He means this makes no sense to sign Cutter, while it bundles not signed dependencies.
He means this makes no sense to sign Cutter, while it bundles not signed dependencies.
That's what I meant yes.
Ah right, so you're saying that the Cutter build process pulls-in various unsigned binaries, so signing the final release doesn't provide full integrity verification?
Should we keep this open?
Yes because without signed binaries cutter won't be able to debug on OS X
Should we keep this open?
@ITAYC0HEN Yes please, I'd really like to see a way to verify the integrity of the Cutter downloads, e.g. via detached GPG signatures. For sensitive work, I am unable to use Cutter unless I have assurance of it's integrity.
Hey @jamie-cyc, to be honest I don't really understand your need. As capstone and radare2 versions we use are not signed themselves, I don't really understand the purpose of us signing our binaries (apart for OS X issues with debugging, but that's not our issue right now). You are talking about "verifying the integrity" of the Cutter downloads, so would some hash algorithm like e.g. sha256 that we add to the Release changelog be a solution to you? [EDIT] Also did you consider building Cutter yourself? Could it be an option for you? Thanks :)
Hi @xarkes, thanks for your response.
The fact that some of the included libraries aren't signed/verified could pose an issue for sensitive work, as I'd essentially be running untrusted/unverified code in an environment where integrity is absolutely imperative (e.g. malware analysis work). Is it feasible for the included libraries to be integrity checked too when they're imported, or do the Capstone and R2 projects not make this easy?
Providing hashes in the releases changelog would help a bit, but as they're distributed using the same method as the binaries themselves (GitHub releases), the assurance is severely degraded (as an attacker who could modify the released binaries could also just edit the hashes).
Instead, would it be feasible for you add detached GPG signatures to the releases page, a bit like the KeePassXC project does (as an example).
This lack of integrity assurance is currently a bit a barrier to me using Cutter in secure environments / for sensitive work, so I am hoping that we can find a solution. I understand that since Cutter is open source, these sort of requests would normally be opened up to contributors to implement, however since this is related to the actual packaging/release process, I don't think that anybody who isn't already fully on the Cutter team could really help that much.
In regards to building Cutter myself, that would perhaps help in some cases, however it doesn't necessarily help in assuring that the source code that I am compiling was actually written by the trusted Cutter developers, unless I were to manually code review every line. Reproducible builds could be a project to look at for the future?
Thanks for your help, Jamie
Is there any way to build cutter from sources and auto sign it ? I have been able to follow this procedure for radare2 and debug with it under macOS 10.13. I would be happy to do the same with cutter! https://github.com/radareorg/radare2/blob/master/doc/macos.md
To answer your question, no there is no support implemented as of today :-)
I am not sure if https://www.sigstore.dev/how-it-works might be useful
I am not sure if https://www.sigstore.dev/how-it-works might be useful
It would help to sign the artifacts just to assure users that the artifacts comes from us and not from someone else (e.g. even if someone has access to rizin github account they could not upload a new release of rizin that is signed by "us"). However, it would not be a "code signing" feature like authenticode or MacOS alternative.
IOW sigstore would be an alternative to us manually signing with GPG the artifacts, from what I understand.
Seems GPG is easier and more common then: https://wiki.debian.org/Creating%20signed%20GitHub%20releases
sigstore does not have the problem of storing/sharing keys though, as it just requires you to have a Google account, AFAIK. I did not dig too much into it.
Find a way to sign our release binaries That will be useful for the debugger for macOS.