You can use local certs with nginx proxy manager as well. You can upload certs via the web ui.

Rather than local certs though, I would recommend buying a domain and using it locally, with https. The problem with the local cert approach outlined in the video, is that importing a root cert opens up a big security hole to MITM attacks. If an attacker gets the root certificate, they can now MITM everything else your browser is accessing. You turn the browser from one of the most secure components of a modern OS, into only as secure as the server hosting the root certificates.

The approach I would prefer, is to buy a domain, and use it locally, using DNS-01 challenges to get letsencrypt signed certificates even from within an internal network. Both Caddy and NPM have support for DNS-01 challenges.

No, they are trivial to block using techniques like deep package inspection.

In addition to that, they aren’t truly decentralized (no decentralized network really is), both rely on relay/bootstrap servers to start up the connection. So, if you block the public relay/bootstrap servers, you effectively block access to the network.

Tailscale, netbird also can traverse NAT.

Iroh (the actually pretty interesting software which the vibecoded rayfish is based on) and Yggdrassil do have their uses, but evading blocks isn’t one of them.

You want a reverse proxy. A reverse proxy reads requests to subdomains and then forwards them to ports and back.

The easiest GUI one is: https://nginxproxymanager.com/

But there is also just straight nginx, or you can use Caddy or traefik or anything else.

Yes. Under the hood, gnome controls the power profiles daemon.

You can configure it from the cli via powerprofilesctl.

powerprofilesctl get gets the currently active mode. powerprofilesctl set performance set’s it to performance mode.

There are three modes: ‘power-saver’, ‘balanced’, ‘performance’

Yes, I do lock it down. It’s still worth securing it because “internal servers” can still get exposed and touched, even though there are less paths to them, and it’s not as punishing to slip up vs a public server. For example, One of the wireguard client devices downloads a virus, and now you have a cyberattacker with access.

Another problem is supply chain issues. If the distributor of a docker container is hacked, it’s not that bad… as long as your kernel is up to date and is protected against some of the recent vulns, that would enable someone to break out of a docker container

Blajah.zone’s lemmy instance was hacked partially becuase internal servers weren’t being held to the same security standards as the public ones:

https://pen.blahaj.zone/supakaity/weve-been-hacked

I had not patched these internal servers that nobody should have access to against this. Rebooting DB servers causes downtime, and in my hubris – I thought nobody should (nay COULD) be on my servers except me, right?

I have a comment on that post with some potential solutions, that would have cut off attack paths.

Though, I guess, it still does depend. Like if it’s just gonna you wireguarding in and no one else, then the data on your devices is probably worth more than the data on the server, so no, it wouldn’t be worth spending too much effort to secure less valuable data.

But if you are handing out internal access to people, including to some relative who keeps falling for scammers, then yeah, I’d take some time to harden the systems.

https://programming.dev/comment/24515044

Same problem is present here. Uses JWT’s for auth.

Edit:

Using jwt’s for auth isn’t bad, it’s good and quite common The problem is when they are used in place of actual bearer/cookie/session auth methods. As I understand it at least, a jwt token with a lifespan greater than 5 minutes is a red flag.

I used to use innoextract to extract the launchers, and the the system wine to run it. Although sometimes I have to run extra installers that put dlls in the right spots.

You should probably just run the installer in lutris (which ships a proton distributution) or bottles.

Edit: I can’t read smh my head.

Check this out: https://github.com/lutris/docs/blob/2b116519c5b67254733234f36ab33a60f14f1358/WineDependencies.md

Calling an enterprise-grade platform

Except you use JWT’s for auth, which is idiotic and a security nightmare. No enterprise that cares about security would ever accept this.

More info: https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452

There are other problems, some of which I can see… and some of which I can’t. The problem is that I am not a comprehensive expert, I can only spot a few things here and there. Even if I was an expert, why would I audit your software for free lmao? Pay me for that shit.

What I do know, is that vibecoded apps are bad at security. Many, many vibecoded apps have been hit by horrific security bugs like remote code execution, xss, or authentication bypasses. That shit is simply unacceptable and should be extremely rare in modern apps. The fact that I’m not skilled enough to find them reliably makes me even more cautious and concerned around apps like yours.

It’s not just about the app architecture, but also about you. When a known community figure creates an app, I have confidence that they will have a good security posture and architecture. With vibecoding… not so much.

If you have an actual architectural critique

Nice bait, but the problem is this: Just because you get people to audit “critique” your software, doesn’t fix the root cause of those problems — you. Just because you manage to re-vibecode the app to not use JWT’s or to fix any other number of issues someone would point out, doesn’t actually mean more issues exist that that person missed. Like if someone specialized in python, then they might miss database issues, and so on. The second problem is that inevitably, you will expand this software, adding more features… and vulnerabilities. That is to say, even if you manage to fix the architecture and security now, you have not demonstrated the requisite skill needed in order to keep it fixed.