The more I think about it - I think in case of binaries in source tree we have to take different approach for "Version Control source tree" (git/svn), and "Software packages we release". Those two are pretty different if you ask me.
1) I think including binaries in the source repo is a useful thing - mostly due to optimization of both the time of developers and the time of doing any kind of testing (including CI testing). For me adding binaries would be acceptable if generating or re-creating the binaries for testing would require significant effort (to build and maintain it) or significant CI time to recreate the binaries for testing. 2) However I would be strongly 0/1 of not including binaries in the source packages that are intended (as it was in case of xv) for consumption by downstream dependencies. There - ideally you should just provide instructions / scripts on how to recreate those binaries, if someone would like to run the part of the test suite that requires them. I believe we should have different rules for "version control repo" and "source packages" - those two are quite distinct. As already discussed in the "source code provenance discussion" https://lists.apache.org/thread/tykjz93tjdofxsm7jxg79rzr69g4l4pr - source packages produced by the foundation can (and will) differ from the TAGged sources in the repo. While the version control repo should be the "source of provenance" that (I think) should be verified is the case when +1 by PMC), this is not a big problem if the git repo contains more binaries. I think this is the whole "legal" (but also practical) part of the whole voting process we have, where by making it "officially approved", source provenance is checked and source packages are inspected and by making them available in "downloads.apache.org" - they are made the source of all downstream consumers who care about provenance. This is what was really wrong in the xv case - not only the "Makefiles" were modified by the roque release manager, but also test binaries were part of the source package used by downstream distributors. So my proposal here (and I was also advocating for that in gradle-wrapper discussions some time ago which is somewhat related): * it's ok to have binaries in the version control source code if they optimize development/contribution experience, as long as their purpose is well defined * it's not ok to have binaries in the source package we vote on and release, there you should assume that the one who uses the package (downstream distributor) will get all the binary tools and environment as described in the requirements to build the package This then makes the distributor responsible to make sure they have the right (possibly binary) tools and environment and make sure they are vetted. We should not take the responsibility on the PMC voting on the source package that the binary being part of the source package is "safe", we should generally only vote on sources + whatever was generated from the sources. Also - we have to remember that this discussion is on the source packages - which are used by downstream distributors of the libraries and software we build, not on end-user/convenience packges - I think in this discussion we should focus on that use case, because this is what the xz case is all about. J. On Wed, Apr 3, 2024 at 11:35 AM Emmanuel Lécharny <elecha...@gmail.com> 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... > > -- > *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 > >
