Thread

Fakecloud: Local AWS cloud emulator for integration tests

154 points · 78 comments · theanonymousone

otterley · 1790521883 · focus · HN ↗
There’s also MiniStack, which forked from LocalStack after they started breaking developer workflows: <a href="https://ministack.org/" rel="nofollow">https://ministack.org/
Both fakecloud and its website look sloppily vibe-coded, and its “authors” are anonymous. It’s going to take a while for it to earn trust. I’d treat it with suspicion. (Curl-to-shell pipe to install? Ugh.)
1. straygarr · 1790522617 · focus · HN ↗
  Agreed with everything up to:
  "curl-to-shell pipe to install" - what's the problem here? that's pretty common on linux systems and something the AWS CLI uses.
  Or is the problem the fact that this dev is untrusted and is executing a possibly malicious script on your machine?
  1. MisterMunchkin · 1790523114 · focus · HN ↗
    Running arbitrary code directly in your terminal is very dangerous
    luma · 1790526881 · focus · HN ↗
    Any code I didn't write is arbitrary code. At some point I'm left to trust someone or run no software at all.
    mulmen · 1790527183 · focus · HN ↗
    It’s a shell script. You can download and read it before you run it. Piping it directly to the shell is reckless.
    I’m not sure how your machine is configured but mine has permission boundaries and security policies that make sure programs are behaving properly. I don’t run everything with my personal user context.
    mynameisvlad · 1790531175 · focus · HN ↗
    So then... Just do that and it's no longer reckless.
    If someone wants to be reckless they can be. If someone doesn't, they also have that ability.
    bornfreddy · 1790531627 · focus · HN ↗
    Actually... Server can detect if you are piping or not and serve a modified version for inspection.
    But really, there is no reason not to use prebuilt packages for distribution. Curlpiping needs to die.
    [deleted] · 1790532481 · focus · HN ↗
    [deleted]
    otterley · 1790533270 · focus · HN ↗
    At first I thought “this sounds like bullshit” but then found <a href="https://web.archive.org/web/20230408195648/https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side" rel="nofollow">https://web.archive.org/web/20230408195648/https://www.idont...
    [deleted] · 1790547629 · focus · HN ↗
    [deleted]
    mulmen · 1790553145 · focus · HN ↗
    Package distribution is the best solution but why would you download the install script a second time?
    john01dav · 1790554411 · focus · HN ↗
    If you're about to install an upstream binary with this and you're not reviewing this then it's purely (irrational) vibes to be concerned with the also unreviewed shell script from the same source.
    NewJazz · 1790564526 · focus · HN ↗
    Yeah but at least with a binary you can verify the checksum of a recent official immutable github release rathrr than just trust a script hosted on the website.
    darkwater · 1790581060 · focus · HN ↗
    If you don't really trust the author, what's a checksum going to provide you? That the maybe malicious code released on GH has not been tampered with? Not so helpful.
    NewJazz · 1790608400 · focus · HN ↗
    In the case I described you are trusting the developer at least a bit. But you aren't trusting them to keep their website secure.
    Furthermore, you can be sure that theversion that you download is the same version it has always been and it is the same version everyone else sees. Curl|bash can mean getting a version of the code that is different from everybody else.
  2. sdcfgy · 1790524530 · focus · HN ↗
    I'm worried that this behaviour has to be defended.
  3. jasongi · 1790524639 · focus · HN ↗
    For a mock server? Surely a versioned, standalone executable, library/package or docker image makes more sense. Integration tests generally need to be portable and running on CI, you don't wanna be shell-piping whatever exists in the moment.
  4. x3n0ph3n3 · 1790528279 · focus · HN ↗
    curl-to-shell is a terrible installation mechanism because it's not easily reversible and I can't tell if any of the assets are signed, or integrity checked, or not.
  5. ssl-3 · 1790531353 · focus · HN ↗
    The problem, for me, is that self-running installers can create a mess that's hard to keep track of.
    I've run Linux without meaningful package management, as that was kind of the style of the time 30 years ago with Slackware. It can quickly become untenable.
    There's no real difference between an uninspected script that gets piped straight from the URL into the shell, or a similarly-uninspected make&&sudo make install routine from a tarball. They can both execute code that does bad things (whether unintentionally or deliberately), and they can both leave a mess that is hard to cleaned up.
    I've found that it is better to just avoid going down that road to begin with. Whether distro-specific packages, Docker containers, flatpaks, or whatever: All of these make housekeeping easier.
    giantrobot · 1790561914 · focus · HN ↗
    > The problem, for me, is that self-running installers can create a mess that's hard to keep track of.
    For reasons my machine with a beefy GPU is stuck on an older set of Nvidia drivers. I've got them pinned with apt. The ollama installer fucked everything up by updating stuff that apparently wasn't pinned. After I had fun cleaning up that fucking mess I found it overwrote my custom systemd service file so I had to go in and fix that.
    Curl-to-shell is a bullshit antipattern. I have no interest in going back to the dark days of expanding tarballs to / and hoping for the best.
    ssl-3 · 1790600299 · focus · HN ↗
    Right. I've done the same.
    And when the new distro-provided nVidia driver does something garish like, say, break XFCE, then it's easy(ish) to roll it back using distro tools and pin it there. After that, just wait until some other more-functional combination of shakes loose in the distro channel.
    When a new nVidia driver shows up that promises a fix but the distro hasn't packaged it yet, then the temptation to just download and run the installer that's on nVidia's website. But using nVidia's special-sauce installer taints the system in ways that distro tools deliberately seek to avoid.
    And: Oh, man. I'd almost forgotten about the binary tarballs that were intended to be simply dumped into /, where they'd just tromp on whatever. Sure, it was fast. And for some people, some times, it even worked. Sometimes, it didn't work. Other times, it broke other things that had been working. And it left a mess behind every single time.
    A little bit of a mess isn't necessarily devastating on a personal system. But the mess accumulates every time such an unmanaged installation process happens until it eventually overwhelms to the point that even the most functionally-disorganized of people become dysfunctional.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.