Il team di OpenBSD ha iniziato a patchare e fixare OpenSSL:
https://lobste.rs/s/3utipo/openbsd_has_started_a_m...
https://lobste.rs/s/3utipo/openbsd_has_started_a_m...
Young professional woman and busy mom.
Young professional woman and busy mom.
Scritto da:
>
> Conosco solo roba commerciale, cioè i film che mi portano a vedere quando mi pagano il biglietto.
eraserhead è un film cult del genere parecchio strampalato
>
> Conosco solo roba commerciale, cioè i film che mi portano a vedere quando mi pagano il biglietto.
eraserhead è un film cult del genere parecchio strampalato
Young professional woman and busy mom.
Scritto da:
>
> Installato, ma non ricordo come si usa.
Ha un solo bottone…
>
> Installato, ma non ricordo come si usa.

Ha un solo bottone…
Young professional woman and busy mom.
Scritto da: avvelentani
>
> Non e` vero, il codice di X.org che fa il parsing del protocollo e` una merda che non tocca nessuno da tempi immemori. Non esponete mai X11 su internet binbi.
Xorg è stato ben manutenuto, i suoi difetti sono nel protocollo. È stato reso modulare, ma non hanno voluto riscrivere niente da zero, ergo il parser naive.
>
> Non e` vero, il codice di X.org che fa il parsing del protocollo e` una merda che non tocca nessuno da tempi immemori. Non esponete mai X11 su internet binbi.
Xorg è stato ben manutenuto, i suoi difetti sono nel protocollo. È stato reso modulare, ma non hanno voluto riscrivere niente da zero, ergo il parser naive.
Young professional woman and busy mom.
Scritto da:
> Scritto da: altg
> > > 2. la storia di openssl non è un sintomo di niente se non di un progetto praticamente in maintainance mode, con delle api che non sono proprio semplici da utilizzare e tendono a far commettere degli errori a chi le utilizza; il codice è in cattivo stato e molta gente non se ne cura perché funziona; altri progetti nell'ambito netsec godono di migliore stato; openssl è sintomo di cattiva gestione del progetto
> >
> > Ma prima di heartbleed si sapeva che era un progetto "praticamente in maintenance mode"? Qualunque cosa sto giro di parole significhi? Se si sapeva, non l'ha cagato nessuno quel cazzo di controllino sulla dimensione della richiesta? Quanti sono i progetti in blahbanf mode che scoppieranno tranquillamente nei prossimi anni?
> >
>
> mi avete fatto venire la curiosità di vedere come è fatto 'sto software
>
> e questo è male perchè ho altre n cose da studiare
>
>
Cerca con google "openssl is written by monkeys", è un articolo del 2009.
> Scritto da: altg
> > > 2. la storia di openssl non è un sintomo di niente se non di un progetto praticamente in maintainance mode, con delle api che non sono proprio semplici da utilizzare e tendono a far commettere degli errori a chi le utilizza; il codice è in cattivo stato e molta gente non se ne cura perché funziona; altri progetti nell'ambito netsec godono di migliore stato; openssl è sintomo di cattiva gestione del progetto
> >
> > Ma prima di heartbleed si sapeva che era un progetto "praticamente in maintenance mode"? Qualunque cosa sto giro di parole significhi? Se si sapeva, non l'ha cagato nessuno quel cazzo di controllino sulla dimensione della richiesta? Quanti sono i progetti in blahbanf mode che scoppieranno tranquillamente nei prossimi anni?
> >
>
> mi avete fatto venire la curiosità di vedere come è fatto 'sto software
>
> e questo è male perchè ho altre n cose da studiare

>
>

