Bug 424994 - Warn about insufficient package security
Summary: Warn about insufficient package security
Status: CLOSED UPSTREAM
Alias: None
Product: Discover
Classification: Applications
Component: discover (show other bugs)
Version: unspecified
Platform: unspecified All
: NOR wishlist
Target Milestone: ---
Assignee: Dan Leinir Turthra Jensen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-04 07:33 UTC by Someone Concerned
Modified: 2022-01-20 18:36 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Someone Concerned 2020-08-04 07:33:28 UTC
Please add the following security warnings to Discover:

- No/Insufficient Transport Encryption
- No/Insufficient Package Signing
- No/Insufficient Repository Signing
- No/Insufficient Security Notifications
- Package Is Not Reproducible
- Package Cannot Be Cross-Checked


No/Insufficient Transport Encryption
====================================

Transport encryption can mitigate critical package manager vulnerabilities such as https://justi.cz/security/2019/01/22/apt-rce.html, provided that the mirror that's being used is not compromised.

In most Linux distributions though, either the package manager downloads packages over plain HTTP/FTP, or the mirrors sync over plain rsync, or both. Solus is one notable exception [1].


No/Insufficient Package Signing
===============================

Package signing prevents compromised mirrors from serving malicious packages.

Guilty: Solus [1], KaOS [2].


No/Insufficient Repository Signing
==================================

Repository signing prevents compromised mirrors from withholding security updates.

Guilty: Arch Linux [3], Manjaro [4].


No/Insufficient Security Notifications
======================================

Even with signed packages and repositories, a compromised mirror can still withhold security updates until the user notices the lack of updates or the repository expires. This can be solved by fetching security notifications from the distribution's official servers. As far as I know, Fedora is the only distribution that implements this [5].


Package Is Not Reproducible
===========================

Reproducible builds allow anyone to check if a binary package corresponds to its source code by building the source code themselves and comparing the output with the original binary package. This makes it very easy to detect backdoors introduced during the compilation process.

From https://reproducible-builds.org/:

"[...] most software is distributed pre-compiled with no method to confirm whether they correspond. [...] This incentivises attacks on developers who release software, not only via traditional exploitation, but also in the forms of political influence, blackmail or even threats of violence."

"This ability to notice if a developer has been compromised then deters such threats or attacks occurring in the first place as any compromise would be quickly detected. This offers comfort to front-liners that they not only can [not] be threatened, but they would not be coerced into exploiting or exposing their colleagues or end-users."


Package Cannot Be Cross-Checked
===============================

Cross-checking packages against multiple independent mirrors (or even against packages downloaded by other users via peer-to-peer communication) would prevent an attacker who has compromised the developer and one of the mirrors from serving a backdoored package to a specific user who's using the said compromised mirror.

I don't know of any Linux distribution or package manager that implements this. In fact, I got this idea from some obscure article that I can't even find anymore...


================

[1] https://discuss.getsol.us/d/5073-eopkg-security
[2] https://github.com/KaOSx/core/blob/0310e8fd08595ec57e87e3f9af5ee53bc407b8d5/pacman/pacman.conf#L41
[3] https://github.com/archlinux/svntogit-packages/blob/a04db1567ee37a6e7fc84fb8493e39d49dd54ec2/trunk/pacman.conf#L40
[4] https://gitlab.manjaro.org/packages/core/pacman/-/blob/master/pacman.conf.x86_64#L42
[5] https://patrick.uiterwijk.org/blog/2018/2/23/fedora-package-delivery-security#metalink
Comment 1 Someone Concerned 2020-08-04 10:10:54 UTC
Information can be sourced from we the people as described here: https://bugs.kde.org/show_bug.cgi?id=424577#c3
Comment 2 Nate Graham 2020-08-05 00:28:41 UTC
If all of this information is already available in the form of some kind of data stream we can subscribe to, or else it's something that Discover itself can programmatically determine, it seems reasonable to me. However I don't think KDE hosting a crowdsourced repository is an ethical plan, for the same reason I gave in Bug 424577.
Comment 3 Someone Concerned 2020-08-05 04:40:25 UTC
> I don't think KDE hosting a crowdsourced repository is an ethical plan

Staying silent all while humankind plunges deeper and deeper into secular damnation with every passing day sounds even less ethical to me. We need strong information security for everyone to keep dissent and resistance possible.

See: https://bugs.kde.org/show_bug.cgi?id=424577#c6
Comment 4 Aleix Pol 2022-01-20 18:22:07 UTC
It seems like it's all coming from PackageKit, so it's there where this should be addressed. There's already ways to submit security concerns from PackageKit and they should be used with their according error messages.

We can consider having the discussion over there where it will also be more exposed to the different backend developers and eventually distributions.
https://github.com/PackageKit/PackageKit

That said, if you consider bringing this up there, I'd recommend some more research as I don't think this is phrased in ways that can foster concord among the different actors.