6 ms·

This is a cool tool, I like the idea. But the way `uc machine init` works under the hood is really scary. Lot's of `curl | bash` run as root. While I would lov

by tex0 10mo ago

This is a cool tool, I like the idea. But the way `uc machine init` works under the hood is really scary. Lot's of `curl | bash` run as root. While I would love to test this tool, this is not something I would run on any machine :/

redrove 10mo ago
+1 on this I wanted to try it out but was put off by this[0]. It’s just straight up curl | bash as root from raw.githubusercontent.com. If this is the install process for a server (and not just for the CLI) I don’t want to think about security in general for the product. Sorry, I really wanted to like this, but pass. [0] https://github.com/psviderski/uncloud/blob/ebd4622592bcecedbc51ad653513d91f43ef124e/internal/cli/machine.go#L45 https://github.com/psviderski/uncloud/blob/ebd4622592bcecedb...
psviderski 10mo ago
Totally valid concern. That was a shortcut to iterate quickly in early development. It’s time to do it properly now. Appreciate the feedback. This is exactly the kind of thing I need to hear before more people try it.
tontony 10mo ago
Curious, what would be an ideal (secure) approach for you to install this (or similar) tool?
- rovr138 10mo ago
  It's deploying a script, which then downloads uncloud using curl. The alternative is, deploying the script and with it have the uncloud files it needs.
- yabones 10mo ago
  The correct way would be to publish packages on a proper registry/repository and install them with a package manager. For example, create a 3rd party Debian repository, and import the config & signing key on install. It's more work, sure, but it's been the best practice for decades and I don't see that changing any time soon.
  - tontony 10mo ago
    Sure, but it all boils down to trust at the end of the day. Why would you trust a third-party Debian repository (that e.g. has a different user namespace and no identity linking to GitHub) more than running something from evidently the same user from GitHub, in this specific case? I'm not arguing that a repository is nice because versioning, signing, version yanking, etc, and I do agree that the process should be more transparent and verifiable for people who care about it.
jabr 10mo ago
There is a `--no-install` flag on both `uc machine init` and `uc machine add` that skips that `curl | bash` install step. You need to prepare the machine some other way first then, but it's just installing docker and the uncloud service. I use the `--no-install` option with my own cluster, as I have my own pre-provisioning process that includes some additional setup beyond the docker/uncloud elements.

by tex0 10mo ago

redrove 10mo ago

+1 on this I wanted to try it out but was put off by this[0]. It’s just straight up curl | bash as root from raw.githubusercontent.com. If this is the install process for a server (and not just for the CLI) I don’t want to think about security in general for the product. Sorry, I really wanted to like this, but pass. [0] https://github.com/psviderski/uncloud/blob/ebd4622592bcecedbc51ad653513d91f43ef124e/internal/cli/machine.go#L45 https://github.com/psviderski/uncloud/blob/ebd4622592bcecedb...

psviderski 10mo ago

Totally valid concern. That was a shortcut to iterate quickly in early development. It’s time to do it properly now. Appreciate the feedback. This is exactly the kind of thing I need to hear before more people try it.

tontony 10mo ago

Curious, what would be an ideal (secure) approach for you to install this (or similar) tool?

rovr138 10mo ago
It's deploying a script, which then downloads uncloud using curl. The alternative is, deploying the script and with it have the uncloud files it needs.
yabones 10mo ago
The correct way would be to publish packages on a proper registry/repository and install them with a package manager. For example, create a 3rd party Debian repository, and import the config & signing key on install. It's more work, sure, but it's been the best practice for decades and I don't see that changing any time soon.
- tontony 10mo ago
  Sure, but it all boils down to trust at the end of the day. Why would you trust a third-party Debian repository (that e.g. has a different user namespace and no identity linking to GitHub) more than running something from evidently the same user from GitHub, in this specific case? I'm not arguing that a repository is nice because versioning, signing, version yanking, etc, and I do agree that the process should be more transparent and verifiable for people who care about it.

jabr 10mo ago

There is a `--no-install` flag on both `uc machine init` and `uc machine add` that skips that `curl | bash` install step. You need to prepare the machine some other way first then, but it's just installing docker and the uncloud service. I use the `--no-install` option with my own cluster, as I have my own pre-provisioning process that includes some additional setup beyond the docker/uncloud elements.