Re: Looking for advice on how to deal with potential slop packages

[Simon Josefsson <simon@josefsson.org>]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

"Andreas K. Huettel" <dilfridge@gentoo.org> writes:

> Am Samstag, 7. März 2026, 16:31:18 Mitteleuropäische Normalzeit
> schrieb Simon Josefsson:
>> Morten Linderud <foxboron@archlinux.org> writes:
>> 
>> > A lot of this is probably already a lost cause I think.
>> 
>> +1
>
> Here's another example of a (cryptography-related) package gone full auto.
>
> https://github.com/cpan-authors/Crypt-OpenSSL-RSA/commits/main/?after=5d7e2e6faf3d6938b55aeebd40f5fb2379248c36+34
>
> Lost cause or not, shouldnt we even try to fight this tendency?

Could the answer be in the follow-on question "How?"?

I can't think of any feasible way to oppose this tendency today.

LLM-authored code is already part of a growing list of low-level and/or
security critical components of the free software eco-system --
including, if I'm not mistaken, Linux, systemd, OpenSSL, Go crypto, etc.

One reaction could be to build a GNU distribution based only on software
components that doesn't contain LLM-authored code.  This assumes we can
even identify that code.  I think that will be challenging -- some
projects are adopting policies to accept LLM-contributions that doesn't
acknowledge or mention that a LLM-assistant was used.  How to make a
decision in that case?

A stronger reaction could be to build a GNU distribution based only on
software components that have a sufficiently strong no-LLM policy.  A
100% "Human-written Software" distribution, based on something similar
to Debian's DFSG but replacing (or augmenting) 'free software' with
'human-written software'.

These things are do-able, but I don't see anyone verbalize the ideas and
starting the work involved.

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1251 bytes --]