Alan Cox: 'opensourcesoftware lang niet altijd veilig'
Alan Cox, Linux-kerneldeveloper en in dienst bij Red Hat, heeft tijdens de LinuxWorld Conference in Londen gesproken over de veiligheid van opensourcesoftware. Volgens Cox wordt er veel geld gespendeerd aan het veiliger maken van dergelijke applicaties, maar worden er ook grote sommen geld betaald om juist veiligheidsgaten te vinden in dat soort software. 'Via de media wordt het beeld geschapen dat opensourcesoftware veiliger, betrouwbaarder en buglozer zou zijn. Dat zijn echter gevaarlijke opmerkingen', aldus Cox. Wanneer dit soort uitspraken gedaan worden, zijn ze vrijwel altijd gebaseerd op code-analyse van enkele high-profile en bekende opensourceprojecten. Als echter de broncode van 150 willekeurig geselecteerde SourceForge-applicaties nauwkeurig bekeken zou worden, dan zou het beeld anders zijn, zo verwacht de kernelontwikkelaar: 'high quality only applies to some projects — those with good code review and those with good authors'.
Reacties (47)
Daar kan deze man wel heel erg gelijk in hebben. Bij veilige open source software denkt mijn bijvoorbeeld direct aan Apache en MySQL en die zijn ook wel veilig maar hoeveel Distro makers stoppen er wel niet allemaal beta of zelfs alpha dingetjes in hun distro's? Daarbij komt ook direct het gevaar van de zogenaamde 3rd party repository's om de hoek kijken. Veel mensen voegen die toe aan hun Linux installatie om wat leuke extratjes binnen te lepelen maar staan totaal niet stil bij de veiligheid of onveiligheid hier van. Op zich wel iets om eens over na te denken.
heb je de stable van debian wellis gezien? Ik denk niet dat daar alpha en beta's tussen zitten;)
ja dat je voor je huis tuin en keuken pc nou kUbuntu ofso neemt met alle unstable van dien moet je zelf weten
ja dat je voor je huis tuin en keuken pc nou kUbuntu ofso neemt met alle unstable van dien moet je zelf weten
Door Debian stable aan te halen, haal je (naar mijn mening) wel 1 van de veiligste en stabielste distro's die er is aan. Dat heeft echter wel als gevolg dat je over het algemeen achter loopt met software pakketten.
Debian Unstable heeft al een hoop meer software pakketten. Bij debian kan je zelfs instellen of je BETA's e.d. wil ontvangen.
Zoals eerder vermeld, de 3rd party repository's zijn de meest riskante. Zolang je maar met een beetje verstand je bak inricht is er niets aan de hand. En zowiezo, bijv. iptables is zomaar ingesteld!
Extra'tjes binnenslepen is werk dat je doet op een workstation, bij workstations wil je wel dat de pakketten behoorlijk up-to-date zijn (Debian Unstable/Ubuntu). Bij servers wil je liever veilig, zeker als deze in een datacenter hangen (Debian Stable met de Volatile source).
Debian Unstable heeft al een hoop meer software pakketten. Bij debian kan je zelfs instellen of je BETA's e.d. wil ontvangen.
Zoals eerder vermeld, de 3rd party repository's zijn de meest riskante. Zolang je maar met een beetje verstand je bak inricht is er niets aan de hand. En zowiezo, bijv. iptables is zomaar ingesteld!
Extra'tjes binnenslepen is werk dat je doet op een workstation, bij workstations wil je wel dat de pakketten behoorlijk up-to-date zijn (Debian Unstable/Ubuntu). Bij servers wil je liever veilig, zeker als deze in een datacenter hangen (Debian Stable met de Volatile source).
Tja Debian is zo eentje van de weinige dat enkel software erin zet dat al in zijn uiteindelijke release is én al genoeg heeft doorstaan. Dan heb je echter te maken met een iets wat ouder besturingssysteem en is de gebruiksvriendelijkheid soms wel ver te zoeken, als je vergelijkt naar de alternatieve zoals Suse.
Die hebben bij de release van hun nieuwe enterprise release al de beta van Xen erin gezet. Hier hebben ze wel een stapje voor dan de rest als de gebruiker niet echt in zit met de fouten die erin zitten.
Die hebben bij de release van hun nieuwe enterprise release al de beta van Xen erin gezet. Hier hebben ze wel een stapje voor dan de rest als de gebruiker niet echt in zit met de fouten die erin zitten.
Een Enterprise gebruiker zal doorgaans die fouten juist niet op de koop toe willen nemen!
Als desktopgebruiker draai ik zelf Gentoo met meer dan genoeg testing packages als dat me uitkomt en ik een leuke feature wil die nog niet stable is - maar dat boeit niet voor desktopwerk.
Als ik een systeem moet neerzetten dat gewoon *moet* werken kies ik voor Debian stable. Dat het sommige mooie nieuwe geile features mist is irrelevant, toeters en bellen zijn van ondergeschikt belang op productieservers. Daar telt puur of het te vertrouwen is.
Als desktopgebruiker draai ik zelf Gentoo met meer dan genoeg testing packages als dat me uitkomt en ik een leuke feature wil die nog niet stable is - maar dat boeit niet voor desktopwerk.
Als ik een systeem moet neerzetten dat gewoon *moet* werken kies ik voor Debian stable. Dat het sommige mooie nieuwe geile features mist is irrelevant, toeters en bellen zijn van ondergeschikt belang op productieservers. Daar telt puur of het te vertrouwen is.
@DLGandalf:
Een uitzondering op de regel veranderd de regel niet. Heb je wel eens een McLaren F1 gezien? Daar kun je dik mee racen maar in de regel kan dat niet met de gemiddelde auto en die McLaren F1 veranderd daar niets aan.
Het aantal Debian gebruikers is echt aanzienlijk kleiner dan bijvoorbeeld het aantal Ubuntu, Open Suse of Fedora gebruikers en ik denk dat dit wel juist de 3 distro's zijn waar veel experimentele software in zit.
Een uitzondering op de regel veranderd de regel niet. Heb je wel eens een McLaren F1 gezien? Daar kun je dik mee racen maar in de regel kan dat niet met de gemiddelde auto en die McLaren F1 veranderd daar niets aan.
Het aantal Debian gebruikers is echt aanzienlijk kleiner dan bijvoorbeeld het aantal Ubuntu, Open Suse of Fedora gebruikers en ik denk dat dit wel juist de 3 distro's zijn waar veel experimentele software in zit.
Dit is mijns inziens niets nieuws......... open of closed maakt niet per definitie iets uit kwa veiligheid........
slechte OSS is nooit beter dan goede closed software, en visa versa
wat betreft alpha of beta software: ik zie het verschil niet tussen een goede alpha, en een slechte final.........
slechte OSS is nooit beter dan goede closed software, en visa versa
wat betreft alpha of beta software: ik zie het verschil niet tussen een goede alpha, en een slechte final.........
Het verschil is natuurlijk wel dat de gebruiker (met enige kennis) dat zelf beter zou kunnen controleren en kan verhelpen.
In principe heb je wel gelijk, maar toch is dat voor een groot gedeelte theoretisch. Ik weet niet of je je ooit ingewerkt hebt in grotere projecten, en ik kan je verklappen dat je dat gewoon heel erg veel tijd kost. Een simpele bug als een buffer overflow is allemaal nog wel te doen, maar een fout die je niet kan oplossen door een paar regels aan te passen is echt niet zo simpel.
Dit argument wordt overigens wel vaker gebruikt, maar ik vraag me af hoeveel mensen echt in de broncode gaan zitten spitten, ik denk dat het er beroerd weinig zullen zijn.
Dit argument wordt overigens wel vaker gebruikt, maar ik vraag me af hoeveel mensen echt in de broncode gaan zitten spitten, ik denk dat het er beroerd weinig zullen zijn.
Ik moet toegeven dat je gelijk hebt. Maar ook wel stellen, dat ik en waarschijnlijk vele anderen, de neiging heb om even de code te checken.
Niet voor te reviewen, gewoon even zien:
- is er overzichtelijk gewerkt
- voldoende commentaar
- zijn stukjes van de code "slordig"
Dat zijn eigenlijk dingen die je in één oogopslag kunt zien, dus veel tijd verlies je er uiteindelijk niet aan. En je hebt (al is het vluchtig) gelijk een idee van het onderhoud van de code en de skills/ervaring van de coders.
Wat niet wil zeggen dat "op zicht" slordige code niet perfect (of zelfs geniaal) kan werken, maar wel dat elk volwassen project groeit naar deftige documentatie, overzicht en plugability.
Niet voor te reviewen, gewoon even zien:
- is er overzichtelijk gewerkt
- voldoende commentaar
- zijn stukjes van de code "slordig"
Dat zijn eigenlijk dingen die je in één oogopslag kunt zien, dus veel tijd verlies je er uiteindelijk niet aan. En je hebt (al is het vluchtig) gelijk een idee van het onderhoud van de code en de skills/ervaring van de coders.
Wat niet wil zeggen dat "op zicht" slordige code niet perfect (of zelfs geniaal) kan werken, maar wel dat elk volwassen project groeit naar deftige documentatie, overzicht en plugability.
Simpel gesteld (er zijn natuurlijk enkele nuances mogelijk) for the sake of the argument: uiteindelijk klooit iedere autorijder in Nederland ook niet zelf onder de moterkap, maar je kan echter wel bij vrienden, kennissen en verschillende(!) bedrijven terecht om dat te laten doen.
Uiteindelijk gaat het niet om het feit dat iedereen zijn problemen zelf zou kunnen oplossen, simpelweg omdat dit inderdaad niet gebeurt.. maar het gaat er om dat iedereen die dat wil en kan zijn steentje kan bijdragen. Dat gebeurt ook bij grote populaire OSS projecten. Zie de vele namen in de changelogs bij de diverse grote projecten.
Als je software hebt waar je dat totaal niet bij zou kunnen (closed source) dan houdt het zowieso automatisch op. Fouten kan je dan alleen vinden tijdens gebruik (of de machinecode door een debugger halen) en eventueel melden, meer ook niet.
Het is zo dat het veel tijd kan kosten om je in te werken in een groot project, maar soms kan je al fouten oplossen als je maar bekend bent met een bepaald deel. Zo ben ik relatief bekend met het VFS deel van Linux. Ik zou fouten kunnen oplossen in die geest. Over de netwerkstack hoef je me niks te vragen. Daar weet ik niks van. Over de USB stack echter over een tijd weer wel.
Uiteindelijk gaat het niet om het feit dat iedereen zijn problemen zelf zou kunnen oplossen, simpelweg omdat dit inderdaad niet gebeurt.. maar het gaat er om dat iedereen die dat wil en kan zijn steentje kan bijdragen. Dat gebeurt ook bij grote populaire OSS projecten. Zie de vele namen in de changelogs bij de diverse grote projecten.
Als je software hebt waar je dat totaal niet bij zou kunnen (closed source) dan houdt het zowieso automatisch op. Fouten kan je dan alleen vinden tijdens gebruik (of de machinecode door een debugger halen) en eventueel melden, meer ook niet.
Het is zo dat het veel tijd kan kosten om je in te werken in een groot project, maar soms kan je al fouten oplossen als je maar bekend bent met een bepaald deel. Zo ben ik relatief bekend met het VFS deel van Linux. Ik zou fouten kunnen oplossen in die geest. Over de netwerkstack hoef je me niks te vragen. Daar weet ik niks van. Over de USB stack echter over een tijd weer wel.
Om het argument af te maken.
Ik ga liever met m'n auto naar een gecertificeerde garage om het daar te laten fixen dan dat er een of andere klojo uit m'n vriendenkring aan gaat zitten vogelen.
Zelfde geldt voor de code. Het is meestal complexe code die ver door ontwikkeld is. Een of ander lapmiddeltje inbouwen houdt meestal in dat er iets anders wordt open gegooid.
-R-
Ik ga liever met m'n auto naar een gecertificeerde garage om het daar te laten fixen dan dat er een of andere klojo uit m'n vriendenkring aan gaat zitten vogelen.
Zelfde geldt voor de code. Het is meestal complexe code die ver door ontwikkeld is. Een of ander lapmiddeltje inbouwen houdt meestal in dat er iets anders wordt open gegooid.
-R-
Rune,
Ik laat ook geen klojo's in mijn vriendenkring aan mijn auto prutsen, maar ik heb ook mensen in diezelfde kring die daar dus wel capabel voor zijn. Dat ze geen gecertificeerde garage hebben staat daar los van. De essentie van het argument is juist dat ik die keuze uberhaupt zelf kan maken. Of jij dat wil is een ander verhaal.
Zo zijn ook genoeg kernel developers te vinden die capabel genoeg worden geacht door Torvalds zodat hun patches worden verwerkt. Torvalds kijkt in principe niet naar certificaat of je opleidingsniveau, maar puur naar het werk dat ze naar hem insturen.
Ik laat ook geen klojo's in mijn vriendenkring aan mijn auto prutsen, maar ik heb ook mensen in diezelfde kring die daar dus wel capabel voor zijn. Dat ze geen gecertificeerde garage hebben staat daar los van. De essentie van het argument is juist dat ik die keuze uberhaupt zelf kan maken. Of jij dat wil is een ander verhaal.
Zo zijn ook genoeg kernel developers te vinden die capabel genoeg worden geacht door Torvalds zodat hun patches worden verwerkt. Torvalds kijkt in principe niet naar certificaat of je opleidingsniveau, maar puur naar het werk dat ze naar hem insturen.
Snap je punt, maar gaat met auto's maar zeer ten dele op tegenwoordig, met alle software die erin zit. De merktdealer heeft als enige altijd de juiste apparatuur hiervoor.
Misschien een idee: Open Source motor management systemen..?
Misschien een idee: Open Source motor management systemen..?
Dus als ik bv een open source browser gebruik hoef ik helemaal niet te wachten totdat er een waarschuwing komt voor een vulnerability, laat staan dat ik hoef te wachten op een patch? Met 'enige kennis' controleer en repareer ik dat zelf wel even?
"Het verschil is natuurlijk wel dat de gebruiker (met enige kennis) dat zelf beter zou kunnen controleren en kan verhelpen."
In principe. Praktijk leert dat diverse OS projecten mensen te kort komt om mee te werken, laat staan om te kijken. Dus helaas pindakaas.
In principe. Praktijk leert dat diverse OS projecten mensen te kort komt om mee te werken, laat staan om te kijken. Dus helaas pindakaas.
De dingen die je meteen opvallen kan je zelf met de nodige kennis idd verhelpen. Er zijn echter meer dingen op je systeem aanwezig dan waar jij weet van hebt, en voor de gemiddelde gebruiker en zelfs de gemiddelde programmeur is het vinden en oplossen van bugs in een basis systeemlib als glibc net zo moeilijk als het doorzien van wat Internet Explorer allemaal achter de schermen op jouw systeem doet.
Ik ben het met de andere mensen die reageren dat dit in de praktijk niet zo gemakkelijk is wel eens, maar dat wil niet zeggen dat bijvoorbeeld een organisatie (groot bedrijf, overheid) niet zelf een aantal specialisten zou kunnen inhuren om de problemen wel te verhelpen. Ze zijn daarvoor niet afhankelijk van de originele makers.
Dus: voor "gewone" gebruikers is het lastig (maar niet onmogelijk, ik heb het zelf meer dan eens gedaan), maar voor grote gebruikers is het gewoon haalbaar als ze dat willen.
Dus: voor "gewone" gebruikers is het lastig (maar niet onmogelijk, ik heb het zelf meer dan eens gedaan), maar voor grote gebruikers is het gewoon haalbaar als ze dat willen.
Helemaal waar natuurlijk, maar ook wel een open deur. Wat er wel bij vermeld moet worden is dat je bij Open Source de mogelijkheid hebt de code in te zien en te beoordelen. En dan zie je snel genoeg of je kwaliteit hebt of niet. Wat je bij Closed Source eigenlijk alleen maar kunt afleiden van de UI.
Dat is maar relatief, zou jij aan de source code van Linux kunnen zien of het veilig is? Je kan nooit volledig een gehele OSS applicatie kunnen begrijpen tenzij je al erg lang actief bezig bent. Iedereen kan de source code zien, maar niet iedereen is een Linus Torvalds.
Nee, maar als een heleboel mensen allemaal een stukje doen, dan ben je al een heel eind...
In dat geval vertrouw je alsnog op derden. Waardoor je vanuit veiligheidsoogpunt in min of meer dezelfde positie zit als wanneer je niets gecontroleerd zou hebben.
Je kunt inderdaad niet met een vlugge blik kijken of de applicatie compleet waterdicht is. Dat kan bij closed source ook niet.
Wat wel zo is, is dat je even een blik onder de moterkap kunt kijken. Als je een 2e hands auto koopt kijk je daar ook even. Misschien ben je wel geen monteur en met die snelle blik kun je echt niet alles zien, maar je kunt wel een blik werpen om te zien of alles een beetje netjes is. Als de motorkap niet open mag weet je niet of het soepel zonder bijgeluidsjes lopen nu komt omdat het goed in elkaar zit, of omdat de verkoper het hele motorcompartiment heeft geisoleerd met glaswol en met plakband de hele uitlaat weer luchtsdicht geplakt heeft.
Volg voor de gein eens http://www.thedailywtf.com. Hierin komen vaak dingen voorbij die gewoon in commersiele software voorkomen. Bij open source pik je dit soort wanproducten er een stuk makkelijker uit.
Wat wel zo is, is dat je even een blik onder de moterkap kunt kijken. Als je een 2e hands auto koopt kijk je daar ook even. Misschien ben je wel geen monteur en met die snelle blik kun je echt niet alles zien, maar je kunt wel een blik werpen om te zien of alles een beetje netjes is. Als de motorkap niet open mag weet je niet of het soepel zonder bijgeluidsjes lopen nu komt omdat het goed in elkaar zit, of omdat de verkoper het hele motorcompartiment heeft geisoleerd met glaswol en met plakband de hele uitlaat weer luchtsdicht geplakt heeft.
Volg voor de gein eens http://www.thedailywtf.com. Hierin komen vaak dingen voorbij die gewoon in commersiele software voorkomen. Bij open source pik je dit soort wanproducten er een stuk makkelijker uit.
Ah, het bekende 'de verpakking is belangrijker dan de inhoud'. Hoewel ik snap dat je voor CS alleen nog maar de UI (en de handleiding) hebt om de software te kunnen beoordelen, is dit zeker geen maatstaf! Ik kan baggersoftware schrijven met een schitterende UI (dat gebeurt trouwens regelmatig).Wat je bij Closed Source eigenlijk alleen maar kunt afleiden van de UI.
Daarom is Alan Cox' uitspraak zo nietszeggendEr is geen vergelijk tussen CS en OS software te maken (zeker niet op gebied van veiligheid). Het enige verschil is de openheid; de waarde daarvan hangt af van de gebruikers.
edit:
Artikel in eerste instantie verkeerd geïnterpreteerd; Alan Cox waarschuwt alleen maar voor een scheef beeld ("OS is per definitie veiliger"), Toch vind ik de uitspraak "Software lang niet altijd veilig" beter...
Artikel in eerste instantie verkeerd geïnterpreteerd; Alan Cox waarschuwt alleen maar voor een scheef beeld ("OS is per definitie veiliger"), Toch vind ik de uitspraak "Software lang niet altijd veilig" beter...
Dan zal ik jou maar niet inhuren om software te schrijven!Ik kan baggersoftware schrijven met een schitterende UI (dat gebeurt trouwens regelmatig).
@Cameleon73:
Alleen al door die openheid, zal de prorgrammeur er niet bewust een stukje malware/spyware in kunnen stoppen.
(Mede daarom zie je ook haast geen malware op linux-systemen, nog afgezien van 't feit dat je daar niet als root ingelogd hoeft te zijn om fatsoenlijk te kunnen werken en afgezien van de betere modulaire opbouw.) En als je weet dat er mensen mee kunnen kijken in je code, ben je wel geneigd netter en veiliger te programmeren.
En bij OS zal de programmeur meer inhoudelijke respons kunnen krijgen (bijv. over bugs), omdat er toch altijd wel een paar mensen zijn die wél in de code kijken.
Maar dat is nu juist net een heel groot verschil!Het enige verschil is de openheid; de waarde daarvan hangt af van de gebruikers.
Alleen al door die openheid, zal de prorgrammeur er niet bewust een stukje malware/spyware in kunnen stoppen.
(Mede daarom zie je ook haast geen malware op linux-systemen, nog afgezien van 't feit dat je daar niet als root ingelogd hoeft te zijn om fatsoenlijk te kunnen werken en afgezien van de betere modulaire opbouw.) En als je weet dat er mensen mee kunnen kijken in je code, ben je wel geneigd netter en veiliger te programmeren.
En bij OS zal de programmeur meer inhoudelijke respons kunnen krijgen (bijv. over bugs), omdat er toch altijd wel een paar mensen zijn die wél in de code kijken.
Alleen al door die openheid, zal de prorgrammeur er niet bewust een stukje malware/spyware in kunnen stoppen.
IIRC doet/deed men dat bij Limewire (een opensource P2P-client) wel, er zijn dan ook wel genoeg forks te vinden waar die spyware er uit is gehaald.
IIRC doet/deed men dat bij Limewire (een opensource P2P-client) wel, er zijn dan ook wel genoeg forks te vinden waar die spyware er uit is gehaald.
Inderdaad niets nieuws. Als actieve kernen binnen OSS communities niet groter zijn dan een gemiddeld softwarebedrijf (zoals de meeste projecten op sourceforge) is er geen rede om aan te nemen dat het veiliger is.
Sterker nog: Ik zou durven beweren dat het dan minder veilig is, aangezien softwarebedrijven over het algemeen bewezen testmethodes en tools gebruiken, terwijl OSS communities zich over het algemeen beperken tot het toepassen van gebruikersscenario's. Hierdoor zijn kleinschalige OSS projecten niet veel meer dan hobbyprojecten.
Sterker nog: Ik zou durven beweren dat het dan minder veilig is, aangezien softwarebedrijven over het algemeen bewezen testmethodes en tools gebruiken, terwijl OSS communities zich over het algemeen beperken tot het toepassen van gebruikersscenario's. Hierdoor zijn kleinschalige OSS projecten niet veel meer dan hobbyprojecten.
Bij veel softwarebedrijven wordt ook maar wat aangeprutst, en standaard testmethodes zeggen weinig over de veiligheid van software, wat ook weer een heel breed begrip is. Als het ontwerp van je software niet gemaakt is met veiligheid in het achterhoofd dan kan je het nooit meer echt veilig maken zonder alles helemaal om te gooien.
Over het algemeen zijn mensen die aan OSS projecten werken in het dagelijks leven gewoon programmeurs of iig bekend met programmeren. Of dat er binnen bedrijven ook wordt meegewerkt aan OSS omdat die software er al was maar nog samengevoegd moet worden.
En voor beide soorten ontwikkelingen zijn pro's en con's maar ik denk niet dat per saldo een van de twee beter is maar dat per project verschilt.
En dat is denk ik ook precies waar Alan Cox op doelt.
En voor beide soorten ontwikkelingen zijn pro's en con's maar ik denk niet dat per saldo een van de twee beter is maar dat per project verschilt.
En dat is denk ik ook precies waar Alan Cox op doelt.
Dat niet alle OSS even veilig is helemaal niet van belang. Als een slecht geschreven applicatie niet met rootrechten in aanraking komt en geen externe input krijgt kan er nog niks gebeuren. Kortom, de applicaties waarbij het wel van belang is dat de software veilig is zijn servers, browsers en editors. Servers zijn over het algemeen goed uitgeplozen, en redelijk makkelijk dicht te spijkeren. Browsers worden ook met de regelmaat van de klok foutjes in gevonden, maar zolang je browser niet in de kernel draait is dat vaak geen ramp, is er al concreet misbruik gemaakt van firefox bugs? Ik denk het niet. En editors, als je ze als root draait. En dat moet je niet doen, daarvoor moet je sudoedit gebruiken. Hoewel ik daarvoor ook nog nooit van een serieus probleem heb gehoord.
Kortom zolang je je gezond verstand gebruikt is er niet veel aan de hand met OSS, zelfs als met matige software werkt. Naja, bij PHP valt nog het een en ander te verbeteren. Maar ook daarvoor zijn er al zat alternatieven. Ruby on rails, Django etc.
Kortom zolang je je gezond verstand gebruikt is er niet veel aan de hand met OSS, zelfs als met matige software werkt. Naja, bij PHP valt nog het een en ander te verbeteren. Maar ook daarvoor zijn er al zat alternatieven. Ruby on rails, Django etc.
Da's allemaal wel heel leuk, maar ondertussen kan het nog wel bij al je eigen bestanden. En als die verwijderd/gewijzigd worden zou ik dat niet "niks" willen noemen.Als een slecht geschreven applicatie niet met rootrechten in aanraking komt en geen externe input krijgt kan er nog niks gebeuren.
Nee, doe mij maar een gebotnette computer.. da's een stuk makkelijker te verhelpen dan dat je je vakantie plaatjes kwijtraakt voordat je ze op een backup hebt kunnen zetten.
Daarom heb ik ook firefox onder zijn eigen account draaien 
http://www.xs4all.nl/~han...refox_for_paranoid_people
http://www.xs4all.nl/~han...refox_for_paranoid_people
Sandboxen van programma's die verbinding hebben met het "gevaarlijke" internet wordt de volgende hit in beveiligingsstappen, zeker met de virtualizatie technieken die op de nieuwe generatie processoren zitten.
Had de man thuis geen open deuren meer?
marketingtechnisch moet dat verhaal natuurlijk wel zo worden gehouden 
het is ook niet raar om een verband te zien tussen een ontwikkelmethode ala open-source en veiligheid van het resultaat, maar je mag het niet gelijk voor alle open-source projecten doortrekken. Als je open-source als wijze van distributie, wat in feite de meeste projecten doen, ziet is veiligheid natuurlijk geen verband.
het is ook niet raar om een verband te zien tussen een ontwikkelmethode ala open-source en veiligheid van het resultaat, maar je mag het niet gelijk voor alle open-source projecten doortrekken. Als je open-source als wijze van distributie, wat in feite de meeste projecten doen, ziet is veiligheid natuurlijk geen verband.
Tsja, vind ik ook niet echt een direct verband.het is ook niet raar om een verband te zien tussen een ontwikkelmethode ala open-source en veiligheid van het resultaat
Waar het eigenlijk op neerkomt, is hoeveel developers er naar de code kijken, hoeveel tijd ze daaraan besteden, en hoeveel kennis en ervaring ze hebben. Manuren en kennisniveau dus. Opensource heeft daarop alleen invloed in die zin dat ook mensen 'van buitenaf' er naar kunnen kijken. Wat natuurlijk geen garantie is dat dat ook gebeurt, laat staan dat die mensen door het kijken naar de sourcecode ook een nuttige bijdrage leveren aan de kwaliteit van de code.
Ook bij belangrijke closed-source projecten worden er code-reviews gedaan... Bij open-source is het vaak lastig om na te gaan wie er allemaal naar de code kijkt, en wanneer. Bij een closed-source project gaat dit natuurlijk heel gestructureerd, er worden gewoon mensen betaald om zich full-time met het project bezig houden.
Maar ik kan me best voorstellen dat het voorkomt dat er closed-source projecten zijn waar meer code reviews worden toegepast dan opensource-projecten. Waar dus uit volgt dat die code dan veiliger moet zijn.
"Als echter de broncode van 150 willekeurig geselecteerde SourceForge-applicaties nauwkeurig bekeken zou worden, dan zou het beeld anders zijn, zo verwacht de kernelontwikkelaar"
Ik verwacht dat als de broncode van closed-source bekeken zou worden dat dit ook niet altijd tengoede van beeld van closed-source zou werken.
Misschien een idee: Jullie kijken onze open-source code na, wij kijken jullie closed-source na
(hé, het is misschien dan niet altijd het allerveiligst. Maar het is in iedergeval wel GRATIS)
Ik verwacht dat als de broncode van closed-source bekeken zou worden dat dit ook niet altijd tengoede van beeld van closed-source zou werken.
Misschien een idee: Jullie kijken onze open-source code na, wij kijken jullie closed-source na
(hé, het is misschien dan niet altijd het allerveiligst. Maar het is in iedergeval wel GRATIS)
Dat is ook helemaal niet het punt dat hij wil maken.Ik verwacht dat als de broncode van closed-source bekeken zou worden dat dit ook niet altijd tengoede van beeld van closed-source zou werken.
Hij zegt alleen dat opensource nogal eens als veilig wordt aangeprezen, en dat geeft een vals gevoel van veiligheid.
Het kan veiliger zijn, maar het is niet per definitie zo. Je moet er gewoon nooit vanuit gaan dat je software veilig is, en altijd blijven streven naar het verbeteren ervan.
In feite betekent opensource op zich niets. Als ik mijn closed-source projecten ineens onder GPL publiceer op sourceforge oid, dan is de code natuurlijk niet ineens veiliger.
Dat wordt het pas als andere mensen ernaar kijken, en problemen eruit halen. Nogal een grote 'als' dus. Zoals hij aangeeft, zullen er vast genoeg sourceforge-projecten zijn waar bijna niemand naar kijkt, en waar dus een hoop fouten gewoon in blijven zitten.
Daar wil hij dus voor waarschuwen.
open source is niet per definitie gratis (zie Red Hat). En Closed Source kan wel gratis zijn (Freeware)Het verschil zit hem in de beschikbaarheid van de source, nergens anders....
PhoenixT: 'closedsourcesoftware lang niet altijd veilig'
Damn, wat een nieuwswaarde
Damn, wat een nieuwswaarde
Deze uitspraken zijn voor een deel wel marketing : Red Hat heeft er zeker baat bij dat een met supportcontracten ondersteunde distributie (waarin ook nog eens door Red Hat zelf gereviewde packages zitten) op meer belangstelling mag rekenen.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
