Hacker News Reader

ashishbon The surprisingly complex journey to text-selectable client-side generated PDFs

Software engineers drastically underestimates GUI - Web layouts, mobile app layouts, and even PDF layouts are non-trivial pieces of work to get right in all circumstances.

ashishbon Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library

Always run third party code inside a sandbox

ashishbon Waymo in Portland

> At least 80% of what you’re describing would be satisfied by trains and buses. It’s wild that Americans are so obsessed with self-driving cars while ignoring public transit that solves most of the problems. It’s reliable, more efficient, better for the environment, and less stressful for you.

So, let's say you take public transport from SF to Yosemite/Los Angeles. Now, how do I cover the last mile (or even multiple points)? Take more public transport? Hitchhike?

The reason long-distance public transport works well in Europe is that there is good local public transport in both the source and the destination cities. When that does not exist, you are better off driving.

ashishbon Apple fixes bug that cops used to extract deleted chat messages from iPhones

This has nothing to do with Apple/Firebase notification service.

It has to do with the fact that any notification displayed on your device goes via a separate system service which was caching them.

It is amusing to see how often people confuse device notifications with Apple notification service.

ashishbon Someone bought 30 WordPress plugins and planted a backdoor in all of them

WordPress was great because of the plugins.

WordPress is now a dangerous ecosystem because of the plugins and their current security model.

I moved to Hugo and encourage others to do so - https://ashishb.net/tech/wordpress-to-hugo/

ashishbon Mercor says it was hit by cyberattack tied to compromise LiteLLM

And what are good options that you use and that work on Linux as well as Mac OS?

ashishbon Axios compromised on NPM – Malicious versions drop remote access trojan

What makes you think that? Your can see the commit history <10% of code is written by agents.

Rest was all written by me.

Unlike other criticisms of the project, this one feels personal as it is objectively incorrect.

ashishbon Mercor says it was hit by cyberattack tied to compromise LiteLLM

I only said it is a defense-in-depth measure.

I definitely want to know how is it worse than running npm directly on the host

ashishbon Mercor says it was hit by cyberattack tied to compromise LiteLLM

So the worst case is that you are back to running npm on your host. Right?

ashishbon Mercor says it was hit by cyberattack tied to compromise LiteLLM

Compared to what? Which one is superior?

Running npm on your dev machine? Or running npm inside Docker?

I would always prefer the latter but would love to know what your approach to security is that's better than running npm inside Docker.

ashishbon Mercor says it was hit by cyberattack tied to compromise LiteLLM

What makes you think that?

Your cab see the commit history ~10% of code is written by agents.

Rest was all written by me.

Unlike other criticisms of the project, this one feels personal as it is objectively incorrect.

ashishbon Telnyx package compromised on PyPI

I do. It wasn't obvious that that's what you were referring to. If you use it regularly then that's great.

ashishbon Axios compromised on NPM – Malicious versions drop remote access trojan

I wrote a Docker-based sandbox [1] for myself last year to control the blast radius of such malicious packages.

https://github.com/ashishb/amazing-sandbox

ashishbon Axios compromised on NPM – Malicious versions drop remote access trojan

Run npm/pnpm/bun/uv inside a sandbox.

There is no reason to let random packages have full access to your machine

ashishbon Telnyx package compromised on PyPI

> Why? Just open your entire editor/whatever inside a limited namespace and that's it no?

How will that prevent `npm run dev` or `uv run python` from accessing files outside your current directory?

ashishbon Telnyx package compromised on PyPI

> That is very inconvenient.

All executions (especially of random third-party code) inside the containers are not inconvenient at all for me.

Infact, I even open-sourced my setup - https://github.com/ashishb/amazing-sandbox

ashishbon Telnyx package compromised on PyPI

Rather than being hopeful why not start running 'uv' inside sandbox?

Why does your python package (cli/Web server/library) need full access to your full disk at the time of execution?

