You should probably migrate now, forgejo is currently a soft fork that is fully compatible, but in the future they are planning to hard fork and not be compatible. Well, they are in the process of doing so right now.

Second comment, but also check out midpoint by evoloum: https://docs.evolveum.com/iam/

It is a modern web frontend on top of Active Directory.

1. Use an Identity Provider (IDP)*. Other people have mentioned LDAP, which can play this role.

2. Use groups within the IDP to declare who has what privileges.

3. Apps using the IDP for auth can read the groups and allow/deny permissions based on groups.

*Or Identity and Access Management if you are in the cloud ig.

For open source solutions, I would recommend:

• Authentik (what I use)
• Kanidm (doesn’t have web ui)
• Nubus by Univention

These three solutions all have invites, ldap, and can act as oauth providers. (Oauth is single sign on), which are the features I want. There are also integrated, including it all in the one app.

There is also LLDAP, which is a web ui for ldap, and then you could use a service that connects to that, like authelia or keycloak, to add oauth on top.

No, Socks5 does not work for this usecase. You don’t get permissions to run it locally via crostini (or use crostini in general) and the relevant proxy settings are locked in the chromebook settings. In addition to this, it is too easy to fingerprint, and some of the more aggressive setups will catch it and block it. For example, my high school would autodetect wireguard and then kick you off of the network for 10 minutes if you attempted to connect.

These kinds of setups are used to bypass agressive network filtering and content censhorship. All the traffic is http(s). And then the way only a browser is needed means it works on locked down devices like chromebooks.

The browser in docker is something I have used, but it requires more resources to host and can only be used by one person at once if you are using something like linuxserver’s webtop.

Yeah you want the titanium networks projects, which are essentially a bunch of web proxies exactly like what you ask for.

I used to use Metallic, but it’s not actually that good and not maintained anymore.

Here is a public instance of holy unblocker: https://uc.robby.blue/scramjet

This is one of their flagship projects, and is what you want. Self hostable of course, code on github. I preferred the projects that give you internal tabs though, like hypertabs or anura.

Public anura instance: https://anura.pro/ (but anura looks like a pain to self host, it’s much more complex)

This requires manually enabling every additional provider.

No, it doesn’t. The docs are confusing on this, but forgejo has two methods to enable oauth/oidc. One is to manually enable them, but there is a second, where people bring their own openid link.

The docs contain 3 things related to oauth:

• Oauth provider forgejo acts as oauth for someone else
• Ouath client — This is the one where you manually enable providers
• But then there is a third config. Openid. This one lets users bring their own openid/oauth link and sign in with that. No manual configuration required on the side of the forgejo server per oauth provider being used.

Do you use the web ui?

I use the web ui heavily, but it’s only packaged by the incus package from the author, and not included in the debian packages.

Also, what are you using for authentication?

I (plus friends who do something similar) have been using centralized auth systems for this stuff. Proxmox supports OIDC, so if you are using Authentik or something similar you can just use one password.

And then Authentik supports 2FA, so you can use TOTP with that, or use passwords only.

In addition to netbox, a wiki or other knowledgebase would be nice. You can document setup procedures as you go, and then other people can use that to figure stuff out.

Forgejo has a feature (that people usually disable) where you can bring your own openid connect url and use it to auth. So if I have my own OIDC provider I am self hosting, I can just use that to log in.

Most people only use OIDC for google and microsoft and whatnot but it’s very possible. I don’t realkly see what FedCM offers that OIDC doesn’t or can’t, or why we shouldn’t be adding features to the existing and popular OIDC instead.

The problem is that real dumb phones are hard to find. Many modern “dumb phones” are actually full android devices, complete with a boatload of spyware that helps keep the cost of the device itself low.

KaiOS is better but that’s a whole linux distro, with similar issues.

Since you mentioned tethering, do you have an example of a non android (or at least one that’s not preloaded with a ton of spyware) dumbphone that supports usb tethering? I am skeptical that a real dumbphone would have this feature.

My one fear with this is offline authentication. I enjoy oauth/oidc a lot, but it doesn’t have mechanisms for machines to continue to be able to authenticate while offline, like the way ldap/kerberos can do.

Is this just for machines that will always be online? I can understand that usecase but :/

EDIT: Okay, one comment, mentions himmelblau an alternative to authd, which seems to be more mature. Himmelblau has docs about offline usage. It looks like it has an emergency config that can use a cached password from the oidc provider,

Single-factor authentication (SFA-only) users and Hello-PIN users already have offline sign-in capability

Hmmm. Okay. Upon doing further reseach, it looks like offline authentication is exclusive to Microsoft Entra ID. :/

Syncthing has encryption as well. You can have a device be “untrusted” so you put in an encryption password, and data sent to and stored on that device will be encrypted.

Although this does encrypt file (and directory) names, the caveats about folder structure and modification time still apply.

He fed only the API and the test suite to Claude and asked it to reimplement the library from scratch.

What was the test suite licenced under? If it was in the same repo, then it was probably LGPL code as well.

If the MIT rewrite uses the LGPL licensed test cases, including them in the repo, then it probably must be LGPL as well.

I use fluxcd with helmrelease’s which auto update the helm release. If the helm chart versions specify container versions, then updating the helm chart updates the containers in the deployments.

But for raw deployments, I found this, but not much else.

In addition to adding more worker instances, you can also increase the amount of threads each worker instance uses to vertically scale. It’s about equivalent to adding a worker instance.

Authentik is definitely the best of all I’ve tried. It has the most features, supporting both ldap and oauth, and also has an official helm chart.

Openbsd is definitely more secure than secureblue. There is only so much you can do to handle the massive monolithic architecture of the Linux kernel. Further down the stack, many parts of Linux, like sudo, dbus, or systemd are regularly hit by zero days. The SELinux domain architecture that Secureblue is interesting, but SELinux is extremely complex and difficult to get right, compared to the much more simpler pledge and unveil sandboxing that openbsd offers.

In addition to that, there are further issues like the problematic way that user namespaces interact with browsers. (And user namespaces are frustrating in general, secureblue actually has a short article on their problems). For maximum security, you want to sandbox tabs from eachother using user namespaces (only works on chromium btw, firefox can’t do this so it doesn’t matter) — BUT, if you run your browser in a sanbox created by user namespaces, then you can’t nest them, disallowing you from using that powerful tool to isolate tabs. So you are forced to make a choice: You can either sandbox the browser itself, in exchange for weakening the isolation between tabs, or you can strengthen the isolation between tabs, in exchange for weaking the sandbox around the browser itself. Giving the browser access to user namespaces is questionable though, because see above, user namespaces have led to a lot of vulnerabilities.

OpenBSD’s pledge + unveil (but only on chromium again), does not really make such tradeoffs. It can sandbox tabs from eachother, while also sandboxing the browser itself. In addition to that, pledge + unveil do not present a massive kernel attack surface that people have had to restrict for having too many 0days. And this is just one of the many, many examples, where OpenBSD presents a better security posture than Linux.

Qubes is technically Xen, a different kernel than Linux. The Xen kernel virtualizes Linux distros, from which you can manage Qubes/Xen, or do normal Linux app stuff. But nothing stops you from using a BSD virtualized by Xen for management or usage. Qubes talks about why they use Xen here — but the short version is that they did not consider the Linux kernel’s kvm secure enough for their usecase.

Tailscale already does though, I think.

https://tailscale.com/docs/features/tailscale-funnel

Although it might work differently.