• gwen@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 month ago

    can we start reading the articles and not just the headlines??? it literally says it’s a packaging bug

    • sugar_in_your_tea@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 month ago

      In general, if it’s Phoronix, I assume the headline is a bit more exaggerated. They put out pretty good content, but they also put out a lot of content, so the editing can be a little lacking IMO.

    • cmrn@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 month ago

      …in the update that came out after this article was posted and the discussion took place.

    • 486@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 month 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
        0
        ·
        1 month 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.

        • 486@lemmy.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          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.