Re: xz meltdown/Lasse Collin

On Sat, 2024-04-13 at 06:47 -0700, H. Peter Anvin wrote:
> On April 13, 2024 6:16:09 AM PDT, James Bottomley
> <[email protected]> wrote:
> > On Fri, 2024-04-12 at 10:36 -0700, H. Peter Anvin wrote:
> > > Hi,
> > > 
> > > Does anyone know if anyone has reached out to Lasse Collin
> > > (original xz-utils maintainer) and see if he needs any material
> > > assistance?
> > 
> > After the abuse campaign was exposed, he seems to have found a
> > community of supporters and is getting back into the swing of
> > development (at least now that the github repos and accounts have
> > been restored):
> > 
> > https://github.com/tukaani-project/xz/commit/e93e13c8b3bec925c56e0c0b675d8000a0f7f754
> > https://github.com/tukaani-project/xz/issues/105
> > 
> > For the ecosystem, I think the main lessons are
> > 
> >   1. Trust is not a useful security metric.  Note Trust is still
> >      useful for ensuring people have the skills and ability to
> >      contribute, it's just not a guarantor of future good
> > behaviour.
> >      This means we should always have independent reviews for every
> >      commit.
> >   2. We need better build artifact transparency generally but  I
> > think
> >      the kernel is fine here: we still use make so don't have the
> > huge
> >      build artifact issue that allowed the exploit in and we have a
> >      documented signing process for our build artifacts (kernel
> >      tarballs).
> >   3. The indirect library dependency problem doesn't apply to us.
> > 
> > If you're asking what the TAB could do, I think OpenSSF needs a
> > complete makeover. The badge thing is futile and wouldn't have
> > helped here. What we need is pro-active identification of and
> > support for projects at risk of this type of maintainer burnout
> > attack. We could also do with some resources looking at the library
> > dependency problem and the complex build system (autoconf, meson,
> > etc) artifact issue.
> > 
> > Regards,
> > 
> > James
> > 
> > 
> 
> Well, in the more short term: are there any financial/material help
> that can be provided? 

If he enables github sponsorship, you could donate, yes.

> On a bigger scale, perhaps LF could use to have an "emergency support
> plan" for isolated developers whose projects find themselves under
> attack.

I gave an idea for that above.  But the first key step is pro-active
identification.  The MO of the burnout attack was to try to make the
attacker the single help resource; people in this position tend not to
know they need to ask for other help.  So the first step has to be pro-
active in looking for them (which is also useful for providing a risk
report about the entire ecosystem).

>  Let's say someone might need to take a brief leave of absence from
> their day job due to such an emergency, for example.

I think for small project curation services, the LF isn't particularly
effective (it likes larger projects) but the Software Freedom
conservancy seems to do a great job:

https://sfconservancy.org/projects/current/

Unfortunately they're better known for other things.

For projects that want independence some sort of grant system (like n
months of hosting or a security training system) might be useful if
well advertised and easy to obtain.

I suppose we could always ask the question could a maintainer vetting
system be made to work?  I suspect given how development works, the
answer is that it wouldn't really be effective, but it might be worth
exploring.

James