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

Simon Josefsson <[email protected]> Mon, 23 Mar 2026 09:14:12 +0100
Newsgroups dev.linux.lists.distributions
Message-ID <[email protected]>
--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

"Andreas K. Huettel" <[email protected]> writes:

> Am Samstag, 7. M=E4rz 2026, 16:31:18 Mitteleurop=E4ische Normalzeit
> schrieb Simon Josefsson:
>> Morten Linderud <[email protected]> writes:
>>=20
>> > A lot of this is probably already a lost cause I think.
>>=20
>> +1
>
> Here's another example of a (cryptography-related) package gone full auto.
>
> https://github.com/cpan-authors/Crypt-OpenSSL-RSA/commits/main/?after=3D5=
d7e2e6faf3d6938b55aeebd40f5fb2379248c36+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

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmnA9lQUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA
/iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx
+3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6
qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF
PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh
is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFomZFAQD8Azxl0BX2
guL/SuZcFQTNcNzW+SHEBlAhJy3w9dYC7wEA98V2FybvlmGlOp0LljmXroqoCbsz
ALj12bzhV7SutQA=
=bZyO
-----END PGP SIGNATURE-----
--=-=-=--