Cerca con google "openssl is written by monkeys", è un articolo del 2009.
Young professional woman and busy mom.
Scritto da: altg
>
> Ma prima di heartbleed si sapeva che era un progetto "praticamente in maintenance mode"?
Sì, ma finché funziona nessuno se ne cura.
> Qualunque cosa sto giro di parole significhi?
Significa che non vengono aggiunte nuove feature a meno che non siano richieste per raggiungere particolari scopi, ad esempio aggiornamenti di specifiche che sono implementate nel software.
Le api esposte non varieranno più, salvo motivi sufficentemente "gravi".
> Se si sapeva, non l'ha cagato nessuno quel cazzo di controllino sulla dimensione della richiesta?
Non vengono fatti audit del codice spesso, perché è poco movimentato e ci si aspetta che rimanga abbastanza stabile.
> Quanti sono i progetti in blahbanf mode che scoppieranno tranquillamente nei prossimi anni?
Sono pochi i progetti che hanno un ruolo così critico ad essere in cattivo stato.
Dal mio punto di vista i progetti che costituiscono le basi di un so linux sono: il kernel, la libc, le coreutils, l'init; se un sistema è un server aggiungi openssh, openssl, l'httpd (nginx o apache che sia), altri servizi che espone.
Di questi solo di openssl si trova in questo stato. Di progetti comparabili come complessità e dimensione che sono stati resuscitati e godono di un buono stato c'è Xorg tra tutti.
>
> Ma prima di heartbleed si sapeva che era un progetto "praticamente in maintenance mode"?
Sì, ma finché funziona nessuno se ne cura.
> Qualunque cosa sto giro di parole significhi?
Significa che non vengono aggiunte nuove feature a meno che non siano richieste per raggiungere particolari scopi, ad esempio aggiornamenti di specifiche che sono implementate nel software.
Le api esposte non varieranno più, salvo motivi sufficentemente "gravi".
> Se si sapeva, non l'ha cagato nessuno quel cazzo di controllino sulla dimensione della richiesta?
Non vengono fatti audit del codice spesso, perché è poco movimentato e ci si aspetta che rimanga abbastanza stabile.
> Quanti sono i progetti in blahbanf mode che scoppieranno tranquillamente nei prossimi anni?
Sono pochi i progetti che hanno un ruolo così critico ad essere in cattivo stato.
Dal mio punto di vista i progetti che costituiscono le basi di un so linux sono: il kernel, la libc, le coreutils, l'init; se un sistema è un server aggiungi openssh, openssl, l'httpd (nginx o apache che sia), altri servizi che espone.
Di questi solo di openssl si trova in questo stato. Di progetti comparabili come complessità e dimensione che sono stati resuscitati e godono di un buono stato c'è Xorg tra tutti.
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: gengiva
>
> work in progress MERDAZOR!!
> http://gfycat.com/ImpartialSmartLangur
>
> uploadato in webm ma non so come l'ha convertito, di sicuro l'url è bislacco
Gli url sono generati per essere mnemonici, gfycat li serve sia in webm che in mp4, a seconda del supporto del browser.
>
> work in progress MERDAZOR!!

> http://gfycat.com/ImpartialSmartLangur

>
> uploadato in webm ma non so come l'ha convertito, di sicuro l'url è bislacco

Gli url sono generati per essere mnemonici, gfycat li serve sia in webm che in mp4, a seconda del supporto del browser.
Young professional woman and busy mom.
Scritto da:
> Scritto da: ::1
> > Scritto da: altg
> > >
> > > Colpito al cuore, eh?
> >
> > Vabbè, ho capito, procedo.
> >
> > 1. se proprio vogliamo fare i precisi, cosa accade sui frontend di autenticazione è dipendente dall'implementazione, e google, facebook, amazon non usano certo dei prodotti già fatti ma si scrivono i propri meccanismi di autenticazione; e non è detto che utilizzino openssl
>
> i meccanismi di autenticazione a livello applicativo poggiano comunque su ssl
>
> mi viene in mente ad esempio paypal
Nì, ma ipotizziamo una struttura di una gigazienda tipo quelle nominate, avrai un frontend che serve solo files statici e reverseproxa tutto verso le macchine dedicate al task, comprese le request di autenticazione.
Se gli fai fare l'autenticazione hai i cookie in memoria, e un attacker te li deve cercare 64k per volta dentro gb di ram.
> > 2. la storia di openssl non è un sintomo di niente se non di un progetto praticamente in maintainance mode, con delle api che non sono proprio semplici da utilizzare e tendono a far commettere degli errori a chi le utilizza; il codice è in cattivo stato e molta gente non se ne cura perché funziona; altri progetti nell'ambito netsec godono di migliore stato; openssl è sintomo di cattiva gestione del progetto
>
> rimane un punto: trovi gente che ci lavori sopra, magari rifattorizzi il codice e sopratutto se ne prenda la responsabilità?
Allo stato delle cose no, ma non è un problema se si diffondono strade alternativa più manutenibili.
> > 3. esistono delle alternative a openssl che stanno fortunatamente prendendo piede, ma l'adozione è lenta perché si tratta di codice molto delicato per la funzione che svolge, per quanto nacl di djb sia nuova, migliore e sbrilluccicante ci vorrà del tempo per vederne una estesa adozione; non nomino gnutls perché fa schifo
> > 4. le contribuzioni relative ad android hanno avuto un picco, ora che le api sono stabili ci si limita ad aggiungere i driver delle nuove periferiche, lo sviluppo del kernel non è orientato ad android, non lo è stato in passato (era un fork)
> > 5. i contributi di sviluppatori al kernel di linux sono stabilmente (ultimi 5 anni) nella proporzione 75% dipendenti di aziende pagati per lavorare sul kernel e 25% volontari, non è così per gli altri progetti, dove i volontari sono in numero maggiore, soprattutto nell'ambito desktop dove c'è pochissimo interesse per le aziende ad oggi
> > 6. c++ gode di ottima salute, ha avuto degli sviluppi eccezionali negli ultimi 10 anni, ha ancora dei problemi dovuti a decisioni prese quando è progettato la prima volta; stanno nascendo delle alternative promettenti a c++, il futuro promette benissimo (go, rust, d, ...ehm.. cough... vala)
>
> domanda: ci si mangia o ci si gioca in cantina?
>
>
Se sei Theo De Raadt ci mangi e vivi di consulting, se sei Young ed Erwing ci fondi la Red Hat e ti quoti in borsa, se sei The Lich da Forlì ci scrivi una tesina.
> Scritto da: ::1
> > Scritto da: altg
> > >
> > > Colpito al cuore, eh?

