Login
You're viewing the discuss.systems public feed.

Replies

  • 💬 0🔄 0⭐ 1
  • 💬 0🔄 0⭐ 4
  • bbukbbuk@mastodon.social
    Oct 13, 2026, 5:39 PM

    @eltonfc @ni @taschenorakel @keepassxc Well that settles it, it's staying uninstalled. I just tried the version in trixie and it crashed as soon as the lid shut. The errors I got led me to the github issue about autotype/wayland where the dev was very dismissive. A fail on process, stability, attitude, certainly not something I can trust. Why it's in the debian repo I just don't know.

    💬 1🔄 0⭐ 1
  • 💬 0🔄 0⭐ 1
  • bbukbbuk@mastodon.social
    Oct 13, 2026, 6:29 PM

    @eltonfc @whitequark @ni @taschenorakel

    You have my attention, though for something so critical I'd really prefer it to be in trixie to make sure updates are applied in a timely manner and integration tested with the relevant versions of the related components.

    Any plans to persuade a debian maintainer of the value of this package?

    💬 0🔄 0⭐ 1
  • 💬 1🔄 0⭐ 0
  • bbukbbuk@mastodon.social
    Oct 14, 2026, 6:29 AM

    @whitequark Thanks, but that doesn't fix the process and attitude of upstream. Switching to bsd instead to address the larger issue here.

    💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • bbukbbuk@mastodon.social
    Oct 14, 2026, 7:08 AM

    @whitequark What started as the mention of a possible bug evolved to a discussion about the trust of the package given the attitude of some dev's github comments and the AI policy of the team, which was more of an issue to me than the posible bug. Switching to bsd is solving the larger (slop) problem for me.

    If chipass was in trixie I'd be probably be using it now but instead I'm thankful I became inspired enough to start the bsd journey. Thanks for your hard work and sensible policies!

    💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • bbukbbuk@mastodon.social
    Oct 14, 2026, 7:24 AM

    @whitequark Ah, gotcha. Thought you meant file a bug against keepassxc. Thinking about it, I suspect debian wouldn't want multiple similar implementations of the same functionality and would defer to keepassxc.

    Maybe the solution would be a non-ai suite like we have non-free but that would require too much work since the package/dependency overlap would be hard to administer, and while licenses are clear, ai use is not.

    💬 1🔄 0⭐ 0
  • 💬 2🔄 0⭐ 0
  • ✧✦Catherine✦✧whitequark@treehouse.systems
    Oct 14, 2026, 7:31 AM

    @bbuk anyway, the upstream builds (we'll publish static Linux x86_64 binaries for the next release) have update checking, so you aren't missing much by not going with a Debian package

    💬 1🔄 0⭐ 0
  • bbukbbuk@mastodon.social
    Oct 14, 2026, 7:35 AM

    @whitequark Thanks but in general, I feel that such out of band update methods broaden the supplier chain attack surface of a system as well as increase the likelihood of issues between dependency versions.

    💬 1🔄 0⭐ 0
  • ✧✦Catherine✦✧whitequark@treehouse.systems
    Oct 14, 2026, 7:50 AM

    @bbuk I'm a lot more confident in our ability to build a reproducible binary for all of the supported architectures than I am confident in Linux distros' ability to do so (especially now that Debian voted in favor of using LLMs)

    💬 1🔄 0⭐ 0
  • bbukbbuk@mastodon.social
    Oct 14, 2026, 8:12 AM

    @whitequark That's a great point. I've delegated my trust of thousands of packages to debian because it's much easier than making the thousands of trust decisions myself, which would obviously be impossible.

    Which OS are you yourself using today to best incorporate the issues in "reflections on trusting trust"? Previously the smaller package numbers in bsd have discouraged me but that seems to be a winning feature now. As soon as I get to a bsd desktop I'll try out chipass!

    💬 1🔄 0⭐ 0
  • ✧✦Catherine✦✧whitequark@treehouse.systems
    Oct 14, 2026, 8:15 AM

    @bbuk still Debian, but only because like all of my spare cycles are spent on helping other people escape this fresh hell (not just via ChiPass, but also git-pages and FelineBuildServices)

    💬 1🔄 0⭐ 0
  • bbukbbuk@mastodon.social
    Oct 14, 2026, 8:24 AM

    @whitequark When the UK started their "government digital services" approach to move away from being beholden to the likes of fujitsu and hp they chose github. I was disappointed and told them they were doing the same thing but they didn't see it at the time. They remained at the mercy of the whims of the US feds/corps and will presumably get ICC'ed in due course.

    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • bbukbbuk@mastodon.social
    Oct 14, 2026, 7:46 AM

    @whitequark I wouldn't want to waste their time considering it for little old me that really doesn't care about passkeys anyway. It has been a while since I built a deb but IIRC the starting point are some config/make files and if upstream maintain those in the source it makes the package maintainer's life much easier and so more likely to be accepted. I could be talking out of my ass though.

    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • bbukbbuk@mastodon.social
    Oct 13, 2026, 6:48 PM

    @keepassxc @eltonfc @ni @taschenorakel github.com/keepassxreboot/keep

    Whether the debug that landed me there was the result of the crash or not I don't know.

    All I was after was a dead simple cli passkey manager, the GTK layout was tiny fonts/widgets and too enterprisey. Sadly the cli package doesn't support passkeys for reasons I'm not informed enough to understand. The whole browser integration concerns me though. I think I'm just opposed to the complexity of the architecture of passkeys.

    💬 1🔄 0⭐ 0
  • Team KeePassXCkeepassxc@fosstodon.org
    Oct 13, 2026, 6:59 PM

    @bbuk @eltonfc @ni @taschenorakel That thread is 8 years old. Back then, Qt had very buggy Wayland support. KeePassXC 2.7.12 and 2.8.0 are much more stable in that regard, as they use Qt 5.15 and Qt6, respectively. You may have come there with the "Wayland does not support QWindow::requestActivate()" message, but that's just a Qt-internal warning, not an error. We don't know of any "lid-close" crashes at the moment, so we'd need more info to help you.

    💬 2🔄 0⭐ 0
  • Team KeePassXCkeepassxc@fosstodon.org
    Oct 13, 2026, 7:01 PM

    @bbuk @eltonfc @ni @taschenorakel Passkeys are not supported by the CLI, because they require an established browser connection, and thus a permanent background session. Since the CLI doesn't provide that, it cannot support passkeys.

    💬 1🔄 0⭐ 0
  • bbukbbuk@mastodon.social
    Oct 13, 2026, 7:18 PM

    @keepassxc @eltonfc @ni @taschenorakel Well I feel that speaks to the over-complexity of the architecture (of passkeys, not your app). What kind of session, DBUS? ssh-agent seems to play nice with seahorse or whatever the gnome passphrase dialog is, is that kind of capability not usable?

    And sorry if I'm over-tagging people, just using the defaults, believe it or not I'm new to mastodon and social media in general.

    💬 1🔄 0⭐ 0
  • Team KeePassXCkeepassxc@fosstodon.org
    Oct 13, 2026, 7:21 PM

    @bbuk @eltonfc @ni @taschenorakel KeePassXC needs to be running in the background to respond to requests for passkeys. A CLI application doesn't do that, typically. We have an interactive CLI mode, but it doesn't have passkey support at the moment, as that would duplicate a lot of functionality.

    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • bbukbbuk@mastodon.social
    Oct 13, 2026, 7:13 PM

    @keepassxc @eltonfc @ni @taschenorakel No worries, maybe it got OOMed, maybe I've got bad RAM, thanks for providing a passkey solution anyway. The AI use here is the big no for me though. I'm fine with passwords and 2FA, KISS FTW. And the last comment was 2024, so the issue appeared to me to be still relevant and ongoing for 8 years.

    💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • bbukbbuk@mastodon.social
    Oct 13, 2026, 7:26 PM

    @taschenorakel I'm sorry, that statement does nothing to allay my fears. I don't accept that AI for code is inevitable, necessary, stable between releases, deterministic, or particularly useful. I'll prefer code that is developed only by humans even if it takes a little longer. It has worked fine for 70 years. I don't believe you will draw the line correctly, or that that line will stay in place, be honoured by all developers, or that those developers will remain as competent because of it.

    💬 0🔄 0⭐ 0