HN user

s_ting765

152 karma
Posts2
Comments130
View on HN

The solution is not to use docker to sandbox Opencode. It is to use flatpak/bubblewrap/flatseal.

I have vscode running in flatpak with directory permissions handled by flatseal. Vscode only has access to my dev folders and nothing else. Even the git bundled by vscode cannot call git push because of this (vscode doesn't have permission to read ~/.ssh!).

It's an easy sandbox that's provided free of charge courtesy of bubblewrap/flatpak.

As someone who uses opencode regularly, the quip about it asking for permission to read logs in /tmp after already writing to the directory is pretty funny.

1.98.9 has already been tagged since bulletin was published (don't know why they chose on github to tag but not release).

1.98.9 version exists! That's not the question. It should already have been made available for Linux distros assuming this resource from Tailscale is accurate https://pkgs.tailscale.com/stable/?v=1.98.9

Edit: Their changelog also mentions the version: https://tailscale.com/changelog#all

This decision tree doesn't make much sense to me. Why you someone forego performance today in favor of adding a completely unnecessary network layer to every DB query in order to "satisfy" future imaginary "scaling concerns"?

Vladimir Fedorov is GitHub's Chief Technology Officer .... He currently serves on the board of Codepath.org, an organization dedicated to reprogramming higher education to create the first AI-native generation of engineers, CTOs, and founders.

I think I found the issue.

What makes you think simply throwing random crap on a home VPN network is secure?

Tailscale/Wireguard is overkill because it is not needed where access controls work fine which is true for the majority of the popular self-hosted apps. And you now have to install a VPN client/cert on every device you want to access your services from. That's a major oof.

Tailscale is an overkill solution. Opening ports 80 and 443 for a reverse proxy is enough security provided your apps don't have broken authentication. I've been doing this for years now.

Double checking Github actions does not mitigate threats from supply chain vulnerabilities. Forking an action moves the trust from a random developer to yourself. You still have to make sure the action is pulling in dependencies from trusted sources which can also be yourself depending on how far you want to go.

Pinning github actions by commit SHA does not solve the supply chain problem if the pinned action itself is pulling in other dependencies which themselves could be compromised. An action can pull in a docker image as a dependency for example. It is effectively security theatre. The real fix is owning the code that runs in your CI pipelines. Or fork the action itself and maintain it as part of your infrastructure.

I tried this out after getting annoyed for the 100th time by a recent bug in kgx/console that will occasionally fail to launch windows leaving incomplete windows as tabs.

Console has long since become abandonware pushing people towards ptyxis which is now the default gnome terminal. A damn shame considering console is basically complete software (the quality of software in gnome is on a downhill).

I would have given ptyxis a chance if they didn't take a basic terminal and added some fluff (features related to distrobox) on top of other annoying things I can't be bothered to remember about because I ended up removing the software every time I gave it a spin.

In just a few days I've been able to replace console with ghostty-nightly and I don't miss anything.

Docker provides some host isolation which can be used effectively as a sandbox. It's not designed for security (and it does have some reasonable defaults) but it does give you options to layer on security modules like apparmor and seccomp very easily.

How uv got so fast 7 months ago

Rust rewrites are known for breaking (compatibility with) working software. That's all there is to them.