Personally, I think Proxmox is somewhat unsecure too.

Proxmox is unique from other projects, in it's much more hacky, and much of the stack is custom rather than standards. Like for example: For networking, they maintain a fork of the Linux's older networking stack, called ifupdown2, whereas similar projects, like openstack, or Incus, use either the standard Linux kernel networking, or a project called openvswitch.

I think Proxmox is definitely secure enough, but I don't know if I would really trust it for higher value usecases due to some of their stack being custom, rather than standard and mantained by the wider community.

If I end up wanting to run Proxmox, I’ll install Debian, distro-morph it to Kicksecure

If you're interested in deploying a hypervisor on top of an existing operating system, I recommend looking into Incus or Openstack. They have packages/deployments than can be done on Debian or Red Hat distros, and I would argue that they are designed in a more secure manner (since they include multi tenancy) than Proxmox. In addition to that, they also use standard tooling for networking, like both can use Linux Bridge (in-kernel networking) for networking operations.

I would trust Openstack the most when it comes to security, because it is designed to be used as a public cloud, like having your own AWS, and it is deployed with components publicly accessible in the real world.

For example, Open Watcom is nonfree because its license does not allow making a modified version and using it privately. Fortunately, few programs use such licenses.

Although the FSF doesn't like licenses that force release of code of private versions, it should be noted that Open Watcom also has a termination clause. You can no longer use that software if you are being sued by Watcom or something like that.

This termination clause is why entities who otherwise would be okay with this license, like Debian, don't find it acceptable.

Because forgejo's ssh isn't for a normal ssh service, but rather so that users can access git over ssh.

Now technically, a bastion should work, but it's not really what people want when they are trying to set up git over ssh. Since git/ssh is a service, rather than an administrative tool, why shouldn't it be configured within the other tools used for exposes services? (Reverse proxy/caddy).

And in addition to that, people most probably want git/ssh to be available publicly, which a bastion host doesn't do.

So based on what you've said in the comments, I am guessing you are managing all your users with Nixos, in the Nixos config, and want to share these users to other services?

Yeah, I don't even know sharing Unix users is possible. EDIT: It seems to be based on comments below.

But what I do know is possible, is for Unix/Linux to get it's users from LDAP. Even sudo is able to read from LDAP, and use LDAP groups to authorize users as being able to sudo.

Setting these up on Nixos is trivial. You can use the users.ldap set of options on Nixos to configure authentication against an external LDAP user. Then, you can configure sudo

After all of that, you could declaratively configure an LDAP server using Nixos, including setting up users. For example, it looks like you can configure users and groups fro the kanidm ldap server

Or you could have a config file for the openldap server

RE: Manage auth at the reverse proxy: If you use Authentik as your LDAP server, it can reverse proxy services and auth users at that step. A common setup I've seen is to run another reverse proxy in front of authentik, and then just point that reverse proxy at authentik, and then use authentik to reverse proxy just the services you want behind a login page.

I just realized... a previous lemmy post I saw appears to be this sign.

https://discuss.tchncs.de/post/21651766

OP is on OpenWRT (a router distro), and Alpine. Those distros don't come with very much by default, and perl is not a core dependency for any of their default tools. Neither is python.

Based on the way the cosmo project has statically linked builds of python, but not perl, I'm guessing it's more difficult to create a statically linked perl. This means that it's more difficult to put perl on a system where it isn't already there, and that system doesn't have a package manager*, than python or other options.

*or the the user doesn't want to use a package manager. OP said they just want to copy a binary around. Can you do that with perl?

It's already been done: https://github.com/seemoo-lab/opendrop

There are two problems:

• Apple is able to make airdop so seamless because they ensure their devices support a special feature, wifi direct: https://apple.stackexchange.com/a/428700
• Nothing stops apple from just changing how airdop works to break the open source version's compatibility.

It doesn't need root, but it is shady as fuck. Thankfully, there's been no reports of malware from the official lucky patcher project... although that link doesn't look official, given the ads and popups, I got that link from my copy of the app.

I briefly looked into the revanced project to see if they had any relevant patches, as I would rather recommend FOSS solutions first, and revanced is shaping up to be lucky patcher, but FOSS, but they didn't have anything,

LXD/Incus. It's truly free/open

Please stop saying this about lxd. You know it isn't true, ever since they started requiring a CLA.

LXD is literally less free than proxmox, looking at those terms, since Canonical isn't required to open source any custom lxd versions they host.

Also, I've literally brought this up to you before, and you acknowledged it. But you continue to spread this despite the fact that you should know better.

Anyway, Incus currently isn't packaged in debian bookworm, only trixie.

The version of lxd debian packages is before the license change so that's still free. But for people on other distros, it's better to clarify that incus is the truly FOSS option.

The guide won't work. Grub attempts to verify everything in /boot, even if it is encrypted, which is pointless for a desktop use case.

https://moonpiedumplings.github.io/playground/arch-secureboot/

Original guide I followed: https://wejn.org/2021/09/fixing-grub-verification-requested-nobody-cares/

I haven't encountered any of these issue on matrix, but admittedly I haven't joined a lot of matrix chats.