this post was submitted on 20 Oct 2024
627 points (87.4% liked)

Technology

59534 readers
3209 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] 486@lemmy.world 11 points 1 month ago (2 children)

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.

[–] Highsight@lemmy.world 9 points 1 month ago (1 children)

When I read this this morning, I had concerns, but then I did some research. The SDKs source is fully available for all to look at and compile. The main issue that people bring up is the license that states:

3.3 You may not use this SDK to develop applications for use with software other
than Bitwarden (including non-compatible implementations of Bitwarden) or to
develop another SDK.

This part seems to be what most people take issue with, as it makes the sdk no longer modifiable, yet a requirement of the core source itself. The head of BitWarden has come out and stated the SDK being required to compile BitWarden was a mistake, however, and if this proves to be true (which I have no reason to doubt) then I see no reason why any of this is an issue.

From a security standpoint, since the SDK is source available, it can be audited by anyone still (and compiled) so personally, I'm fine with this.

[–] 486@lemmy.world 4 points 1 month ago

The head of BitWarden has come out and stated the SDK being required to compile BitWarden was a mistake, however, and if this proves to be true (which I have no reason to doubt) then I see no reason why any of this is an issue.

I don't see why this should make any difference at all. Sure, I get why he is are saying they are going to fix it - he thinks that this gets them in compliance with the GPLv3. But from a practical point of view there is no difference at all. The software is useless without that SDK part. Even if it does indeed get them in the clear from a legal point of view (which I am not convinced that it actually does), it is still a crappy situation.

I think, it would look way less shady, if they said they are going fully source-available and not pretend that they are keeping the client open source. I would still dislike that, of course. At least that wouldn't have eroded the trust in them as much as it did for me.

[–] gwen@lemmy.dbzer0.com 3 points 1 month ago

oh shit i didnt know that, mb man