• 486@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 months ago

    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
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 months ago

      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.