cutter icon indicating copy to clipboard operation
cutter copied to clipboard

Sign binaries

Open xarkes opened this issue 6 years ago • 22 comments

  • [ ] Windows
  • [ ] macOS https://github.com/rizinorg/cutter/issues/3232

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

xarkes avatar Sep 07 '18 18:09 xarkes

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

jamie-cyc avatar Sep 17 '18 11:09 jamie-cyc

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

xarkes avatar Sep 17 '18 12:09 xarkes

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

sajattack avatar Oct 08 '18 03:10 sajattack

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

jamie-cyc avatar Oct 08 '18 08:10 jamie-cyc

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

Maijin avatar Oct 08 '18 08:10 Maijin

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?

jamie-cyc avatar Oct 08 '18 08:10 jamie-cyc

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

xarkes avatar Oct 08 '18 09:10 xarkes

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

That's what I meant yes.

Maijin avatar Oct 08 '18 09:10 Maijin

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?

jamie-cyc avatar Oct 08 '18 09:10 jamie-cyc

Should we keep this open?

ITAYC0HEN avatar Jun 28 '19 11:06 ITAYC0HEN

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

Maijin avatar Jun 29 '19 12:06 Maijin

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.

jamie-cyc avatar Jul 01 '19 10:07 jamie-cyc

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

xarkes avatar Jul 01 '19 12:07 xarkes

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

jamie-cyc avatar Jul 01 '19 13:07 jamie-cyc

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

amrx06 avatar May 01 '20 12:05 amrx06

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

xarkes avatar May 06 '20 06:05 xarkes

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

XVilka avatar Aug 21 '23 10:08 XVilka

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

XVilka avatar Aug 21 '23 10:08 XVilka

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 avatar Aug 21 '23 11:08 ret2libc

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

ret2libc avatar Aug 21 '23 11:08 ret2libc

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

XVilka avatar Aug 23 '23 08:08 XVilka

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.

ret2libc avatar Aug 23 '23 13:08 ret2libc