Re: How could we get society to adequately fund free software developers

Simon Lees via linux-aus <[email protected]> Thu, 4 Apr 2024 16:56:03 +1030
Newsgroups	gmane.linux.australia
Message-ID	<[email protected]>

On 4/4/24 4:29 PM, Brian May wrote:
> Simon Lees via linux-aus <[email protected]> writes:
> 
>> With both Github and Gitlab it is possible to create releases from
>> artifacts created as part of pipelines / actions. When using this for a
>> release process it would be much harder for this kind of attack to
>> happen. Although both still allow manual uploads and there doesn't seem
>> to be a good indication of what is manual vs auto generated.
> 
> The attacker could potentially modify the pipelines / actions to include
> mallacious code in the released archive. Not sure how easy it would be
> to obscure this, but after seeing the XZ attack, I think anything could
> be possible here.

They could, but generally these modifications are also committed to the 
git repository which means for any project with multiple active 
contributors hopefully such changes would get reviewed. For smaller 
projects with only one main author this is always going to be a risk 
that's hard to mitigate.

> Even if the source code release is OK, what about prebuilt binaries?
> Reproducible builds here could help a little. But not if the build steps
> add the mallacious code every time.

Again at the upstream level all these files should be committed to the 
git repo so if changes are being made here they should be reviewed the 
same as any other source code. At a distro level for openSUSE atleast we 
have an enforced policy of atleast someone reviewing all changes to spec 
files and patches, we also have ways of verifying the tarball that the 
packager uploads matches the one from upstream.

> Typically upstream tar balls to have legitimate changes from git, such
> as autogenerated autotools files for example. Which in turn could be
> hiding mallacious code. Maybe we need to move to using git code and
> archives autogenerated by trusted entity (e.g. github) more and
> more. Even if this means user's need to build the autotools files
> themselves.

It is possible to do these steps for autotools using pipelines / actions 
and then use the resulting artifacts in a github release. Obviously this 
is atleast some amount of effort that someone probably needs to learn 
which is why many projects don't have this setup.

Maybe an upside of this will be that more projects adopt such an 
approach or that several people who know how to set this up go through 
and send pull requests to add it to a large number of projects.

Such an approach will still have the potential for issues but hopefully 
it means that tarballs match whats in git and people will have the 
chance to pick up malicious changes in reviews in the same way they 
currently do for code.

-- 
Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

_______________________________________________
linux-aus mailing list
[email protected]
http://lists.linux.org.au/mailman/listinfo/linux-aus

To unsubscribe from this list, send a blank email to
linux-aus-unsubscribe-cunTk1MwBs8iFSDQTTA3OBCuuivNXqWP@public.gmane.org
OpenPGP_signature.asc (application/pgp-signature, 840 B)