Hacker News Reader

Comment by sjburt | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com