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----- --=-=-=--