Chris,
The specific points of entry were evading the strength of open source:
many skilled eyes. Therefore, there is value in programmatically
enforcing that everything used as an input in a build must have been
exposed to *normal opensource workflows*. It is a very simple principle,
yet very powerful: let's flag everything that can evade review:
basically, tar.gz must be equal in content to what it is browseable on
the git repository, and also blobs must be flagged for additional
analysis, because released tar.gz and blobs are not normally reviewed on
a opensource workflow.
Those problems can be codified in a tool (which it is already done in a
proof of concept to show that it is simple to do and possible), or the
approach can be changed all together to something like source-git?
On 4/1/24 18:47, Chris Adams wrote:
Yeah. This was clearly an attack targeted at Fedora and Debian;
trying
to fix the specific point of entry is a losing battle, as at the end of
the day, Fedora will still be taking code from upstreams and
distributing it to systems far and wide. The particular use of test
and autoconf files to try to hide the attack may be novel, but there are
other ways it could have been done. If there's easy and minimal-impact
ways to help (which I haven't really seen suggested), that's good to
look at, but putting lots of effort into how tests are run or wholesale
changes to configuration seem to not be all that useful.
However, it's a good trigger to review Fedora's security approach in
general (like 2FA use).