> >
> > Vabbè, ho capito, procedo.
> >
> > 1. se proprio vogliamo fare i precisi, cosa accade sui frontend di autenticazione è dipendente dall'implementazione, e google, facebook, amazon non usano certo dei prodotti già fatti ma si scrivono i propri meccanismi di autenticazione; e non è detto che utilizzino openssl
>
> i meccanismi di autenticazione a livello applicativo poggiano comunque su ssl
>
> mi viene in mente ad esempio paypal
Nì, ma ipotizziamo una struttura di una gigazienda tipo quelle nominate, avrai un frontend che serve solo files statici e reverseproxa tutto verso le macchine dedicate al task, comprese le request di autenticazione.
Se gli fai fare l'autenticazione hai i cookie in memoria, e un attacker te li deve cercare 64k per volta dentro gb di ram.
> > 2. la storia di openssl non è un sintomo di niente se non di un progetto praticamente in maintainance mode, con delle api che non sono proprio semplici da utilizzare e tendono a far commettere degli errori a chi le utilizza; il codice è in cattivo stato e molta gente non se ne cura perché funziona; altri progetti nell'ambito netsec godono di migliore stato; openssl è sintomo di cattiva gestione del progetto
>
> rimane un punto: trovi gente che ci lavori sopra, magari rifattorizzi il codice e sopratutto se ne prenda la responsabilità?
Allo stato delle cose no, ma non è un problema se si diffondono strade alternativa più manutenibili.
> > 3. esistono delle alternative a openssl che stanno fortunatamente prendendo piede, ma l'adozione è lenta perché si tratta di codice molto delicato per la funzione che svolge, per quanto nacl di djb sia nuova, migliore e sbrilluccicante ci vorrà del tempo per vederne una estesa adozione; non nomino gnutls perché fa schifo
> > 4. le contribuzioni relative ad android hanno avuto un picco, ora che le api sono stabili ci si limita ad aggiungere i driver delle nuove periferiche, lo sviluppo del kernel non è orientato ad android, non lo è stato in passato (era un fork)
> > 5. i contributi di sviluppatori al kernel di linux sono stabilmente (ultimi 5 anni) nella proporzione 75% dipendenti di aziende pagati per lavorare sul kernel e 25% volontari, non è così per gli altri progetti, dove i volontari sono in numero maggiore, soprattutto nell'ambito desktop dove c'è pochissimo interesse per le aziende ad oggi
> > 6. c++ gode di ottima salute, ha avuto degli sviluppi eccezionali negli ultimi 10 anni, ha ancora dei problemi dovuti a decisioni prese quando è progettato la prima volta; stanno nascendo delle alternative promettenti a c++, il futuro promette benissimo (go, rust, d, ...ehm.. cough... vala)
>
> domanda: ci si mangia o ci si gioca in cantina?
>
>

