[-] unskilled5117@feddit.org 18 points 3 days ago

Update: A license was added

[-] unskilled5117@feddit.org 45 points 4 days ago* (last edited 4 days ago)

Great to see progress! Why is it behind their official github releases though? Latest version is 2024.10.2 and not 2024.09.0. It is four releases, meaning more than a month, behind.

[-] unskilled5117@feddit.org 214 points 2 weeks ago* (last edited 2 weeks ago)

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.

[-] unskilled5117@feddit.org 12 points 3 weeks ago

Great news!

[-] unskilled5117@feddit.org 3 points 3 weeks ago

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

Add support for biometric unlock on Linux

[-] unskilled5117@feddit.org 3 points 3 weeks ago

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

[-] unskilled5117@feddit.org 9 points 3 weeks ago

You could use your

to unlock the app instead of the password

[-] unskilled5117@feddit.org 12 points 3 weeks ago* (last edited 3 weeks ago)

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.

[-] unskilled5117@feddit.org 9 points 3 weeks ago

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?

[-] unskilled5117@feddit.org 12 points 3 weeks ago

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.

[-] unskilled5117@feddit.org 91 points 3 weeks ago* (last edited 3 weeks ago)

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).

[-] unskilled5117@feddit.org 4 points 3 weeks ago* (last edited 3 weeks ago)

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.

16

cross-posted from: https://feddit.org/post/3179293

Install instructions for OpenSuse Tumbleweed/ MicroOs using Full Disk Encryption secured by a TPM2 chip and measured boot or a FIDO2 key.

Nice to see OpenSuse pushing forward on securing the Linux Desktop with FDE and measured boot. Hope to see other distros following.

18

Install instructions for OpenSuse Tumbleweed/ MicroOs using Full Disk Encryption secured by a TPM2 chip and measured boot or a FIDO2 key.

Nice to see OpenSuse pushing forward on securing the Linux Desktop with FDE and measured boot. Hope to see other distros following.

31
submitted 2 months ago by unskilled5117@feddit.org to c/linux@lemmy.ml

I use 2 different computers in 2 different locations both running Universal Blue.

I was wondering if there is any way to create a backup system where i could backup Computer1 over the internet to Computer2 and continue work like nothing happened with all the user data and installed applications being there. The goal is to only need to transfer the user data/applications and no system data (that should be the same for both because of Ublue, right?), to keep the backup size small.

To be clear, i need help figuring out the backup part, not the transfering over the internet part.

If I were to backup the directories on Computer1, which store user data, with for example borgbackup, could I restore them on Computer2 and have a working system? Or would there be conflicts because of more low level stuff missing like applications and configs? Which directories would I need and which could be excluded?

Is there a better option? Any advice is appreciated!

I also came across btrfs snapshot capabilities and thought they could possibly used for this. But as far as I understand it, that would mean transferring the whole system and not only the data and applications. Am i missing something?

32
submitted 3 months ago by unskilled5117@feddit.org to c/linux@lemmy.world

OpenSuse leading the development in regards to boot security, an area in which Linux Distros are lagging behind other operating systems.

Full Disk Encryption is designed to protect data in cases of device loss, theft or unauthorized booting into an alternative operating system. Depending on the hardware configuration of a system, Aeon’s encryption will be set up in one of two modes: Default or Fallback.

Default Mode:

This mode utilizes the Trusted Platform Module(TPM) 2.0 chipset […], Aeon Desktop measures several aspects of the system’s integrity. These including:

  • UEFI Firmware
  • Secure Boot state (enabled or disabled)
  • Partition Table
  • Boot loader and drivers
  • Kernel and initrd (including kernel command line parameters)

These measurements are stored in the system’s TPM. During startup, the current state is compared with the stored measurements. If these match, the system boots normally.

view more: next ›

unskilled5117

joined 4 months ago