You can use firejail or other sandoxes with any application packaged in any distribution.

I am well aware of it. It is an example of the traditional distribution workflow preventing a backdoor from landing into Debian Stable and other security-focused distributions. Of course the backdoor could have been spotted sooner, but also much later, given its sophistication.

In the specific case of xz, “Jia Tan” had to spend years of efforts in gaining trust and then to very carefully conceal the backdoor (and still failed to reach Debian Stable and other distributions). Why so much effort? Because many simpler backdoors or vulnerabilities have been spotted sooner. Also many less popular FOSS projects from unknown or untrusted upstream authors are simply not packaged.

Contrast that with distributing large “blobs”, be it containers from docker hub or flatpak, snap etc, or statically linked binaries or pulling dependencies straight from upstream repositories (e.g. npm install): any vulnerability or backdoor can reach end users quickly and potentially stay unnoticed for years, as it happened many times.

There has been various various reports and papers published around the topic, for example https://www.securityweek.com/analysis-4-million-docker-images-shows-half-have-critical-vulnerabilities/

They have to watch hundreds to thousands of packages so having them do security checks for each package is simply not feasible.

That is what we do and yes, it takes effort, but it is still working better than the alternatives. Making attacks difficult and time consuming is good security.

If there is anything to learn from the xz attack is that both package maintainers and end users should be less lenient in accepting blobs of any kind.

They do now have a verified tick in Flathub to show if a Flatpak is official

Jia Tan liked your comment

Without the traditional distribution workflow what prevents flatpaks to be full of security issues? Unfortunately sandboxing cannot protect the data you put in the application.

Thanks!

A speech-to-text / dictation system geared towards writing documentation.

I would love a text based ActivityPub client focused on meaningful discussions: threaded view, ability to follow threads or branches, highlight posts based on keywords.

How does it compare with Paperwork? https://www.openpaper.work/en/

You are better off with an encrypted password store and a 2FA on a phone. You can back up both, easily, and they are both protected with fingerprints and/or global passwords.

Radicle has plenty of red flags, see https://lemmy.ml/comment/8982169

People panic about face scan while the ongoing massive privacy breaches exist around online services and electronic devices. The amount of personal data that people pour into smartphones is enormous compared to using that vending machine. We need more GDPR.

I would come along a question that I was well educated on, and the top voted responses were all very clearly wrong, but sounded correct to someone who didn’t know better.

This can be said to https://news.ycombinator.com/ as well. I wonder how much of this is due to sock puppets and bots.

This tends to give more influence to people who spend more time on it and write more. And they are less likely to be subject matter experts.

Honest question: deleted comments might be just hidden and still up for sale, do people know if GDPR can come to the rescue here?

Github is designed to centralize git (as the word “hub” suggests). You can still migrate away code, issues and wikis, but contributors, followers, wiki editors, issue subscribers, visibility in general and github stars are locked in. Discoverability matters to projects trying to attract contributors.

I did the survey but please would you mind identifying yourself and linking to the research paper when it’s ready?

Does OrganicMaps have editing abilities?

signal is designed not to trust the server

Unfortunately this is not enough. A malicious Signal server can mount a timing correlation attack and infer the social graph of an user. Having a centralized server makes it more difficult to mitigate such risk.

Then yes there’s EEE danger. Hopefully the Mastodon developers will resist that.

Unfortunately developers can do very little to prevent that. EEE works by first attracting a large userbase into a service and later on prevent them from leaving. It’s up to instances admins and users to defederate to prevent EEE.

This is debatable. The GPL allow redistribution of a given version of the software without additional restriction. If the user receives that copy knowing in advance that redistribution will lead to retaliatory actions this can be treated as an additional restriction.

This is not correct. APT always verifies cryptographic signature unless you explicitly disable it. Yet it’s very important to understand who is signing packages. What kind of review process did the software go through? What kind of vetting did the package maintainer themselves go through?

If software is signed only by the upstream developer and no 3rd party review is done by a distribution this means trusting a stranger’s account on a software forge.

Update: the Debian infrastructure supports checking gpg signatures from upstream developers i.e. on the tarballs published on software forges.