On 04/04/2024 14:16, Stefan Bodewig wrote:
On 2024-04-03, Emmanuel Lécharny wrote:
On 02/04/2024 21:57, Nick Wellnhofer wrote:
Binary test data can also be generated with a script or a more sophisticated
test suite which might even be more maintainable in the long run.
On the other hand, tests are the prime target to hide malicious code
and there are many ways to hide data even in innocuous-looking text
files.
We don't provide binaries, we provide source code. For the projects
providing executables, I expect they don't include tests and the
associated bionary files in their packages...
In the case of XZ utils it is the source tarball that spreads the
malicious code. The code sits inside test binaries and makes its way
into the liblzma binary built from the source tarball via a patched
build script - which is different from the one in git and thus hopefully
would have been detected by our release vetting processes.
So "we only ship sources" on its own is not enough.
Note that if you add some code to create those binaries - we do that
when creating certificates, for instance -, you have the same pb:
nothing forbid a rogue developer to create those binaries from some code
that will be ran when building the packages.
Forbidding binaries in git does not solve any issue related to security.
The only part that it solves is that the developers aren't facing an
opaque piece of data with no idea about what's inside (and I know that
because before we added the code in our tests to generate the
certificates, we had to do it by hand, because the provided certificates
have expired ;-)
Note: I don't like binaries in a repo either.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org
For additional commands, e-mail: security-discuss-h...@community.apache.org
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org
For additional commands, e-mail: security-discuss-h...@community.apache.org