Debian Breaks KeepassXC Package For "Security"
ฝัง
- เผยแพร่เมื่อ 16 ก.ย. 2024
- Debian has a much bigger focus on security than many other Linux distros so much so that they will sometimes miss the mark like with this KeepassXC case, the issue is the maintainer won't revert the change.
==========Support The Channel==========
► Patreon: brodierobertso...
► Paypal: brodierobertso...
► Liberapay: brodierobertso...
► Amazon USA: brodierobertso...
==========Resources==========
KeepassXC Post: fosstodon.org/...
Debian Bug Report: bugs.debian.or...
Minimal Default: packages.debia...
Full Package: packages.debia...
Github Issue: github.com/kee...
Xscreensaver: bugs.debian.or...
MPV: github.com/mpv...
=========Video Platforms==========
🎥 Odysee: brodierobertso...
🎥 Podcast: techovertea.xy...
🎮 Gaming: brodierobertso...
==========Social Media==========
🎤 Discord: brodierobertso...
🐦 Twitter: brodierobertso...
🌐 Mastodon: brodierobertso...
🖥️ GitHub: brodierobertso...
==========Credits==========
🎨 Channel Art:
Profile Picture:
/ supercozman_draws
#Linux #Debian #OpenSource #FOSS
🎵 Ending music
Track: Debris & Jonth - Game Time [NCS Release]
Music provided by NoCopyrightSounds.
Watch: • Debris & Jonth - Game ...
Free Download / Stream: ncs.io/GameTime
DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation.
In other words, a maintainer deliberately broke a package then got mad when people didn't like that he deliberately broke a package.
That's hilarious and concise at the same time! 🤣
For consistency Debian should disable networking in all packages. Anything else would be unfair!
Better to disable the OS networking as well.
Disable the package manager, because it can install full version of keypassxc with networking functionality.
Create a separate repository called main-network and move every package that needs network to there, then disable it by default.
They should compile the kernel without networking
If the networking functionality isn't built by default... keepassxc has them all off by default and behind feature flags. I can kinda see the argument there.
Mozilla already found the solution to this back when they were at odds with Debian over long feature freezes and the security and compatibility implications.
Trademark rights. It's well within the upstream developers rights to say *sure, you can do this but you can't call it KeepassXC anymore"
Normally I frown on that tactic, but here it's entirely reasonable in order to deflect all the bug reports that should be going to the maintainer
Why do I hear Iceweasel boss music?
Honestly I don't get why more devs don't do this, like the dev of Bottles could just say anyone repackaging it has to rebrand it and have any support links send people to them so he doesn't have to get bug reports from anyone not using the Flatpak, or the dev of XScreensaver could require the same of anyone who doesn't keep it up to date.
@@t1m3f0x it's usually seen as a heavy-handed move, going against the spirit of open source.
Reaction to major user-hostile changes/policies by one or more downstream maintainers, or severe neglect by downstream maintainers are pretty much the only way a developer can do this without looking like the bad guy.
When it's done proactively, it makes the developer look like a control freak, and tends to encourage hard forking, which makes it self defeating.
@@StephanieDaughertygood take. Glad some people here understand nuance.
@@StephanieDaugherty What about something like requiring anyone repackaging your app to just call it app-name unofficial or something? and require they have all support links direct users to them, because users don't read instructions so even you say "only the Flatpak is supported" you're still going to get bug reports for things caused by their distro repackaging it. Just some kind of effort to get their users to go thru them for support instead of upstream.
This is 100% maintainer overreach. The maintainer believes that he should have a say in what features are and aren't enabled in the software. That is simply not true. The maintainer's job is to package the software and make sure it can be installed and run with no issues.
If the maintainer wants to offer a "minimal" version with no networking, he's free to make a "keepassxc-minimal" or "keepassxc-nonetwork" package. But mutilating the default package to the point where users feel the package is broken? No. Just no.
The maintained just reverted to the default build options, which is to enable nothing. Still ignores the best interest of users, but he has a point: if these features are important, they should be on by default.
“If you disagree you must be a fed”
@@szaszm_I wonder what the maintainer would do if the flags were default, perhaps then disable them? Like.... I don't see your point, they want a stripped down version as default, not just deciding to use default flags and made an oopsie?
just package the minimal under the same name. Users are used to the keepassxc package containing everything. Just distribute the minimal version under some other package
i am the package maintainer of sm64ex-coop for android.
i deliberately disable features in my version of the app that i consider harmful to my users' freedom and security.
at the moment, those are the closed-source BASS sound library and the closed-source discord game SDK.
in my opinion, *the creators of downstream packages have no obligation to obey orders from the app developers that aren't codified in the license* .
The whole purpose of independent distros is that they _choose their own settings and other people go to them if they like those default settings_ .
If you don't like the package name change, uninstall Debian and switch to one of the 16 other mainstream, popular independent distros.
I'm a KeepassXC user on Debian 12. I support a keepassxc-minimal and a keepassxc (full-fat) version so as not to break existing users ingrained workflow. The Yubikey issue is particularly egregious.
I've encountered people who consider any password manager insecure, so maybe Debian should just ship a book and pen by default to make those people happy?
Debian PostIt notes when????
I don't particularly have an opinion one way or another about password managers, but there is legitimate and logical reasoning to that argument. I would say is most fair to state that managers simply move the problem-space. Technically managers are adding a new attack vector, but are likewise helping to alleviate human-error. Comparing these two is apples/oranges in regards to which is more "secure", and will vary greatly from user to user.
I dunno, I think the argument that password managers by default are "insecure" is kind of ridiculous hyperbole. I don't usually see the same people who are making this claim also voicing concerns over the security of the countless websites, apps, services, etc. that they use many times per day, every day online which are secured by the same underlying encryption algorithms.
@@ForeverZer0 6 of one, half-a-dozen of the other.
Definitionally, any online storage of credentials is "insecure", but everything is about trade-offs - the level of security you need depends on your risks and costs, etc.
If you live is a low-risk environment or you only want to use a PW manager for unimportant sites, (i.e., anything NOT financial), that's really not a big deal.
A book has the problem that you'll probably keep it in your laptop bag, which could get stolen...
@@ForeverZer0 I kept it simple for the sake of the joke, but those people also have other bad security practices such as simple passwords or reusing passwords and it can become an organisational nightmare. Despite this, these people still felt that it was more secure to use a book over even an OFFLINE password manager.
The latter of which is why I made my joke because ultimately different people will have different ideas over what they think is more or less secure, such as the use of hardware keys.
they should remove the build option that allows a broken package to be built, then watch julian lose his mind 🤣🤣
This is so evil!
DEWIT!
I mean, if we're supposed to do this with guns, why not here too?
how about no. let gentoo users decide themselves what build flags they toggle.
Next up: Firefox, localhost only 👍
Edit: wait wait, even better: Firefox, but automatically block ports 80, 8080, 443, and 8443.
They can't as someone here already mentioned, Mozilla had balls to use trademark rights and block changes while still using their product name - so they can do any fork they want of "Firefox", but can't call it "Firefox" anymore.
@@Eshelion and what is wrong with that?
@@ChrisWijtmans Point where I said anything about something being wrong with that.
A web browser should connect to the network. A password manager should not. I've used old versions of keypassx for the past ~15 years -- and those old versions most definitely do not connect to the network.
Looks like I need to start looking for a replacement for keypassx if the project is going down this route.
I wonder if Debian will disable js by-default in Firefox going forward, that stuff is wild to exploit and is not safe for everyday users.
I just gotta go with Linus with this one "Don't break user-space", make a new package called minimal.
KeepassXC itself has the ability to enable/disable the browser integration built-in by default in the settings, that's up to the user and secure enough IMO.
I really don't want distro/repo maintainers to babysit me and make me loose hours asking myself what happened only to find out the packages i downloaded and installed are behaving differently and read each news files package just to check they f*d up base features.
Don't make me regret Windows MSI installer packages!
The approach of the package mentainer was really out of line. Especially since better options exist. If they don't want to make the full version the default they could have created two equal options, like -minimal and -full and set -full as the replacement for the existing package.
This way people upgrading won't loose functionality and new users have to make a deliberate choice.
Change the package so drastically and keeping the same name is just disrespectful to the developers.
Not to mention calling it shitty...
Yeah it just seems like a bad way to handle it the way they did. If they did it this way it wouldn't be so much of an issue.
Debian isn't arch where your xorg server by default listens to the internet. Sorry buddy, go back on the arch forums to tell someone to read the holy scriptures of the arch wiki.
@@nou712Debian is not Arch where xz vulnerability has not affected sshd
@nou712
It's very funny to see you imply that Arch is so much less secure than your beloved Debian... But at the same time, while Arch wasn't affected, both Debian Sid and Debian Testing were affected by the worst recent Linux vulnerability, the xz backdoor. They were affected specifically because Debian goes out of its way to patch openssh with systemd, which depends on liblzma (xz), thus making the attack vector possible, making the system vulnerable. Very wise decision from your beloved Debian packagers, bravo! (sarcasm).
While Arch is even more bleeding edge than Debian Sid, it wasn't affected by the xz backdoor simply because Arch makes a more "default" build of openssh, which does not link it to systemd nor xz, making the attack vector not possible on Arch systems. But yeah, go ahead and keep typing your b#llsh1t in the comment section... Lol
I think the solution is simple, 1. Debian needs a clear policy and 2. Debian maintainers MUST have a conversation with the upstream dev before gimping their application.
it is a policy to work with upstream though.
@@fu886 then they should probably enforce that policy
In that case mere fact that they didn't inform upstream should be enough to revert this decision, at least for now, and start working with them on the new solution.
"Gimping an application" is a great phrase in FOSS context hahahah
@@fu886 unless it's XScreenSaver
I love how they make it sound like using the functionality in the full version is basically the same as completely disabling your firewall. I would hope people this worried about networking functionality have their network unplugged whenever they're not actively downloading updates.
Downloading updates? From the internet? 😱 No, no, no I get my packets delivered to me via homing pigeon.
@@Etchacritic Good old RFC1149/RFC2549
@@Etchacritic Pigeon? That's ridiculously dangerous.
My packets are delivered in an armored van with 6 security officers as escort.
I'd rather they have their network unplugged forever tbh with the crap upstream has to deal with from them.
@@hubertnnn packets? Those are ridiculously dangerous.
They come from other people. I only write my software myself. Otherwise I don't know if the code is fully secure.
If I felt like being a jerk, I would just remove that compile flag entirely. Let them patch it back in every time if they want to keep using it. If they want to keep ruining the software I make, that's their problem!
I said in a comment above that I thought KeepassXC should break the haveibeenpwned check to an external tool so that KeepassXC could be denied the ability to connect to an external network and the other tool denied access to memory that might contain sensitive info. I mean, that might be actually useful hardening.
Debian keepassxc should become a dummy package that depends on a full or min package, with full being the default for upgrade purposes. Julian is doing KeepassXC, Debian, and Debian's users a great disservice here.
@@knghtbrd there is actually a script that did exactly that before the function was added. Must still be around somewhere...
Honestly I would remove the compile flag, screw the maintainer, his job is to distribute not decide what features should or should not be included.
good one... it's silly trusting #ifdefs more than the guys who put them there in the first place...
@@t1m3f0x You realise maintainers and packagers constantly cherry pick which compile flags to include in software? For example Firefox and Chromium and others have various settings that are enabled / disabled depending on the needs and wants of the maintainer and distribution.
Honestly, suggesting something like that sounds like something a 5 year old child with a temper tantrum would do.
I understand the change and wanting to avoid bloat, but a minimal package probably is more practical considering that this version has already been out, especially considering I’ve never heard the term “news file”.
I had to look that up too, as far as I understood, on Fedora it may be located in /usr/share/doc//NEWS
News files have been around since the dawn of Linux and was the only way you got to know about changes. Now people just Google stuff. Was you using Linux in the 90s then you would be defaulting to the news file
@@damiendye6623 sure, it exists since an eternity
you know what else exists since a very long time: landline phones
I don't know of a single person of about my age which still has one
what does this have to do with this?
simple: only because it exists since a long time and was commonly used at some point, doesn't mean, it still is
From my, admittedly limited, experience - news files are the epitome of low signal-to-noise ratio. I'm not surprised no-one reads them.
@@FraggleH Hey, I think it's the best thing to read through 10 pages of tiny changes that will probably not affect me on every upgrade.
As a security person myself i'm all for secure defaults. But it's a bit ridiculous to not compile in many values features which come in an disabled configuration anyway. Code that isn't executed isn't a real risk. Furthermore one can argue it's even less secure to have no autofill. So you're actually removing a feature that makes people more secure. What comes next? Debian ships a with a default kernel without netfilter because that code can have vulnerabilities?
Code that isn't executed isn't a risk? ROP buffer overflows disagree with you
up next: they start shipping it without any network support or any way to install packages for "security"
GUIs introduce a larger attack surface, Debian should not allow GUI applications by default. /s
@@0x00a If the code is not running it can not overflow the buff. Here what wikipedia said "A buffer overflow or buffer overrun is an anomaly whereby a program writes data to a buffer beyond the buffer's allocated memory, overwriting adjacent memory locations."
Buffers are areas of memory set aside to hold data
I would link wikipedia but youtube would delete it
Euh... if it's loading in a library, that's a risk, as we've seen from XC issue.
Including liblzma which is the same way it was linked to SSH (!)
Julian works for Canonical. So of course he’ll assume what’s best for end users, not listen to valid criticism, and not communicate effectively.
Ah, that explains it. This is why I don't use Ubuntu and never will.
sounds like a gnome dev fr
Uggghhh, I should've guessed.
Nice false equivalence you've got there
Ah, the usual suspects.
DON'T. BREAK. USERSPACE.
My one regret is that I have but one 👍 to give to this comment.
that's when a lib breaks API in next version and nothing works anymore
Debian maintainers: Instructions unclear. Breaks network functionality and yubikey support locking you out of all your passwords
@@kuroenekodemon
Well, what do you expect from an Ubuntu Dev that's allowed to mess with Debian.
@@Henry-sv3wvthat explains how I went from liking ubuntu and loving debian to hating ubuntu and feel confused by being irritated by debian.
I do use keepassxc but not Debian. I couldn't imagine doing a simple system upgrade then suddenly the YubiKey is not functioning. That sounds cray!
This only landed in Unstable, where breakage between updates is expected.
Or yknow, after you figure this out, you install the fully featured one and keep on chugging along as if nothing happened.
You must be new to this Linux thing. Back in the single-digit Ubuntu releases, every other system upgrade broke the WiFi on my laptop.
@@himagainstillback in the day, I'd swear doing nothing all was all it took to break WiFi support on laptops.
It IS insane, my goodness! 😱
Funny enough, I was reading an article about this a few hours ago and figured you'd be making a video about it. :D
Who wrote an article about it, I got sent the mastodon post directly
I basically get the arguments of both sides.
Calling it crappy was way over the top tho.
The MAJOR issue here is the hardware key issue. Password managers are a very integral part of most users workflows. Can we seriously allow an update to LOCK THEM OUT of their password manager? Seriously, nobody would ever imagine that happening. Imagine somebody has their root password in their database and elusively unlock using hardware keys. They only notice it after next restart of the app and then they might already be logged out of any privileged users, so they can't even install the full package.
Major oversight from the package maintainer!
Eh, both of my password managers, my history extension, my tab sorting extension, my proxy control extension, and most of my content blocking extensions are about to be cut off when googlechrome migrates to ManifestV3-only come June/July. I will not be a happy camper, but I've backed up everything I needed to, and have older chromium packages on standby, ready to counteract google's chosen path. Some of the stuff I rely on daily hasn't been touched by it's developer since 2018 (nor has it needed to be) and is risking removal just for being stable, much like Hacker's Keyboard on android, which I relied on for most SSH sessions... Fortunately, JuiceSSH picked up it's own internal keyboard layout with the Ctrl keys.
But it's quite annoying to be forced into these changes on what seems to be a yearly basis of ensh*ttification.
I think the example is not that realistic but yeah, just pulling the rug on features that users rely on is never a good idea.
I hope nobody uses Debian Sid in some critical production environments, or they kinda deserve to be screwed 😅
@@forzatoro89 Last time I used Debian, my options were "use a version of MySQL that had been out of support for multiple years in production" or "use unstable". So it would come as no surprise to me to be told that there are Debian servers running on unstable.
While security is the responsibility of the distro, overreaching and removing core features that will affect upstream like this is not their responsibility nor should they do it. provide a secondary package for those that don't need the feature. Browser integration, etc are very important and many many users use it, including me.
I wish people would stop calling package maintainers doing the thing package maintainers are supposed to do and expected to do "overreach".
You could even say this change makes it less secure, since you need to use the clipboard to input passwords, which is much less secure then the browser extension communication.
@serenity1378 If you think that a package maintainer doesn't get to decide how the code is built and packaged for their distribution, then it would appear that you're the one that fundamentally misunderstands what they're supposed to do.
As a user (On Windows anyway) It doesn't take a genius to know, if a feature suddenly doesn't work
people will not be pleased. I agree with the XScreensaver thing, you mess with my stuff. I mess with you
I don't care what the reason is, pulling the rug like that on people is incredibly inconsiderate.
It's not a single maintainer's job to be opinionated, but to follow whatever rules the distro sets,
while also not causing the developer grief by gutting a feature or whatever else. Shame on him
I'm reminded of Gnome 3's password manager not working, as in you cannot put half of the key types listed on the program's description and in its UI, I also remember looking into the why and finding out that the project is barely maintained and was relying on random user contributions.
utterly a joke.
@@Rexhunterj Sheeesh
They should've transitioned progressively puttin warning about the future limited release while providing the full one so people can prepare and adapt their workflow
But Julian's decision is good, this way he ensures people willingly choose "feature over security" in dependencies he doesn't control for a software he is responsible for
Props to Julian
Who cares about the Developer? He released as GPL, now debian can do with it what they want ...
@cialk calling his decision to go about it this way "good" is absolutely insane!
You sir, are absolutely insane! 🤦
I've never complained about my software being compiled with too many features, but I have had issues with missing features/dependencies/codecs. For server applications sure, tighten things up, but for desktop applications I expect all the features are available to me and just work at least on parity with the Windows builds of the same software. If features are intentionally disabled there should be clear indications of why. If I want some very specific compile flags and hardening which fit exactly my use case I'll used a source based distribution or otherwise compile it myself.
Wow that guy actually said on the fedi that calling other people's hard work that they provide to you for free "crap" is just a normal thing that we do here in Germany.
For the record: No. It's not. Like in pretty much any other country/culture that is obviously unacceptable. That's exclusively a this guy thing, not a german thing.
Where on the fedi?
@@kuhluhOG you know you can't put links in the yt comment section
@@kuhluhOG youtube won't let me tell you :(
@@AbteilungsleiterinBeiAntifaEV well, you can also describe how/where to find it since I didn't find it in the mastodon link from the description
@@kuhluhOG that's the right post though. Under that post someone else is calling out his language and it's in his reply to that. I can't find it either when I'm looking at it through fosstodon, but on my instance it's visible.
I think that the Debian council should formulate some simple procedures to keep package maintainers from knee-jerking like this. While it is very important to ensure that reactions are as quick as humanly possible in the case of issues like the XC debacle, bad decision-making like this should be tempered with common sense. The first major error was not including upstream in discussions, and the second (arguably even larger) error was to dig in an try to save face. This is a fight that nobody won, in fact there are only victims here. Debian is an enormously influential project, but even so it should not steamroll over upstream in this manner. Trust has been damaged. Julian, please grow up.
I am a keepassxc user. The unfortunate thing is browser integration and some of those features don’t work with the flatpak due to how flatpacks are isolated. Giving off the inferior feeling yes there is a way around it but at that point it’s just always easier to run the actual package because you basically have to break the flat pack.
Thankfully I’m on arch. But decisions like this make it really hard to recommend these distributions to family members who would be in that same case of not knowing what’s going on and then I have to fix it not knowing what happened either. It’s just too much work. I’m not sure about any of you but I don’t appreciate having to deal with tech Support phone calls at 3 am lol.
That’s why I’ve stopped recommending Linux. Linux is good if you are willing to invest(or loose) your time fixing issues and being updated with the latest community drama. I’m a long time Linux user(started with slackware) but as time passes, I get really annoyed by these kind of things.
I just wish there was a distro as stable as Debian but as bullshit-free as Arch.
@@A5A5A5A5h that would mostly be opensuse I think. At the. End of it all you can always make a distribution and maintain the packages you specifically use. Though that's a insane amount of work
I'm using Ubuntu with KeepassXC and I use my fido2 key to unlock my database. I vehemently disagree with Julian Klode here. The autofill option with sequence shuffeling is more secure than a simple copy-paste. Note that all the extra features apart from the basic functionality are disabled by default.
watch them remove the clipboard feature from the OS when clipboard attacks happen
yeah clipboard is an attack vector... like in ms windows.
Does Debian have any process in place for when a maintainer is straight up hostile towards upstream? I mean, they have to care about their relationships with the larger free and open source community, right?
right?
right?
As a long time open source maintainer I see where both parties are coming from. I think it’s entirely fair for Debian to package a minimal version as default, though arguably they should have done it via a more user friendly transition (e.g. a -full and -minimal package where the default package is equal to -full for now and then switched to -minimal in a new major version of Debian). I also think the bug reports against the repo are fair, features when compiled out provide no indication to the user that their omission is intentional because they were not enabled. The maintainers are not helpless in reducing incoming bug reports by updating the user experience when features are disabled. A simple documentation page can go a long way, or even updating their issue template to guide confused Debian users to the solution.
If only these options were configurable at runtime..... oh wait, they were opt in already. This is so dumb.
If you want to prevent an app from using network, have a firewall rule (I assume linux can attach firewall rules to program signatures?!?)
Pretty damn sure gufw and any GUI for it can
Thanks for the resources in the info box. Almost no "daily upload" youtuber provides their sources in the info box anymore. I am positively surprised you still do that.
So many things are done in the name of security which prevent security. One example is when some applications started preventing the user from cutting and pasting a password into the password field which made the use of password managers with really long passwords much more difficult. I haven't seen this for a while now, thankfully. Sometimes in the effort to make software idiot proof it ends up being smart person proof.
Lucky you. I run into that problem far more often with work software than I'd like.
Restricting which special characters can be used in combination with a requirement to regularly change the password is my favorite hated insecure practice in the name of "security"*:
Sooner or later, it just leads people to create simple passwords with NO special characters and "change" them by just adding the same character at the beginning or end for the eleventh time! 🤣🥳
*Obviously, the real reason is because the devs suck and their code can only handle a tiny selection of special characters .
I actually have a solution to this problem: it's called "not being an entitled dickhead". The maintainer's job is to provide users with the application they need. The maintainer's job is _not_ to tell the users what they need and don't need, or tell the developers how to develop their application, or pretend like he has ultimate authority over the developers' work. This maintainer should resign or be removed from the project immediately.
Seems to me that severely downgrading a package that users already have and expect to function mostly the same is a really bad idea.
And no, people aren't going to read every release note of every package on their system. Why would they? Maybe I'm just a casual user, but when I do an update, I don't expect to LOSE most of the functionality. Maybe I'll have to do something a different way. Maybe I'll need to convert some old file. Not "suddenly nothing works any more".
Also, Julian seems to hate the people that use his distribution.
the debian team might as well disconnect their PC's from the internet and leave to our devices whilst they hand deliver git diff's to eachother, it is after all the most secure option :P
GUIs are insecure, they introduce a larger attack surface. In fact running any process except the kernel is also problematic. So many attack surfaces! /s
@@futuzaThe Linux kernel is disgustingly bloated. All of that "hardware support" nonsense. I prefer to just use my BIOS menu for everything.
This was just fixed in Debian unstable a few hours ago. Now there are 2 packages: keepassxc-minimal and keepassxc-full, and normal keepassxc is a transitional package depending on keepassxc-full | keepassxc-minimal, i.e. people upgrading (or just installing keepassxc) will get the full version by default, but they can choose to install the minimal version if they want to.
Also, YubiKey support was reintroduced into keepassxc-minimal.
That makes sense. Glad things resolved sensibly, but I hate that 'drama' was required.
I'm support of a giant red bar saying "YOU ARE USING A MINIMAL VERSION OF THE APPLICATION. DO NOT LEAVE BUG REPORTS RELATED TO NETWORKING"
creating a minimal one was the best choice for everyone, Julian just being a total cannonical employee as always!
So why should people not be vocal about these guy? Cause it hurts his feelings ? i can live with that. Thats how society works, if you act like shit towards others you get a fitting response. In times before the internet being a ass to others would sooner or later lead to someone giving you a smack. I dont advocate for something like this, but being disliked, maybe vocal disliked, is the response of you act mean against others. Its not even hate, its the result of your own actions
that guy's about to get hired by EA, ubisoft, microsoft, and sony all at once for their rugpulling specialty
I can so see julian just wanting to disable networking and it snowballing into everything else for _reasons_
Up next: canonical employee creates a minimal KeePassXC Snap build 🤭
Am I the only one using more than one computer? What's next? Disabling network support in the OS itself? Back to the good old times when I was an operator on a HP 3000 Micro where networking was a rarely use extra expensive option?
Wait a second, but that would make it really secure, especially in current age. Hmmm... are you giving them ideas for free? Very kind of you. :)
(hint for cybersecurity professionals: you know how you can make the computer even more secure than just removing network interfaces? Power it off. Yes, when it's off, it's almost completely impossible to attack it, at worst they can steal the encrypted disks)
@ped7g
"Turn off your computer and make sure it powers down
Drop it in a forty-three-foot hole in the ground
Bury it completely, rocks and boulders should be fine
Then burn all the clothes you may have worn any time you were online!"
-Weird Al
and no serial or USB support ( only PS/2 keyboard ), its not vulnerable if you cant use it to do anything
As i asked before, is there no way to remove him as maintainer?
I don't get this either. Also why can one person decide this? This is one of the things I don't like about how many (not all) things are handled in Linux and often FOSS software in general too.
There's a whole process for resolving disputes like this in debian. I expect they're already starting to spin up. This is a clown look for debian, and the leadership is, in general, not stupid. Discussion is likely happening on one of the mailing lists.
Remove him? For doing the thing a maintainer is supposed to do?
@@himagainstill Retired Debian developer here: Breaking upgrades in a way that lock people out of things and telling upstream that their software is crap is **NOT** what a maintainer is supposed to do.
You transition existing installs to the -full package to avoid breakage, you create the -min one, and you explain the situation in a NEWS entry that users with apt-listchanges install will see before installation, but honestly people without it probably won't, even if they should. So if you feel real strongly about the need to inform the user they should change to -min, you feed them a message using debconf in the now-transitional un-suffixed package one time.
@@knghtbrd That's a pretty dishonest response. I think you knew and understood pretty well that the "overreach" people are complaining about isn't that he botched the upgrade path by not setting dependencies correctly. And I think you also know very well that even if that were the case, that would not be something to remove a maintainer for.
"GNOME detected. Things will be broken." Really cracked me up somehow! 🤣
They should just make droidmonkey the maintainer of the package, and take this julian out of the loop completely. As the project owner it should be their decision on how their project is being packaged and deployed.
I like how despite one of my passwords taking somewhere between 618k and 2bn years, it's still a super scary yellow instead of green on that chart.
14:21
There're SYS packages (like xy lib)
and user APPS (like KeePass).
Those shouldn't be mixed all together on pkg managers, split things is what flatpak containers was created for.
Sys unrestricted, privileged stuff -> pkg managers
User containerized, restricted apps -> flatpak, snap
Very interesting dilemma. I can respect a distribution for trying to package binaries with minimal features and therefore minimal attack vectors. If this is the case then Debian should probably not be identified as a general purpose distribution any more but rather a hardened point-release server distribution or something else. If maintainers / packagers have different visions, then it's a problem because their individual decisions will not be coherent and represent the projects vision.
In my opinion I think the packager is in the wrong here. Debian is advertised as easy to use, wide OOTB support and for wide range of use cases. Which means that the default should be to maximize the support and availability not the other way around.
I use KeePassXC on my mac, and always compile it without the networking code, but it's a bit of a hassle. Every time there is an update I have to download the new sourcecode and run through all the steps to compile it the way I want. I would actually love it if there was an easier way to install and maintain it without any networking code. If there was just a specific homebrew package that did this for me, I would be so happy.
That being said, I feel this Debian situation was not handled properly. The current package should have been full feature, and then a new minimal version would have been more appropriate
that seems like way too much work just to do the same thing that turning off the checkbox does!
If you watched the video, when you download it from upstream, everything is compiled in but turned off, so just recompile the upgrade and don't turn anything on.
I'd keep the code in the main package, but when toggling on a feature, it will open a info screen to give awareness to the user of what it does in detail and how they should use it, while minimizing the vector for attack on that feature. Most of these features are a few kilobytes or at least a megabyte or two, so nothing heavy.
One of the reasons to use Arch. The packaging story is so much more chill and non elitist
Using Flatpak for all non system stuff. Works great and little to no trubbleshooting neccesary!
Yes it does use a bit more space on my drive - i dont care.
amen
In this case, browser plugin integration becomes a can of worms when you go the Flatpak route. Don't get me wrong, I'm a proponent of Flatpak, but there are definitely edge cases where it breaks things in "interesting" ways.
@@dkessler14 I dont realy have any browser plugins which need to comunicate with an external app.... But yea a misconfigured portal an some funny bugs can occure
That maintainer is like a reddit moderator. Absolute edgelord looking to cause turmoil in the guise of "security". This is just silly.
He's definitely diagnosed as a reddit moderator by a license psychiatrist. stubborn af no matter how no one agrees with him. No surprise if he's a expertise in part time dog walking. and "normie" and "neurodivergent" are in his regular vernacular.
Reddit Moderator should be consider a crime against humanity
Actually, you saying that has reminded me of the many clashes between Linus and various self-proclaimed security experts.
Are you telling me that DT password is not strong enough?
DT is fine password, I have seen it being used in some youtube video, must be good.
It is a very strong and complicated password.
13:58 another gnome L
They really said "Gnome detected, opinion rejected"
I could have in a very small part justified the choice to impose a downgrade if it were only that. Unfortunately, we have the Yubikey issue - so the mantainer's choice is not a downgrade, it is actively harmful, and it should be treated as a critical bug.
XZ was not "drive by" ... it was like 2 years of gaining more maintenance responsibility
It's how a lot of people are describing it
@@BrodieRobertson Sorry, I'm not saying you said it that way. A comment you were going through did.
That move by Debian was dirty pool. I use KeepassXC and am happy for the most part. Arch user so not hit by Debian's shenanigans.
Arch does the same thing with OBS, unfortunately every maintainer does some stupid shit
Shit like this is why I run Gentoo.
Yeah. I've pretty much only used Gentoo so a problem like this feels a bit weird. Being able to just tweak my use flags to pick features is just my norm.
you invest time installing and tweaking gentoo mainly and the rest is pretty much headache free.
There's this idea that the reason to install gentoo is having a lean system. One reason why I find gentoo attractive is exactly the opposite: I like bloatware. I want my bloatware. Thanks.
In debian, they did a thing with python3 and python3-minimal. Why not for Keepass too?
Security by default, which didn't exist before is why. If you want the insecure option just switch out the package.
I disagree on having to read a random file on every package you update. The default should be "nothing has changed that could possibly break the app for my workflow", and if not, the package manager should **warn** about it, and offer an option to show the relevant changes.
Yeah, expecting daily driving users to search for and read every changenote is DELUSIONAL!
Julian doesn't seem to understand the purpose of a desktop OS, it should not require to be the center of the users' attention, EVER!
I think a potential solution is for flatpack to have maintainers who review packages for issues, cebtralizing the process and cutting down on duplicate work, but ensuring that every package still has a second set of eyes on it
The thing about this it is, it's Sid.
It's one of the branches that Debian makes sure you know does not have their stamp of approval.
If people need something suitable for important activities, they need to stay with the branches that Debian has signed off on, as fit for such a purpose.
If this happened in a mainline branch, it would be a massive problem -- but these things are what you sign up for by using the unstable or testing build.
First, sid isn't test. Second, as much as I love Debian, stable is typically far enough behind that it's painful. Especially all of the documentation referring to features that don't exist in Debian stable.
Sure, but nonetheless, you don't just unilaterally decide to gut a working package like this. Even on rolling release distros, you generally expect a package to provide the same features between updates. We expect bugs and unintentional problems. Not deliberate sabotage by package maintainers.
@@arthurmoore9488 Trixie is test
The issue was in Trixie as well I believe, and you assume the same risk
@@R4d1o4ct1v3_ That's the part that doesn't make sense to me.
If it were a single maintainer or a small team, a creative decision like that to attempt some sort of optimization makes sense.
But this is a community distro, and decisions are made by the community -- which makes it almost impossible to push something drastic like this.
Debian has done all sorts of crazy things for "stability" and "security".
I remember way back when Debian shipped NVIDIA drivers so old that they didn't support the GPU that I had that was old when I got it. I had to use a curses application to download and install the drivers.
I would only use Debian for a server, because on desktop it isn't great.
I love Gentoo in that regard, I can disable and enable features with USE flags myself
keepassxc ubuntu 24.04 user here. I had this issue (but didn't know what it was) and just switched to the flatpak version and had no issues since. Didn't even realize I had done it until I double checked while watching this video.
Wtf... Should it not be implied that the base package *is* the full package?
No? Glad we could get that cleared up.
It is absolutely psychotic to make the version of a package without any modifiers to be built with strange compiler flags that break basic functionality.
The network-less version should be it's own release.
😑
Debian always had their philosophy of being stable, long tested and secure, fixing bugs, aligning the packages to work well together in a way that doesn't break system for any reason and fixing security vulnerabilities. I've never thought Debian remove or implement features and treat that as if it wasn't a fork.
In this case, Devuan should be called Debian-Without-SystemD and Debian called Debian-with-SystemD. 🙄
>debian sid
>literally the "arch" version of debian
thanks, but i will stick with debian
thank you for beta testing for me
have fun with 2 yo broken packages!
@@donkey7921 Never saw a single broken package in stable, plus i'm not retarded, i know how to use the /opt/ and the /usr/local, in fact, that's where my neovim 0.9.5 is in, which is a version that suffices my needs and i don't need any upgrades from that. But thank you from remind me of a thing that i already know and complied with that, updooter.
@@donkey7921 Thanks! Have fun with fresh broken packages, too!
@@donkey7921 Thanks! Have fun with fresh broken packages, too!
Thanks! Have fun with fresh broken packages, too!
7:30 sometimes you dont have alternative or even the project is subpar it is good enough or better than alternatives
15:10 distro dont only make sure you don't have nad actor they are in practice a way to do intergration testing foss-wide as well can identify and test for more obscure usages, for example in case of bottles fedora were working on support in 3rd party library for big endian isa.
removing them from the equation along with moving to self-depoendent binary blob solution such as flatpak/snap or appimage will have really bad effects foss-wide where the actual integartion of all those libraries will start to crumble and actually using the programs will erode even faster.
I only needed to read the articles linked in the video description - what a disaster. That's not a good look for Debian at all.
I REALLY do not understand the problem. If you want the full functionality, install the -full package. If it had been split like this from the beginning, i dont think anyone would have a problem.
This is not ideal, but to never be able to change a package is stupid for the maintainer. Packages have been split for years.
Also, EVERYONE should have taken notice now
Minimal attack surface is a valid security practice
I've always maintained that standard user applications should be flatpaks now, whilst leaving the server stuff for the distro maintainers. It's a happy medium where users get the latest, greatest and unmolested software and server admins know to report CVEs, bugs, regressions to the distro maintainer instead of some random upstream dev.
They should not be removing features. If the maintainer wants a version without networking that version should be the new package, KeepassXC should be the version compiled the way the developer intended (with networking) and the maintainer's gimped version version should be KeepassXC Light, because it's not the full program.
and third post to answer Brodie's questions:
distros should patch as few things as possible. A build patch here or there for example.
also I am using keepassxc
also I am using gentoo, where it is the users choice what to turn on (browser integrations) and what to turn off (yubikey, because I am not using it). The strenght of gentoo. You want a feature, you enable it yourself. You do not want, you disable it.
Now I want to know. What's stopping flathub from making a flathub-LTS repo that ships slightly older but better tested and audited versions of its packages?
the ubikey problem is an actual issue, the rest of the removals seem fine and it makes sense to railroad people to the minimal package, the only real solution is for keepass to say check for alternative versions when features are missing, sometimes you have to make breaking change for the sake of improvement and security
It’s actually a bit concerning something like this was able to happen without formalised pushback. I’m not saying maintainers should have everything reviewed, but top dogs should have the power to revert anything like this that might not be of community benefit.
Half of the problem with XZ was the distros needlessly externally and silently patching a package just to get a feature they should've been requesting be added as a damn feature, if they had done things through the official upstream XZ wouldn't have been able to activate. The other half of the issue is that XZ was integrating binary blobs into the codebase via the test suite instead of compiling from source and relying purely on source available files. (aside from the lacking maintenance oversight) So long as a package wasn't being compiled with binary blobs that could integrate secret behavior, the XZ problem simply does not exist. Any further security complaints are generally pretty dumb because after those issues you can't distinguish legitimate code from hidden malicious code, they'll look the basically the same, best you get to deal with that is code review. (like how do you distinguish a hidden backdoor from a standard buffer overflow at that point? You can't)
It's a bit misguided to point at XZ's behaviour as a mistake. XZ itself was the attacker.
It's like saying a home's defense is lacking because the burglar had a lockpick. Yeah, duh, they're a burglar.
Tell us you didn't understand the xz thing without telling us.
@@Poldovico Yeah but the big issue is that nobody questioned the binary files being included in the build process (regardless of the fact they were test files) even just for testing purposes, had that not been accepted, it wouldn't have been possible for that backdoor to even be made, any other backdoor would've required being written in the source code or somehow constructed completely from the build system, something that is more able to be validated by code review. (and at that point it often becomes impossible to distinguish between bugged code and malicious code)
@@himagainstill The only reason the XZ could happen was because of those patches, none of the backdoors could activate on the distros that didn't ship a patched systemd, the most prominent being Arch. The other half of the issue is that binary files included in the upstream source repo didn't ever trigger any flags when it really should have, that type of behavior shouldn't have been permitted in the first place, you can't fully validate behavior if its in a binary format, if git code review could review said binary files then perhaps it be less of a concern, but even then the content of the binary file needs to be full observable and inert.
@@Spartan322 Tell me you haven't written tests that interact with binary data without telling me you haven't written tests. Sorry, I'm not going to spend hours writing code that's basically a hex editor macro just to not have "binary blobs" when checking how the system behaves with bad input.
Plus, you're completely glossing over the entire part where the makefiles were modified to use said binary blobs. That was pure text!
The whole lesson from xz is developer exhaustion and mental health issues that caused the vulnerability to happen.
Julian, by doing this, created an enormous amount of unnecessary headache and inadvertently directing (potentially toxic) user complaints to the dev. And then also have the audacity to reference xz in his response.
This is not security. This is masturbation.
I agree there can be a package with disabled functionality. A minimal or no network package as others said already. But the package that as a name has simply the software name, should come as the developer team intended it.
As a Debian user, I think it's a sane default as long as another package is available with networking enabled
Don't worry systemd-password-man is coming right up :).
Don't even joke about stuff like that, Lennart might actually think that's a good idea 🤦
@@LordHonkInc 😆
@@LordHonkIncdes he would
run0? Lennart?
with an openssl and polkit vulnerability build in.
where do I even go to read these "news files"? I don't think I've ever had an update where I've seen a "there's news!" message -- not when using apt in the terminal and not when the DE tells me it did automatic updates. I've been using Debian for years and this is the first I've heard of "news files"
If you have apt-listchanges installed, it is auto-displayed (possibly also with changelogs as well) before you install the packages. If you do not, they are located in /usr/share/doc/${PACKAGE}/NEWS.gz if they exist. Yes, IMO relying on the NEWS entry to alert people of a a system-breaking upgrade that could have been prevented/avoided is not a sufficient solution.
It's been the default to show the news before you accept an upgrade or dist-upgrade for years now. As he said, I usually don't bother reading the news and just close it and press "Y" to keep going, but I've been bitten a couple times now by changes that were warned in the news
Migrating from a system package to flatpak is not painless. I just today had to do it on my media center that I updated to noble and that broke Kodi (noble ships python 3.12 but same Kodi 20 as mantic, but you need Kodi 21 for python 3.12 support, otherwise it crashes). Migrating to Kodi flatpak solves the problem, but then you have to rebuild your config - which is a pain for a large app like Kodi.
Forget sometimes Linux is a religious undertaking for some people.
Din't know about favicon feature. It is super useful. 8 years keepassxc user
I am all in for password manager being cut from the networking (i use keepasses and don't use any browser integration), but if default version from developers has the feature and even UI option to disable (and even disabled by default), it should be available unless it affects system stability.
"Walled garden" philosophy is the reason for most issues I have with windows and macos.
Bundling a custom package for your own liking and making it the default for everyone, instead of labeling it as a custom derivative, has nothing to do with a community effort. Especially when the actual developer of the software is getting issues from this. Also calling the default build "crappy" is just crappy behavior.
It's one person abusing their power to shove their opinion down the throats of others. But I guess that's just what it's like to live the Debian SID style ;-)
Also I've got better things to do than reading news files for all my software... playing minecraft for example lol
I'm a Debian and KeePassXC user, and I will not miss any features and will have improved security by this maintainer decision.
Improved security... haha you are really falling for it.
Imo Flatpak basically make the vetting process a conscious choice, rn most of the vetting is done kind of as a side effect of every distro packaging the software. With flatpak that practice might be shrinking, but that only means distros need to act like every other os and check the software they're using. (Also, I think system lvl software shouldn't really be flatpaks as it doesn't need the sandbox and at that point you might as well just stick to the traditional packages, so that way yu still get the "vetting by repackaging" effect)
It's funny that this maintainer is using the XZ incident as a reason, to validate his own "course correction". That's very pot calling kettle black.
As for the question: yes, I'm a KeePassXC user, but no, I am not (yet) affected, simply because I don't give a fuck about updates until something /needs/ an update.
So just like with XZ, I dodged a bullet through my ignorance. XZ was actually the first time I got worried enough to even bother checking the version I'm running, only to find out I was using the original version of the "emergency fix" revert.
And the more things like this happen, the more I feel validated in my reluctance to update shit. At first I only was like that because of Windows back then. Then Android started being just as much of a pain. And now Linux too. At this point, I feel like you should never update something once it's working to your liking.
Unless something like XZ happens and you're forced to update.
Hope your not handling sensitive information as you will not get cyber insurance with that lack of care to patching issues
@@damiendye6623 I don't, and I'm glad, because otherwise I'd have to spend my days reading patchnotes to figure out whenever or not something's a needed update or just something like the KeePass issue.
I've *tried* to read the news files before, but I never end up feeling like I have any more idea of whether or not to accept the update. So I end up defaulting to "well, the distro maintainer thinks this is a net positive, and I have a restore point, so...."
An update on this: keepassxc 2.7.7+dfsg.1-3 turns keepassxc into a transitional package which depends on keepassxc-full or keepassxc-minimal, with -full being the default. I previously said this was the correct behavior, and anything else was a bug because it broke functionality and upgrades. The bug has been fixed.
I didn't follow this, and only noticed by chance (a side-effect of using Debian's aptitude and reviewing new available packages), so if it was someone convincing the developer to do the right thing or if there was some internal Debian drama over it I don't know. And I don't care, because fixing it before a stable release is all that really matters.
I am still considering that maybe my next installation won't be Debian… we shall see.
as we saw with the xscreensaver issue, Debian is actively removing the lines targeting their user base so, even if KeepassXC were to implement something to say "hey you're on a crippled version build by Debian, please go see the Debian bug report and not us", the corresponding lines might be removed by Debian maintainers so ...
> if debian in bug report, close
> ignore flag, it's opt-in anyway