August 2026 - nexa - server-nexa.polito.it

Re: Mea Culpa - Dark Hours

by abregni

La vera domanda, Giacomo, è dove sia alla fine il plagio... Se tu fai una ricerca con un motore qualsiasi, e poi ne faccio una uguale io, mica ti incazzi. Se ora la gente non programma piú, il software -- già difficile da proteggere... -- diventa in automatico una commodity "accessibile". Il secondo utente ha fornito specifiche di app sostanzialmente simili a quelle del primo (senza "copiarle", immagino). Ergo, ...addio proprietà intellettuale. Quella "vera" rimane, ...mi auguro. Il 2026-08-09 23:15 Giacomo Tesio ha scritto: > Non esattamente. > > Il primo HA usato Claude durante ls realizzazione della sua app, > fornendo codice e feedback che Anthropic ha inglobato nel proprio > archivio compresso. > > Il secondo (Godier) ha inconsapevolmente fornito a Claude > un contesto simile ottenendo il sorgente del primo (bug inclusi). > > Il fatto che il primo fosse open source è irrilevante: Claude vi ha > avuto > accesso ancor prima che fosse pushato su github. > Se l'app originale fosse stata proprietaria, l'autore avrebbe > semplicemente fatto più > fatica a dimostrare il plagio da parte di Godier. > > > È per questo che i modelli di Anthropic sembrano sempre più > "intelligenti: > sempre più aziende gli forniscono il proprio codice e pagano i propri > programmatori > per effettuare il fine tuning di Claude. > Così quando altre aziende / programnatori richiedono codice simile, > Claude gli > spara in output un'approssimazione di quello dei loro competitor, open > source o meno. > > Potremmo chiamare il business model di Anthropic "pay-to-train". > > > Giacomo > > 9 Ago 2026 22:26:03 Alfredo Bregni <abregni(a)iperv.it>: > >> Detto fra di noi -- /ma non lo fate sapere a nessuno.../ -- se anche >> il primo ha usato AI, magari i due LLM hanno rigurgitato la stessa >> "statistica" codifica... >> ;-))) >> >> >> ----- Original Message ----- >> *From:* Giacomo Tesio via nexa[nexa(a)server-nexa.polito.it] >> *To:* nexa[nexa(a)server-nexa.polito.it] >> *Sent:* Sunday, August 09, 2026 7:07 PM >> *Subject:* [nexa] Mea Culpa - Dark Hours >> >> Salve a tutti, >> >> A chi ancora crede che i LLM siano qualcosa di diverso da archivi >> compr#ssi con perdita >> dei testi sorgente, suggerisco questa lettura >> >> https://blog.terrygodier.com/2026/08/09/mea-culpa-dark-hours.html >> >> Naturalmemte non è la prima volta che questo accade (ricorderete >> certamente la >> distribuzione tramite GitHub CopyALot del codice di Quake III Arena in >> violazione >> della GPL), ma questa volta si tratta di un intero progetto >> (ri)generato (rigurgitato?) >> in output da Anthropic. >> >> >> Interessante comunque come l'autore si assume la responsabilità del >> plagio operato >> da Anthropic: un caso esemplare di alienazione cibernetica. >> >> >> Giacomo >> _______________________________________________ >> nexa mailing list -- nexa(a)server-nexa.polito.it >> To change settings or unsubscribe please go to: >> https://server-nexa.polito.it/postorius/lists/nexa.server-nexa.polito.it/ >> The general archive of the list is located at: >> https://server-nexa.polito.it/hyperkitty/list/nexa@server-nexa.polito.it/ >> Permalink to this message: >> https://server-nexa.polito.it/hyperkitty/list/nexa@server-nexa.polito.it/me…

Aug. 9, 2026

Re: Mea Culpa - Dark Hours

by Giacomo Tesio

