You would do well to learn by past and current attempts. This book should be enlightenig (and yes, Elektra is very much alive): https://www.libelektra.org/ftp/elektra/publications/raab2017...

Would also be a useful excercice to write a new configuration UI for existing configuration backend(s) (preferably something already in use by some software you're already in want of better configuration for) - even if you do end up aiming at your own standard (xkcd.com/927), it should give you some clarity on ways to approach it.

Why would anyone want a qt frontend when you can call a cli wrapper, or better yet the core binary directly?

Select Hypervisor "Custom URL", and enter: qemu+ssh://root@<host>/system

And Bob's your uncle.

It works great for me! This means it likely won't work for you until you've paid the proper penance to the computer god.

ssh -L 5901:localhost:5901 username@hypervisor

on the hypervisor, start Qemu with -vnc :1

Then open a local VNC client like RealVNC and connect to localhost:1

I just looked at the shell script and it's not "random" at all, it's getting both the checksum and the ISO from the official source over TLS.

The only way this technique is going to fail is if the distro site is compromised, their DNS lapses, or if there's a MITM attack combined with an incorrectly issued certificate. GPG would be more robust but it's hardly like what this tool is doing is some unforgivable failure either.

It's not that the OP is wrong but I think they give a really dire view of what's happening here.

[0] https://www.zdnet.com/article/hacker-hundreds-were-tricked-i...

It's a subtle difference, but the trust-chain could indeed be (mildly) improved by re-distributing the upstream gpg keys.

It might go above and beyond what most people are doing, but not what most tools are doing. Old school package managers are still a step ahead in this area, because they use GPG to check the authenticity of the data files, independent of the transportation channel. A website to download files and checksums is one such channel. This enables supporting multiple transportation channels, then it was a mirror of ftp mirrors. Today, it might be bittorent or ipfs or a CDN. And GPG supports revoking the trust. Checksums that are hardcoded into a tool cannot be revoked.

As soon as we start to codify practices into tools, they become easier to game and attack. Therefore tools should be held to higher security standards than humans.

People who are responding to you with "you are absolutely right" might not represent the silent majority (within our field, not talking about normal users).

GPG signing covers this threat model but much more, the threats include:

* The server runs vulnerable software and is compromised by script-kiddies. They, then, upload arbitrary packages on the server

* The cloud provider is compromised and attackers take over the server from the admin cloud provider account.

* Attacker use a vulnerability (from SSH, HTTPd, ...) to upload arbitrary software packages to the server

GPG doesn't protect against the developer machine getting compromised, but it guarantees that what you're downloading has been issued from the developer's machine.

[0]: https://linux.die.net/man/1/virt-install

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.

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

After skimming through the source code though, I'd say the concerns are probably overstated.

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

Also, give it 128 MB of RAM as a minimum.

Incus/LXD runs containers as normal users (by default) and also confines the whole namespace in apparmor to further isolate containerized processes from the host. Apparmor confinement is also used for VMs (the qemu process cannot access anything that is not defined in the whitelist)

I would really love to have someone prove me wrong on this thread but I've never found a solution other than building on MacOS hardware, which is such a pain to maintain.

I have multiple old MacOS machines that I keep in a stable state just so I can be sure I'll be able to build our app. I'm terrified of failure or just clicking the wrong update button.

``` Only the latest major release of macOS (currently macOS Sonoma) receives patches for all known security vulnerabilities.

The previous two releases receive some security updates, but not for all vulnerabilities known to Apple.

In 2021, Apple fixed a critical privilege escalation vulnerability in macOS Big Sur, but a fix remained unavailable for the previous release, macOS Catalina, for 234 days, until Apple was informed that the vulnerability was being used to infect the computers of people who visited Hong Kong pro-democracy websites. ```