Who should be software packaging is a tough problem, I can see the value in #linux distros pushing for better changes downstream, encouraging upstream to change (double click in #KDE) but then I see cases like KeepassXC where the Debian package is now by default broken, actively damaging the reputation of upstream but then I remember #XZ where upstream was left unchecked and hid bad code in plain sight and I go back around in a circle.
@BrodieOnLinux I strongly believe in distro packaged software.
But we have to move the culture so that users report their bugs to the software distributor, and not directly to the upstream github. Upstream "issues" should be reserved for the developers and their inner circle of people who test the latest versions, and maybe the distributors themselves.
Users of the distributors (i.e. #Linux distros) should encourage users reporting bugs to them, and they report up when needed.
Yes, I find reporting to downstream packagers (a.k.a. distributors) extremely relevant! When your favorite #SoftwareCenter or #PackageManager is all for linking to upstream, but not to those who directly affect your package in a supply chain, as a result, tops like in #KeePassXC get all the pinecones: there is no enthusiasm in an average user to link back those issues to downstream, not with the p(l)ain text and how derivatives are communicated anyway... :blobcat_flop_woozy:
@BrodieOnLinux let's be honest majority of people wouldn't of used a password manager without the browser integrations so removing that will probably have an inverse effect
@BrodieOnLinux breaking it by default isn't repackaging or maintaining its active malice as is passing off the problems you created on to the upstream devs .
@BrodieOnLinux The Debian maintainer decided to reduce the amount of plugins shipped by default (for which upstream already provides flags, so this is a to-be-expected configuration) to improve security of this piece of software. After some discussion, a "-full" variant is also provided for users who need all features.
@matk But upstream completely disagrees with this approach and instead suggests the default should be the full package and then minimal should be the additional package. They are dealing with a bunch of bug reports due to this change being made with 0 discussion happening with upstream until after it was already shipping in sid.
One of the removed features was yubikey support leaving those users with an inaccessible database until they reported to upstream about it.
@matk I can understand why Debian wants a minimal package but making that the default is absolutely the wrong move here at least without discussing the best approach with upstream beforehand
@BrodieOnLinux Given that a user reported this first, it apparently wasn't discussed with upstream, so I do agree with that part. Packagers and their upstreams - also in Debian - usually have a fairly tight relationship (of course, including disagreements, but a lot of communication generally happens).
That said, individualism is high in Debian and every packager can handle things how they see fir, sometimes for better, sometimes for worse, sadly.
@matk That's fair, I think upstream wouldn't have had as much of an issue with this if Julian didn't initially seem so unwilling to have any conversation about it once they brought up the issue.
@BrodieOnLinux Yeah... Knowing Julian, that was an exceptionally harsh reply of him, and could have been way more diplomatic. But he does care a lot about security, and people are a bit on edge right now (understandably...).
Sometimes when everyone is overworked, stuff like this happens, I hope it gets resolved amicably, as this is a fairly silly thing to fight over.
@BrodieOnLinux This is pretty much one fallout of the XZorcism incident, with security-sensitive distros trying to reduce attack surfaces as much as possible... sometimes going a bit overboard.
If these plugins could be compiled as dynamically-loaded libraries, they could be packages separately people could pick their minimal set, but KeepassXC doesn't seem to be built that way.
In any case, communication for sure was really bad here.
@matk One thing that's important to note is that pretty much all the functionality that was dropped is not enabled by default and is instead behind toggles in the full version of keepassxc
@BrodieOnLinux Toggles mean that users may accidentally flip things on that they don't need, or that malware is one config switch away to enable exploitable code and read all passwords ;-)
Granted though, I assume a tool like KeepassXC is probably audited fairly well and there's likely higher-quality plugins that could always be there.
@matk Regarding the plugin thing, they're not actually plugins this is just the term Julian used. These are core pieces of functionality in the project which can be disabled through compile options
@BrodieOnLinux So, the Debian maintainer reduced the default attack surface as per prior upstream discussions then, right? ;-)
Maybe it's time to revise that and default-enable audited code without flag to disable it...
But I'm in the peanut gallery here, that's really up to the maintainer(s) to decide!
@BrodieOnLinux Yes, but providing options and then complaining if someone uses them is a bit odd... If you provide the knobs, you can expect someone to turn them, so if you don't want that, don't provide the options (or gate them behind a clear "use this at your own risk, using these options will result in an unsupported configuration" warning).
E.g. you can build AppStream without systemd, but it's not recommended, and an error is thrown if a function is run that relies on systemd features.
@matk My main issue is a lot of users don't see the difference between upstream and downstream and a lot of bug reports are being sent to upstream because of a solely downstream choice. Maybe it's going to far but I see why projects like xscreensaver have added giant "unsupported" messages when running on platforms like Debian in the past
@BrodieOnLinux TBH, my personal opinion is that xscreensaver was pretty silly.
However, users should include the software version number in bug reports when they go upstream, always. And for distros, ideally bugs should end up in the distro bugtracker first and then be sent upstream by the package maintainer.
That said, by introducing AppStream, I am probably directing more people to the upstream bugtracker...
And also, for new users, Debian's bugtracker is particulary user-unfriendly too...
@BrodieOnLinux If people report bugs at all it's already a miracle...
The lowest possible bar would likely be to at least make the Debian bugtracker more user friendly (e.g. with a non-email interface), but I doubt that will happen anytime soon.
On the AppStream side, I should maybe add a global bug report URL override option, or the package maintainer should just patch it if the packaging delta is too large. That'd require everyone to play nice...
@matk I don't think an email interface should be done away with, there are a lot of people who are happy with it but some way for non email reporters to interact I think would be a big improvement there
@BrodieOnLinux The Debian bugtracker is controlled exclusively via mail. As developer, it's fine and I memorized all the commands and formatting I have to send, but for a drive-by bugreport by a non-technical average user it's pretty much impossible to file issues reliably (and then their e-mail address is public too, which they might not have wanted...).
This won't change soon though, because of -ENOMANPOWER as well as debbugs having its hardcore fans for the way it is.
@matk It would obviously require a new solution but I know there are options out there which do provide both options. But it probably won't happen anyway
Linux distributions should limit themselves to only offering an operating system and no longer deal with (graphical) user applications. Especially now that we have Flatpak.
This would give them more resources to increase the support life of their distributions, which would undoubtedly be much more useful.
Add comment