On Mon, 1 Apr 2024 at 04:47, François Rigault <rigault.francois@xxxxxxxxx> wrote:
To echo
> To trust code, it needs to be reviewed.
> If the code is reviewed, and the build system is sane, [..]
I deduce from your response that the binary tests committed in systemd were not reviewed neither by co-maintainers nor by downstream package maintainers.
Are we talking about the blobs which contained the malware? Those blobs were not in systemd, they were in the compression library. You are going to see weird blobs in any compression library because compression needs to test how it does against different data types.. especially binary data because you need to see if you improved or worsened the compression with a change. The places you are going to see binary data which may not make any 'sense' are: compression, anything graphics related, sound and general archiving tools. You will find actually 'binaries' in various parts of any compilation set because you may be linking or 'embedding' it into code that will run something else.
But that is just where you are just sticking plain binary data. You can uuencode, base64 or many other things and put it into regular code in places where you might need to run some stuff. They went after ssh most likely because the main target was internet based attacks. However they could have gone a slightly different path and used dnf/apt (rpm/dpkg) as the target application and placed additional scripts to open systems up somewhere. This could be done with a nice bit of C code which usually does one thing but for what would look like legitimate reasons does something else after a certain date or code sequence. Anyone who has tried to read through an obfuscated C contest entry can see where this is going.
I understand that the build system used by systemd makes it much less probable that some binary blob used in a test obfuscates something that could be used for other purposes outside the test; still, wouldn't you agree it would be a good practice to make sure everyone is able to review everything in the source code repository?
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
