not in capitalism no

Except if it’s free software.

I haven’t jumped yet, but the Proton suite is looking more and more appealing. I’ve been eyeing them as a Gmail replacement, but I’ve been happy with my VPN and password management providers. As this reduces the bundle makes more sense.

It’s not open source, but I got a lifetime license for Enpass over a decade ago and it’s done everything I’ve ever needed it for. I think stacksocial occasionally has new lifetime codes for sale. I like the idea of Proton Pass as others have said, but it feels a bit like putting all my eggs in one basket, which is a mistake I already made with Google before (context: I use Proton for email). I think Keepass is the next best option if dedicated to staying FOSS.

Love Keepass. Love that I can sync it however I want. Love that there are multiple open source client options across several operating systems.

Isn’t Vaultwarden used with non-free Bitwarden clients?

It is a license problem. The license condition of the SDK which is required to build the client app change to limit the usage of it. The new license states that you can only use the Bitwarden SDK for Bitwarden. It is against the Freedoom-0 of the Free Software Foundation. The limitation of English language is that it is hard to differentiate between Free (as in Free bear) and Free (as in Freedoom). Also open source which could mean complaining with FOSS and that source is available. This been unfortunately have been abused before.

That’s far from the best option. It’s working, but it’s super complicated compared to Bitwarden and other cloud password managers. Imagine telling your grandma “just use keepass”, she would never be able to make it work. But Bitwarden? Lastpass? That’s possible

Not sure who downvoted you, you literally quoted the article.

I really hope that this is actually the case, but I am not very optimistic. This doesn’t seem to be a mistake. They intentionally move functionality of their clients to their proprietary SDK library. The Bitwarden person stated this in the Github issue and you can also check the commit history. Making that library a build-time dependency might actually have been a mistake. That does not change the fact, that the clients are no longer useful without that proprietary library going forward. Core functionality has been move to that lib. I really don’t care if they talk to that library via some protocol or have it linked at build time. I wouldn’t consider this open source, even if that client wrapper that talks to that library technically is still licensed under GPLv3.

Don’t forget option 3: someone writes a vaultwarden client independent of the closed-source crap.

If you can write a server that fully supports the client via the documented API, then you know everything you’d need to do to make a client as well.

You can’t “dmca” the fork that was created while it was still open source. They could only prevent it from getting future updates (directly from them).

Yes.

Keepass is exactly that. Basically all the client side parts, and the database is a single encrypted file that you can sync however you want.

I’ve done basically this in the past by encrypting a text file with GPG. But a real password manager will integrate with your browser and helps prevent getting phished by verifying the domain before entering a password. It also syncs across all my devices, which my GPG file only worked well on my desktop.

It’s the “stringing it all together” that could be problematic.

If you have multiple clients (desktop/cellphone) modifying the same entry (or even different entries in the same “database” ). You need something smart enough to gracefully handle this or atleast tell you about it.

I did the whole “syncing” KeePass and it was functional, but it also meant I needed to handle conflicts - which was annoying. I switched and really appreciate the whole “it just works” with self-hosted bitwarden.

That is the bare minimum of a password manager like Bitwarden.

I see it as it’s easy to self host. But I’m not skilled nor rich enough to guarantee the availability of it. I don’t want to be stuck on a holiday without my passwords because my server back home died from black out or what have you.

I pay for bitwarden and the proton mail package to keep the password management market a bit more competitive and it actually works out cheaper. It would be nice to have protons anonymous emails built in, but I can live with it.

But I might have to reconsider if Bitwarden is going a different direction that what I’m paying for.

Yup, thanks. Was thinking along these same lines.

Thank you for the update! I would like to keep using it. I’ve been very happy with Bitwarden both as a password manager and a TOTP authenticator. I have even recommended it to my boss as an enterprise solution for us to use at work, and so far we are planning on replacing our current password database solution with Bitwarden.