Non esattamente. Il primo HA usato Claude durante ls realizzazione della sua app, fornendo codice e feedback che Anthropic ha inglobato nel proprio archivio compresso. Il secondo (Godier) ha inconsapevolmente fornito a Claude un contesto simile ottenendo il sorgente del primo (bug inclusi). Il fatto che il primo fosse open source è irrilevante: Claude vi ha avuto accesso ancor prima che fosse pushato su github. Se l'app originale fosse stata proprietaria, l'autore avrebbe semplicemente fatto più fatica a dimostrare il plagio da parte di Godier. È per questo che i modelli di Anthropic sembrano sempre più "intelligenti: sempre più aziende gli forniscono il proprio codice e pagano i propri programmatori per effettuare il fine tuning di Claude. Così quando altre aziende / programnatori richiedono codice simile, Claude gli spara in output un'approssimazione di quello dei loro competitor, open source o meno. Potremmo chiamare il business model di Anthropic "pay-to-train". Giacomo 9 Ago 2026 22:26:03 Alfredo Bregni <abregni(a)iperv.it>: > Detto fra di noi -- /ma non lo fate sapere a nessuno.../ -- se anche il primo ha usato AI, magari i due LLM hanno rigurgitato la stessa "statistica" codifica... > ;-))) > > > ----- Original Message ----- > *From:* Giacomo Tesio via nexa[nexa(a)server-nexa.polito.it] > *To:* nexa[nexa(a)server-nexa.polito.it] > *Sent:* Sunday, August 09, 2026 7:07 PM > *Subject:* [nexa] Mea Culpa - Dark Hours > > Salve a tutti, > > A chi ancora crede che i LLM siano qualcosa di diverso da archivi compr#ssi con perdita > dei testi sorgente, suggerisco questa lettura > > https://blog.terrygodier.com/2026/08/09/mea-culpa-dark-hours.html > > Naturalmemte non è la prima volta che questo accade (ricorderete certamente la > distribuzione tramite GitHub CopyALot del codice di Quake III Arena in violazione > della GPL), ma questa volta si tratta di un intero progetto (ri)generato (rigurgitato?) > in output da Anthropic. > > > Interessante comunque come l'autore si assume la responsabilità del plagio operato > da Anthropic: un caso esemplare di alienazione cibernetica. > > > Giacomo > _______________________________________________ > nexa mailing list -- nexa(a)server-nexa.polito.it > To change settings or unsubscribe please go to: https://server-nexa.polito.it/postorius/lists/nexa.server-nexa.polito.it/ > The general archive of the list is located at: https://server-nexa.polito.it/hyperkitty/list/nexa@server-nexa.polito.it/ > Permalink to this message: https://server-nexa.polito.it/hyperkitty/list/nexa@server-nexa.polito.it/me…

Aug. 9, 2026

Re: Mea Culpa - Dark Hours

by Alfredo Bregni

Detto fra di noi -- ma non lo fate sapere a nessuno... -- se anche il primo ha usato AI, magari i due LLM hanno rigurgitato la stessa "statistica" codifica... ;-))) ----- Original Message ----- From: Giacomo Tesio via nexa To: nexa Sent: Sunday, August 09, 2026 7:07 PM Subject: [nexa] Mea Culpa - Dark Hours Salve a tutti, A chi ancora crede che i LLM siano qualcosa di diverso da archivi compr#ssi con perdita dei testi sorgente, suggerisco questa lettura https://blog.terrygodier.com/2026/08/09/mea-culpa-dark-hours.html Naturalmemte non è la prima volta che questo accade (ricorderete certamente la distribuzione tramite GitHub CopyALot del codice di Quake III Arena in violazione della GPL), ma questa volta si tratta di un intero progetto (ri)generato (rigurgitato?) in output da Anthropic. Interessante comunque come l'autore si assume la responsabilità del plagio operato da Anthropic: un caso esemplare di alienazione cibernetica. Giacomo _______________________________________________ nexa mailing list -- nexa(a)server-nexa.polito.it To change settings or unsubscribe please go to: https://server-nexa.polito.it/postorius/lists/nexa.server-nexa.polito.it/ The general archive of the list is located at: https://server-nexa.polito.it/hyperkitty/list/nexa@server-nexa.polito.it/ Permalink to this message: https://server-nexa.polito.it/hyperkitty/list/nexa@server-nexa.polito.it/me…

Aug. 9, 2026

Mea Culpa - Dark Hours

by Giacomo Tesio

Salve a tutti, A chi ancora crede che i LLM siano qualcosa di diverso da archivi compr#ssi con perdita dei testi sorgente, suggerisco questa lettura https://blog.terrygodier.com/2026/08/09/mea-culpa-dark-hours.html Naturalmemte non è la prima volta che questo accade (ricorderete certamente la distribuzione tramite GitHub CopyALot del codice di Quake III Arena in violazione della GPL), ma questa volta si tratta di un intero progetto (ri)generato (rigurgitato?) in output da Anthropic. Interessante comunque come l'autore si assume la responsabilità del plagio operato da Anthropic: un caso esemplare di alienazione cibernetica. Giacomo

