mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-02-05 00:29:40 +03:00
Bitwarden_rs Docker image uses confusingly identical Vault code without de/re-branding #66
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @taikedz on GitHub (Aug 6, 2018).
Problem
Bitwarden_rs seems to implement the features and interface of original Bitwarden to the exact detail, even parts that don't belong there, like billing pages and copyright notices attributed to
8bit Solutions LLCEnvironment
I'm running a bitwarden server using the instructions in the README.md of this project, namely using the
mprasil/bitwarden:latestimage.Description
I notice that all the Copyright notices at the bottom of the pages refer to
8bit Solutions LLCeven though the project is formally unassociated at all, and is a re-write...This can be cause of confusion, and would seem to be a misrepresentation, unless there's a reason?
Additionally, features like Organizations seem to behave like the original for no valid reason e.g. #96 ; the implementation in the web vault should probably not infer the need for any account levels at all, nor look like they're trying to "call home" for billing purposes.
@taikedz commented on GitHub (Aug 6, 2018):
I only just understood the "why" of the matter. During the image build, the web assets are pulled from the original repository.
It would probably mean an effort at image build time needs to sanitize the interface.... because an issue of trademark and representation still remains...
@blacs30 commented on GitHub (Aug 6, 2018):
I come from the bitwarden ruby originally but switched some weeks to this rust implementation.
There it was more separated between web and api, (container with the official bitwarden/web, the api, nginx with routing which exposes ports)which I basically agree on as it follows the separation of responsibilities.
Would be nice to have such a possibility here too.
The web ui is unchanged so shouldn't the copyright stay unchanged for it too?
@mprasil commented on GitHub (Aug 6, 2018):
Hi, I'm not sure we can do much here. We're basically serving bunch of static files here that we fetch directly from upstream. I'm afraid it would require significant patches to get rid of all the payment stuff and also significant maintenance effort unless the upstream allows for some branding in their code. I doubt they'd go that far to support 3rd party services without any benefit for them directly. (Which is understandable)
And let me just reiterate again, that no payment or anything else is required even if the interface is present, we don't limit the users in any way and there is no paywal as far as I'm aware.
@blacs30, you can do what you described. Just disable static files hosting and you'll be left with just the API. Then host your Vault somewhere else or with separate container just like with the Ruby version. The Vault hosting is just extra convenience, that is there but doesn't have to be.
@taikedz commented on GitHub (Aug 6, 2018):
Indeed, I understand that this would be fairly significant work, whether scripted somehow or fork-and-maintain ...
I'll presume a bespoke web-UI is completely off the cards at the moment...
@blacs30 That's like doing a school fair, putting home-made cola in a coke bottle and leaving the labelling "because it's their bottle." If things are different on the back-end, this should really be reflected in the front end.
In this instance, I'm understanding that the original UI is just pulled and provided for convenience in the Docker image. Since it's GPL code that shouldn't be a problem in itself, but as Mozilla, Red Hat and Canonical have shown, downstreams do not receive a systematic right as a result to deploy the trademarks that ship in the code.
I guess, at worst, it would simply mean the Docker image would not be able to provide the Vault UI as part of its deployment until trademarks are removed. If 8bit choose to assert their trademarks (or find that they need to, at the risk of otherwise losing them), this is a likely path that will arise.
I don't think this will be much of a problem in the immediate, but trademark issues/clashes have been known to be a thorny problem if left unresolved too long...
@mprasil And this feature is most appreciated, though quite undiscoverable at the moment :-)
I'm happy to consider this as "resolved" from my point of view. I originally thought it was an issue in the project's code, but it clearly is not.
@mprasil commented on GitHub (Aug 6, 2018):
I might ask upstream if they would be open to allow some (de)branding, but honestly they already did more than we could ask for. (And this only solves the problem for Vault, there are apps that have the same issue and can't be as easily replaced)
As for maintaining some debranding patches separately from upstream, this would require someone willing to dedicate some effort and willingness to maintain JavaScript code, which is definitely something I'd personally like to avoid. :) But hey, if you feel like handling that, maybe we could think about it?
As for disabling the Vault static files hosting, we really need to add that to the documentation, I guess it wasn't really high priority as you can just ignore it unless you have good reason to not have the Vault there at all. (Resource-wise it's probably negligible difference)
@taikedz commented on GitHub (Aug 6, 2018):
I was considering having a quick look at the upstream repo, and perhaps suggesting there a way for the Vault code to call some sort of feature check to the server, and not-load the back-end specific interface elements if it did not identify a compatible server ...
However, I don't really see a pull-request like that currying favour, for obvious reasons. Also my JS skills date from the pre-jquery era so...
and that would be fine, since what is of interest here is what is "provided" by the Docker container. When users download the apps, they do in fact get them from upstream's own website...
@ptman commented on GitHub (Aug 9, 2018):
This is a non-issue. The web app is copyright the original authors. This is like asking for Debian to rewrite the GNU branding on everything they ship. They did rebrand Firefox, because it was trademarked and they weren't allowed to use the branding. But that issue has now been resolved and Debian again ships Firefox instead of Iceweasel.
@mprasil commented on GitHub (Aug 13, 2018):
Documentation has been added, I'm going to resolve this. If anyone wants to somehow manage patched version of Vault, we should do that under separate issue.