search

radareorg / radare2

UNIX-like reverse engineering framework and command-line toolset
https://www.radare.org/
GNU Lesser General Public License v3.0
20.52k stars 2.99k forks source link

Signed Releases #3822

Closed Manouchehri closed 8 years ago

Manouchehri commented 8 years ago

As far as I can tell, radare2 on w32 hasn't been signed, which results in lots of scary popups from Windows and sometimes a false AV positive.

If @trufae is okay with it, I can sign 0.9.9 and future Windows' releases myself (I don't mind paying for the certificate). This task can be assigned to me, just reopen it if there's a new release that I haven't signed.

Reference: #2165

Maijin commented 8 years ago

Installer should be fixed prior to that imho ping @XVilka

Manouchehri commented 8 years ago

What's wrong with the installer? Issue #?

Either way, signing probably won't hurt. I'd do it right now, but I don't have my HSM yet.

XVilka commented 8 years ago

installer is OK, and fixed. The only problem is failing shell script during the build for Mingw32 https://ci.appveyor.com/project/radare/radare2-shvdd/build/0.10.0.2839#L2837

gcc -c  -MD    -g -Wall -DMINGW32=1 -DCORELIB -Iarch -IC:/projects/radare2-shvdd/libr/..//shlr -I../../shlr/capstone/include -I../../../shlr/capstone/include -I../asm/arch/8051 -I../asm/arch/include -I../asm/arch/cr16/ -I../asm/arch/ebc/ -I arch/gb/ -I../asm/arch/h8300/ -I../asm/arch/msp430/ -I../asm/arch/v810/ -I../asm/arch/v850/ -I../asm/arch/x86/udis86 -I../../asm/arch/x86/udis86 -DHAVE_STRING_H=1 -IC:/projects/radare2-shvdd/libr/include -o pin.o pin.c
/usr/bin/sh: -c: line 8: unexpected EOF while looking for matching `"'
/usr/bin/sh: -c: line 9: syntax error: unexpected end of file
C:/projects/radare2-shvdd/libr/..//libr/rules.mk:58: recipe for target 'libr_anal.dll' failed
mingw32-make[3]: *** [libr_anal.dll] Error 258
mingw32-make[3]: Leaving directory 'C:/projects/radare2-shvdd/libr/anal'
Makefile:63: recipe for target 'anal' failed
mingw32-make[2]: *** [anal] Error 2
mingw32-make[2]: Leaving directory 'C:/projects/radare2-shvdd/libr'
Makefile:28: recipe for target 'all' failed
mingw32-make[1]: *** [all] Error 2
mingw32-make[1]: Leaving directory 'C:/projects/radare2-shvdd/libr'
Makefile:27: recipe for target 'all' failed
mingw32-make: *** [all] Error
trufae commented 8 years ago

This error only happens on native windows builds. Maybe with make -n we can see what is suposed to be executed in there and why it fails.

On Thu, Dec 10, 2015 at 11:00 AM, Anton Kochkov notifications@github.com wrote:

installer is OK, and fixed. The only problem is failing shell script during the build for Mingw32 https://ci.appveyor.com/project/radare/radare2-shvdd/build/0.10.0.2839#L2837

gcc -c -MD -g -Wall -DMINGW32=1 -DCORELIB -Iarch -IC:/projects/radare2-shvdd/libr/..//shlr -I../../shlr/capstone/include -I../../../shlr/capstone/include -I../asm/arch/8051 -I../asm/arch/include -I../asm/arch/cr16/ -I../asm/arch/ebc/ -I arch/gb/ -I../asm/arch/h8300/ -I../asm/arch/msp430/ -I../asm/arch/v810/ -I../asm/arch/v850/ -I../asm/arch/x86/udis86 -I../../asm/arch/x86/udis86 -DHAVE_STRING_H=1 -IC:/projects/radare2-shvdd/libr/include -o pin.o pin.c /usr/bin/sh: -c: line 8: unexpected EOF while looking for matching `"' /usr/bin/sh: -c: line 9: syntax error: unexpected end of file C:/projects/radare2-shvdd/libr/..//libr/rules.mk:58: recipe for target 'libr_anal.dll' failed mingw32-make[3]: * [libr_anal.dll] Error 258 mingw32-make[3]: Leaving directory 'C:/projects/radare2-shvdd/libr/anal' Makefile:63: recipe for target 'anal' failed mingw32-make[2]: * [anal] Error 2 mingw32-make[2]: Leaving directory 'C:/projects/radare2-shvdd/libr' Makefile:28: recipe for target 'all' failed mingw32-make[1]: * [all] Error 2 mingw32-make[1]: Leaving directory 'C:/projects/radare2-shvdd/libr' Makefile:27: recipe for target 'all' failed mingw32-make: * [all] Error

— Reply to this email directly or view it on GitHub https://github.com/radare/radare2/issues/3822#issuecomment-163561985.

trufae commented 8 years ago

How much does a windows code signing certificate costs? can we sign it in the build farm directly from linux?

On Thu, Dec 10, 2015 at 11:29 AM, Àlvarez, Sergi salvarez@nowsecure.com wrote:

This error only happens on native windows builds. Maybe with make -n we can see what is suposed to be executed in there and why it fails.

On Thu, Dec 10, 2015 at 11:00 AM, Anton Kochkov notifications@github.com wrote:

