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.

I think its a recent addition (08/2024) on Linux.

Add support for biometric unlock on Linux

According to the device support page i should be ok, but yeah there might be something weird going on.

You could use your

• fingerprint
• a pin

to unlock the app instead of the password

I hope I am not misunderstanding you. What you are worried about is passkeys in the password manager not syncing to new devices? They are though, with password managers that support passkeys like Bitwarden, ProtonPass, 1Password etc…

Currently using it on Bitwarden, if I log in to a new device, the passkeys are there.

Could you elaborate? I am assuming that everbody would have the password manager on their mobile phone with them, which is used to scan the qr code. I think that’s a reasonable assumption.

I agree that if you wanted the pc to act as the authenticator (device that has the passkey) it wouldn’t work with qr codes. But is that a usecase that happens at all for average people? Does anyone login to a mobile device that you don’t own, and you only have your pc nearby and not your own mobile phone?

The problem with passkeys is that they’re essentially a halfway house to a password manager, but tied to a specific platform in ways that aren’t obvious to a user at all, and liable to easily leave them unable to access of their accounts.

Agreed, in its current state I wouldn‘t teach someone less technically inclined to solely rely on passkeys saved by the default platform if you plan on using different devices, it just leads to trouble.

If you’re going to teach someone how to deal with all of this, and all the potential pitfalls that might lock them out of your service, you almost might as well teach them how to use a cross-platform password manager

Using a password manager is still the solution. Pick one where your passkeys can be safed and most of the authors problems are solved.

The only thing that remains is how to log in if you are not on a device you own (and don’t have the password manager). The author mentions it: the QR code approach for cross device sign in. I don’t think it’s cumbersome, i think it’s actually a great and foolproof way to sign in. I have yet to find a website which implements it though (Edit: Might be my specific setup‘s fault).

I think it‘s fair to remain skeptical but the big organizations were part of the development, so there seems to be some interest. And it‘s not always in their interest to lock users in, when it also prevents users from switching to their platform.

Development of technical standards can often be a fraught bureaucratic process, but the creation of CXP seems to have been positive and collaborative. Researchers from the password managers 1Password, Bitwarden, Dashlane, NordPass, and Enpass all worked on CXP, as did those from the identity providers Okta as well as Apple, Google, Microsoft, Samsung, and SK Telecom.

The author of your blog post comes to this conclusion:

So do yourself a favour. Get something like bitwarden or if you like self hosting get vaultwarden. Let it generate your passwords and manage them. If you really want passkeys, put them in a password manager you control. But don’t use a platform controlled passkey store, and be very careful with security keys.

The protocol (CXP) which the article is about, would allow you to export the passkeys from the “platform controlled passkey store” and import them into e.g. Bitwarden. So i would imagine the author being in favor of the protocol.

The lock-in effect of passkeys is something that this protocol aims to solve though. The “only managed by your device” is what keeps us locked in, if there is no solution to export and import it on another device.

The protocol aims to make it easy to import and export passkeys so you can switch to a different provider. This way you won’t be stuck if you create passkeys e.g. on an Apple device and want to switch to e.g. Bitwarden or an offline password manager like KeyPassXC

The specifications are significant for a few reasons. CXP was created for passkeys and is meant to address a longstanding criticism that passkeys could contribute to user lock-in by making it prohibitively difficult for people to move between operating system vendors and types of devices. […] CXP aims to standardize the technical process for securely transferring them between platforms so users are free […].

Well then you‘ve said it yourself: “shortly after“ they were attacked. That is not really much of an argument.

Ich kann dir nur das aktuelle Interview der Lage der Nation mit Baerbock empfehlen. Es werden die Waffenlieferungen kritisch angesprochen. Ich finde es wichtig, ihre Position zu diesem Thema zu hören, um so die eigene Meinung besser bilden zu können. Hier der Link zur Online Version, falls kein Spotify genutzt wird.

The discussion around this isn’t differentiated enough. Germanys foreign Minister has explicitly stated that what was exported, is stuff whose purpose is defensive in nature, e.g. Ground to air missiles. I can’t say if that is true, though there is some corroborating material. Nevertheless arms exports is too general as a category in my opinion.

The dual root partitions we described in Deepin 20.5 are gone, but version 23 still sets up a moderately complex partitioning scheme, including an EFI system partition, a 1.5 GB /boot partition, a swap partition, and a 15 GB root partition, and the rest of the disk given to a partition labeled _dde_data. All are in plain old ext4 format, but there’s some magic being done with the data partition that we didn’t have time to trace. It appears to be mounted at multiple places, including /home, /var, /opt, and a mount point called /persistent beneath them all. We’re not sure exactly how it’s been done, but the distro has some kind of atomic installation facility with rollback.

Lack of proper documentation by Deepins Devs is enough of a red flag for me to never consider trying it.

Does anyone know why they switched to this new packaging format, especially since they, as far as i can tell, were using flatpak before? I cant find any explanation on it in blog posts or release notes. In general i find the information they provide on implementations (atomic updates etc.) rather minimal.

Some SATA and NVMe devices support hardware encryption (TCG OPAL2 standard) and with the latest cryptsetup LUKS devices can be configured to use hardware encryption to encrypt the data either by itself or together with the existing dm-crypt software encryption. Support for this feature was added in the latest cryptsetup upstream release and we’d like to provide an option for users to use this feature when installing Fedora with disk encryption.

As this is an expert option, it will be available only through the kickstart interface. […] There will be two new options to select either hardware encryption only or hardware encryption in combination with software encryption (analogous to the --hw-opal-only and --hw-opal options used when configuring hardware encryption with cryptsetup).

It‘s not only about using the tpm to unlock the FDE, you should be able to do that on every distro with systemd-cryptenroll. The part that is new, is the the measuring of the systems integrity. It’s a way to ensure that the firmware has not been tampered with, the boot loader is the one that was installed and has not been replaced, that the kernel is exactly the one that comes from the distribution, that the kernel command line is the one that we expect, and that the initrd that is used does not contain any extra binary that we do not control.