Unfortunately, with “enshittification” being so common these days, it was very easy to believe they were also going to the dark side. I will remain cautiously optimistic after learning it was a packaging bug.

Here’s a link to the post on X (yes, I hate X, too) in case anyone else is doubtful:

https://x.com/Bitwarden/status/1848135725663076446

That’s what I’m using mostly, but the convenience of having auto fill in firefox and being able to share some logins made me want to try bitwarden. Also, it’s not complicated to sync between several devices.

mb i didnt see the update part

When I read this this morning, I had concerns, but then I did some research. The SDKs source is fully available for all to look at and compile. The main issue that people bring up is the license that states:

3.3 You may not use this SDK to develop applications for use with software other
than Bitwarden (including non-compatible implementations of Bitwarden) or to
develop another SDK.

This part seems to be what most people take issue with, as it makes the sdk no longer modifiable, yet a requirement of the core source itself. The head of BitWarden has come out and stated the SDK being required to compile BitWarden was a mistake, however, and if this proves to be true (which I have no reason to doubt) then I see no reason why any of this is an issue.

From a security standpoint, since the SDK is source available, it can be audited by anyone still (and compiled) so personally, I’m fine with this.

oh shit i didnt know that, mb man

I’m running a couple of Vaultwarden instances, and it would be really nice if Bitwarden employed Garcia to improve the Rust backend. But as the bitter cynic I am, I guess it is an effort to shut down and control as much of the open source use of Bitwarden as possible.

The worst case, someone will most likely fork Vaultwarden and we can still access it with Keyguard on mobile and the excellent Vaultwarden web interface :)

Syncthing fork seems to still be under active development

F-Droid syncthing-fork is still actively developed and had a patch in the last few weeks.

So hopefully this isn’t the end.

What? I need syncthing-android, where is it going?

Syncthing is encrypted transfers.

The database is encrypted.

And you can set it to not use relays for data, only matchmaking between your own devices.

So it’s an encrypted file, encrypted again, and sent directly from an IP you own to an IP you own.

Consider the possibility that someone could get your database.

It isn’t a safe. You can’t weld through the side of it and get in. You either make it ridiculous or impossible to get in.

Use something memorable, but insane.

My password is a three-line film quote with numbers in some of the places for letters.

Haikus work great. Memorable, complex. Wrote it yourself? Even better.

everything’s a file

An online database is still a file ultimately. A SQL or other DB file stored in a webserver, accessed through a web interface.

Vaultwarden, etc, are the same, only the database file is less directly visible IMO. Keepass IMO is simple. The DB in a bespoke format, stored outside the application.

You could put the vault in system32 and name it “trustedinstaller.log”, and if someone saw you had keepass they wouldn’t even know where your vault is.

Given the number of well documented breaches of online password vaults, I would much rather do a private device to device sync via syncthing and keep it out of webservers.

KeePassxc with syncthing

Nextcloud with their password solutions

A notebook

Update: Bitwarden posted to X this evening to reaffirm that it’s a “packaging bug” and that “Bitwarden remains committed to the open source licensing model.”

I’m not going to jump ship just yet, though I may get around to updating my backup.

There are plenty of alternatives, so feel free to shop around. But don’t jump the gun just because of a random Phoronix article with an update that says basically the opposite of what the article claims. Wait some time to see if there are actual changes coming.

I’m not thoroughly aware of their dealings, but these amounts of private investment aren’t going to pay for themselves. If you raise 100 million, investors typically want a billion back, or more.

From the looks of it, Bitwarden might’ve tried to go with the Open Source model to get free development resources, trust (because it’s an open source PASSWORD manager), and general goodwill. But now that they’ve deemed that got enough of a market share (or investors are starting to breathe down their necks), it’s time to start raising the walled garden.

Even if they claim after the fact that it was a “Bug” that the client couldn’t be built without their proprietary sdk. The very fact one exists is a bad enough sign, specially when its influence is spreading.

VC is a devil’s bargain. Raising VC money is NEVER a good sign.