La sicurezza dell'Open Source

di Alessandro Bottoni - No, l'analisi di Fortify sulla vulnerabilità del software open source e del modello di sviluppo proprio non convince. Ecco perché

Roma - Ho appena finito di leggere "Fortify: open source insicuro per le imprese". In questo articolo si leggono cose come questa:
"Il numero di buchi, sostiene Fortify, è rimasto quasi lo stesso, o persino aumentato, nelle tre versioni successive di sei dei pacchetti esaminati. Ci va giù pesante West: "Non ci sono numeri di telefono. A chi chiedi informazioni? È spesso persino difficile capire chi sia questa gente"."
Francamente, non mi va proprio a genio che si tratti il mondo Open Source in questo modo, per cui riporto qui di seguito alcune mie personalissime considerazioni sul tema "sicurezza di Windows e sicurezza di Linux".

Un errore ogni 50 righe di codice
Chiariamo subito un punto: il software contiene abitualmente un sacco di errori. Quando dico "un sacco" intendo proprio tanti. A seconda delle fonti delle statistiche, si può andare da un minimo di un errore per 50 righe di codice ad un errore ogni 10 righe di codice. Se tenete presente che un "aggeggio" come Windows Vista è composto da circa 50.000.000 (cinquanta milioni) di righe di codice, potete capire quanti errori noti e meno noti si possano annidare al suo interno. Un "programmino" come quelli che si sviluppano su ordinazione per molti clienti è composto abitualmente da migliaia (a volte decine di migliaia o centinaia di migliaia) di righe di codice e contiene, come minimo, centinaia di errori.
Se volete farvi una cultura sulla stabilità del codice, date un'occhiata a questo spassoso "talk" di Andrew Tanenbaum, presentato nel 2007 alla Linux Conference di Sidney: Design of a Microkernel OS.

La cosa più grave è che solo una parte di questi errori è nota. Secondo alcune statistiche, tra il 10 ed il 20% degli errori viene effettivamente scoperto senza una analisi approfondita del codice. In altri termini, anche un normale programma applicativo, sviluppato su ordinazione, contiene abitualmente centinaia o migliaia di errori e solo qualche decina o qualche centinaio di questi errori è noto agli utenti ed agli amministratori. Gli altri errori restano annidati nel codice in attesa che qualcuno li scopra e li sfrutti come punti deboli per un attacco. O, più, semplicemente, aspettano che qualcuno solleciti nel modo "giusto" il software per fare dei danni.
Sicurezza e Qualità
Questo però è più un problema di Qualità del software che di Sicurezza. Infatti, solo una esigua percentuale degli errori di programmazione può essere sfruttata per un attacco.

Ad esempio, per molti anni una delle vie preferite per attaccare un servizio (come un web server come Apache o MS IIS) è stata quella di sfruttare un buffer overflow legato alla acquisizione di qualche stringa di testo proveniente dal mondo esterno. Si inviava al servizio una "richiesta" contenente una lunghissima sequenza di "pattume" in fondo alla quale c'era del codice da eseguire. Il servizio caricava tutta questa "stringa" in RAM e, quando arrivava a sovrascrivere qualcosa di importante, andava in crash e ripartiva. In alcuni casi, il programma lasciava una parte del pattume in RAM e, al momento del riavvio, il sistema si ritrovava ad eseguire il codice inserito appositamente dall'hacker.

Di attacchi come questo ne potete trovare a decine su packetstormsecurity.org e presso altri siti di "full disclosure" o di security. Ne trovate alcuni analizzati e descritti nel dettaglio nella Reading Room di SANS.
Questa tecnica, tuttavia, funziona solo se c'è un mancato controllo del limite superiore di un array. Non funziona se il codice contiene uno qualunque tra altre decine di possibili tipi di errori. Da qualche anno a questa parte, tutto il codice dei servizi viene scritto in Python, PHP, Ruby od in altri linguaggi che fanno automaticamente i controlli del caso e che quindi non sono soggetti a questo tipo di errore. Di conseguenza, non a tutti gli errori del codice corrisponde una vulnerabilità.

Non solo: non a tutti gli errori contenuti nel codice corrisponde un "bug" visibile dall'utente. Molti errori del codice non producono effetti visibili e/o non vengono mai "attivati" dal comportamento normale dell'utente. In altri termini, molti errori sono visibili solo in condizioni di test deliberatamente eccezionali.
Quindi parlare di "scarsa sicurezza", in presenza di una quantità "elevata" di errori del codice o di bug visibili, è quantomeno fuorviante.
Anche limitandosi alle vere vulnerabilità, tuttavia, le cose stanno in modo piuttosto diverso da quello che potrebbe sembrare leggendo le dichiarazioni di Fortify.

