Bitwarden SDK relicensed from proprietary to GPLv3
github.com
github.com
I hope they realized that being FOSS is their moat and it nets them a lot of goodwill (it’s the whole reason I bother with their not-quite-the-best product in the first place). The bold claim „the most trusted password manager“ was kind of justifiable while it was FOSS (if we don’t count keepass), without it not at all.
I’m still not sure how I feel about them now. I can now somewhat trust that the applications will remain free software, but trust in the company has eroded a bit. I still haven’t seen official communication about this.
* I just don't see how taking $100 million can be good for users in the long run. By far the most likely outcomes are bloat or enshittification.
* bitwarden does not appear to be very forkable, ie it's a complex system written in C#. The existence of Vaultwarden helps a lot with this, but what about the client apps? Forkability is the second most important protection against user-hostile action, behind being open source in the first place.
I hope it works out. I'm a recent adopter of bitwarden, and so far the UX has blown keepass out of the water.
For one, it's much easier and natural to add additional pieces of information on entries in 1Password. Bitwarden's implementation of this always feels like a poorly integrated afterthought.
Especially keeping passkeys platform-independent is a huge advantage, in my view.
I would strongly advise using something like Aegis on Android, or Gnome Authenticator on desktop (or both). I like to duplicate/backup my seeds so that I'm not SOL if my phone breaks, but I do it by having them on my laptop, desktop, and phone. That way as long as I have one of the three devices, I can always get in, and then they're not "in the cloud." Though, "in the cloud" is still better than "in the cloud alongside all my passwords."
"Something you know"; "something you have"; "something you do"; "something you are [biometrics]"; "somewhere you are [geolocation]".
Passwords are in your head - "something you know".
TOTP codes are generated by a hardware token - "something you have".
If the TOTP codes are crammed into your password manager, then the factors are no longer distinguished by these qualities, but they're now the same factor, and it's not true MFA anymore, whether or not they're split up across devices, or apps.
Logging in through a password manager requires that you know a password (your master password), and have a file (your vault).
The whole point of a fully featured password manager like 1Password or Bitwarden is to rely on it instead of the security of the service you're using. And that implies that you must trust the security of the vault itself.
Of course, each device you have is an additional (an equally dangerous) attack surface. However, most people should be more worried if someone hacks into their devices than their Facebook accounts anyway.
Though, if you already have to have an app for the important stuff like your email, then IMHO it's actually simpler to just keep them all in one place even if you don't care too much about some of the tokens. Just one less thing you have to remember (i.e. where did I put service X's token again? was that in bitwarden or Aegis? etc).
The factors are:
- Something you know
- Something you have
- Something you are (biometrics)
I'm not talking about my password vault getting breached, in that case I'd be fucked either way.
But that's the whole point. If your password vault is breached, the second factor is what prevents you from being fucked. That's why putting your seeds in the vault is a reduction in security. It may be a reduction/risk that you're willing to take for convenience, but it's still a reduction.
"Something you know" (password) becomes "something you have" as soon as you store/autogenerate/rotate those passwords in a manager (which is highly recommended).
"Something you have" in the form of a hw key is still that device generating a key (password) that device/browser APIs convey to the service in the same way as any other password.
"Something you are" is a bit different due to the algorithms used to match biometric IDs but given that matching is less secure than cryptographic hash functions - this factor is only included in the list for convenience reasons.
The breakdown of this metaphor is one of the reasons passkeys are seen as a good thing.
I'm not saying I think everyone needs real 2FA. I think 99.999% of the time storing your 2FA codes in your PW manager, or just moving on to Passkeys, is the right answer. 2FA is a hack put in place to mitigate passwords being relatively insecure and phishable. It's supplanted by Passkeys.
My thumbprint isn't stored on my phone, so I have two factors.
From the PCI Security Standards supplement on MFA,
> The issue with authentication credentials embedded into the device is a potential loss of independence between factors—i.e., physical possession of the device can grant access to a secret (something you know) as well as a token (something you have) such as the device itself, or a certificate or software token stored or generated on the device. As such, independence of authentication factors is often accomplished through physical separation of the factors; however, highly robust and isolated execution environments (such as a Trusted Execution Environment [TEE], Secure Element [SE], and Trusted Platform Module [TPM]) may also be able to meet the independence requirements.
So your phone can constitute a token, while the biometric constitutes the second factor. I don't know about Apple phones, but Google's requirements for biometrics are:
> Capturing and recognizing your fingerprint must happen in a secure part of the hardware known as a Trusted Execution Environment (TEE).
> Hardware access must be limited to the TEE and protected by an SELinux policy.
> Fingerprint data must be secured within sensor hardware or trusted memory so that images of your fingerprint aren't accessible.
There are plenty of things for which a 2FA in PW manager is fine, but the most important things I think it's an unnecesary and regretful reduction in security. For example, email account. Email is the "forgot password" way to get access to almost everything, so it's worth a trifling inconvenience in having to load your 2FA into a different app. Same with things like AWS, Cloudflare, and other high-value targets. For the vast majority of people, keeping your Twitter seeds in your PW manager is fine, but it's foolish to do that with your email and other high-value targets, and IMHO if you're already going to have to have two apps, you might as well just standardize and keep the seeds in your authenticator app, and your passwords in your vault. YMMV
The person I was responding to was arguing that totp in pw manager is no good. Maybe you meant to reply to them and not me?
> I think 99.999% of the time storing your 2FA codes in your PW manager, or just moving on to Passkeys, is the right answer.
If you're storing your 2FA codes in your PW manager, then you're NOT using separate apps. You're using the same app (your PW manager). My argument is that you should use separate apps for the things that matter, like your email (which can be used to get access to almost every other account), and since you're already using separate apps for those things, you might as well just be consistent so you don't have to remember where each TOTP token is stored.
I see three levels we've discussed:
1. Pure 2FA using hardware token or equivalent (which I agree is rarely needed)
2. Impure 2FA but separate app for storing passwords and TOTP tokens (which I'm advocating for)
3. Storing TOTP tokens in PW manager (which you appear to be arguing for in 99.999% of cases, which is basically all of them)
If you are actually advocating for level 2, then we agree, but from reading your 2nd paragraph it seems pretty clearly to be arguing for level 3.
That's a pretty user-hostile attitude. Sure, some combinations of factors are pretty unergonomic, but I'd call that a bug, not a feature.
It's also incorrectly suggesting that somehow complexity/painful usability automatically yields security, while usually the opposite is true:
An effective secure authentication solution absolutely must consider usability, or it's doomed to be circumvented by users in one way or another (either via some insecure practice, or by your users simply ceasing to be your users).
It does obviously not protect against the scenario where someone is breaking into your password vault.
I tend to enable 2FA but conveniently save the token in the PW manager for relatively low equity stuff, just to make it less enticing for an attacker, but use hardware FIDO for everything actually important.
TOTP is trivially phishable via evil nginx just like your password, and via social engineering.
FIDO2 is not phishable and you have no secret to give out to social engineering attacks.
Is it? I've been on the Internet since the 80s and haven't been phished a single time (despite being the recipient of many obvious attempts). Maybe I could be phished, but I think that's evidence it's not trivial.
I have to wonder how many people sophisticated enough to use and pay for a password manager like Bitwarden could be "trivially" phished.
The phishability of TOTP really is exactly as bad as that of passwords, except that a once-phished TOTP isn't reusable by the attacker(s), unlike a phished password.
But even one-time access is often catastrophic, especially if it allows the attacker to rotate credentials.
(I do use Aegis as I like the UX but that's a separate topic)
I've been debating for ages if this is a hurdle that can be overcome by packaging or even hand-holding support. When I show "normal people" my pass+sync setup they beg me to implement it for them. Once it's running it's near-zero maintenance.
You don't have to trust the single cloud provider to encrypt and not be able to spy. The vault is encrypted on your own device using fully open software, and the cloud only ever sees a blob they have no keys to, directly or indirectly. The encrypting/decrypting software was not written by the cloud provider.
You don't have to trust any single cloud provider to stay up, be available in your country, stay friendly to you. If Dropbox goes down or kills your account, you just flip to any of 20 other options.
You say you don't understand why someone prefers Dropbox over the special custom syncing, but I don't understand what the excuse is for a special vendor-specific implimentation of something that is already generic and agnostic. It's like using a browser that uses it's own version of http to download files and only works with one web site that has the matching special server.
It's not a remotely equivalent comparison between "one cloud" and "another cloud". One is a single vendor-specific, custom purpose, single-provider thing, the other is agnostic and infinite, use any method you want from any provider you want any time you want.
For me it's not about "mitigating a real or percieved threat". It's just basic system resilience and principle to avoid special things and prefer generic/agnostic things, and keep concerns seperated. But it is also more secure not to trust any integrated cloud provider, vs having the cloud be just storage that doesn't know anything about the blob being stored, and can't even if they turn bad, or are pressured by a government, or get hacked, etc.
No local backup? Do you rely on the network working all the time?
I do something similar on the mobile phone (the reasining is, if there's no network, there's nothing I need to login to) but I also keep a local copy on my laptop (that I sometimes operate with limited connectivity). Without any automatic syncing, one of the two copies will be stale.
Normal dropbox behavior keeps a copy on every computer.
Ah, you mean by using some app or daemon. I excluded that possibility because on at least one of my laptops I'm not allowed to install anything, so for me "normal" behavior is using Dropbox as a container for files to download when needed.
And maybe you could write a small shell script to keep that particular file up to date?
Also the one program I've used that opens keepass files directly from dropbox servers keeps a local copy.
I recently mounted a HDD that was at my parents' house. Most files are from 2009-2012ish. I was there one summer between undergrad and grad school and used it for a couple months.
I found an Opera password list that I'd exported, presumably to copy over to my new laptop. It was fun last night skimming the list, seeing which websites I'd completely forgotten about that I used to have accounts for. Almost none of them even exist anymore besides the big players (Slashdot, Apple, etc.), but the point is *almost all of them had the same password*. o.O
Thankfully the incredible hype for passkeys has been dead for years now and people are starting to question it.
With passkeys, both the website and the user can be pretty sure that the "password" is secure. The website knows that it's based on enough entropy, and the user knows that the website can not loose it.
Of course if I use a random generated 80 char password I only mildly care if the website stores it plain text or not.
But if I was a site operator, I could additionally trust that the users are using secure passwords. Without insane strength requirements (which people only work around anyway, e.g. Passw0rd!123 is usually accepted, but thisisasuperlongpassphrase often is not).
I'm in the business of testing security, which means I sometimes crack passwords. No matter how much training you put your employees through: Somebody gonna use ${some name}${0 or 1 special char}${some birthday} - is it's the spouse, kids or affairs data, your guess is as good as mine.
I'm not talking about technical merits, we all know passkeys are so complex they might work decently as obfuscation alone ;)
No, all that crap is meaningless when you give all your keys to an entity that simultaneously locks you in and couldn't give a fuck about you.
Also, some normal people are computer-smart enough to understand problems like credential-stuffing, if someone explains it to them.
Interesting, I've always felt that browser-based password managers provided remarkably little value for most people. Using them on mobile is tricky and platform dependent, it's easy to have local-only, non-synced data and then lose it, and being multi-device is trickier, especially in a work context.
On the other hand, people generally understand installing an app on each device they own and that app doing it for them.
I also recommend it to my friend group, as they can use firefox with uBlock Origin, and also have their passwords synced.
It's genuinely delicious
Watching friends and family struggle with bespoke, poorly integrated password managers makes me cringe and is one of the big reasons I enjoy the seamless experience of the built-in Firefox password manager.
I know for Safari all the sync is via iCloud meaning if you're not signed in it's locally stored and vulnerable in that way. Especially as many people can't/don't sign in to their own iCloud on work computers, or don't have a Mac.
This blog post goes over some of that history: https://blog.mozilla.org/services/2014/04/30/firefox-syncs-n...
The passwords are available offline, so they are stored locally.
Well, that’s kind of the problem isn’t it?
Yes, you can put bogus URLs, but it’s far from a great user experience
Kind of hope regulation will force apple/google/ms to allow iterations for 3rd parties to integrate with the os but on the other hand that will open a host of issues
I use both. Apple's manager supports OTP generation which is nice, but on desktop websites, Firefox is often more convenient.
[0] https://apps.apple.com/app/strongbox-password-manager/id8972...
Context: https://github.com/strongbox-password-safe/Strongbox/issues/...
1. https://support.mozilla.org/en-US/kb/end-of-support-firefox-...
This provides a really terrible UX to "normal" users. I woulnd't recommend that option to anybody who doesn't already know what E2E is and what tradeoffs it has.
Google's implementation is a lot better in that regard, at least they offer plenty of avenues for account recovery.
an app like Firefox or Chrome, perhaps?
They provide the value of "you should, by design, have no idea what most of your passwords are; if you know any significant number of your passwords you probably have bad passwords".
And both Firefox and Chrome sync passwords between devices.
Much as with cell phone cameras, "the best camera is the one you have with you"; the best password manager is the one you have with you.
Storing copies is ok, though, provided that sensitive information is encrypted.
This means that any process on the computer can read them.
It also means that, unless you also use full disk encryption, a stolen device means you're fucked.
Chrome and Safari use the OS's keychain at least, so there is some level of security.
And a standalone password manager has its own encryption.
https://support.mozilla.org/en-US/kb/where-are-my-logins-sto...
> Mozilla accounts uses your password to encrypt your data (such as bookmarks and passwords) for extra security. When you forget your password and have to reset it, this data could be erased. To prevent this from happening, generate your unique account recovery key before forgetting or resetting your password.
But you are maybe right, if the only browsers you use are Firefox desktop/mobile.
+1. I use my password manager (currently 1Password, but I have been looking at self-hosting Bitwarden/Vaultwarden) more for storing credit card information and security questions.
Most built-in password managers don't cut it on that front.
There's at least one API-compatible alternative (vaultwarden) which works with the official client.
Yay to breaking down walls.
No idea how this maps into Bitwarden's own offerings though but all clients support this kind of thing
BW clients support having several accounts at once so you're not forced to choose. Your family can have a regular bitwarden.com account and your vw.example.com account just for emergency access
It's kind of funny to see how gen x in particular deals with aging. For example, menopause memes as gen x women hit perimenopause. We're supposed to be all nonchalant and cynical, and it's interesting to see those attitudes hit the immovable object of aging.
Too good in what way that according to you "normal" people shouldn't be using Bitwarden? Or do you just like the Firefox one but are overselling it a bit too much?
I use Firefox, but I do not trust the Mozilla products. Bitwarden costs me $10/year so I wonder what is so amazing and groundbreaking about Firefox password sync, and does it work across browsers?
I use both Bitwarden and Firefox and I would strongly encourage everyone to not use the password manager in Firefox. Do you know the tab sync across devices is broken in firefox? It was broken since Aug 24 and it is still not fixed https://bugzilla.mozilla.org/show_bug.cgi?id=1913795 . If they can't sync tabs across devices, i wouldn't trust them to sync my passwords.
This was going around the last days: https://github.com/Sohimaster/Firefox-Passwords-Decryptor
If only they could add labels to the name/password combination. I have several accounts stored for a website, with generated gibberish logins that I cannot change and sometimes it takes me multiple tries to get to the correct account.
Also, sometimes a site has two password fields - two secret codes - and for this usecase the password manager doesn't work very well either and remembers only one field.
Other than that, I love how it just works, you add a password on one device and have it seamlessly available on the other with a very little setup. It's a nice experience.
Another usecase for named logins are those multiple routers that you administer for your friends and family that all have http://192.168.1.1
I don't doubt the quality of Firefox's password manager, or your honesty.
But normal people just don't use Firefox.
Normal people use Apple's built-in password manager.
Bitwarden excels here, and i think is the model to beat. However, Mozilla would have the advantage since their browser integration would essentially be built-in and first class.
Otherwise, unless you use Firefox exclusively for everything I just don't think a single browser is the right place to manage passwords. I would say that's true even for a broad audience, given the importance of passwords and security in the modern age.
Bitwarden is also nice in that you can "lock" access to your passwords while keeping the browser open. That way, for the 99% of the time you're just browsing the internet you essentially don't have access to all your passwords "open". The last time I looked at this I had to enter my master password on opening Firefox, even if I didn't need access to my passwords. That meant that "unlocking your vault" is essentially tied to opening the browser. That alone was enough for me to bail on it.
Funny, especially now that I see Apple are now going the other way with a dedicated "Passwords" app on iOS 18 and macOS 15. And for Apple to do this - against their instinct for featureless simplicity and implicit integration - to give passwords their own "shop front" as a dedicated app I think really does acknowledge the first-class importance that passwords now have, even for a broad audience.
It's a shame as I think Mozilla could really compete well in this space. They are both cross-platform, have their their own browser and have a good reputation on privacy. It's a killer combo. Bitwarden is evidence you can make it work and you don't need massive big-tech budgets to make a difference.
They used to have one called LockWise https://support.mozilla.org/en-US/kb/end-of-support-firefox-...
https://old.reddit.com/r/Syncthing/comments/1g7zpvm/syncthin...
Finally, Bitwarden (the payed version) manager also passkeys and OTP codes, the Firefox password manager not.
I wouldn't say it's good, but it does its job, if you can live with the insecurity and limitations. It's very comfortable, which is the only reason I'm still using it over KeePass and Bitwarden. KeepPass has no reliable Browser-integration, and Bitwarden is hard to selfhost. Firefox Passwordmanager is just there, always works, syncs without hassle, usability at it's peak (for this job).
It's trivial to self host. I've been running it in a GCP free tier VM for years.
But a lot of "normal people" actually need a secrets manager which is larger in scope than just a "websites urls passwords manager". This means a password manager with extra metadata fields for users to add notes, associated email aliases, etc. E.g. if a website has an extra step of "Confirm your identity by answering this question : What was your childhood pet's name?", users want a place to save the answer ("BugsBunny") in the "notes" field of a password manager.) Another example would be the secret PIN unlock code for the spouse's phone. That's not a website url, it's just a "secret" that needs to be stored in an encrypted file.
Firefox password manager is too bare-bones with the only 2 fields being "Username" & "Password".
The better UI/UX for normal people is to have a unified app to store all their secrets instead of having some secrets in the Firefox password manager and other non-web-url secrets saved separately in yet another app.
Here's why I recommend bitwarden to "my mom":
- It stores and fills in all your website passwords on your phone and on your laptop
- It makes it easy to generate new passwords for all these places
- It stores your PIN for your bank-accounts (in many EU country payments with PIN are the default)
- It stores your creditcard info and 3d passwords or other extra secrets it requires.
- It's the perfect place to store SSN, Tax IDs, "whats was the name of your first pet?" and so on.
I've never understood the rigid structure of e.g. Firefox or even lastpass, where they e.g. insist on having an URL or even insist on a username/password. I want secret notes with optional metadata - metadata that may follow a predefined structure (username, OTP secret, url, etc) but not always. Bitwarden does this much better IMO.
Also, I regularly hop between 3 machines + a personal phone and a work phone, and I love being able to have access to my logins + secure notes across all 5 devices.
All for the cost of a coffee/month.
The same applies to the password manager any other browser.
I carry with me my keepass db inside my phone and I can use it anywhere at any time.
I just checked it and it looks really basic, right? No OTP, no multiple URLs, no special URL matching?
Where is its "goodness" (I may have missed something entirely)
lol, sorry but this is a ridiculously narrow opinion and wouldn’t even apply to my SO and me as a two person team.
Hmm, maybe I want my passwords on my phone?
There is of course the KeePass ecosystem, but that is why I included my second point, as with KeePass you are responsible for vault syncing, having clients for all platforms, etc.
I suppose that it is good to be aware of other options. At the same time, jumping ship so easily also doesn't seem realistic or ideal behavior to me.
Again, I literally found them the other day, and other than a cursory check to make sure the UI/UX is friendly enough to compete with BW or 1P, I haven't had a chance to look through their code at all yet. I have no idea if the promises they document are met.
keepass works in browser (how I use it on a computer), can work offline (which is good in air-gapped instances, one of my reqs) and works directly on my android phone without issue.
Keeweb for example has not had an active maintainer since 2022 https://github.com/keeweb/keeweb/issues/2022
Also, sometimes the bitwarden client decides to blow away my local copy of the password database. I'd like it to store it pesistently on all machines so I have to lose my phone, my laptop, my vaultwarden server and its two backups before I get locked out of everything.
Currently, the phone + laptop don't count as backup copies.
So how does your browser extension work when outside your LAN? via Tailscale or similar VPN mesh? And for people who use it outside of the LAN entirely?
I don't run the browser extension. (There have been too many other password managers with exploitable password bugs.)
I back things up fairly often, but otherwise I would have no idea I'm not just using the enterprise grade Bitwarden license. Things just work, features are there.
Side-note - VaultWarden is incredibly reliable for a self-hosted free solution (I have 1 pod restart 27 days ago due to a power outage, but otherwise it basically does not fall over. No memory leaks, no high cpu consumption, no reliability problems)
Backups are also fairly easy so if need be a DR can be done (and automated) with very little hassle. The vaultwarden backend does depend upon the bitwarden apps for client devices but also features it's own web UI.
Normally this would mean you are shadow banned, but I don't see any other comments in your history getting this treatment - perhaps this comment caught the ire of some anti-spam algorithm.
Breakage is not ideal, but here's how they handled the second, more subtle compatibility break:
https://github.com/dani-garcia/vaultwarden/issues/5069
I haven't worked up the courage / time to back up my database and upgrade the docker container; will probably get to it this weekend. However, I can't imagine using bitwarden with the official server (too bloated to be trustworthy), or with their cloud thing. I got burnt by lastpass. I'm not putting my passwords in a giant high-value target again.
One thing I do not like (or, say, "miss") in Bitwarden/Vautwarden is the ability to make decrypted backups. I run the service for my immediate family and would like to have access to some people's passwords (of course with their agreement) to make sure they are fine.
A solution is to use Organizations but you cannot have a "organization-only account" - an account that would exclusively save to an organization without a private vault.
The "solution" is to tell people to move what they save to such and such Org but this works fine with me, recently with my wife but somehow my father does not do it and we sometimes end up with tense moments when it is time to get to some accounts :)
I use them both. I have KeePassXC for my local machine, and Bitwarden for things I may need out and about.
With the browser plugins for both it's not that hard to manage them both, at least in my opinion.
I was hoping to see some course correction on this from Bitwarden, even if the over-stated impact was really just to the SDK. They appear to understand the look of their licensing move was going to cost them more than it probably should have. Most companies refuse to change course at all, so I at least see it as encouraging.
edit to fix a typo
I used 1Password for years until they went from one-time payment to monthly sub and removed local sync so you could only use multiple devices by paying them. I think a big decision there was that they wanted $10/mo or something. I can't remember, but at the time it seemed ludicrous.
Years later, when my new laptop couldn't run the final local-sync version of 1Password, I finally decide to look into password managers again, and lo and behold $3/mo. I signed up immediately.
Though I don't understand why this git commit is what's linked here. I'd rather hear the discussions on it. https://github.com/bitwarden/clients/issues/11611
The opening comment and the final reply are the only valuable contributions in that issue. Everything in between is random people jumping in to feign outrage or telling people to use Vaultwarden (which btw recently was in the news for more significant negative reasons). If anything it's a perfect example of the sad state of online discourse.
It looks to me like people expressed genuine concerns about being lied to by a company, one they'd trusted with their passwords no less. Calling it "feigned outrage" is a bit rude.
Do you by chance mean CVE-2024-{39924, 39925, 39926}?
Were there any other recent issues?
https://github.com/bitwarden/sdk-internal/commit/db648d7ea85...
I pay for Bitwarden based on the premise that it is open source. If it tries to pull a Meta and decide that "open source" suddenly means whatever they want it to mean in defiance of the commonly-understood meaning, I want to know about it.
I'm glad they righted the ship on this.
Hope it works out for them, though. It's a good product.
For instance, Google can use bash in their backend infrastructure, but Apple cannot ship it on MacBooks or iOS anymore.
SaaS didn't exist when the GPL was drafted. If that's an issue for you, there's the AGPL.
If you mean v3, this isn't true. AGPLv3 is written the same time as GPLv3, and references each other to maintain compatibility (a special provision that lets you use code in the other license provided you follow the other license for that component)
> The default license throughout the repository is your choice of GPL v3.0 OR BITWARDEN SOFTWARE DEVELOPMENT KIT LICENSE unless the header specifies another license. Anything contained within a directory named bitwarden_license is covered solely by the BITWARDEN SOFTWARE DEVELOPMENT KIT LICENSE.
They've done largely the right things for _years_ in terms of security. They've operated pretty transparently in terms of open sourcing. They've allowed vaultwarden to exist, and eventually created a self hostable version as well.
But one bad release with a license screw up and nobody is willing to give them an inch?
I will continue to use bitwarden, and am willing to give them the benefit of the doubt. Especially considering this action above. They are a company that is perfectly toeing the free/oss and commercial line.
Years later they switched to Argon, somehow solving all of the blocking problems they had repeatedly claimed they couldn’t fix.
I don’t trust the org at all. The software is ok but I only use it because it sucks marginally less than all my other options.
People who care about software freedoms don’t release proprietary software. Organizations like this or Microsoft are just engaging in open source cosplay.
You're not the one who first reported it, but I did see your comments at the time. Calling them hostile is really the pot calling the kettle black, uh?
What worries me, though, that people who should have known better commit such oopsie daisies more and more (across many projects, I don’t mean this one only), almost as if they are testing the waters to see what they can get away with.
I think if it's a pattern then it's no accident. Of course people will test things. Kids, dogs, it's all the same: if you can get away with something, why not do it?
I don't have a lot of context on the issue.
Is it clear it was just a packaging bug, rather than a move towards partially proprietary?
CTO: > There are no plans to adjust the SDK license at this time. We will continue to publish to our own F-Droid repo at https://mobileapp.bitwarden.com/fdroid/repo/
https://github.com/bitwarden/sdk/issues/898
Doesn't seem like a mistake or unintentional action.
I wasn't thinking that at all. BW started as open source afaik.
Plenty of other products started slipping downhill after management saw a need to change the license. Why else would you change your license terms if its not to then be able to change your business practises down the road?
I don't see how you think introducing a GPL license is gonna lead to worse business practices? Unless you don't know what the license is.
Android: Keepass2 android.
Use syncthing to stay in sync.
Another thing I recommend is to enable versioning on syncthing for the database. This way accidental changes can be reverted easily.
Running vaultwarden on a home server is one small disaster away from losing everything. Homelabs typically don't enjoy the same level of protections and redundancies compared to a commercial DC.
This should be easy to encrypt and decrypt on all operating systems, and would make it easy to move your vault to a new password manager.
you could recover from that
It just creates a git repository that I can back up wherever I want.
Presumably they are able to do it because they own the rights and can grant a non-GPL license to Apple for distribution.
This seems to me to still be a “nobody can fork this [and still have a viable iOS app] but us”.
I remember pre-COVID trying to validate the popular claim that the App Store terms were incompatible with GPLv3 but being unable to do so. None of the provisions that were originally called out by the FSF were in the App Store terms anymore at that point. Certainly nothing I found in the terms at the time indicated any incompatibility.
Maybe the European Union comes to the rescue... (for Europeans)
Its rough, but functional, an exercise not a real product, never expected to be a real product. https://github.com/funvill/FancyGorillaPasswordManager
The tech is easy. Website, Browser extension, iOS, Android, Windows, Linux, MacOS apps done in less then a day.
Gaining trust is hard, who is going to trust a random guy on the internet.
We just need to rally together a community that would maintain such a fork.
https://github.com/bitwarden/ios?tab=GPL-3.0-1-ov-file
Is proprietary config required to build the IPA file?
Looking into it again, it seems like the Apple Media Services T&C now has provisions for distributing apps under a "Custom EULA", but it still has weird clauses like the one saying you can't "scrape, copy, or perform measurement, analysis, or monitoring of, any portion of the Content", which their definition of includes apps. (Ridiculous clause since it prohibits so much as looking at an app with Activity Monitor, but whatever.) The GPLv3 has a provision saying users can ignore additional restrictions, but you as an App Store uploader aren't in a position to grant that right, so... the situation still seems legally iffy enough that I'm not sure you could win against Bitwarden if they objected to a fork.
This comment might be more illuminating: https://github.com/bitwarden/clients/issues/11611#issuecomme...
https://support.apple.com/en-us/guide/passwords/mchl35b12625...
What I dislike about Apple Passwords is how tightly coupled everything is.
I just tried to set it up on my Windows 10 machine with a local account, but it requires Windows Hello to be turned on, which can't be done except with a Microsoft account.
Kinda ridiculous of them to force arbitrary restrictions on us.
Not of passkeys, to my knowledge.
> What I dislike about Apple Passwords is how tightly coupled everything is.
That’s definitely also discouraging me as well.
Yes, non-portable across different OEMs. But Apple Passwords app lets you export your passwords in a nice little simple csv file. It was a suspicion-filled (because it's Apple) pleasant surprise to find that out.
I don't know what it is, but password managers just love the high-speed enshittification train.
What are the alternatives for an open-source cross-platform password manager? Anybody has used Vaultwarden already?
Would love your feedback if you can take it for a spin!
[1] https://saveoursecrets.com/ [2] https://github.com/saveoursecrets/sdk [3] https://docs.rs/sos-sdk/latest/sos_sdk/
It doesn't sync between devices by default, but I see that as an advantage, you can use a cloud provider like Dropbox, your own server, FTP, Syncthing, whatever you're comfortable with.
Overall, I’ll stay a Bitwarden customer. People fuck up and I’m a tit-for-tat-with-random-forgiveness tactic user, not grim-trigger.
This said, I still recommend Bitwarden to my family. I moved to pass (https://www.passwordstore.org/) a while ago just because it corresponds better to my needs and I have more control.
There was a bug, it got fixed. Nothing to see here, move along.
It will years until it becomes awful but the process has started. It's really a shame every company has to do this with otherwise good products.
Yes the trust was seriously damaged, but this move does restore it largely for me.
> We have made some adjustments to how the SDK code is organized and packaged to allow you to build and run the app with only GPL/OSI licenses included. The sdk-internal package references in the clients now come from a new sdk-internal repository, which follows the licensing model we have historically used for all of our clients (see LICENSE_FAQ.md for more info). The sdk-internal reference only uses GPL licenses at this time. If the reference were to include Bitwarden License code in the future, we will provide a way to produce multiple build variants of the client, similar to what we do with web vault client builds.
I guess it's time for another FOSS player here. It's fine, such things are cyclical I guess. Happened to Lastpass and Authy and someday it will happen to Ente and 2FAS and so on.
I'm confused what you're responding to. You're making it sound like this was a bad decision and your anecdote was another thing for the pile, but this is a good decision.
Which is all the more ridiculous as this looks like it wasn't really a big license change decision but more of a "forgot to change the license on a component from our internal default". Assuming malice seems like the most boneheaded reaction to this given that there are no other indications Bitwarden was trying to do anything nefarious and the previous license state would have made every single library or tool depending on it non-free.
This is different from criticisms of Mozilla for example which often boil down to "Mozilla positioned itself as privacy-focused but adds a privacy-violating feature you have to opt out of while claiming it's actually fine". Bitwarden never was 100% FLOSS to begin with but introducing downstream license problems is clearly against their own interest. Unless you believe Bitwarden is run by evil idiots who do evil things for no good reason (business or otherwise) whatsoever and then quickly cover their tracks only when called out, "oops" is the only explanation that passes the sniff test.
Here's what someone from Bitwarden said in that issue:
https://github.com/bitwarden/clients/issues/11611#issuecomme...
I think the submission should be rephrased as "Bitwarden SDK fixed license of sub-component" or something. Which of course sounds less bold and interesting and newsworthy because it really isn't.
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/15353#...
> Additionally, one thought that came to mind in evaluating this that might make this not possible is that our rust SDK, a dependency, is not published under an OSS license. See https://github.com/bitwarden/sdk . I assume that is a problem that might disqualify us from the main [fdroid] repo still.
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/15353#...
> At the moment, there are no plans to adjust the SDK license.
Doesn't sound like a mistake:
https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
> There are no plans to adjust the SDK license at this time. We will continue to publish to our own F-Droid repo at https://mobileapp.bitwarden.com/fdroid/repo/
This does, though:
https://github.com/bitwarden/sdk/issues/898#issuecomment-242...
It seems they reconsidered after the change impacted their F-Droid release. They've always been Open Core not fully Open Source so the SDK not being OSS isn't surprising. It just seems like they didn't think about the consequences of integrating a non-OSS SDK into their OSS clients.
Your first quote actually explicitly says that this incompatibility only became apparent after the fact:
> one thought that came to mind in evaluating this
So, yeah, a mistake although it's not so much they "forgot to change the license" but didn't consider which license it should use and stuck with the default.
> There are no plans to adjust the SDK license at this time
This doesn't mean it was an intentional choice or well thought out. It would have been pretty stupid to say "yeah, we actually just went with proprietary because it's the internal default and didn't think about the pros and cons of keeping it that way" so in lieu of wanting to make a decision then and there or signaling radio silence, that's just a standard corporate non-answer.