@matk@mastodon.social
@matk@mastodon.social avatar

matk

@matk@mastodon.social

PhD student in Neuroscience by day, free software developer by night. Debian Developer, KDE and GNOME member; working at https://social.librem.one/@purism

Opinions are my own.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

BrodieOnLinux, to linux
@BrodieOnLinux@linuxrocks.online avatar

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.

matk,
@matk@mastodon.social avatar

@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.

So, both the security-pedantic minimalists and the ones who want all features are happy, I don't see the issue here...
https://packages.debian.org/sid/keepassxc-full

matk,
@matk@mastodon.social avatar

@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,
@matk@mastodon.social avatar

@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,
@matk@mastodon.social avatar

@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.

matk,
@matk@mastodon.social avatar

@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,
@matk@mastodon.social avatar

@BrodieOnLinux Playing devil's advocate here: If they are core pieces of functionality, why can they be disabled by compile flags at all?

matk,
@matk@mastodon.social avatar

@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!

matk,
@matk@mastodon.social avatar

@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,
@matk@mastodon.social avatar

@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...

matk,
@matk@mastodon.social avatar

@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,
@matk@mastodon.social avatar

@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.

nekohayo, to debian
@nekohayo@mastodon.social avatar

The attitude shown by the packager who insists on going against the will of @keepassxc devs, in this comment: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104401817 is… wow 🤦

This "packagers thinking they know better than the developers, and unilaterally patching things" mentality, along with distros often shipping outdated versions, is why many upstream software developers dislike dealing with Debian (& any LTS distro), and now ask users to test/run versions of their applications first and foremost.

matk,
@matk@mastodon.social avatar

@nekohayo @keepassxc Honestly, that sounds like a reasonable take, especially considering the reply of the former maintainer below.
Still, a compromise in providing both the full and a hardened minimal version could surely be done to make everyone happy with it, that's what is done with Nginx and many other packages as well.

matk, to random
@matk@mastodon.social avatar

I wonder: If a project deliberately unilaterally abandons a specification, would it be reasonable to ignore their voice in subsequent change discussions to that particular specification, for changes that other projects want to make to it?

After all, by breaking the convention, there apparently is no longer any interest in collaboration and cross-desktop integration anyway...

It would suck though, it would make the Linux desktop poorer, inconsistent and app dev's lives harder.

matk,
@matk@mastodon.social avatar

@sonny
> Also, I tried to reach out twice by email about our conversation to revive the freedesktop community. Let's catch up?

Oh no, I didn't see any email! Where did you send it? I would have replied for sure otherwise!

As for the notifications thing, I was a bit burnt out on controversies so I was basically waiting to see how things develop, as I didn't have an opinion yet. I do now though, so I should reply there.

matk,
@matk@mastodon.social avatar

@sonny Oh great, GMail spammed it... And you replied to my initial mail, even! Why is Google's spam filter so bad now? I'm really sorry, I will reply once I'm back from work!

juliank, to random
@juliank@mastodon.social avatar

How to render dependency graph as a graph, what are the understandable approaches there?

matk,
@matk@mastodon.social avatar

@zygoon @juliank Low complexity graphs are fine and easy to grasp, but as soon as there's more than 10 nodes and/or a complex structure, it will become unreadable spaghetti for most people, sadly.
And package dependencies are really complex... (there are algorithms to layout complex graphs well, but then they will use a ton of space, and doing so may not always work for complex ones)

pid_eins, to random
@pid_eins@mastodon.social avatar

5️⃣ Here's the 5th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.

I am pretty sure all of you are well aware of the venerable "sudo" tool that is a key component of most Linux distributions since a long time. At the surface it's a tool that allows an unprivileged user to acquire privileges temporarily, from within their existing login sessions, for just one command, or maybe for a subshell.

"sudo" is very very useful, as it…

matk,
@matk@mastodon.social avatar

@pid_eins This is very nice - especially having it provide a clean context, that saves a ton of headaches and sanitization I need to do when using "sudo" in other programs! (not like that's an amazing thing anyway, but occasionally it's useful and justified)
Only having run0 coloring / changing the output of the called command is not something I always like, but maybe that can be optionally disabled...

