I like the idea of the security path as well, where all packages in that path have upstream subject to higher security standards (that means helping them to achieve it as well), and greater defense downstream in any way possible.

Two things that came to mind I shared in another channel:
* no binary blobs in the upstream, or no blob referred to in the source built, or referred to in the build tools * diffoscope should show no difference except file stats between the tar.gz being pulled by the spec, and the source brought with a git clone.

Both things could be automated with tools.


On 3/30/24 08:58, Miroslav Suchý wrote:
Dne 30. 03. 24 v 10:37 dop. Richard W.M. Jones napsal(a):
I'm not pretending these will solve everything, but they should make
attacks a little harder in future.

4) Fetch build artifacts before executing tests

https://github.com/rpm-software-management/mock/issues/1352

(3) We should have a "security path", like "critical path".
Generally good idea. But several packages that JiaT75 GH-starred were:

* doxygen - when you infect this, you have open path to 700 Fedora packages, including gcc.

* squashfs-tools - when you infect this, you have open path to all images (just example, not sure if our toolchain use this or -ng version).

So the security patch should be much wider.

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to