The “minimal” part is incorrect; it is a super complicated container. The number of moving parts don’t leave me with any confidence that I could keep it running or fix any issues going forwards.

Mainly for security. I was originally looking at CoreOS but I liked the additional improvements by the UBlue team. Since I only want it to run containers, it is a huge security benefit to be immutable and designed specifically for that workflow.

The Ignition file is super easy to do, even for just one server (substitute docker for podman depending which you have):

Take a copy of the UCore butane file:

https://github.com/ublue-os/ucore/blob/main/examples/ucore-autorebase.butane

Update it with your SSH public key and a password hash by using this command:

# Get a password hash
podman run -ti --rm quay.io/coreos/mkpasswd --method=yescrypt

Then host the butane file in a temporary local webserver:

# Convert Butane file to Ignition file
podman run -i --rm quay.io/coreos/butane:release --pretty --strict < ucore-autorebase.butane > ignition.ign

# Serve the Igition file using a temp webserver
podman run -p 5080:80 -v "$PWD":/var/www/html php:7.2-apache

During UCore setup, type in the address of the hosted file, e.g. http://your_ip_addr:5080/ignition.ign

That’s it - UCore configures everything else during setup.___

Rootless Podman :) It requires you to learn a little bit of new syntax, for example, the way you mount volumes and pass environment variables can be slightly different, but there’s nothing that hasn’t worked for me.

I’m using this on uBlue uCore, which I would also strongly recommend for security reasons.

I switched and was very glad to do so. You increase your security and so far I haven’t seen any downside. Every container I’ve tried has worked without issues, even complex ones.

Just remember that Cloudflare decrypts and re-encrypts all your data, so they can read absolutely everything that passes through those tunnels.

I’m not aware of any other enterprise password management where the server source is available and auditable. Proton certainly is not.

What features will depend on the close-source part, and which do not?

There are definitely some terminology issues here.

The SDK is not closed source, you can find the source here: https://github.com/bitwarden/sdk

It might not be GPL open-source, but it is not closed either.

Other than that, I agree with your points. I don’t agree with the kneejerk hysteria from many of the comments - it’s one of the worst things about FOSS is how quick people are to anger (I am not referring to you here).

But all of that still doesn’t explain what their goal of introducing the proprietary SDK is.

Let’s wait and see before we get out the pitchforks.

Sorry that’s my mistake - I should have said “source available”, rather than “open source”. IMO, being source available is the critical component of a password manager like Bitwarden, and is what I meant when I referred to their main competitive advantage.

They might also choose to be open source and fix this specific issue and return to GPL-compatibility, but remaining source available would seem to be the more critical factor.

Well, then it would be nice to hear from them an explanation on why they decided to violate the GPLv3

Lucky for you, they provided that explanation:

1. This is a bug/mistake.
2. Our goal is to make sure that the SDK is used in a way that maintains GPL compatibility.
3. We will fix this.

That may or may not be the case, but the comment I replied to said they locked the thread with “no explanation”.

What part changed the code to closed source?

Gitlab has demonstrated its commitment to keep the core of their product, though limited in features, free and open source. As of now, BW’s clients cannot even be compiled without the proprietary SDK anymore.

None of that makes Bitwarden not open source. Not only that, they specifically state this is a bug which will be addressed.

I would go as far as to say that Bitwarden’s main competitive advantage and differentiation is that it’s open source. They would be insane to stop that.

That would be an issue if they were not open source. Them making their own SDK proprietary is not a pitchfork issue.

Open source !== Non-proprietary

I would go as far as to say that Bitwarden’s main competitive advantage and differentiation is that it’s open source. They would be insane to change that.

The explanation is the second-to-last comment before it got locked. 🤦

This hysteria is really stupid.

They recommend SimpleFIN instead of Plaid: https://old.reddit.com/r/selfhosted/comments/1cmfk8x/actualbudget_has_anyone_written_a_plaid_importer/

Yes

You jumped to a conclusion on pricing and made a mistake, it’s ok, no big deal.

Lol you weirdo, I even said I did that:

https://lemmy.world/comment/12622960

Try clicking either of those links.

Regardless, this is a thread about self-hosted open-source budgeting, which is why I linked to Actual Budget. I have updated the first post to be the Github link instead to prevent confusion.

all I saw was pricing […] can you really blame me?

I mean I really can. They don’t have any paid option so you definitely didn’t see any pricing. They only have a big open source message: