Regardless of what their README says, the current trunk has tons of bugs fixed. The release version does not work for me at all, but the trunk does.

Switched release version to v1.2, https download and virtualenv Python package management.

Really need a good release engineer to come clean this up. Been a little busy with comma.ai :)

I'd be interested to see how this compares to gdb record (full and bts), been using that a bit lately

What QIRA is to GDB is what IDA is to objdump. The goal is to dramatically increase debugging productivity using a modern UI.

How about rr? // http://rr-project.org/

Could you expand on this for someone who isn't familiar with IDA? I'm familiar with GDB and objdump, but since I haven't used IDA, I don't follow your analogy.

There is also https://github.com/BinaryAnalysisPlatform/qira but geohot says 1.0 is better which is why he recommends using his site

That message is outdated, the trunk build is superior ATM. (I removed the message.)

By geohot

Wow. He workwd for Google, Project Zero. 2014. I missed that.

> Install

> Linux required, 64-bit Ubuntu recommended.

> cd ~/ && wget -qO- qira.me/dl | unxz | tar x && cd qira && ./install.sh

uhh... no

Seriously, if you want people to adopt your software, even on their development machines, please offer a safe way to get it.

My "uhh... no" moment was when I got this message after manually installing the dependencies* and runnig gira:

    > WTF you use Firefox?!?
    > Go download a real web browser, like Chrome, and try this again

* qemu, python2, flask, flask-socketio, gevent, libcapstone3 and qiradb (in the project root)

Not sure why this was donvoted. This is a perfectly valid complaint.

The download isn't HTTPS

The archives aren't signed.

And having to start some custom installer script is also not really trustbuilding. (Why can't the program simply stay within its folder?)

There was previously a discussion of related issues here:

https://news.ycombinator.com/item?id=6650987

At the end of the day you've got to trust someone even if you download a signed archive of source code. You can't audit every line.

You have to trust someone. You don't have to trust whoever is currently MitMing your Internet connection because the authors didn't bother to add HTTPS support.

> cd ~/ && ...

So I should clutter my home directory with stuff that may or may not break if I later try to move it somewhere sensible?

> ... && ./install.sh

Then I let it programatically dig its tentacles into who-knows-what, making uninstallation laborious and/or dangerous?

Why not give a hyperlink to some "qira.tar.xz" file, and have it execute from the resulting directory? Such applications are usually easier to package too, making it more likely to appear in repos.

All of this is trivial to figure out from the provided command line. As a matter of fact, I did just that to verify it was possible and it took about 3 mins (which was what one would expect given that command line) to get the file, untar it, and look at the build script and the other build script it references. Since anyone downloading this tool likely wants it, 3 mins is fine.

That second build script includes more non-SSL fun if you feel like playing that game.

What's unsafe about this? You download a tarball, extract it, run an installer, and then you can run the program. If the archive get corrupted on the way, unxz will complain.

If it's about running programs from the internet you haven't code reviewed, then you could just review the sources and the installer before running install.sh?

Is xz compression designed to be as tamper-resistant as encrypted data?

If you're going paranoid mode, do it properly. GP pointed out that you're about to run a program from an unknown. That's a bigger issue than some devil doing MITM or whatnot.

The track record of open source projects being non-malicious is decent, especially if you have a bunch of other people looking at the project, you briefly consider the author's reputation, etc. The track record of random unknown MITMers being non-malicious is much less decent. You vastly increase your attack surface if you download and execute code over HTTP.

I work on the project and until geohot's recent talk this tool was used (afaict) by a small segment of the CTF community and so we were more focused on core development issues. We can appreciate the desire to have a cleaner and safer install experience, so we'll make sure to take a look at that. Hopefully you can reserve your judgment until it's addressed.

I appreciate the reply. It looks like you updated the website to suggest downloading from github, which is a positive step (https, recognizable domain).

At least provide https.