installer is OK, and fixed. The only problem is failing shell script during the build for Mingw32 https://ci.appveyor.com/project/radare/radare2-shvdd/build/0.10.0.2839#L2837

gcc -c -MD -g -Wall -DMINGW32=1 -DCORELIB -Iarch -IC:/projects/radare2-shvdd/libr/..//shlr -I../../shlr/capstone/include -I../../../shlr/capstone/include -I../asm/arch/8051 -I../asm/arch/include -I../asm/arch/cr16/ -I../asm/arch/ebc/ -I arch/gb/ -I../asm/arch/h8300/ -I../asm/arch/msp430/ -I../asm/arch/v810/ -I../asm/arch/v850/ -I../asm/arch/x86/udis86 -I../../asm/arch/x86/udis86 -DHAVE_STRING_H=1 -IC:/projects/radare2-shvdd/libr/include -o pin.o pin.c /usr/bin/sh: -c: line 8: unexpected EOF while looking for matching `"' /usr/bin/sh: -c: line 9: syntax error: unexpected end of file C:/projects/radare2-shvdd/libr/..//libr/rules.mk:58: recipe for target 'libr_anal.dll' failed mingw32-make[3]: * [libr_anal.dll] Error 258 mingw32-make[3]: Leaving directory 'C:/projects/radare2-shvdd/libr/anal' Makefile:63: recipe for target 'anal' failed mingw32-make[2]: * [anal] Error 2 mingw32-make[2]: Leaving directory 'C:/projects/radare2-shvdd/libr' Makefile:28: recipe for target 'all' failed mingw32-make[1]: * [all] Error 2 mingw32-make[1]: Leaving directory 'C:/projects/radare2-shvdd/libr' Makefile:27: recipe for target 'all' failed mingw32-make: * [all] Error

— Reply to this email directly or view it on GitHub https://github.com/radare/radare2/issues/3822#issuecomment-163561985.

Manouchehri commented 8 years ago

Next to nothing ($20-$100), that's why I'm fine with using my own.

I'm not entirely sure if it's a good idea to put code signing on a build server. What would be gained by doing that?

Manouchehri commented 8 years ago

To answer your question properly, yes, you can sign directly from Linux (that's how I would be signing it too).

I'm just not sure if we want to be putting private keys on any system. I don't like the idea of it being attached to an automated process.

Maijin commented 8 years ago

If you don't sign it by CI, then that would need extra manual work, so forget it for each commit release maybe for release? But who's using release, since they get obsolete at the moment they get published :P

Manouchehri commented 8 years ago

What do Windows users usually use? I thought they used the releases.

Manouchehri commented 8 years ago

Are the CI (Windows) binaries being uploaded anywhere to begin with? I thought everyone was still expected to build from source if they weren't using the releases or Docker Hub.

XVilka commented 8 years ago

@Manouchehri yes, they'll appear here https://ci.appveyor.com/project/radare/radare2-shvdd/build/0.10.0.2839/artifacts When mingw32 build will be fixed

Manouchehri commented 8 years ago

Oh, didn't know we switched to Appveyor. Okay, I can work with that then.

@trufae I'll buy the certificate, encrypt it and send it to you.

Once the mingw32 build is fixed, I'll make a PR to test it out with a self signed certificate. If all goes well, then we can switch to the real one.

Manouchehri commented 8 years ago

After reading a bit more, I think I can set up a HSM and get Appveyor to send me an automated signing request on each build. That way we don't have to risk putting keys inside the build process.

Give me a few days to figure some more things out and I'll ping you when it's ready.

trufae commented 8 years ago

@Manouchehri its not a problem of money, r2 already have money from donations and we can spend that money on this kind of stuff, im just worried about the trustfulness of our build farm and a secure way to store and use that certificate.

Manouchehri commented 8 years ago

That's why I'm reading up on setting up a central code signing server that can keep the keys in an HSM.

SignServer looks like it'll fit the bill, but their Authenticode implementation is closed source. I might see if I can extend it myself. I also emailed them to see what the price is like.

Manouchehri commented 8 years ago

Going to close this until I have something working. Looks like it'll be a fun project for me. =)

Zenexer commented 7 years ago

I know I'm about a year late to this conversation, but does it really make sense to combine an HSM with something like Appveyor? You'd be signing-off on strong guarantees that are probably weaker in reality. If you're going to sign something using an HSM, you'd better be pretty damn sure of its integrity. If the build servers aren't as secure as the HSM, or there's any way the integrity of the build could be compromised as it makes its way from the build servers to the machine with the HSM, then isn't the HSM more security theater than anything?

Maijin commented 7 years ago

Isn't Producing working binary on Appveyor prioritary to this -_- ?

trufae commented 7 years ago

The build farm cant be used to generate binary releases. I would not trust those machines. I use local machines for that

On 22 Oct 2016, at 07:21, Paul Buonopane notifications@github.com wrote:

I know I'm about a year late to this conversation, but does it really make sense to combine an HSM with something like Appveyor? You'd be signing-off on strong guarantees that are probably weaker in reality. If you're going to sign something using an HSM, you'd better be pretty damn sure of its integrity. If the build servers aren't as secure as the HSM, or there's any way the integrity of the build could be compromised as it makes its way from the build servers to the machine with the HSM, then isn't the HSM more security theater than anything?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.