Aug. 9, 2026

Re: Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation

by Juan Carlos De Martin

Grazie! Ci siamo, ci siamo... tra l'altro la mailing list funzionerà anche tutto il mese di agosto, visto che non è più appoggiata a un server interno del Poli (che sarebbe stato soggetto ai soliti stacchi di corrente elettrica del mese di agosto). JC From: 380° via nexa <nexa(a)server-nexa.polito.it> Date: Tuesday, 4 August 2026 at 13:11 To: nexa(a)server-nexa.polito.it <nexa(a)server-nexa.polito.it> Subject: [nexa] Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation Buongiorno Nexa! (ci siete ancora vero, siete solo in ferie, eh?) Scusate se svio un po' l'attenzione dall'AI... Ve l'ho già detto quanto /adoro/ studiare «Trusting Trust fantastici e dove trovarli (e risolverli!)»?!? Fresca fresca dalla mailing list "bootstrappable" [1] c'è la segnalazione di questo bellissimo articolo che *ridisegna* il concetto di Trusting Trust: «Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation» https://arxiv.org/abs/2607.24888 Tra gli autori c'è Stefano Zacchiroli, che forse ancora bazzica questa lista e ne approfitto per ringraziarlo tantissimo, assieme agli altri autori. --8<---------------cut here---------------start------------->8--- Abstract: Ken Thompson's trusting-trust attack, in which a compromised compiler backdoors the programs it builds and reproduces the backdoor in subsequent rebuilds of itself, is widely regarded as a threat specific to compilers. We show that it is not. We construct a complete trusting-trust attack around GNU strip, an ordinary build utility that neither inspects nor generates source code, using only manipulations of finished ELF files. In the bootstrap of the NixOS Linux distribution, a single tampered strip in the binary seed implants a payload that propagates from one generation of strip to the next and survives into the final standard environment after the seed leaves the dependency closure. On a real nixpkgs revision, the attack builds a complete graphical installer without failures and backdoors almost every one of its binaries, enabling arbitrary malicious behavior of the subverted packages. --8<---------------cut here---------------end--------------->8--- Cioè: finalmente qualcuno s'è preso la briga di dimostrare che non c'è bisogno di /spippolare/ in modo sofisticato un compiler, come "fece" (abbozzò) Thompson, ma è sufficiente *scartavetrare* ad arte uno dei tool che /spippola/ i binari nel processo di build: taaaac! (sono stato abbastanza tecnico?!?) Se vi sfuggisse qualcosa del giro del fumo di cosa significha "boostrappare" un intero sistema operativo è sufficiente che leggiate "1 Introduction", e "2.1 Bootstrapping Linux Distributions" del paper. ...ecco perché il (set di) software più fico che sia stato mai concepito sulla faccia della terra è "hex0+GNU Mes": https://doc.guix.gnu.org/mes/0.27.1/en/html_node/ É GNU Mes che sta rendendo _pragmaticamente_ implementabile il concetto di "Full Source Bootstrap": https://doc.guix.gnu.org/mes/latest/en/html_node/Full-Source-Bootstrap.html --8<---------------cut here---------------start------------->8--- Most computers work pretty well so apparently there is not a pressing need to inspect and study all of these codes. At the same time it is tricky to fully trust a computer that was bootstrapped in this way [with 250MB of binary seeds, n.d.r.]. What if we could bootstrap our entire system from only this one hex0 assembler binary seed? We would only ever need to inspect these 500 bytes of computer codes. Every10 later program is written in a more friendly programming language: Assembly, C, … Scheme. Inspecting all these programs is a lot of work, but it can certainly be done. We might be able to create a fully inspectable path from almost nothing to all of the programs that our computer runs. Something that seemed to be an impossible dream is suddenly starting to look like “just a couple years of work”. --8<---------------cut here---------------end--------------->8--- (https://doc.guix.gnu.org/mes/latest/en/html_node/Stage0.html) In altre parole, l'unico "binary seed" possibile è un programma in codice macchina (assembly) di 500 bytes... ispezionabile "a mano". Non è meraviglioso?!? :-O Non c'è ancora nessuna distribuzione che è in grado di effettuare il "full binary boostrap" (da hex0), ma GNU Guix è decisamente a buon punto: https://guix.gnu.org/manual/devel/en/html_node/Preparing-to-Use-the-Bootstr… --8<---------------cut here---------------start------------->8--- Our first major achievement is the replacement of GCC, the GNU C Library and Binutils by MesCC-Tools (a simple hex linker and macro assembler) and Mes (see GNU Mes Reference Manual in GNU Mes, a Scheme interpreter and C compiler in Scheme). Neither MesCC-Tools nor Mes can be fully bootstrapped yet and thus we inject them as binary seeds. We call this the Reduced Binary Seed bootstrap, as it has halved the size of our bootstrap binaries! Also, it has eliminated the C compiler binary; i686-linux and x86_64-linux Guix packages are now bootstrapped without any binary C compiler. Work is ongoing to make MesCC-Tools and Mes fully bootstrappable and we are also looking at any other bootstrap binaries. Your help is welcome! --8<---------------cut here---------------end--------------->8--- Quindi GNU strip (in Binutils) _non_ fa parte del binary seed di GNU Guix, quindi il binary seed da compromettere dovrebbe essere un altro, tipo GNU Mes. Ehrm... certo poi ci sono i *geni del male* che hanno creato linguaggi di programmazione (_quindi_ software binario) non bootstrappabili e per quelli non c'è GNU Mes che tenga (che tristezza infinita): --8<---------------cut here---------------start------------->8--- Some program languages have become very hard or practically impossible to bootstrap. Instead of depending on a simple language such as C, they depend on a recent version of itself, or on other binary or ASCII seeds, on other recent programs written in that language, or even on manual intervention. Programs written in a language that cannot be bootstrapped can still run on our systems, but cannot enjoy any of the trust we intend to create. --8<---------------cut here---------------end--------------->8--- (https://doc.guix.gnu.org/mes/latest/en/html_node/Stage0.html#DOCF10) L'obiettivo /eterno/ è sempre quello: auditable elegance! --8<---------------cut here---------------start------------->8--- To be honest, the elegance displayed above that we achieved at the very start of the Mes project is currently hard to find. It is our sincerest hope to bring back this level of quality and elegance.. --8<---------------cut here---------------end--------------->8--- ((https://doc.guix.gnu.org/mes/latest/en/html_node/LISP-as-Maxwell_0027s-Equa…) Saluti, 380° [1] https://www.freelists.org/post/bootstrappable/What-are-some-exciting-develo… -- 380° (lost in /traslation/) «Welcome to the chaos of the times If you go left and I go right Pray we make it out alive This is Karmageddon»

