Comment by arghwhat
2 years ago
The convenience of such a tool is great, but it's also ~5000 lines of bash across the two main scripts.
I'd want to vet such a thing before I run it, but I also really don't want to read 5000 lines of bash.
2 years ago
The convenience of such a tool is great, but it's also ~5000 lines of bash across the two main scripts.
I'd want to vet such a thing before I run it, but I also really don't want to read 5000 lines of bash.
While I agree in general that shell script is not usually fun to read, this particular code is really not bad.
Not sure if this will sway you, but for what it's worth, I did read the bash script before running it, and it's actually very well-structured. Functionality is nicely broken into functions, variables are sensibly named, there are some helpful comments, there is no crazy control flow or indirection, and there is minimal use of esoteric commands. Overall this repo contains some of the most readable shell scripts I've seen.
Reflecting on what these scripts actually do, it makes sense that the code is fairly straightforward. At its core it really just wants to run one command: the one to start QEMU. All of the other code is checking out the local system for whether to set certain arguments to that one command, and maybe downloading some files if necessary.
I do see that it is better structured, but as any other bash script it relies heavily on global variables.
For example, `--delete-vm` is effectively `rm -rf $(dirname ${disk_img})`, but the function takes no arguments. It's getting the folder name from the global variable `$VMDIR`, which is set by the handling of the `--vm` option (another global variable named $VM) to `$(dirname ${disk_img})`, which in turn relies on sourcing a script named `$VM`.
First, when it works, it'll `rm -rf` the parent path of the VMs disk_img variable is set to, irrespective of whether it exists or is valid as dirname doesn't check that - it just tries to snip the end of the string. Enter an arbitrary string, and you'll `rm -rf` your current working directory as `dirname` just return ".".
Second, it does not handle relative paths. If you you pass `--vm somedir/name` with `disk_img` just set to the relative file name, it will not resolve`$VMDIR` relative to "somedir"- `dirname` will return ".", resulting in your current working directory being wiped rather than the VM directory.
Third, you're relying on the flow of global variables across several code paths in a huge bash script, not to mention global variables from a sourced bash script that could accidentally mess up quickemu's state, to protect you against even more broken rm -rf behavior. This is fragile and easily messed up by future changes.
The core functionality of just piecing together a qemu instantiation is an entirely fine and safe use of bash, and the script is well-organized for a bash script... But all the extra functionality makes this convoluted, fragile, and one bug away from rm -rf'ing your home folder.
Why is it different from any other software just because it is a shell script? Do you read the kernel sources for your OS before running it? Your web browser? My point is not that we should blindly run things, but that we all have criteria for what software we choose to run that typically doesn't rely on being familiar with its source code.
Well, yes, I read code of (and contribute to) the kernel and web browsers I use, but that's not really relevant.
There's a big difference between "large, structured projects developed by thousands of companies with a clear goal" vs. "humongous shell script by small group that downloads and runs random things from the internet without proper validation".
And my own personal opinion: The venn diagram of "Projects that have trustworthy design and security practices", and "projects that are based on multi-thousand line bash scripts" is two circles, each on their own distinct piece of paper.
(Not trying to be mean to the developers - we all had to build our toolkits from somewhere.)
Heh, this reminds me a bit of when on live television Contessa Brewer tried to dismiss Mo Brooks with "well do you have an economics degree?" and he actually did and responded with "Yes ma'am I do, highest honors" :-D [1]
I have no problem with (and have written a few) giant bash scripts, and I completely agree with you. A giant bash script isn't going to have many eyes on it, whereas a huge project like the kernel is going to get a ton of scrutiny.
[1] https://www.youtube.com/watch?v=5mtQyEd-zS4
I believe GP implicitly assumes that bash (and generally POSIX-y shell script) has lots of quirks and footguns (to which I generally agree).
After skimming through the source code though, I'd say the concerns are probably overstated.
Probably going to catch some flack for this comment but... if you are that concerned with it, and have some free time, you could always use chatgpt to talk about the code. A prompt could be: "You are a linux guru, and you have extensive experience with bash and all forms of unix/linux. I am going to be pasting a large amount of code in a little bit at a time. Every time I paste code and send it to you, you are going to add it to the previous code and ask me if I am done. When I am done we are going to talk about the code, and you are going to help me break it down and understand what is going on. If you understand you will ask me to start sending code, otherwise ask me any questions before you ask for the code." I have used this method before for some shorter code (sub 1000 lines, but still longer than the prompt allows) and it works pretty well. I will admit that ChatGPT has been lazy of late, and sometimes I have to specifically tell it not to be lazy and give me the full output I am asking for, but overall it does a pretty decent job of explaining code to me.
I'd say this is a general issue with software, most generally how and what you do to establish trust, what expectations/responsibilities there are of a developer and user. The "many eyes make all bugs shallow" phrase does seem to be a little bit of a thought terminating cliché for some users, if it's open to scrutiny then it must be fine, conjuring an image of roaming packs of code auditors to inspect everything (I'd expect them more on the malicious side rather than benevolent)
Over for windows, there's been a constant presence of tweak utilities for decades that attract people trying to get everything out of their system on the assumption that 'big corp' developers don't have the motivation to do so and leave easy options on the table behind quick config or registry tweaks that are universally useful. One that comes to mind which I see occasionally is TronScript which if I had to bet on it passes the 'sniff test' with its history and participation I'd say it's good, but presents itself as automation, abstracting away the details and hoping they make good decisions on your behalf. While you could dig into it and research/educate yourself on what is happening and why, for many it might as well be a binary.
I think only saving grace for this is that most of these tools have a limited audience, so they're not worth compromising. When one brand does become used often enough you may get situations like CCleaner from piriform that was backdoored in 2017.
Googled that, found the GitHub with a <h1> of
> DO NOT DOWNLOAD TRON FROM GITHUB, IT WILL NOT WORK!! YOU NEED THE ENTIRE PACKAGE FROM r/TronScript
I see later it mentions you can check some signed checksums but that doesn't inspire confidence. Very much epitomises the state of Windows tweaky utilities vs stuff you see on other platforms.