ashishbon Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

> docker run super-evil-oci-container

  1. That super evil OCI container still needs to find a vulnerability in Docker
  2. You can run Docker in rootless mode e.g. Orbstack runs without root

ashishbon Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

> Docker itself is privileged and now any unsandboxed program on your computer can trivially escalate to root.

Inside the sandbox but not on my machine. Show me how it can access an unmounted directory.

> Have you solved for publishing? You'll need your token to enter the container or you'll need an authorizing proxy.

Amazing-sandbox does not solve for that. The current risk is contamination; if you are running `trivy`, it should not need access to tokens in a different env/directory.

> All of these problems and many more go away if the project is built around them from the start.

Please elaborate on your approach that will all me to run markdown/JS/Python/Go/Rust linters and security scanners. Remember that `trivy` which caused `litellm` compromise is a security scanner itself.

> developers can write sandboxes for their software more effectively because they can architect around the sandbox,

Yeah, let's ask 100+ linter providers to write sandboxes for you. I can't even get maintainers to respond to legitimate & trivial PRs many a time.

ashishbon Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

> Yes, but now you are in charge of knowing every potential file access, network access, or possibly even system call, for a program that you do not maintain.

Not really. I try to capture the most common ones for caching [1], but if I miss it, then it is just inefficient, as it is equivalent to a cache miss.

I'll emphasize again, "no linter/scanner/formatter (e.g., trivy) should need full disk access".

1 - https://github.com/ashishb/amazing-sandbox/blob/fddf04a90408...

ashishbon Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

I wrote this[1] for myself last year. It only gives access to the current directory (and a few others - see README). So, it drastically reduces the attack surface of running third-party Python/Go/Rust/Haskell/JS code on your machine.

1 - https://github.com/ashishb/amazing-sandbox

ashishbon Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

> This assumes that we can get a locked down, secure, stable bedrock system and sandbox that basically never changes except for tiny security updates that can be carefully inspected by many independent parties.

Not really. You should limit the attack surface for third-party code.

A linter running in `dir1` should not access anything outside `dir1`.

ashishbon Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

> We need to start working in full sandboxes with defence in depth that have real guardrails

Happily sandboxing almost all third-party tools since 2025. `npm run dev` does not need access to my full disk.

ashishbon Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

> It's very painful to sandbox software from the outside and it's radically less effective because your sandbox is always maximally permissive.

Not really.

Let's say I am running `~/src/project1 $ litellm`

Why does this need access to anything outside of `~/src/project1`?

Even if it does, you should expose exactly those particular directories (e.g. ~/.config) and nothing else.

ashishbon Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

I am happily running all third-party tools inside the Amazing Sandbox[1]. I made it public last year.

1 - https://github.com/ashishb/amazing-sandbox

ashishbon Trivy under attack again: Widespread GitHub Actions tag compromise secrets

> I don't think it would help here, they were stealing credentials

So, stealing credentials in the current directory and in all other directories are the same thing?

ashishbon Trivy under attack again: Widespread GitHub Actions tag compromise secrets

> The sandbox will need internet access (to update data) and you will need to send code to test into it; so compromise already equals leaking all your code, without even breaking the sandboxing

Compromising all code in one directory is bad. Compromising all my data in all other directories, including mounted cloud drives, is worse.

I restrict most dev tools to access only the current directory.

ashishbon Trivy under attack again: Widespread GitHub Actions tag compromise secrets

I always run such tools inside sandboxes to limit the blast radius.

ashishbon Type systems are leaky abstractions: the case of Map.take!/2

> Have mypy/pyright/pryefly/ty type errors break CI.

Only if types are present.

> If you're starting a new project, there's no reason you shouldn't. Most dependencies would still be untyped.

ashishbon Type systems are leaky abstractions: the case of Map.take!/2

And you can never mandate that optional type checking in a big enough team.

You can even see popular FOSS Python packages that have very limited type checking.