Se sei Theo De Raadt ci mangi e vivi di consulting, se sei Young ed Erwing ci fondi la Red Hat e ti quoti in borsa, se sei The Lich da Forlì ci scrivi una tesina.
Young professional woman and busy mom.
Scritto da: altg
>
> Colpito al cuore, eh?
Vabbè, ho capito, procedo.
1. se proprio vogliamo fare i precisi, cosa accade sui frontend di autenticazione è dipendente dall'implementazione, e google, facebook, amazon non usano certo dei prodotti già fatti ma si scrivono i propri meccanismi di autenticazione; e non è detto che utilizzino openssl
2. la storia di openssl non è un sintomo di niente se non di un progetto praticamente in maintainance mode, con delle api che non sono proprio semplici da utilizzare e tendono a far commettere degli errori a chi le utilizza; il codice è in cattivo stato e molta gente non se ne cura perché funziona; altri progetti nell'ambito netsec godono di migliore stato; openssl è sintomo di cattiva gestione del progetto
3. esistono delle alternative a openssl che stanno fortunatamente prendendo piede, ma l'adozione è lenta perché si tratta di codice molto delicato per la funzione che svolge, per quanto nacl di djb sia nuova, migliore e sbrilluccicante ci vorrà del tempo per vederne una estesa adozione; non nomino gnutls perché fa schifo
4. le contribuzioni relative ad android hanno avuto un picco, ora che le api sono stabili ci si limita ad aggiungere i driver delle nuove periferiche, lo sviluppo del kernel non è orientato ad android, non lo è stato in passato (era un fork)
5. i contributi di sviluppatori al kernel di linux sono stabilmente (ultimi 5 anni) nella proporzione 75% dipendenti di aziende pagati per lavorare sul kernel e 25% volontari, non è così per gli altri progetti, dove i volontari sono in numero maggiore, soprattutto nell'ambito desktop dove c'è pochissimo interesse per le aziende ad oggi
6. c++ gode di ottima salute, ha avuto degli sviluppi eccezionali negli ultimi 10 anni, ha ancora dei problemi dovuti a decisioni prese quando è progettato la prima volta; stanno nascendo delle alternative promettenti a c++, il futuro promette benissimo (go, rust, d, ...ehm.. cough... vala)
7. varie ed eventuali
>
> Colpito al cuore, eh?

Vabbè, ho capito, procedo.
1. se proprio vogliamo fare i precisi, cosa accade sui frontend di autenticazione è dipendente dall'implementazione, e google, facebook, amazon non usano certo dei prodotti già fatti ma si scrivono i propri meccanismi di autenticazione; e non è detto che utilizzino openssl
2. la storia di openssl non è un sintomo di niente se non di un progetto praticamente in maintainance mode, con delle api che non sono proprio semplici da utilizzare e tendono a far commettere degli errori a chi le utilizza; il codice è in cattivo stato e molta gente non se ne cura perché funziona; altri progetti nell'ambito netsec godono di migliore stato; openssl è sintomo di cattiva gestione del progetto
3. esistono delle alternative a openssl che stanno fortunatamente prendendo piede, ma l'adozione è lenta perché si tratta di codice molto delicato per la funzione che svolge, per quanto nacl di djb sia nuova, migliore e sbrilluccicante ci vorrà del tempo per vederne una estesa adozione; non nomino gnutls perché fa schifo
4. le contribuzioni relative ad android hanno avuto un picco, ora che le api sono stabili ci si limita ad aggiungere i driver delle nuove periferiche, lo sviluppo del kernel non è orientato ad android, non lo è stato in passato (era un fork)
5. i contributi di sviluppatori al kernel di linux sono stabilmente (ultimi 5 anni) nella proporzione 75% dipendenti di aziende pagati per lavorare sul kernel e 25% volontari, non è così per gli altri progetti, dove i volontari sono in numero maggiore, soprattutto nell'ambito desktop dove c'è pochissimo interesse per le aziende ad oggi
6. c++ gode di ottima salute, ha avuto degli sviluppi eccezionali negli ultimi 10 anni, ha ancora dei problemi dovuti a decisioni prese quando è progettato la prima volta; stanno nascendo delle alternative promettenti a c++, il futuro promette benissimo (go, rust, d, ...ehm.. cough... vala)
7. varie ed eventuali
Young professional woman and busy mom.
Vieni anche tu in gita in Africa!
Ad
https://www.ilmessaggero.it/AMP/italia/luca_tacchetto_italiano_scomparso_burkina_faso-4209268.html
Le popolazioni locali ti accoglieranno così bene che scomparirai letteralmente dal resto del mondo! Lasciati alle spalle la civiltà occidentale, gli smartphone, la ruota e il fuoco!
Scritto da: gengiva
> perché mi pare tutto molto piu piccolo e incomprensibile
Il fòro è rimasto uguale, ctrl+0 per resettare lo zoom.
> perché mi pare tutto molto piu piccolo e incomprensibile

Il fòro è rimasto uguale, ctrl+0 per resettare lo zoom.
Young professional woman and busy mom.
Scritto da: SAMURAI
> te l'ho già detto. se vuoi aprire una chat lo devi dire PRIMA, MOLTO PRIMA. Io difficilmente apro il forum di sera.
Non so se l'hai notato, in alto c'è un link a ##fdt@freenode, se ci clicchi sopra ti mostra chi c'è in chat.
> te l'ho già detto. se vuoi aprire una chat lo devi dire PRIMA, MOLTO PRIMA. Io difficilmente apro il forum di sera.

Non so se l'hai notato, in alto c'è un link a ##fdt@freenode, se ci clicchi sopra ti mostra chi c'è in chat.
Young professional woman and busy mom.




