Stories
Slash Boxes
Comments

SoylentNews is people

posted by hubie on Saturday May 18, @08:04AM   Printer-friendly

Team KeePassXC (@keepassxc@fosstodon.org):

Debian Users - Be aware the maintainer of the KeePassXC package for Debian has unilaterally decided to remove ALL features from it. You will need to switch to `keepassxc-full` to maintain capabilities once this lands outside of testing/sid.

The default install package is being changed to one where all extra functionality has been removed by default, such as networking capability and browser integration. There is a lot of arguing whether this was the proper way to handle it, or whether the default compiler options should have remained the same in the default package and a keepassxc-minimal optional package have been offered instead.

For those who rely on package managers, which approach would you have preferred?


Original Submission

This discussion was created by hubie (1068) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 2, Insightful) by Anonymous Coward on Saturday May 18, @09:03AM (1 child)

    by Anonymous Coward on Saturday May 18, @09:03AM (#1357478)

    Even though I use a full version of KeepassXC (compiled with the default flags on Gentoo), I understand different users may have different risk profiles, so the Debian bug report [debian.org] makes sense.
    Users still have choice, that’s what matters.
    As a user, if I update one day and notice loss of functionality, my first reaction is not to open a complaint bug report to the software developer or the package maintainer. Maybe I first try to understand what happened and whether I can do something about it myself. In such a case, I check the change log or the corresponding news item, then decide to reenable a compile flag or install a -full package.

    I also think both the KeepassXC developers side and the Debian package maintainer are being unnecessarily emotional in their exchange in the KeepassXC bug report.
    Counter-reaction after counter-reaction ("if you disable the flags, we’ll start removing them in future releases", e.g. %20 [soylentnews.org])" rel="url2html-657519">https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104750715/>) just sounds like a waste of time. I’d like to tell one side "just develop the software you want without caring how people use it" and the other side "why justify yourself anywhere except in your distribution’s website and materials?"

    • (Score: 2) by VLM on Saturday May 18, @03:51PM

      by VLM (445) on Saturday May 18, @03:51PM (#1357497)

      unnecessarily emotional in their exchange

      Whenever developers start quoting chapter and verse about what the users want and how the users feel, as if they ever have or had the faintest idea to begin with under any other historical circumstances, its similar to observed behavior on "normal" webforms where you know the conversation has degenerated into meaningless shitslinging once someone declares anyone I don't like is literally Hitler.

      You literally don't even have to read the entire ticket, once you see any kind of dev pompously declaring what the users want, you know the entire discussion is content-free and can be skipped.

  • (Score: 4, Insightful) by darkfeline on Saturday May 18, @09:38AM (1 child)

    by darkfeline (1030) on Saturday May 18, @09:38AM (#1357481) Homepage

    My approach is to use Arch, where it is trivial to fork a distro package, edit the build file, and build it locally (and beside, where the practice is to ship upstream without modifications).

    On to the actual drama, however...

    From a brief skim, it sounds like KeePassXC is adding a ton of "fancy" functionality, and some people do not like the potentially enlarged attack surface. I do think a password manager needs to be very careful what functionality they add, that it should not integrate with Yubikey by default, and that a native program should not add browser integration (which should be a browser extension).

    --
    Join the SDF Public Access UNIX System today!
    • (Score: 2) by krokodilerian on Saturday May 18, @02:58PM

      by krokodilerian (6979) on Saturday May 18, @02:58PM (#1357496)

      > My approach is to use Arch, where it is trivial to fork a distro package, edit the build file, and build it locally ...

      Hm. Where is this a serious problem? I do this with Debian packages all the time, and with RPMs once in a while. The RPMs are a bit shittier, but in general it's easy enough with most distros, I think.

      Distro maintainers are people too, and they too like to have things easy :)

  • (Score: 3, Insightful) by Mojibake Tengu on Saturday May 18, @01:53PM (3 children)

    by Mojibake Tengu (8598) on Saturday May 18, @01:53PM (#1357491) Journal

    I recommend every one of users to write their own password manager.

    If there are 10 billions different password managers out there, the agencies would find themselves out of luck and money.

    The same with encryption algorithms, though the humanity mindset is not yet ready for that.
    With Darwin principle at work, those who fail to reach that level of cyber cultivation will perish, sooner or later.

    --
    Rust programming language offends both my Intelligence and my Spirit.
    • (Score: 2, Interesting) by Anonymous Coward on Saturday May 18, @04:08PM (1 child)

      by Anonymous Coward on Saturday May 18, @04:08PM (#1357504)

      > I recommend every one of users to write their own password manager.

      That's what I do, and I'm not even a programmer. My password manager is a little book with passwords manually written inside. Before that they all fit on a single sheet of paper, but eventually I out-grew that and have been slowly migrating to the book, which has at least a hundred lined pages.

      Oh, that's not what you meant by "password manager"? Sorry...

      • (Score: 4, Insightful) by Ox0000 on Saturday May 18, @07:59PM

        by Ox0000 (5111) on Saturday May 18, @07:59PM (#1357529)

        As long as that book is stored securely, and your passphrases are unique, strong, and random, there is absolutely nothing wrong with your approach.

    • (Score: 2) by Ox0000 on Saturday May 18, @07:56PM

      by Ox0000 (5111) on Saturday May 18, @07:56PM (#1357528)

      While I think this particular suggestion is beyond "unwise" (NEVER write your own encryption, because you'll end up with encraption), I like the underlying methodology of salting the earth. In a way, this suggestion is a form of poisoning the well.

  • (Score: 4, Insightful) by BlueCoffee on Saturday May 18, @06:15PM

    by BlueCoffee (18257) on Saturday May 18, @06:15PM (#1357511)

    Give me feature, setting, and configuration overload and I can determine by myself what I want or need to enable or disable. One size does not fit all. If you are already using KeepassXC then you are smart enough to find it, and thus you are intelligent enough to enable the features you want, and know enough to disable the features you don't want.

(1)