backport master password verification support

[stefan0xC]

if you are using biometrics or pin to unlock your android device and then use that device to login, the user verification e.g. when exporting your personal vault will not work (cf. dani-garcia/vaultwarden#4875)

so we also need to backport bitwarden/clients@1043a58 to add server side master password verification support (bitwarden/clients#9523) for the v2024.6.2.patch

[stefan0xC]

patch files for future web-vaults should be less messy again as we don't need to backport this fixes.

the alternative to backporting those two commits would be to temporarily disable the master password verification for the v2024.6.2 web-vault as suggested here dani-garcia/vaultwarden#4628 (comment))

[BlackDex]

Either that, or we need to somehow add extra ways to add some cherry-picked patches.

But, lets first see if we can get a newer vault working at all.

[stefan0xC]

Well, I am kinda waiting on bitwarden/clients#10549 to be merged and released. I mean, we could also use the tw-fill-text-headers class as a workaround for now as suggested in #169 (comment) but I have not found the time or motivation to work on this at the moment. (And the other issue #169 (comment) is maybe not that big of a deal either but we probably want to use SVG instead of PNG for the logo.)

we need to somehow add extra ways to add some cherry-picked patches.

Since I'm using my soft fork approach to generate the patch file it's not a problem for me personally because I can just cherry-pick from future branches and adapt them as needed (cf. bitwarden/clients@web-v2024.6.2...stefan0xC:bitwarden_clients:v2024.6.2). And this specific commit includes changes to a not-yet-existing file for the CLI (apps/cli/src/oss-serve-configurator.ts) so we would have to ignore that too if we use another way to add cherry-picked patches. (I mean we could store them as separate patch files but what would be the benefit to the current approach? We would still have to apply them the same.)

[BlackDex]

With the soft-fork you could also have that as a sub-repo and maybe a shallow fork? Excluding specific directories not not being pulled at all?

I still have to see in more detail how the soft-fork is that much of a difference in the sense that the patches made and then doing a pull or whatever makes it difficult to maintain and update.

But i have not looked into it really good. If you have some (detailed) steps then i can try it my self.

Also, that way of working would be better for the vaultwarden GitHub project to be used instead of modifying this one 😄

[stefan0xC]

With the soft-fork you could also have that as a sub-repo and maybe a shallow fork? Excluding specific directories not not being pulled at all?

Maybe? I mean I was not really concerned with that. To me the benefit of my current approach is that I keep track of each web-vault version in a separate branch (as fork of the bitwarden/clients repo). I mean I have added this bitwarden_clients repo for testing purposes as a sub module to my bw_web_builds fork (which is mainly used to hold my scripts to update to the newest web-vault and create a compatible patch file to this repo) - I mean it will also be build using GitHub workflows when adding a tag but I have not really looked deeper into that myself - but like I said that is only for testing purposes (and I agree that this would be something for the vaultwarden organization).

My workflow in general is very straight-forward: fetching the latest web-vault release, creating a new branch from the tag (without the web- prefix) and then I git cherry-pick the changes from a previous release (e.g. web-v2024.7.1..v2024.7.1). While cherry-picking the changes for Vaultwarden I will have to fix each merge conflict when it comes up - so this still needs to be done but in my opinion it's much more convenient doing it interactively this way then manually applying the changes that could not be applied.

To create a compatible patch file for this repository I ignore the changes to certain files and directories (e.g. the icons, logos and images).