matk, to random
@matk@mastodon.social avatar

The new apt text UI feels so nice in daily use! Like a very modern tool, but modern in the best way possible, with all information easily accessible and some quality-of-life changes that are very minor, but still matter. Colors in the terminal can be a huge help for readability!
Since I use the APT cli tools a lot, this is super nice, thanks @juliank 😃

matk, to random
@matk@mastodon.social avatar

1.0.3 is out 😄
It mostly consists of bugfixes and a bunch of additions to the validator to make it catch even more issues in advance. "Plasma Mobile" is also a recognized desktop-style now.

Changes:
https://github.com/ximion/appstream/commit/0f83f572c89f936ddb3c5bf1a8fd85e8c3976a68

juliank, to random
@juliank@mastodon.social avatar

Is the bold too aggressive? It's coming on a bit strong maybe. Anyway go play with that and other changes in 2.9.2 and let me know your impressions.

matk,
@matk@mastodon.social avatar

@juliank Really nice! It matches appstreamcli now, almost ^^
(e.g. appstreamcli get org.freedesktop.appstream.cli --details)

Very useful, I love all the new APT usability changes!

juliank, to random
@juliank@mastodon.social avatar

OK I just opened the new APT output format merge request. I'm attaching the current state side-by-side comparison in a picture (and yes I typoed git into the wrong tab)

https://salsa.debian.org/apt-team/apt/-/merge_requests/337

You can see that apt-get(8) maintains its retro interface, the test suite is happy about that (it literally is validating the apt output).

Gonna do some bike shedding about the summary using nouns instead of verb still I suppose.

matk,
@matk@mastodon.social avatar

@juliank I love this! Fantastic work 🙂

matk, to random
@matk@mastodon.social avatar

FFmpeg does not mince words on TwiX...

"The xz fiasco has shown how a dependence on unpaid volunteers can cause major problems. Trillion dollar corporations expect free and urgent support from volunteers.

Microsoft/MicrosoftTeams posted on a bug tracker full of volunteers that their issue is "high priority""
https://twitter.com/FFmpeg/status/1775178803129602500

pid_eins, to random
@pid_eins@mastodon.social avatar

PSA: In context of the xzpocalypse we now added an example reimplementation of sd_notify() to our man page:

https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes

It's pretty comprehensive (i.e. uses it for reload notification too), but still relatively short.

In the past, I have been telling anyone who wanted to listen that if all you want is sd_notify() then don't bother linking to libsystemd, since the protocol is stable and should be considered the API, not our C wrapper around it. After all, the protocol is so trivial

matk,
@matk@mastodon.social avatar

@pwithnall @pid_eins I wonder if the sd_notify protocol would make sense to be built into GLib directly... It's fairly foundational and ubiquitous now.

Conan_Kudo, to random
@Conan_Kudo@fosstodon.org avatar

All this talk about over the weekend, I want to also point out that it's important to remember that the "software supply chain" largely does not exist in regards to open source, because most people have no real relationship other than parasitic consumption with the project.

@Di4na's great blog post on this topic explains it quite well: https://www.softwaremaxims.com/blog/not-a-supplier

matk,
@matk@mastodon.social avatar

@Conan_Kudo @Di4na That "I am not a supplier" blog post is spot on!

bagder, to random
@bagder@mastodon.social avatar

💚 Stay strong xz maintainer(s). We're with you.💚

matk,
@matk@mastodon.social avatar

@bagder Thank you! I can't imagine how bad this must feel for Lasse Collin, especially after reading1.
We're with him and all honest XZ contributors, and they're not to blame 🙂

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • provamag3
  • thenastyranch
  • magazineikmin
  • InstantRegret
  • Durango
  • rosin
  • Youngstown
  • osvaldo12
  • slotface
  • ngwrru68w68
  • everett
  • mdbf
  • kavyap
  • DreamBathrooms
  • Leos
  • PowerRangers
  • cisconetworking
  • vwfavf
  • tacticalgear
  • ethstaker
  • khanakhh
  • tester
  • GTA5RPClips
  • normalnudes
  • modclub
  • cubers
  • anitta
  • megavids
  • All magazines
    •