☺
Scritto da: Suor Dannata
> http://voxnews.info/2014/02/09/cagliari-alle-eleme...
>
>
E’ in atto, in tutta Italia, un grande progetto di lavaggio del cervello nei confronti dei bambini, per ‘educarli’ al nuovo ordine mondiale.
> http://voxnews.info/2014/02/09/cagliari-alle-eleme...
>
>
E’ in atto, in tutta Italia, un grande progetto di lavaggio del cervello nei confronti dei bambini, per ‘educarli’ al nuovo ordine mondiale.
Young professional woman and busy mom.
Arricchimento culturale in Svezia in corso
Ad
https://www.breitbart.com/europe/2019/01/04/patient-placed-in-quarantine-after-suspected-ebola-case-in-sweden/
The Emergency Room of a Swedish hospital was closed down Friday morning after a patient recently returned from Africa arrived vomiting blood, a possible symptom of the deadly and contagious Ebola virus.
☺
Scritto da: altg
> > > Ma a che ti servono i sorgenti del/dei parser? Per curiosita`?
> >
> > Sto imparando a parsare come fanno i grandi, volevo vedere come facevi tu.
>
> Um... io sono un tipo atipico, come ben puo` confermarti il Prof. Avvelentani. Uno che pensa parecchio lateralmente, quasi di sbieco, solo un po' piu` giu` a babordo.
Non è un approccio per forza di cose sbagliato, ci sono molti che preferiscono il tuo approccio per questione di flessibilità.
> > Niente generatore di parser quindi, né grammatiche del linguaggio.
>
> No, mai provato generatori di parsers. Non saprei quanto sarebbe comodo un generatore di parsers, puo` darsi che sarebbe comodo, oppure che per fargli fare quello che vuoi tu debba pregarlo in cinese tradizionale. Boh. Comunque io mi trovo bene a scriverli per conto mio. Quello di Lino4 guarda carattere per carattere in ordine piu` o meno LTR, ma ogni tanto fa una puntatina ahead per distinguere qualche caso, tipo quelli di "-" e "-->", nel senso che si chiede "che viene dopo il trattino?".
Sì, ti tocca litigare un po' per fargli fare quello che vuoi. Un vantaggio è la portabilità, metti che un domani vuoi cambiare l'implementazione in un altro linguaggio/piattaforma, sarà molto più facile visto che la grammatica è quella. L'altro vantaggio è che l'approccio formale evita alcuni tipi di bug nell'implementazione (qualcuno ha detto parser di php?).
> > > Ma a che ti servono i sorgenti del/dei parser? Per curiosita`?
> >
> > Sto imparando a parsare come fanno i grandi, volevo vedere come facevi tu.
>
> Um... io sono un tipo atipico, come ben puo` confermarti il Prof. Avvelentani. Uno che pensa parecchio lateralmente, quasi di sbieco, solo un po' piu` giu` a babordo.
Non è un approccio per forza di cose sbagliato, ci sono molti che preferiscono il tuo approccio per questione di flessibilità.
> > Niente generatore di parser quindi, né grammatiche del linguaggio.
>
> No, mai provato generatori di parsers. Non saprei quanto sarebbe comodo un generatore di parsers, puo` darsi che sarebbe comodo, oppure che per fargli fare quello che vuoi tu debba pregarlo in cinese tradizionale. Boh. Comunque io mi trovo bene a scriverli per conto mio. Quello di Lino4 guarda carattere per carattere in ordine piu` o meno LTR, ma ogni tanto fa una puntatina ahead per distinguere qualche caso, tipo quelli di "-" e "-->", nel senso che si chiede "che viene dopo il trattino?".
Sì, ti tocca litigare un po' per fargli fare quello che vuoi. Un vantaggio è la portabilità, metti che un domani vuoi cambiare l'implementazione in un altro linguaggio/piattaforma, sarà molto più facile visto che la grammatica è quella. L'altro vantaggio è che l'approccio formale evita alcuni tipi di bug nell'implementazione (qualcuno ha detto parser di php?).
Young professional woman and busy mom.
☺
Scritto da: altg
> Ma a che ti servono i sorgenti del/dei parser? Per curiosita`?
Sto imparando a parsare come fanno i grandi, volevo vedere come facevi tu.
Niente generatore di parser quindi, né grammatiche del linguaggio.
> Ma a che ti servono i sorgenti del/dei parser? Per curiosita`?
Sto imparando a parsare come fanno i grandi, volevo vedere come facevi tu.
Niente generatore di parser quindi, né grammatiche del linguaggio.
Young professional woman and busy mom.
☺
Scritto da:
> Scritto da: ::1
> > Io sono dell'opinione opposta, systemd ha grossi vantaggi proprio per i sysadmin;
>
> Onestamente non ne vedo. Non sono un sysadmin ma tutti i sysadmin che conosco sono, in genere, fortemente contrari a Systemd con qualche voce fuori dal coro.
Non so che sysadmin conosci tu, io lavoro per una azienda piena di sysadmin, a contatto con sysadmin di altre aziende. Avere un process supervisor come init è un vantaggio e basta, non ha contro, solo pro; infatti upstart era inizialmente stato adottato come init di rhel (ci lavoro, lo uso).
Ti dico pure che iniziano a sperimentare l'user mode di systemd, dove un utente ha i suoi demoni, che girano unprivileged, coi suoi unit file, per usare systemd per lanciare le procedure di business del cliente senza avere prodotti esterni (usano ancora orsyp dollar universe su aix, stanno migrando alcune cose verso rhel).
> > è chiaro che deve ancora dimostrare di essere affidabile e stabile per anni e anni e anni,
>
> Quindi sei d'accordo che è sbagliato metterlo in produzione già da subito. Se l'avessero messo _come opzione_ non ci sarebbero stati problemi, invece non solo per molte distro non è affatto un'opzione, ma è addirittura richiesto se vuoi usare determinati componenti (come Gnome)... e sarà sempre peggio perché Systemd è _progettato_ per essere usato quasi come libreria e quindi per diventare una dipendenza fondamentale per sempre più sistemi.
gnome <> server
> > ma c'è da dire che le features di base (unit file, process monitor, journald) non hanno problemi, tant'è che i server centos/redhat non esplodono e sono ancora considerati rock-solid.
>
> Non ne sono sicuro. Su cosa basi questa tua affermazione? Sul mero (presunto) fatto che ancora nessuno ha ownato un server CentOS/redhat? Magari hai anche ragione, ma la mia esperienza mi dice che un sistema complesso è in genere il primo motivo per cui un sistema finisce per fallire.
Ne sono sicuro.
> > L'unico appunto sono forse i binary log, ma basta cambiare un flag e tornano testuali.
>
> Finché non decideranno che quella flag non serve più per via degli "innegabili vantaggi dei binary log". Magari ti faranno sparire l'opzione da una release all'altra e tu potrai solo inghiottire e chiudere la bocca... tanto è più o meno stata questa la politica adottata fin'ora circa Systemd.
> "Non ti piace? Cazzi tuoi. Noi andiamo avanti per questa strada, se vuoi forka... ah... e good luck with that... visto che ora Gnome dipende da noi e in futuro sempre più sistemi e sottosistemi dipenderanno da noi".
Avrei un elenco di fallacie da proporti, visto che stai ragionando sui se e sui ma.
> Non so... a te sembra una politica/modo di fare accettabile nel mondo opensource? A me sembra una politica piuttosto aggressiva e poco "user-friendly". E, nota, è stata più o meno la stessa politica usata con pulseaudio... guardacaso l'autore è lo stesso.
E guardacaso pulseaudio era una merda all'inizio, ma basato su una idea buona, e oggi è un buon software che risolve un problema che linus non ha voluto risolvere nel kernel (la parentesi audio su linux non sta nel margine della pagina).
> > Per quanto riguarda la filosofia unix, sono tutte minchiate davanti ai problemi da risolvere,
>
> Continui a parlare di "problemi da risolvere"... io ripeto... non ne vedo (forse perché non sono un sysadmin) e non capisco perché non si possano risolvere con delle modifiche all'init attuale anziché buttare via tutto per passare ad un sistema monolitico che includerà un po' tutto quello che ora invece è delegato a vari sottosistemi indipendenti e testati da decenni di uso in ambiente ostile.
Ti racconto il mio problema da risolvere: hai mai letto il file /etc/init.d/tomcat6 di debian?
Io sì, per quello so che problema vogliono risolvere: 295 righe di shellscript sul server del fdt, dove la cosa peggiore è che siccome java non forka da solo si manda il processo in background e si aspettano 5 secondi; Se il pid è ancora vivo allora considero il server startato; tutto questo non tiene conto che i pid vengono riusati dal sistema e potrei avere un nuovo processo che non è tomcat avviato con lo stesso pid, che il pidfile potrebbe essere rimasto là perché il sistema è crashato, che tomcat potrebbe crashare in avvio dopo oltre 5 secondi.
Una bella ciofeca.
Inoltre se lo script ha un bug è molto probabile che questo venga copincollato in molti rc di altri demoni basati su java (hai visto /etc/init.d/jetty? non ti sembra stranamente simile a quello di tomcat?).
Questo senza entrare nel merito di come sia impossibile lanciare due tomcat su due porte diverse e controllarli senza dover copincollare le 295 righe di cui sopra e adattarle a gestire parametri aggiuntivi.
> La filosofia unix non è una minchiata, deriva da decenni di esperienza e ha dimostrato di essere ottimale in termini di modularità e sicurezza. Se per esempio wget si rompe... basta aggiustare wget. Nessun riavvio necessario, nessuna necessità di ricompilazione di niente a parte wget, tutti i programmi che usano wget in background ora automagicamente useranno quello nuovo. Se poi wget non ti piace puoi facilmente crearne un sostituto senza dover cambiare niente altro nel tuo sistema.
La filosofia unix deriva dal fatto che il process spawning in unix costa poco e se ne è abusato, ma vedere un sistema bootato dopo aver lanciato 2000 volte exec molti dei quali sono sed/grep & co. infilati nei vari script è una vera porcata.
Per la cronaca nel mio sistema dal boot al desktop aperto passano circa 300 pid.
> Da un punto di vista della sicurezza di un sistema... più piccolo e semplice è e meno problemi provoca... e la sicurezza in un SO dovrebbe essere prioritaria rispetto a tutte le altre considerazioni, soprattutto se si tratta di server (ma anche a casa mia pretendo che i miei computer siano il più possibile sicuri, di quello che succede a casa altrui non mi interessa nulla).
Il core di systemd (init e journald) sono piccoli, il resto sono utility che se sparissero non intaccherebbero l'init in nessun modo.
> Quando hai a che fare con un minestrone di migliaia di righe di codice, magari scritte in un linguaggio error-prone come C/C++, scritte da decine di persone diverse con altrettanti stili di programmazione diversi finisce quasi certamente nel disastro.
Shellscript non è error-prone?
> > e sysv ha un approccio peggiore al problema di gestire i demoni.
>
> Mah, sarà anche peggiore, ma ha funzionato per decenni... ed essendo pure semplice i bugfix che ha necessitato negli anni si contano sulle dita di una mano.
> Possiamo fare le stesse considerazioni su Systemd? No.
> Possiamo ragionevolmente prevedere che Systemd si comporterà altrettanto bene? No, anzi, tutte le premesse fanno pensare che non sarà così.
[opinione]
> > Il problema di systemd è l'integrazione di gnome e come sia diventato una sua dipendenza, rendendo necessario anche solo installare systemd (senza che sia l'init di sistema) per poter usare il desktop.
>
> Questo in realtà non riguarda solo Gnome. Systemd vuole essere un po' tutto e perciò è normale che gli altri sistemi comincino a richiederlo come dipendenza. Systemd sembra più una sorta di trojan che piano piano si espande all'intero sistema rendendoti impossibile far funzionare il tuo sistema in modo indipendente da esso che un init-system.
>
> Negli anni vedrai che sempre più sistemi e sottosistemi DOVRANNO avere Systemd come dipendenza... prova a quel punto a proporre qualcosa di diverso... come potresti fare? Immagina che Systemd si riveli essere una cattiva scelta... come lo sostituisci se tutto il resto di Linux dipenderà da esso?
>
> Cambiare init oggi è facile... domani, con Systemd, potrebbe non essere così semplice.
Guarda che tutta la polemica è verte su logind, e ti ripeto che desktop e server sono due cose diverse.
> > Il problema degli aggiornamenti di systemd invece non esiste, finora sono stati retrocompatibili dal punto di vista di interfacce binarie (dbus), rendendo possibile l'uso del sistema dopo un update senza "urgenza" di riavviare (systemctl & co. continuano a funzionare).
>
> Bé, speriamo tu abbia ragione, i miei server non li voglio riavviare ogni volta che qualcuno a RedHat starnutisce.
È così già oggi, a 4 anni dalla nascita di systemd.
> Scritto da: ::1
> > Io sono dell'opinione opposta, systemd ha grossi vantaggi proprio per i sysadmin;
>
> Onestamente non ne vedo. Non sono un sysadmin ma tutti i sysadmin che conosco sono, in genere, fortemente contrari a Systemd con qualche voce fuori dal coro.
Non so che sysadmin conosci tu, io lavoro per una azienda piena di sysadmin, a contatto con sysadmin di altre aziende. Avere un process supervisor come init è un vantaggio e basta, non ha contro, solo pro; infatti upstart era inizialmente stato adottato come init di rhel (ci lavoro, lo uso).
Ti dico pure che iniziano a sperimentare l'user mode di systemd, dove un utente ha i suoi demoni, che girano unprivileged, coi suoi unit file, per usare systemd per lanciare le procedure di business del cliente senza avere prodotti esterni (usano ancora orsyp dollar universe su aix, stanno migrando alcune cose verso rhel).
> > è chiaro che deve ancora dimostrare di essere affidabile e stabile per anni e anni e anni,
>
> Quindi sei d'accordo che è sbagliato metterlo in produzione già da subito. Se l'avessero messo _come opzione_ non ci sarebbero stati problemi, invece non solo per molte distro non è affatto un'opzione, ma è addirittura richiesto se vuoi usare determinati componenti (come Gnome)... e sarà sempre peggio perché Systemd è _progettato_ per essere usato quasi come libreria e quindi per diventare una dipendenza fondamentale per sempre più sistemi.
gnome <> server
> > ma c'è da dire che le features di base (unit file, process monitor, journald) non hanno problemi, tant'è che i server centos/redhat non esplodono e sono ancora considerati rock-solid.
>
> Non ne sono sicuro. Su cosa basi questa tua affermazione? Sul mero (presunto) fatto che ancora nessuno ha ownato un server CentOS/redhat? Magari hai anche ragione, ma la mia esperienza mi dice che un sistema complesso è in genere il primo motivo per cui un sistema finisce per fallire.
Ne sono sicuro.
> > L'unico appunto sono forse i binary log, ma basta cambiare un flag e tornano testuali.
>
> Finché non decideranno che quella flag non serve più per via degli "innegabili vantaggi dei binary log". Magari ti faranno sparire l'opzione da una release all'altra e tu potrai solo inghiottire e chiudere la bocca... tanto è più o meno stata questa la politica adottata fin'ora circa Systemd.
> "Non ti piace? Cazzi tuoi. Noi andiamo avanti per questa strada, se vuoi forka... ah... e good luck with that... visto che ora Gnome dipende da noi e in futuro sempre più sistemi e sottosistemi dipenderanno da noi".
Avrei un elenco di fallacie da proporti, visto che stai ragionando sui se e sui ma.
> Non so... a te sembra una politica/modo di fare accettabile nel mondo opensource? A me sembra una politica piuttosto aggressiva e poco "user-friendly". E, nota, è stata più o meno la stessa politica usata con pulseaudio... guardacaso l'autore è lo stesso.
E guardacaso pulseaudio era una merda all'inizio, ma basato su una idea buona, e oggi è un buon software che risolve un problema che linus non ha voluto risolvere nel kernel (la parentesi audio su linux non sta nel margine della pagina).
> > Per quanto riguarda la filosofia unix, sono tutte minchiate davanti ai problemi da risolvere,
>
> Continui a parlare di "problemi da risolvere"... io ripeto... non ne vedo (forse perché non sono un sysadmin) e non capisco perché non si possano risolvere con delle modifiche all'init attuale anziché buttare via tutto per passare ad un sistema monolitico che includerà un po' tutto quello che ora invece è delegato a vari sottosistemi indipendenti e testati da decenni di uso in ambiente ostile.
Ti racconto il mio problema da risolvere: hai mai letto il file /etc/init.d/tomcat6 di debian?
Io sì, per quello so che problema vogliono risolvere: 295 righe di shellscript sul server del fdt, dove la cosa peggiore è che siccome java non forka da solo si manda il processo in background e si aspettano 5 secondi; Se il pid è ancora vivo allora considero il server startato; tutto questo non tiene conto che i pid vengono riusati dal sistema e potrei avere un nuovo processo che non è tomcat avviato con lo stesso pid, che il pidfile potrebbe essere rimasto là perché il sistema è crashato, che tomcat potrebbe crashare in avvio dopo oltre 5 secondi.
Una bella ciofeca.
Inoltre se lo script ha un bug è molto probabile che questo venga copincollato in molti rc di altri demoni basati su java (hai visto /etc/init.d/jetty? non ti sembra stranamente simile a quello di tomcat?).
Questo senza entrare nel merito di come sia impossibile lanciare due tomcat su due porte diverse e controllarli senza dover copincollare le 295 righe di cui sopra e adattarle a gestire parametri aggiuntivi.
> La filosofia unix non è una minchiata, deriva da decenni di esperienza e ha dimostrato di essere ottimale in termini di modularità e sicurezza. Se per esempio wget si rompe... basta aggiustare wget. Nessun riavvio necessario, nessuna necessità di ricompilazione di niente a parte wget, tutti i programmi che usano wget in background ora automagicamente useranno quello nuovo. Se poi wget non ti piace puoi facilmente crearne un sostituto senza dover cambiare niente altro nel tuo sistema.
La filosofia unix deriva dal fatto che il process spawning in unix costa poco e se ne è abusato, ma vedere un sistema bootato dopo aver lanciato 2000 volte exec molti dei quali sono sed/grep & co. infilati nei vari script è una vera porcata.
Per la cronaca nel mio sistema dal boot al desktop aperto passano circa 300 pid.
> Da un punto di vista della sicurezza di un sistema... più piccolo e semplice è e meno problemi provoca... e la sicurezza in un SO dovrebbe essere prioritaria rispetto a tutte le altre considerazioni, soprattutto se si tratta di server (ma anche a casa mia pretendo che i miei computer siano il più possibile sicuri, di quello che succede a casa altrui non mi interessa nulla).
Il core di systemd (init e journald) sono piccoli, il resto sono utility che se sparissero non intaccherebbero l'init in nessun modo.
> Quando hai a che fare con un minestrone di migliaia di righe di codice, magari scritte in un linguaggio error-prone come C/C++, scritte da decine di persone diverse con altrettanti stili di programmazione diversi finisce quasi certamente nel disastro.
Shellscript non è error-prone?
> > e sysv ha un approccio peggiore al problema di gestire i demoni.
>
> Mah, sarà anche peggiore, ma ha funzionato per decenni... ed essendo pure semplice i bugfix che ha necessitato negli anni si contano sulle dita di una mano.
> Possiamo fare le stesse considerazioni su Systemd? No.
> Possiamo ragionevolmente prevedere che Systemd si comporterà altrettanto bene? No, anzi, tutte le premesse fanno pensare che non sarà così.
[opinione]
> > Il problema di systemd è l'integrazione di gnome e come sia diventato una sua dipendenza, rendendo necessario anche solo installare systemd (senza che sia l'init di sistema) per poter usare il desktop.
>
> Questo in realtà non riguarda solo Gnome. Systemd vuole essere un po' tutto e perciò è normale che gli altri sistemi comincino a richiederlo come dipendenza. Systemd sembra più una sorta di trojan che piano piano si espande all'intero sistema rendendoti impossibile far funzionare il tuo sistema in modo indipendente da esso che un init-system.
>
> Negli anni vedrai che sempre più sistemi e sottosistemi DOVRANNO avere Systemd come dipendenza... prova a quel punto a proporre qualcosa di diverso... come potresti fare? Immagina che Systemd si riveli essere una cattiva scelta... come lo sostituisci se tutto il resto di Linux dipenderà da esso?
>
> Cambiare init oggi è facile... domani, con Systemd, potrebbe non essere così semplice.
Guarda che tutta la polemica è verte su logind, e ti ripeto che desktop e server sono due cose diverse.
> > Il problema degli aggiornamenti di systemd invece non esiste, finora sono stati retrocompatibili dal punto di vista di interfacce binarie (dbus), rendendo possibile l'uso del sistema dopo un update senza "urgenza" di riavviare (systemctl & co. continuano a funzionare).
>
> Bé, speriamo tu abbia ragione, i miei server non li voglio riavviare ogni volta che qualcuno a RedHat starnutisce.
È così già oggi, a 4 anni dalla nascita di systemd.
Young professional woman and busy mom.
☺
s2> openssl version LibreSSL 2.0 s2> uname -a OpenBSD s2.[redacted].com 5.6 GENERIC#2 i386 s2> nginx -v nginx version: nginx/1.6.0 s2> node -v v0.10.28 s2> coffee -v CoffeeScript version 1.7.1 s2> redis-server -v Redis server v=2.8.12 sha=00000000:0 malloc=libc bits=32 build=ef22ad39d399e42f
Young professional woman and busy mom.
☺
Scritto da: Pippo Pernacchia
>
> E' arrivata già la smentita
>
> http://www.bufale.net/home/bufala-sesso-uomo-in-og...
>
> Comunque specificava che i partner avrebbero dovuto essere affascinanti, non morti viventi, quindi tu che c'entri?
A che serve un multinick se si può postare anonimamente?
>
> E' arrivata già la smentita
>
> http://www.bufale.net/home/bufala-sesso-uomo-in-og...
>
> Comunque specificava che i partner avrebbero dovuto essere affascinanti, non morti viventi, quindi tu che c'entri?
A che serve un multinick se si può postare anonimamente?
Young professional woman and busy mom.
☺
Scritto da:
> Scritto da: SΑMURAI
> > Comunque io non credo a 'sta storia.
> >
> > Io per sapere se posso crederci o meno aspetto che si esprimano Pablo Aio o Adam Kadmon
>
>
> Te le bevi tutte, come al solito
>
> http://www.meteoweb.eu/2014/10/limminente-allineam...
>
>
Anche tu non sai distinguere SΑMURAI da SAMURAI.
> Scritto da: SΑMURAI
> > Comunque io non credo a 'sta storia.
> >
> > Io per sapere se posso crederci o meno aspetto che si esprimano Pablo Aio o Adam Kadmon
>
>
> Te le bevi tutte, come al solito
>
> http://www.meteoweb.eu/2014/10/limminente-allineam...
>
>
Anche tu non sai distinguere SΑMURAI da SAMURAI.
Young professional woman and busy mom.
Arricchimento culturale in Svezia
Ad
https://www.breitbart.com/europe/2019/01/04/patient-placed-in-quarantine-after-suspected-ebola-case-in-sweden/
The Emergency Room of a Swedish hospital was closed down Friday morning after a patient recently returned from Africa arrived vomiting blood, a possible symptom of the deadly and contagious Ebola virus.
☺
Scritto da:
>
> Stasera sono troppo intontito per capirne le implicazioni.
tl;dr: facebook apre un onion service per chi accede da tor, dice che così è più sicuro, hanno fatto pure il cert ssl per quell'hostname (facebookcorewwwi.onion); nei commenti di HN c'è un post intereffante di uno che lavorava alle login di google, dice che se ti registri via tor il numero di telefono è obbligatorio, in alternativa devi fare la registrazione senza tor perché così hanno un dato fisico per evitare abusi del sistema, altri commenti invece parlano di come facebook con questa mossa possa dare una falsa sensazione di sicurezza e di come hanno bruteforceato il marchingegno che ti crea un nome random di hostname .onion per trovare quelli carini.
>
> Stasera sono troppo intontito per capirne le implicazioni.
tl;dr: facebook apre un onion service per chi accede da tor, dice che così è più sicuro, hanno fatto pure il cert ssl per quell'hostname (facebookcorewwwi.onion); nei commenti di HN c'è un post intereffante
di uno che lavorava alle login di google, dice che se ti registri via tor il numero di telefono è obbligatorio, in alternativa devi fare la registrazione senza tor perché così hanno un dato fisico per evitare abusi del sistema, altri commenti invece parlano di come facebook con questa mossa possa dare una falsa sensazione di sicurezza e di come hanno bruteforceato il marchingegno che ti crea un nome random di hostname .onion per trovare quelli carini.
Young professional woman and busy mom.
☺
Scritto da:
> non esiste una cosa come l'amicizia tra Achille e Patroclo
> non esiste una cosa come l'amicizia tra Achille e Patroclo
Young professional woman and busy mom.
☺
Commenti su HN: https://news.ycombinator.com/item?id=8538281
Young professional woman and busy mom.
☺
Scritto da: altg
>
> Non ci ho capito quasi una minchia.
> Come sarebbe non usare POST per scrivere... cosa?
Ho sbagliato: era usare sempre POST, all'inizio mi stavo mettendo a parlare di metodi idempotenti, il non mi è rimasto là.
> La mia Top 1 (uno e basta) per evitare hackeraggi e` sempre stata "tanto scrivo tutto io, sicche` chi deve hackerare deve prima capire come funziona tutta la baracca, mica trova gli exploit pronti".
Infatti frenchi in un nanosecondo ti aveva trovato i buchi di postline
>
> Non ci ho capito quasi una minchia.
> Come sarebbe non usare POST per scrivere... cosa?
Ho sbagliato: era usare sempre POST, all'inizio mi stavo mettendo a parlare di metodi idempotenti, il non mi è rimasto là.
> La mia Top 1 (uno e basta) per evitare hackeraggi e` sempre stata "tanto scrivo tutto io, sicche` chi deve hackerare deve prima capire come funziona tutta la baracca, mica trova gli exploit pronti".
Infatti frenchi in un nanosecondo ti aveva trovato i buchi di postline
Young professional woman and busy mom.
☺
Scritto da:
> Ai tempi in cui me n'ero occupato si fondeva con il problema dell'erronea trasmissione di certi caratteri da parte dei browser (un baco forse risalente a Mosaic) per cui conveniva trasformare in entità via Javascript tutti i caratteri non lower ASCII, e anche qualcuno lower ASCII, prima di trasmetterli al server.
Succede ancora oggi con IE che non onora il page encoding quando invia i form, a meno che non gli infili tra i dati da inviare un carattere tipo snowman o pile of poo che non sta nelle tabelle caratteri non unicode.
> Suppongo che oggi i browser trasmettano correttamente tutti i caratteri Unicode, e allora mi chiedo, come dev'essere fatta oggi questa igienizzazione? Col Viakal?
>
> Una volta che la stringa inserita in un campo INPUT o TEXTAREA o altro è ricevuta dal server, questo che deve fare per evitare iniezioni di codice o altri problemi? Convertire in entità i caratteri aventi un significato particolare in HTML, JS e PHP, e opzionalmente tutto ciò che eccede il lower ASCII per prevenire problemi di encoding?
Il trasporto dal browser al server avviene solitamente mediante percent encoding fatta dal browser (enctype application/x-www-form-urlencoded). Devi trasportare la stringa ricevuta, opportunamente trattata dal framework server che si usa, possibilmente così com'è (non come sul fdt) e escapare l'output con le apposite funzioni. Se usi un db usa sempre i prepared statement. Non fidarti del client per niente che non sia il mero dato richiesto, abusa della sessione utente (praticamente tutti i framework web la mettono a disposizione). Le operazioni di scrittura non vanno fatte con metodo http POST (verificalo sempre) per evitare che un link malevolo possa eseguire operazioni non desiderate.
Il tuo punto di partenza comunque è owasp top 10 per le vulnerabilità più diffuse e i rimedi da usare: https://www.owasp.org/index.php/Category:OWASP_Top...
> Ai tempi in cui me n'ero occupato si fondeva con il problema dell'erronea trasmissione di certi caratteri da parte dei browser (un baco forse risalente a Mosaic) per cui conveniva trasformare in entità via Javascript tutti i caratteri non lower ASCII, e anche qualcuno lower ASCII, prima di trasmetterli al server.
Succede ancora oggi con IE che non onora il page encoding quando invia i form, a meno che non gli infili tra i dati da inviare un carattere tipo snowman o pile of poo che non sta nelle tabelle caratteri non unicode.
> Suppongo che oggi i browser trasmettano correttamente tutti i caratteri Unicode, e allora mi chiedo, come dev'essere fatta oggi questa igienizzazione? Col Viakal?
>
> Una volta che la stringa inserita in un campo INPUT o TEXTAREA o altro è ricevuta dal server, questo che deve fare per evitare iniezioni di codice o altri problemi? Convertire in entità i caratteri aventi un significato particolare in HTML, JS e PHP, e opzionalmente tutto ciò che eccede il lower ASCII per prevenire problemi di encoding?
Il trasporto dal browser al server avviene solitamente mediante percent encoding fatta dal browser (enctype application/x-www-form-urlencoded). Devi trasportare la stringa ricevuta, opportunamente trattata dal framework server che si usa, possibilmente così com'è (non come sul fdt) e escapare l'output con le apposite funzioni. Se usi un db usa sempre i prepared statement. Non fidarti del client per niente che non sia il mero dato richiesto, abusa della sessione utente (praticamente tutti i framework web la mettono a disposizione). Le operazioni di scrittura non vanno fatte con metodo http POST (verificalo sempre) per evitare che un link malevolo possa eseguire operazioni non desiderate.
Il tuo punto di partenza comunque è owasp top 10 per le vulnerabilità più diffuse e i rimedi da usare: https://www.owasp.org/index.php/Category:OWASP_Top...
Young professional woman and busy mom.