Aug. 4, 2026

Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation

by 380°

Buongiorno Nexa! (ci siete ancora vero, siete solo in ferie, eh?) Scusate se svio un po' l'attenzione dall'AI... Ve l'ho già detto quanto /adoro/ studiare «Trusting Trust fantastici e dove trovarli (e risolverli!)»?!? Fresca fresca dalla mailing list "bootstrappable" [1] c'è la segnalazione di questo bellissimo articolo che *ridisegna* il concetto di Trusting Trust: «Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation» https://arxiv.org/abs/2607.24888 Tra gli autori c'è Stefano Zacchiroli, che forse ancora bazzica questa lista e ne approfitto per ringraziarlo tantissimo, assieme agli altri autori. --8<---------------cut here---------------start------------->8--- Abstract: Ken Thompson's trusting-trust attack, in which a compromised compiler backdoors the programs it builds and reproduces the backdoor in subsequent rebuilds of itself, is widely regarded as a threat specific to compilers. We show that it is not. We construct a complete trusting-trust attack around GNU strip, an ordinary build utility that neither inspects nor generates source code, using only manipulations of finished ELF files. In the bootstrap of the NixOS Linux distribution, a single tampered strip in the binary seed implants a payload that propagates from one generation of strip to the next and survives into the final standard environment after the seed leaves the dependency closure. On a real nixpkgs revision, the attack builds a complete graphical installer without failures and backdoors almost every one of its binaries, enabling arbitrary malicious behavior of the subverted packages. --8<---------------cut here---------------end--------------->8--- Cioè: finalmente qualcuno s'è preso la briga di dimostrare che non c'è bisogno di /spippolare/ in modo sofisticato un compiler, come "fece" (abbozzò) Thompson, ma è sufficiente *scartavetrare* ad arte uno dei tool che /spippola/ i binari nel processo di build: taaaac! (sono stato abbastanza tecnico?!?) Se vi sfuggisse qualcosa del giro del fumo di cosa significha "boostrappare" un intero sistema operativo è sufficiente che leggiate "1 Introduction", e "2.1 Bootstrapping Linux Distributions" del paper. ...ecco perché il (set di) software più fico che sia stato mai concepito sulla faccia della terra è "hex0+GNU Mes": https://doc.guix.gnu.org/mes/0.27.1/en/html_node/ É GNU Mes che sta rendendo _pragmaticamente_ implementabile il concetto di "Full Source Bootstrap": https://doc.guix.gnu.org/mes/latest/en/html_node/Full-Source-Bootstrap.html --8<---------------cut here---------------start------------->8--- Most computers work pretty well so apparently there is not a pressing need to inspect and study all of these codes. At the same time it is tricky to fully trust a computer that was bootstrapped in this way [with 250MB of binary seeds, n.d.r.]. What if we could bootstrap our entire system from only this one hex0 assembler binary seed? We would only ever need to inspect these 500 bytes of computer codes. Every10 later program is written in a more friendly programming language: Assembly, C, … Scheme. Inspecting all these programs is a lot of work, but it can certainly be done. We might be able to create a fully inspectable path from almost nothing to all of the programs that our computer runs. Something that seemed to be an impossible dream is suddenly starting to look like “just a couple years of work”. --8<---------------cut here---------------end--------------->8--- (https://doc.guix.gnu.org/mes/latest/en/html_node/Stage0.html) In altre parole, l'unico "binary seed" possibile è un programma in codice macchina (assembly) di 500 bytes... ispezionabile "a mano". Non è meraviglioso?!? :-O Non c'è ancora nessuna distribuzione che è in grado di effettuare il "full binary boostrap" (da hex0), ma GNU Guix è decisamente a buon punto: https://guix.gnu.org/manual/devel/en/html_node/Preparing-to-Use-the-Bootstr… --8<---------------cut here---------------start------------->8--- Our first major achievement is the replacement of GCC, the GNU C Library and Binutils by MesCC-Tools (a simple hex linker and macro assembler) and Mes (see GNU Mes Reference Manual in GNU Mes, a Scheme interpreter and C compiler in Scheme). Neither MesCC-Tools nor Mes can be fully bootstrapped yet and thus we inject them as binary seeds. We call this the Reduced Binary Seed bootstrap, as it has halved the size of our bootstrap binaries! Also, it has eliminated the C compiler binary; i686-linux and x86_64-linux Guix packages are now bootstrapped without any binary C compiler. Work is ongoing to make MesCC-Tools and Mes fully bootstrappable and we are also looking at any other bootstrap binaries. Your help is welcome! --8<---------------cut here---------------end--------------->8--- Quindi GNU strip (in Binutils) _non_ fa parte del binary seed di GNU Guix, quindi il binary seed da compromettere dovrebbe essere un altro, tipo GNU Mes. Ehrm... certo poi ci sono i *geni del male* che hanno creato linguaggi di programmazione (_quindi_ software binario) non bootstrappabili e per quelli non c'è GNU Mes che tenga (che tristezza infinita): --8<---------------cut here---------------start------------->8--- Some program languages have become very hard or practically impossible to bootstrap. Instead of depending on a simple language such as C, they depend on a recent version of itself, or on other binary or ASCII seeds, on other recent programs written in that language, or even on manual intervention. Programs written in a language that cannot be bootstrapped can still run on our systems, but cannot enjoy any of the trust we intend to create. --8<---------------cut here---------------end--------------->8--- (https://doc.guix.gnu.org/mes/latest/en/html_node/Stage0.html#DOCF10) L'obiettivo /eterno/ è sempre quello: auditable elegance! --8<---------------cut here---------------start------------->8--- To be honest, the elegance displayed above that we achieved at the very start of the Mes project is currently hard to find. It is our sincerest hope to bring back this level of quality and elegance.. --8<---------------cut here---------------end--------------->8--- ((https://doc.guix.gnu.org/mes/latest/en/html_node/LISP-as-Maxwell_0027s-Equa…) Saluti, 380° [1] https://www.freelists.org/post/bootstrappable/What-are-some-exciting-develo… -- 380° (lost in /traslation/) «Welcome to the chaos of the times If you go left and I go right Pray we make it out alive This is Karmageddon»

Aug. 4, 2026