- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
You must log in or # to comment.
This is an important issue IMO that needs to be addressed and the official response by Bitwardens CTO fails to do so.
There is not even a reason provided why such a proprietary license is deemed necessary for the SDK. Furthermore this wasn’t proactively communicated but noticed by users. The locking of the Github Issue indicates that discussion isn’t desired and further communication is not to be expected.
It is a step in the wrong direction after having accepted Venture Capital funding, which already put Bitwardens opensource future in doubt for many users.
This is another step in the wrong direction for a company that proudly uses the opensource slogan.
600 upvotes and only 10 downvotes on literal fake news. I wish readers were less lazy, it’s very frustrating.
Edit: made my statement a bit less toxic. I was mad.
I use to always recommend bitwarden to people. Now i feel like an idiot for doing so with them switching up. Ill be making the effort to move to keepassxc soon and host it myself.
They literally posted that this is a packaging bug and will be resolved.
That’s good news
Keepass vault synced over syncthing.
I keep not regretting it.
I was thinking the same. But, it is safe to share the password database like this?
I’ve always loved Keepass, however I moved away from it in 2012 as it and any file based vault has brute forcing issues. You need to track every copy of it that has been made and if any copy falls out of your hands, like if you lose a device, you need to do a password rotation on 100% of your passwords. Since its a file, its not possible to prevent brute forcing.
Daniel García, owner of the Vaultwarden repo, has recently taken employment for Bitwarden.
The plot thickens.
Honestly, if he can replace the current Bitwarden BE w/ Vaultwarden, that would be awesome! The last time I looked at the Bitwarden self-hostable BE, it was super heavy, which is the entire reason I was interested in Vaultwarden.
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 :)
And I am an ardent optimist, hence why I see it as a good thing.
But yes, worst case someone will fork it, and I’ll probably use that fork.
EDIT: The article has been updated and it was described as a “packaging bug” and not an intended change.
How many times do I need to pack up and move to the next “best option”
In this case, zero, because it’s a packaging bug, not an actual change in direction. Read the update on the article:
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.”
Next time, before jumping to conclusions, wait a day or two and see if the project says something.
Not sure who downvoted you, you literally quoted the article.
can we start reading the articles and not just the headlines??? it literally says it’s a packaging bug
It is really not just a packaging bug. If you read that comment of the Bitwarden person a little further, you’ll notice that he’s talking about that proprietary “SDK” library that they are integrating with their clients. Even if they manage to not actually link it directly with the client, but rather let the client talk to that library via some protocol - it doesn’t make the situation any better. The client won’t work without their proprietary “SDK”, no matter if they remove the build-time dependency or not.
