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.
Validating every single service I run on my home server for security (currently at 30 containers + other non-containerised random crap) vs. enabling the built-in Wireguard server on my router (which is more or less as simple as setting up Tailscale). I have a very different idea on which of these is overkill.
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.
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.
Owning, auditing, and maintaining your entire supply chain stack is more secure than pinning hashes, but it is not practical for most projects.
Pinning your hashes is more secure than not pinning, and is close to free.
At the end of the day, the line of trust is drawn somewhere (do you audit the actions provided by GitHub?). It is not possible to write and release software without trusting some third party at some stage.
The important part is recognizing where your "points of trust" are, and making a conscious decision about what is worth doing yourself.
Shouldn't you always read & double-check the 3rd-party GitHub actions you use, anyway? (Forking or copying their code alone doesn't solve the issue you mention any more than pinning a SHA does.)
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.
Coding agents are like asking a genie for code. They will give you the code you ask for alright but you never know what kind of curse has been crontabbed for you.
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.
What features related to distrobox? I use both ptyxis and distrobox and I don’t notice any integration between them. I do notice an integration between ptyxis and sudo however. It simply turns the title bar red.
> Ptyxis: Your Container-Oriented Terminal for GNOME
> A modern terminal emulator built for the container era.
Seamlessly navigate between your host system and local containers like Podman,
Toolbox, and Distrobox with intelligent detection and a beautiful, responsive
GNOME interface.
Ask the LLM to create for you a POC for the vulnerability you have in mind. Last time I did this I had to repeatedly make a promise to the LLM that it was for educational purposes as it assumed this information is "dangerous".
I revived a once popular Youtube frontend called Cloudtube. All the Youtube media url deciphering is still done by Invidious and I use it more like a frontend for invidious.
reply