Login
You're viewing the discuss.systems public feed.
  • 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

Replies

  • 💬 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