La Sicurezza Closed Source
Per alcuni anni, il mio gruppetto ed io abbiamo lavorato su Windows (NT, 2000 ed XP). Come quasi tutti i consulenti abbiamo fornito hardware, software, manodopera specializzata, servizi di manutenzione, di installazione, di aggiornamento del software e via dicendo. Tra le nostre attività, c'è stata per un periodo anche la gestione della sicurezza: test di penetrazione, gestione degli aggiornamenti, installazione e manutenzione di firewall e di altre "network appliance" e via dicendo. Ad un certo punto, abbiamo deciso che non avremmo più accettato di seguire il tema "sicurezza" per i clienti che usavano Windows (e solo per quelli che usavano Windows).
Perché?
Perché "non ci si arrivava in fondo". Noi facevamo il giro ad installare i service pack ed a configurare correttamente il software e, dopo due minuti, la situazione era già cambiata a causa degli aggiornamenti di Microsoft e dei suoi partner (che a volte modificano anche alcuni aspetti della configurazione) e, soprattutto, a causa del comportamento irresponsabile degli utenti e dei loro capi.

Abbiamo visto di tutto: password scambiate come figurine, firewall disattivati con stizza per accedere al sito porno del momento, giochini di ogni sorta installati senza riflettere (spesso usando l'utenza "administrator" anche quando sarebbe bastata una utenza normale), antivirus lasciati scadere per disinteresse etc. Una delle cose più scioccanti è stato scoprire che molti impiegati e molti dei loro manager lasciavano il laptop aziendale - incustodito, privo di antivirus e connesso ad Internet! - nelle mani dei loro figli di 9 o 12 anni durante il week-end! "Tanto è dell'azienda... non c'è sopra niente di importante..." Ad aggravare la situazione, ci si sono messi anche Microsoft ed altri produttori di software. Per ragioni a noi incomprensibili, infatti, alcuni programmi utente girano solo con i privilegi da amministratore, mandando a carte 48 ogni possibile concetto di sicurezza.

Come potete capire, per garantire la impenetrabilità di una rete o anche di una singola macchina, in queste condizioni, ci vuol un sistema nato per essere sicuro. Se chiunque, sia esso un utente od un partner che opera via Internet, può mettere le mani alla configurazione del sistema, garantirne la sicurezza diventa praticamente impossibile. Se poi dovete far affidamento su un antivirus che spesso non c'è... la frittata è completa. Da questo punto di vista, Linux è già molto meglio di Windows, soprattutto dei vecchi Windows NT e 2000, ma, in realtà, sarebbe necessario un sistema basato su messaggi e su apposite access list, come MS Singularity.

Per chiarezza: gli utenti irresponsabili ci sono in qualunque ambiente ma una cosa è tentare di porre un limite alle loro azioni ed un'altra cosa è assecondarli o fregarsene. Unix (e quindi Linux) tenta seriamente di arginare i comportamenti irresponsabili, soprattutto attraverso l'uso di "default" orientati alla sicurezza. Inoltre, fornisce agli amministratori di sistema gli strumenti necessari per imporre e mantenere uno stato di sicurezza. Questo non è sempre vero nel mondo Windows.

Il Servizio Clienti Closed Source
Nelle condizioni che ho appena descritto, francamente, non serve a nulla avere un numero di telefono da chiamare. Il tecnico dall'altra parte può solo ripetere cose che, per professione, sei già tenuto a sapere.

In realtà, non serve a niente avere un numero da chiamare nemmeno per mettere una pezza ai bug ed ai buchi di vulnerabilità. Quasi sempre, il tecnico si limita a dirti che il problema è già noto, che ci stanno lavorando, e che nell'attesa devi disattivare il servizio o devi disattivare qualche specifica funzionalità. Come nel caso precedente, fino a questo punto ci si arriva anche da soli. Basta consultare il database degli errori noti, leggere qualche articolo in Rete e/o fare uso di un minimo di buon senso e di competenza professionale.

La Sicurezza Open Source
Quando abbiamo "abbandonato" la gestione della sicurezza di reti e macchine basate su Windows, abbiamo però continuato a fornire lo stesso servizio su reti e macchine che usano Unix (Linux, BSD e persino Mac OS X).
Perché?
Né Linux, né BSD, né Mac OS X sono intrinsecamente più sicuri di Windows, almeno non di Windows NT, 2000, XP e Vista. Tutti questi sistemi, nelle mani di un utente esperto e responsabile possono essere resi "sicuri" (nella misura necessaria per le loro attività quotidiana). L'unica vera differenza è che su Windows bisogna acquistare, installare e mantenere aggiornato un antivirus. In nessuno degli altri casi questo è necessario.

La differenza vera la fanno la più rigida compartimentazione delle utenze, la resistenza intrinseca al malware ed una gestione più responsabile dei default durante l'installazione.

Su Unix la differenza tra l'utenza "root" (amministratore) e le utenze normali è chiara, inequivocabile e non può essere facilmente ignorata. Molte distro, di default, non permettono l'accesso grafico (Gnome o KDE) a root e molte distro non permettono l'accesso remoto (via internet) a root. Inoltre una utenza "normale" non può essere facilmente dotata delle capacità specifiche di root. Insomma: l'utente non ha modo di equivocare o di pasticciare con le utenze: root è root e gli altri sono un'altra cosa.

Questo impedisce agli utenti di fare cose assurde come prendere l'utenza "creatura", destinata al figlio di 4 anni, e di attribuirgli i privilegi di amministrazione per non dover premere il tasto "OK, lo so." ogni volta che Windows si lamenta di qualcosa.

La resistenza al malware è più una conseguenza dell'uso di software non-Microsoft che di altre caratteristiche. Come ha fatto notare anche l'US CERT, il solo fatto di non utilizzare MS Internet Explorer rende molto meno vulnerabile l'intero sistema all'attacco da parte di virus, worm, trojan ed altri malware (vedi: http://www.kb.cert.org/vuls/id/713878). Questo vale anche per MS Outlook (ora MS Mail), per MS Word, Access, PowerPoint e via dicendo. La maggiore sensibilità al malware del software Microsoft è soprattutto la conseguenza della maggiore vulnerabilità degli interpreti di linguaggio usati per l'automazione dei compiti e per lo sviluppo di personalizzazioni. L'interprete Visual Basic (VBA) presente in MS Office ed in quasi tutti gli altri programmi MS è notoriamente il primo responsabile di molte infezioni, seguito a ruota dall'interprete JavaScript di MS Internet Explorer e dal vecchio interprete delle Macro di Word ed Excel.

Anche altri programmi, non Microsoft, come OpenOffice, Firefox e Thunderbird, contengono degli interpreti di questo tipo ma nessuno di essi si è mai rivelato vulnerabile come quelli di Microsoft (e non per mancanza di interesse da parte dei virus writer). Curiosamente, Microsoft ha persino risposto in maniera stizzita alle critiche che le sono giunte in passato dalla comunità degli esperti di sicurezza riguardo a questi linguaggi. Ad esempio, la richiesta di disattivare certe funzionalità pericolose (come il preview dei messaggi di posta in formato HTML di Outlook) è stata liquidata come infondata.

Gli interessi degli utenti o quelli dei partner?
In questo si coglie una delle differenze più importanti tra il mondo Open Source ed il mondo Closed Source (soprattutto Microsoft): la capacità di ascoltare gli utenti.
Francamente, è difficile credere che certe decisioni di Microsoft, come la già citata questione delle preview dei messaggi HTML, siano dettate da motivazioni razionali. Molti osservatori, tra cui il sottoscritto, vedono in queste scelte la volontà di favorire Microsoft stessa ed i suoi partner commerciali anche a discapito della sicurezza e della autonomia dell'utente (del proprietario del PC). Alcune di queste funzionalità, infatti, servono soprattutto ai partner di Microsoft per fare i loro comodi sulla macchina dell'utente. Questo è, ad esempio, il caso delle preview HTML: sono certamente più utili agli operatori di Internet che inviano materiale pubblicitario che all'utente che, a causa della preview, si "becca" un virus come Nimda (vedi anche US CERT su Nimda).

Default
Più in generale, questo disinteresse di Microsoft per la sicurezza e per l'autonomia operativa dell'utente si abbatte sugli utenti sotto forma di assurdi default al momento dell'installazione.

Ad esempio: Windows dispone di utenze separate (administrator/altri) almeno da Windows NT (1998) ma solo di recente (Windows XP e Windows Vista) è diventato obbligatorio creare una utenza "admin" ed una utenza "user" al momento dell'installazione. La creazione di due utenze separate è una pratica normale sui sistemi Unix dal 1970.

Questo vale anche per le impostazioni di molti strumenti che dovrebbero garantire la sicurezza del sistema, tra cui le impostazioni dei già citati interpreti di linguaggio integrati nei programmi Microsoft. Addirittura, per comprensibili (ma discutibili) ragioni commerciali, ha fatto in modo che sia sostanzialmente impossibile rimuovere MS Internet Explorer da Windows (visto che è proprio Explorer che genera e gestisce l'interfaccia grafica di Windows). Questo vuol dire che non ci si può liberare in nessun modo del programma che, da solo, viene considerato responsabile della trasmissione del 30 - 60% del malware (a seconda delle fonti).
Insomma: se installate ad un cliente una normale distro Linux Ubuntu, e seguite la procedura standard, ottenete automaticamente un sistema sicuro (ragionevolmente sicuro, per essere esatti).
Se installate Windows (specialmente XP, 2000 ed NT) ottenete un sistema non sicuro o, per essere più gentili, non altrettanto sicuro di Ubuntu. In particolare, ottenete un sistema vulnerabile a molto malware. Come minimo, dovete installare un antivirus per ottenere un sistema equivalente a Linux. Inoltre, è necessario l'intervento di una persona competente per sistemare molti "default" e per trasformare questa installazione in un sistema sicuro come quello garantito di default da Ubuntu.

La cosa più inquietante è che per rendere Windows sicuro quanto Linux è necessario, come prima cosa, disinstallare molto software Microsoft che è notoriamente vulnerabile e sostituirlo con software tipico dell'ambiente Linux. Ad esempio, è necessario sostituire MS Office con OpenOffice o ThinkFree e MS Outlook con Thunderbird.
A questo punto, francamente, viene da chiedersi per quale motivo non si dovrebbe usare direttamente Linux.

Il Servizio Clienti Open Source
A questo punto è chiaro che il Servizio Clienti del mondo Open Source diventa molto meno indispensabile di quanto si potrebbe credere. I bug per i quali è realmente necessario l'intervento dei produttori sono piuttosto rari (uno all'anno, o anche meno, per ogni singolo programma) e vengono prontamente risolti, spesso grazie all'intervento tempestivo di un utente che dispone anche delle necessarie capacità tecniche.

Teoricamente, infatti, è possibile cercare e correggere gli errori all'interno dei sorgenti, senza aspettare l'intervento di altre persone. Si noti che questo è possibile solo con il Software Open Source. Se rilevate un problema con MS Internet Information Service, potete solo segnalarlo a Microsoft ed aspettare. Se rilevate un problema su Apache, e avete le capacità tecnica per farlo, potete cercare la fonte del problema nel codice e correggerlo. Tuttavia, non è quasi mai necessario sfruttare questa possibilità.

In quasi dieci anni di attività su Linux, infatti, non ci siamo mai trovati alle prese con un bug o con una vulnerabilità critica che non sia stato risolto nel giro di alcuni giorni al massimo. Quasi sempre, siamo venuti a conoscenza del problema solo perché ci è stata segnalata la necessità di installare la patch da parte degli stessi produttori.
Intendiamoci: problemi di sicurezza ne abbiamo avuti anche noi, su Linux e su BSD. Non viviamo in paradiso. Tuttavia, non abbiamo ancora sperimentato situazioni veramente critiche come quelle prodotte da Code Red, Nimda ed altri virus. Come noto, il flagello dei virus (e di quasi tutto il malware esistente), colpisce solo Windows e solo il software che gira su di esso. Non è una differenza da poco.

Anche la triste realtà delle backdoor, dei rootkit e delle botnet resta una caratteristica del mondo Windows e solo del mondo Windows. Né Linux, né BSD né Mac OS X sono mai stati coinvolti in questo gioco. Il solo fatto che immense botnet come Storm, Kraken e Srizbi possano esistere, e che coinvolgano solo macchine Windows, dovrebbe far riflettere.

Due pesi e due misure
L'analisi del codice Open Source che ipotizza Fortify è semplicemente priva di giustificazioni. Come abbiamo detto, solo una esigua percentuale degli errori di programmazione si traduce veramente in vulnerabilità. Rovistare in mezzo a centinaia di migliaia di righe di codice in cerca di queste vulnerabilità è un'impresa che costerebbe milioni di euro. Se le righe di codice sono milioni, è semplicemente impossibile fare un'analisi di questo tipo. In ogni caso, non ne varrebbe la pena: servirebbe solo a garantire una sicurezza che è possibile garantire con altri mezzi (firewall, sistemi di rilevamento delle intrusioni e antivirus).

Ma, soprattutto, perché mai una azienda dovrebbe sottoporre il codice Open Source che utilizza (Apache, Tomcat, Jboss o simili), e solo quello, ad una code review così estesa, approfondita, costosa e impegnativa? Il codice Closed Source è comunque molto meno sicuro e, soprattutto, non potrebbe mai essere sottoposto ad una analisi di questo tipo. Se si è disposti ad accettare i rischi di MS IIS, il cui codice non può essere ispezionato o riparato, perché mai ci si dovrebbe fare dei problemi per Apache o Jboss, dei quali si dispone invece dei sorgenti?

Una code review come quella ipotizzata da Fortify ha senso solo in alcune, rarissime applicazioni e, comunque, è possibile solo su software Open Source. Invocarla in questo contesto serve solo a rendere evidente quanto sia faziosa l'analisi di Fortify.

Conclusioni
Fortify può dire quello che vuole ma resta il fatto che avventure come quella di Nimda e di Code Red sono effettivamente costate molto alle aziende che usavano Windows. Non sono rischi teorici come quelli di cui si accusa il mondo Open Source. Lo sostiene addirittura il Gartner Group:
"Far sì che i Web server IIS (Internet Information Server) esposti ad Internet IIS siano sicuri, comporta per le aziende un costo di manutenzione molto alto", si legge in un'analisi pubblicata dal Gartner pochi giorni dopo la rapida diffusione di Nimda. "Le aziende che stanno usando il server Web Microsoft IIS devono aggiornare ogni server IIS con ogni patch di sicurezza rilasciata da Microsoft su base quasi settimanale. Tuttavia Nimda (ed in minor misura Code Red) ha nuovamente dimostrato l'alto rischio insito nell'utilizzo di IIS ed il grande sforzo necessario per stare al passo con le frequenti patch di sicurezza di Microsoft."
Nell'analisi del Gartner, firmata da John Pescatore, si arriva addirittura a consigliare alle aziende colpite da entrambi i worm, Code Red e Nimda, di "prendere immediatamente in considerazione alternative a IIS (...) come iPlanet e Apache. Sebbene questi server Web abbiano richiesto alcune patch di sicurezza, essi offrono maggiore affidamento di IIS e non sono sotto l'attacco attivo di un vasto numero di creatori di virus e worm". (Da Nimda non molla. IIS sotto processo)Se la storia deve insegnarci qualcosa, allora la storia ci insegna a fidarci del software Open Source ed a diffidare di quello Closed Source. Non è una questione di opinioni ma il semplice risultato della conta dei cadaveri sul campo di battaglia: per ogni Apache "schiantato" ci sono 100, o forse 1000, MS IIS.

Alessandro Bottoni
http://www.alessandrobottoni.it/
295 Commenti alla Notizia La sicurezza dell'Open Source
Ordina
  • 1° I software testati non sono l'editor-di-sto-pinko o il programma per sentire i cd audio ma roba che si presume debba essere utilizzata in ambienti professionali PER CUI ci si aspetta che sia sempre possibile contattare qualcuno per ricevere assistenza. Contattare non significa registrarsi con un nick da bimbominkia su un forum, ma avere dei numeri di telefono e qualcuno di competente che possa dare risposte. Se questi programmi "professionali" non offrono un servizio di questo tipo non possono fare altro che perdere punti anche se la concorrenza offre delle telefoniste incompetenti.

    2° Se gli utenti sono dementi e scambiano password come figurine/disattivano firewall per andare su siti porno/fanno giocare i figli col portatile aziendale e tutto questo comporta disastri come nimba la colpa è principalmente loro e non di questo o quel sistema operativo. Tra l'altro non si spiega perchè simili personaggi non potrebbero fare le stesse cagate con un sistema diverso da windows... per caso linux prima di switchare in un account di root fa uno scanning psicologico di chi sta davanti lo schermo e decide ?

    3° La vogliamo finire di dire che linux è sicuro solo perchè tiene due tipi di account separati ?
    Cosa conta dentro un pc ? La sopravvivenza del sistema o l'integrità dei dati importanti per l'utente ?
    Se quest'ultimo avvia programmi dannosi con l'user che registra questi dati, esiste, interviene qualche santo a risolvere il problema ?

    Bah... fanatismo, solo becero fanatismo e poi lagnatevi che linux resta ancorato al solito 0.x %
    -----------------------------------------------------------
    Modificato dall' autore il 31 luglio 2008 23.59
    -----------------------------------------------------------
  • Prima di parlare di fanatismo, fatti un bell'esame di coscienza e cerca di capire perché il mercato di massa ha comportato la più idiota percentuale di mercato che si sia mai registrata: 80% e + del mercato OS in mano alla Microsoft che di fatto, negli ultimi anni, si è arroccata dietro i suoi successi di vendita senza proporre una minima innovazione. E per fortuna le cose, anche se lentamente, stanno cambiando: +40% di vendite per i Mac, e un considerevole aumento del numero di macchine Linux nel settore professionale.
    E per concludere: c'è una netta differenza dall'essere frustrato dalla continua attenzione da riporre ai programmi di protezione che devono tenerti tranquillo, e incvece avere il default del tuo OS già sicuro (Os X, Linux). E di questo si stanno convincendo molte persone. L'utilizzo soprattutto a livello consumer ha bisogno di tranquillità non di paura di fronte al mezzo del PC che di personal (in casa Microsoft) ha sempre avuto poco. Microsoft sta subendo lo scotto di Vista, uno dei peggiori OS mai visti! Bill ha fatto bene ad andarsene in pensione...
    Ah un'altra cosa: mio figlio (7 anni) messo di fronte ad un Mac e un PC, trova molto + interessante il Mac e la prima volta ci ha messo 15 min per far crashare Win e con il Mac mi ha detto: Papà ma il "Leopardo" non si blocca mai?!
    non+autenticato
  • Non capisco di cosa tu parli, davvero.
    IIS, dalla versione 6.0, è diventato di una stabilità impressionante e sono anni che non ci sono bug aperti.
    Sappilo.
    non+autenticato
  • ho già segnalato qui un grande assente: il buco di debian per la generazione delle chiavi di crittografia, che erano parzialmente prevedibili

    mi è stato detto che la vulnerabilità è stata risolta in due ore, quando era attiva da due anni, e che non risulta che sia mai stata sfruttata

    vorrei chiedere come si può dire che una vulnerabilità di due anni non sia mai stata sfruttata, chi può dimostrarlo?

    ciononostante il fatto rimane, semplicemente quella caratteristica non è stata, come molte altre, testata a sufficienza, pur essendo per ora alla base della fiducia dei navigatori in internet

    ora vi chiedo di parlarmi di questo:

    http://www.doxaliber.it/ricercatori-delluniversita...

    sono certo che mi farete subito notare questo:

    http://www.doxaliber.it/torvalds-contro-la-spettac...

    bene, sono preoccupato dall'assenza di riflessioni dell'autore all'interno dell'articolo, e non sono e non sarò mai d'accordo con il secondo:

    perché la sicurezza non è tutto, ma è alla base di tutto

    come spesso capita, le frasi vengono lasciate a metà, si chiama "parzialità"

    facciamo un esempio: certo non vi bastano una buona porta e dei buoni muri per abitare in una casa, ma mi dite che cosa fareste (oggi e in questa società) se chiunque potesse entrare e uscire comodamente da casa vostra mentre siete fuori a far la spesa?

    e se questa voce si spargesse?
    non+autenticato
  • Quando Linus Torvalds ha scritto quel commento contro la spettacolarizzazione dei bug non credo affatto che si riferisse alla ricerca effettuata dall'Università dell'Arizona, non foss'altro perché in quel caso il problema riguarda i package manager, ovvero i software utilizzati per installare programmi sulle distribuzioni Gnu/Linux, non il kernel di Linux, che è l'unica parte del sistema operativo sviluppata da Torvalds e di cui Torvalds si interessa. I bug nei package manager non lo riguardano, sono un problema degli sviluppatori delle distribuzioni.

    Non capisco cosa intendi quando dici che non ci sono riflessioni all'interno dell'articolo, i bug sono sempre esistiti e sempre esisteranno, sono nati nello stesso momenti in cui è nata la programmazione. Non esiste software privo di bug, al massimo esiste software realizzato meglio e software realizzato peggio, software sviluppato con maggiore attenzione alla sicurezza e software sviluppato con i piedi, software in continuo sviluppo ed i cui bug vengono corretti velocemente e software che rimane bacato per sempre, perché non supportato e non sviluppato.

    Questo è quanto. La differenza è che se un software open source è sviluppato con i piedi lo si vede subito (perché il sorgente è a disposizione), se un software closed è sviluppato male gli unici che lo sapranno (semmai saranno in grado di capirlo!) saranno solamente gli sviluppatori del software stesso. Questo ovviamente non significa che il software open source sia automaticamente più sicuro, significa solo che c'è più trasparenza, perché guardando il codice spesso si capiscono molte cose. Certo, per un utente che non capisce niente di programmazione la differenza non è così chiara, posso capirlo.
    Nel pezzo Torvalds si scaglia contro la "spettacolarizzazione dei bug", ovvero contro coloro che creano intorno ai bug un circolo mediatico per ottenere pubblicità e fama, ma che in realtà non sono davvero interessati al miglioramento del software stesso ed ad una maggiore sicurezza. Di certo lo sviluppatore del kernel di Linux non afferma assolutamente che la sicurezza non è importante, semmai afferma che la sicurezza non è la sola cosa importante in un software. D'altro canto un software ultrasicuro ma inutilizzabile perché non ergonomico di certo è un software inutile perché gli utenti non lo useranno, quindi come dargli torto?

    Ciao,
    Doxaliber
    non+autenticato
  • Ma di closed esiste solo M$, leggendo l'articolo sembra quasi di si.

    Lo sapete che esistono altre ditte che sviluppano closed e non hanno a che fare direttamente o/e indirettamente con MS ?
  • - Scritto da: pippo75
    > Ma di closed esiste solo M$, leggendo l'articolo
    > sembra quasi di
    > si.
    >
    > Lo sapete che esistono altre ditte che sviluppano
    > closed e non hanno a che fare direttamente o/e
    > indirettamente con MS
    > ?

    E tu lo sai che esiste open source che non sia Linux o GPL? Eh?
    non+autenticato
  • - Scritto da: pippo75
    > Ma di closed esiste solo M$, leggendo l'articolo
    > sembra quasi di
    > si.
    >
    > Lo sapete che esistono altre ditte che sviluppano
    > closed e non hanno a che fare direttamente o/e
    > indirettamente con MS
    > ?

    rimeditando l'articolo... cito:
    Né Linux, né BSD, né Mac OS X sono intrinsecamente più sicuri di Windows

    MAC OS lo sviluppa Apple...
    o Apple ha smesso di sviluppare closed oppure l'articolo lo hai letto male
    non+autenticato
  • Non serve il numero di telefono? Il tecnico si limita a dirti che il problema è noto?
    Ok un altro che non ha mai visto come funzionano le cose dove girano i soldi veri.

    I clienti per cui ho lavorato io hanno speso milioni in licenze SAP, Oracle e Microsoft e quando si trovano dei bug si compila un bel form (quelli vecchi di oracle erano divertentissimi) in cui c'è sempre una domanda del tipo "quanto potrebbe costare il problema sul cliente?" ... beh quando mettevi il fatturato dell'azienda e il numero di licenze comprate venivi richiamato dopo 10 minuti da un manager e mediamente dopo 5 giorni arrivava la patch, fatta apposta per te.

    Visto capitare per Oracle e Microsoft ... con SAP,fino ad ora, non ho mai trovato niente di così grave da non poter essere risolto con un workaround (ovviamente suggerito e supportato dalla casa madre).

    Con il software opensource tipo Apache, Tomcat e cazzi vari posso anche segnalare il bug ma se nessuno di buon cuore si prende la briga di risolverlo allora mi tocca assumere un programmatore esperto e pagarlo a caro prezzo per sistemarlo. Non sono certo i milioni della licenza (almeno si spera) ma il tempo perso a cercare il programmatore può costare molto più caro.
    Oltretutto dopo aver pagato qualcuno per risolvere il problema devo fare in modo che la correzione diventi parte del ramo principale di sviluppo altrimenti mi scordo gli aggiornamenti. E anche qui mi rimetto al buon cuore del mantainer del programma che potrebbe benissimo decidere di non includere il fix. A quel punto tocca mantenere un fork... e allora ciao.
    non+autenticato
  • > I clienti per cui ho lavorato io hanno speso
    > milioni in licenze SAP, Oracle e Microsoft e
    > quando si trovano dei bug si compila un bel form

    EVVIVA !

    Almeno non sono l'unico programmatore che legge sto forum.
    CSOE
    728
  • tu saresti un programmatore ma allora le cantonate che spari sono frutto di cosa? , potrei sapere che linguaggi usi abitualmente?
    -----------------------------------------------------------
    Modificato dall' autore il 23 luglio 2008 23.23
    -----------------------------------------------------------
  • > tu saresti un programmatore ma allora le
    > cantonate che spari sono frutto di cosa? , potrei
    > sapere che linguaggi usi abitualmente?

    Senti cantonata, dimmene una tecnica che avrei sparato e ti dico tutto quello che vuoi.
    CSOE
    728
  • dai non essere così acido, ti ho semplicemnte chiesto che linguaggi usi abitualmente.
  • > dai non essere così acido, ti ho semplicemnte
    > chiesto che linguaggi usi
    > abitualmente.

    Ammazza, prima mi dai di quello che prende le cantonate e poi dell'acido ..

    I linguaggi sono i soliti, da java a .net passando dai DB. Odio php, adoro ma conosco poco python.
    -----------------------------------------------------------
    Modificato dall' autore il 24 luglio 2008 00.07
    -----------------------------------------------------------
    CSOE
    728
  • - Scritto da: CSOE
    > > dai non essere così acido, ti ho semplicemnte
    > > chiesto che linguaggi usi
    > > abitualmente.
    >
    > Ammazza, prima mi dai di quello che prende le
    > cantonate e poi dell'acido
    > ..
    >
    > I linguaggi sono i soliti, da java a .net
    > passando dai DB. Odio php, adoro ma conosco poco
    > python.
    > --------------------------------------------------
    > Modificato dall' autore il 24 luglio 2008 00.07
    > --------------------------------------------------

    modificato?
    di la verità... hai tolto VB (almeno il 90% del codice che sviluppi)...
    non+autenticato
  • > di la verità... hai tolto VB (almeno il 90% del
    > codice che
    > sviluppi)...

    Lo spero per lui... vuol dire che il 90% del codice che sviluppa ha un margine di profitto dell'80%.
    non+autenticato
  • > modificato?
    > di la verità... hai tolto VB (almeno il 90% del
    > codice che
    > sviluppi)...

    Se anche fosse non me ne vergognerei di certo ! Perfino di Access, pensi forse che tutti siano capaci di scriverci programmi ? Molti espertoni inneggianti a OO non sanno neppure fare una macro in VBA.


    Comunque ho aggiunto dopo i linguaggi, all'inizio non li avevo scritti.


    PS: C'è una legge fondante : In qualunque linguaggio è possibile scrivere cattivi programmi.
    CSOE
    728
  • - Scritto da: CSOE
    > > modificato?
    > > di la verità... hai tolto VB (almeno il 90% del
    > > codice che
    > > sviluppi)...
    >
    > Se anche fosse non me ne vergognerei di certo !

    questa è una implicita ammissione...
    e comunque se ci fai su dei soldi, allora buon per te

    > Perfino di Access, pensi forse che tutti siano
    > capaci di scriverci programmi ? Molti espertoni
    > inneggianti a OO non sanno neppure fare una macro
    > in
    > VBA.

    mi pare impossibile che stia succedendo...
    non concordo mai su nulla con te...
    ma su questo ti devo dare ragione!

    > Comunque ho aggiunto dopo i linguaggi, all'inizio
    > non li avevo scritti.
    >
    > PS: C'è una legge fondante : In qualunque
    > linguaggio è possibile scrivere cattivi
    > programmi.

    verissimo...
    però questa legge ha anche un corollario:
    con alcuni linguaggi (uno a caso: VB) è possibile scrivere SOLO cattivi programmi

    PS:
    col VB e con le macro-Access (come pure con quelle OOo) mi è toccato (raramente capita ancora) lavorare...
    so bene di cosa parlo e, in verità, in passato (remoto) ci ho anche guadagnato qualche panino...

    ma metto mano anche su C, bash, PHP, macro OOo, ecc... e, a conti fatti, non esito un attimo ad ammettere una semplice verità: VB ed Access sono una CAGATA PAZZESCA!!

    ora, capisco che ci guadagni sopra... ma dai...
    che sono emerite cagate dovresti ammetterlo anche tu, per onestà intellettuale...
    non+autenticato
  • > ammettere una semplice verità: VB ed Access sono
    > una CAGATA PAZZESCA!!

    VB è tecnicamente insalvabile, è un linguaggio ridicolo non c'è niente da dire. Ciò non toglie che sia semplice ed efficace e che siano degni di rispetto i programmatori che lo usano. Devo ammettere di conoscerlo davvero poco, mi sono sempre rifutato di impararlo.

    Access è un grande prodotto, potentissimo, non ho mai visto niente che permetta ad un non informatico di gestire efficacemente una base dati.

    Non mi fraintendere, non userei mai access per un mio progetto, ma lo consiglierei all'amico smenettone fissato con i fumetti.

    Non conosco altro prodotto al mondo in cui un incompetente assoluto possa scriversi una applicazione gestionale che funziona ed un professionista possa aggiungerci codice per sfruttare i web service di Amazon.
    CSOE
    728
CONTINUA A LEGGERE I COMMENTI
1 | 2 | 3 | 4 | 5 | 6 | 7 | Successiva
(pagina 1/7 - 34 discussioni)