Edit: no, it doesn’t. Looking at the comments below, it’s public key crypto.

Original comment:

The problem is that if that is your threat model, then the VPS provider, ISP, and literally everything between you and letsencrypt can pull a conpromised key fro letsencrypt.

This actually happened btw, an xmpp server was attacked this way, they compromised not the server itself, but the VPS provider MITMed their traffic: https://www.devever.net/~hl/xmpp-incident

If your threat model involves this, then the only solution is Tor, which eliminates these requirements of trust.

EDIT no wait, this post is about secure, not hosting/tunneling in general. This comment is off topic ig.

I would like to avoid paying for a VPS

Oracle cloud free tier, but it does have a history of randomly killing the VPS’s created.

Public ipv4 addresses are scarce, and becoming more expensive now. You are probably going to have to shell out some cash if you don’t already get one as part of your internet plan.

What reverse proxy are you using?

Tailscale works great, but their free tier is limited to a total of 8 users, which is enough for a tiny minecraft server, but doesn’t seem to be enough for your usecase.

For 10-15+ users, you probably want to self host a VPN on your own VPS. Like, you can self host headscale, which is tailscale but self hosted. : https://github.com/juanfont/headscale [1]

I wouldn’t port forward game servers, because they often lack authentication (login and stuff), and then they also have security issues due to not receiving updates. If your game server isn’t truly public, then it’s easier to just have people use the tailscale client to connect to your VPN.

[1] Although I would recommend headscale to OP for it’s simplicity, it is very barebones, and software like netbird or netmaker is more close to a truly self hosted tailscale, with things like more advanced accounts, OIDC integration, authorization, and so on. But they are more annoying to host and set up.

Nix is also packaged in debian as nix-bin.

A common distribution method involves multi-party signing, that is, multiple developers use keys to sign off on reviewed changes.

Multiple developers review the changes, before signing the git commit after review. Then they build the package, either locally or on CI servers, but again, multiple parties/servers sign and review, doing a reproducible build to verify across machines.

In an ideal architecture, there is never a single point of failure. You would have to compromise the computers of multiple devs, or multiple build servers that are building signed reproducible builds, in order to do it.

Although in theory, you could compromise all of them. But it’s extremely difficult.

Anyway I was gonna write a rant about it but I’m too tired. But basically the docker ecosystem is kinda fucked in this regard, and trades security in many aspects for convenience of development and distribution. This is one of the most notable examples of this.

It’s popular because it’s convinient and easy to use in many ways. If these pitfalls are a dealbreaker for you, then there is no trivial way to add the security requirements you are asking for.

You can pay for signed images from someone else, which is a little better, but there are still disadvantages.

Also what are you building? You might be able to replace docker with nix for example.

I think the most popular solution is locally building and registry.

Is your comment supposed to say “native pf or nftables”?

Doesn’t it already do that?

When using the website it informs me if a link has already been losted, while also searching for similar posts via title.

The app I’m using (Eternity) doesn’t do that tho

Debian has a policy of only cherry picking security updates, or critical bugfixes, in order to ensure maximum system stability. In general, they don’t do entire program updates or additional features. For the 4 year lifecycle of a Debian release, it will behave the same as it did yesterday.

As of today, current version of rsync in Debian’s stable’s packages is 3.4.1: https://packages.debian.org/stable/rsync (archive).

The versions with significant LLM assistance are 3.4.3 and later.

Certbot?

It can automate provisioning of certificates using DNS-01 challenges, which have wildcard certificates.

https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins

Example tutorial: https://www.digitalocean.com/community/tutorials/how-to-create-let-s-encrypt-wildcard-certificates-with-certbot

Once you do that it puts the cert in /etc/letsencrypt/live/ so you can then do whatever you want with it. You would have to handle distribution manually.

If you want to automate stuff across of a bunch of machines at once, I recommend Ansible: https://docs.ansible.com/projects/ansible/latest/index.html

One thing I read about is that Ubuntu provides unattended updates, so it can automatically update packages and restart the server (that seems a bit too far ;) ). It’s probably possible on Debian but not out of the box.

Ubuntu automatically has unattended upgrades, which makes I think makes it a popular choice for VPS providers to push (beyond being popular in corporate/institutions overall), since they don’t have to worry about users forgetting security updates. However, it doesn’t enable automatic reboots. But, it does look like automatic restarts of services updated via unattended upgrades is done, but only as of Ubuntu 24.

Another thing to note is that Ubuntu has updates that are explicitly for security, and then everything else, including more general bugfixes and program updates with additional features. By default, unattended upgrades on Ubuntu only do security updates.

Of course, both a unattended upgrades and automatic reboots are possible on Debian (same software, Ubuntu just preconfigures it), although default configurations can vary. I wouldn’t be suprised if a VPS provider was shipping a default Debian configuration that enabled automatic upgrades.

On Debian, for the most part, ALL updates are only for security issues or severe bugfixes (program crashes or the like). Debian, for the most part, doesn’t do minor bugfixes at all, or do program feature updates. I prefer this model, since it’s easier to manage than having separate types of package updates. It ensures absolute stability, a guarantee that the system tomorrow will behave the same as it did yesterday, while still enabling automatic security updates. This model is ideal for a server I don’t want to babysit, or for your grandpa who loses his mind when the button he is supposed to click was moved one spot over.

In addition to that, I like the policy of automatic reboots. With the stable, slow moving nature of both distros, it’s safe to automatically reboot to ensure that kernel vulnerabilities, or vulnerabilities in other critical systems are fixed. Automatic updates and reboots can be the difference between someone being able to escape a docker container or someone not being able to.

There is one thing to note, is that adding additional repos (or PPA’s which technically you aren’t supposed to work on Debian), can be dangerous, and you have to be careful: https://wiki.debian.org/DontBreakDebian/#Don.27t_make_a_FrankenDebian

The main problem is that if a third party repo and Debian provide the same package, and the system is configured to prefer the third party repo, then you can be installing a potential dependency to the rest of your system that isn’t actually tested against your system, or compatible.

You have to be really careful to ensure that the programs in the repo are actually built and designed for your system, and also that the your system does not default to installing them.

Third party repos also break the guarantee of stability that automatic updates depend on. Third party repos don’t have a separate security channel, so Ubuntu will probably avoid touching them, even if critical security fixes are needed. Debian will update them, but unlike Debian’s packages, the overall program updates won’t be guaranteed to be behave the same due to potential major/minor version changes.

For example, if you get Docker from docker’s repo instead of Debian’s/Ubuntu’s, now your version of docker can no longer auto update and receive potential security fixes safely.

Overall, I prefer Debian but Ubuntu is fine. If I was in an environment that used Ubuntu already, I would also just use Ubuntu. If you are already using Debian, then Debian is probably preferable.

What made moodle frustrating?

I have also heard the opposite take, that canvas sucks and moodle is great.

Did you use it as a student/user, or as an administrator?

There is also moodle.

Canvas and moodle are really popular in schools and universities.

Paperless ngx seems to support fulltext search of PDF’s, in addition to other document types.

It looks like criticisms similar to mine were offered in the comments of the youtube video you linked at first, and now the youtuber has released a second video, a correction. In this video he uses nginx proxy manager and DNS-01 challenges:

https://www.youtube.com/watch?v=XEltHEZU6aE

Big respect for doing that.

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.