rizinorg / cutter

Free and Open Source Reverse Engineering Platform powered by rizin
https://cutter.re
GNU General Public License v3.0
15.82k stars 1.15k forks source link

Sign binaries #690

Open xarkes opened 6 years ago

xarkes commented 6 years ago

Find a way to sign our release binaries That will be useful for the debugger for macOS.

jamie-cyc commented 6 years ago

I guess you're meaning a code signing certificate rather than developer GPG signatures?

xarkes commented 6 years ago

In this case yes, but I think having developer GPG signature is also a good practice.

sajattack commented 6 years ago

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

jamie-cyc commented 6 years ago

Could we get GPG signatures distributed with the releases first? Authenticode signing feels a bit fluffy.

Maijin commented 6 years ago

@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.

jamie-cyc commented 6 years ago

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?

xarkes commented 6 years ago

He means this makes no sense to sign Cutter, while it bundles not signed dependencies.

Maijin commented 6 years ago

He means this makes no sense to sign Cutter, while it bundles not signed dependencies.

That's what I meant yes.

jamie-cyc commented 6 years ago

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?

ITAYC0HEN commented 5 years ago

Should we keep this open?

Maijin commented 5 years ago

Yes because without signed binaries cutter won't be able to debug on OS X

jamie-cyc commented 5 years ago

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.

xarkes commented 5 years ago

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 :)

jamie-cyc commented 5 years ago

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

amrx06 commented 4 years ago

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

xarkes commented 4 years ago

To answer your question, no there is no support implemented as of today :-)

XVilka commented 1 year ago

For Windows: https://stackoverflow.com/questions/252226/signing-a-windows-exe-file

XVilka commented 1 year ago

I am not sure if https://www.sigstore.dev/how-it-works might be useful

ret2libc commented 1 year ago

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.

ret2libc commented 1 year ago

IOW sigstore would be an alternative to us manually signing with GPG the artifacts, from what I understand.

XVilka commented 1 year ago

Seems GPG is easier and more common then: https://wiki.debian.org/Creating%20signed%20GitHub%20releases

ret2libc commented 1 year ago

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.