Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 74 reacties

De ontwikkelaars van de GnuTLS-bibliotheek, een opensource-implementatie van de ssl-, tls- en dtls-protocollen, waarschuwen voor een beveiligingsprobleem in de clientversie. GnuTLS wordt onder andere gebruikt in Linux-distributies als Red Hat en Ubuntu.

De kwetsbaarheid maakt het mogelijk om op afstand code op een Linux-computer te starten zonder dat de gebruiker dit door heeft. Daarvoor moet een kwaadwillende via een server een gemanipuleerd ServerHello-bericht versturen. Door een fout in de parsing van dit ServerHello-bericht ontstaat er na een buffer overflow toegang tot het werkgeheugen van de client. Hierdoor kan de aanvaller bijvoorbeeld een Linux-pc laten crashen of er malware op plaatsen.

Red Hat heeft de bug de kwalificatie 'ernstig' gegeven. Inmiddels zijn er updates voor diverse versies van GnuTLS uitgebracht. Deze dragen de versienummers 3.1.25, 3.2.15 en 3.3.3. Vrijwel alle bekende Linux-distributies hebben inmiddels de updates opgenomen in hun repositories.

De bug in GnuTLS is ontdekt en gepubliceerd door Joonas Kuorilehto van de firma Codenomicon. Dit beveiligingsbedrijf ontdekte eerder de Heartbleed-bug in OpenSSL, een bug die een grote impact heeft gehad.

Moderatie-faq Wijzig weergave

Reacties (74)

Je kunt eigenlijk geen enkele software vertrouwen. Zelfs open-source niet (ook al kun je daar de broncode doorzoeken naar backdoors) namelijk: zolang je niet zelf je compiler hebt geschreven. Want hoe weet jij of je compiler niet stiekem backdoors implementeert in je - anders dan - wel veilige code!
Ken Thompson, co-author of UNIX, recounted a story of how he created a version of the C compiler that, when presented with the source code for the "login" program, would automatically compile in a backdoor to allow him entry to the system. This is only half the story, though. In order to hide this trojan horse, Ken also added to this version of "cc" the ability to recognize if it was recompiling itself to make sure that the newly compiled C compiler contained both the "login" backdoor, and the code to insert both trojans into a newly compiled C compiler. In this way, the source code for the C compiler would never show that these trojans existed.
http://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html

[Reactie gewijzigd door ZeroSect0r op 2 juni 2014 12:52]

Dank voor je link naar dat artikel! :Y)
Ik denk dat dit wel te omzeilen is als je verschillende compilers gebruikt:
Compileer LLVM met een oude versie van GCC van voordat LLVM bestond, dan zouden ze al een forward compatibele backdoor voor andere compilers moeten geschreven hebben...
Uit dat idee is ongeveer het TCC-project geboren. Het idee is dat je met die compiler een andere compiler maakt die eventueel zichzelf weer compiled.
Waarom houd je op bij de compiler? Misschien zit de backdoor wel ergens op hardwareniveau? Pas als je elke chip zelf hebt gebakken heb je absolute zekerheid.
Toch wel bizar dat zowel deze bug als Heartbleed enkel Linux treffen... en niet Windows.
De bugs kunnen worden ontdekt omdat de broncode vrij is om te gebruiken en ook om te lezen. Het fixen van zo'n bug is daarom ook makkelijker. Een bug vinden in Windows is moeilijker en het fixen moet gedaan worden door Microsoft. We hebben geen idee hoeveel bugs er in zitten en of ze er opzettelijk in zijn gemaakt. Linux lijkt soms lek als een mandje maar van Windows weten we het eigenlijk niet zo goed en dat is in mijn ogen gevaarlijker.
Omdat windows weer hun eigen bugs hebben, voorbeeldje: https://technet.microsoft.com/library/security/ms12-006
Goede voorbeeld, maar als je al enige tijd Windows Server 2012 of 2012 R2 draait heb je zo te lezen hier geen last van.

@OT
Vreemd dat het zo lang duurt voordat mensen er achter komen terwijl de code juist open is, en het dus juist snel gespot zou moeten worden?!
Het is opensource dus je had de bug zelf kunnen vinden.

Er zijn maar heeeeeeel weinig mensen die dit voordeel van opensource benutten. Maw, het is niet echt een argument om voor opensource te zijn. Er zijn veel betere argumenten om ervoor te zijn.
Voeg toe dat open source ook vaak verschilt per project.

De beste projecten zijn vaak projecten waar een klein aantal die-hard mensen zich eigenaar voelen, en de zaak actief controleren. Vaak ook worden deze ontwikkelaars full-time betaald door professionele bedrijven. De Linux kernel is een mooi voorbeeld hiervan.

Je hebt dan de voordelen van professionele closed source met de vooprdelen van open source.

Aan de andere kant heb je projecten waar af en toe iemand iets aan bijdraagt, maar die geen echte eigenaar heeft. OpenSSL is een mooi voorbeeld gebrek aan lange termijn visie en dat 'iedereen' zomaar zaken kan inchecken en geen noemenswardige kwaliteitscontrole. OpenSSL is bovendien volstrekt onleesbaar, zodat ook een expert in crypto er geen wijs uit kan worden.

De Heartbleed bug was een prachtig voorbeeld van bijna alles wat fout kan gaan. Slechte leesbare code, ongedocumenteerd, inchecken op nieuwjaars-avond zonder noemenswaardige code-review, twijfelachtige standaard (waarom default aan?) en een hele serie van andere fouten in het kielzog (SSL prime numbers default gecached, geen clear-free maar normale free).

Gelukkig hebben de meeste grote gebruikers van OpenSSL (Akamai, Google, CloudFlare) allemaal hun eigen 'fix' stap en nemen geen OpenSSL as-is in hun producten, maar een product als OpenSSL zou eigenlijk gemanaged moeten worden zoals Linux, waar een aantal sponsoren full-time developers leveren die mogen bijdragen. OpenSSL is gewoonweg te belangrijk en waardevol.

GnuTLS valt wat dat betreft ook in dit rijtje. Het was al een paar jaar bekend dat deze code net zo zooi was als OpenSSL. Zo gebruikt het bijvoorbeeld string-functies voor binary data. Dat is een architectuur-fout. En blijkt er een soort Apple-goto-fail in te zitten. De reden dat GnuTLS gebruikt werd blijkt bij rondgang ook vaak dat er geen alternatief is vanwege licentie-redenen.
Vreemd dat het zo lang duurt voordat mensen er achter komen terwijl de code juist open is, en het dus juist snel gespot zou moeten worden?!
Waarom? Open source betekent niet dat het constant gereviewed wordt. In dat opzicht verschilt het niet van closed source. Het voordeel is hooguit dat het gereviewed *kan* worden als je een fout denkt te hebben. Terwijl je bij closed source dan afhankelijk bent van de goodwil/contracten van de leverancier.

Ik acht ook zeker niet uitgesloten dat de Heartbleed bug dit lek aan het licht heeft gebracht. Zo in de trant van: "Laten we ook eens wat van onze 'oude draken' onderzoeken." Wat dat betreft is zo'n bug wel goed om de boel weer eens scherp te krijgen. Veel van dit soort code is vrij oud en absoluut niet spannend vanuit een ontwikkelaarsoogpunt. Door het lek is het nu weer in elk geval weer even spannend voor bugjagers.
Over MS12-006: "This vulnerability affects the protocol itself and is not specific to the Windows operating system". Slecht voorbeeld dus.

Op zich is het niet raar dat dit alleen onder Linux voorkomt: er moet een aparte port gemaakt worden voor Windows om de software te laten werken op dat OS. Kennelijk heeft men dit specifieke foutje daarin niet gemaakt.

EDIT: Ik kan trouwens nergens terugvinden dat dit alleen op Linux zou optreden, volgens mij is de Windows versie van GnuTLS net zo hard getroffen. De opmerking is vooral dat de software op Windows niet veel gebruikt wordt, maar dat betekent niet dat er geen probleem is ;)

[Reactie gewijzigd door Ximon op 2 juni 2014 13:31]

Ik probeerde een snel voorbeeld aan te halen waar windows getroffen door andere bugs wordt. De heartbleed bug is erg breed in de media gezet en komt daardoor over dat OpenSSL bijna per definitie slecht is, terwijl er op windows wellicht net zulke kwalelijk bugs in de SSL implementatie zitten (MS12-006 was een van de eerste artikele die ik tegen kwam met SSL en content disclosure in 1 artikel)
Niemand 'in his right mind' gaat een andere ssl implementatie anders dan die van Microsoft zelf op een Windows server installeren. Wie dat wel doet moet afvragen waar hij/zij mee bezig is. |:(
Is ook wel erg vervelende zaak aan het worden. Dat het nu pas ontdekt wordt betekend in mijn ogen dat het er al erg lang in zit zonder dat iemand het door heeft gehad én door heeft gegeven. Gelijk maar eens de server updaten want dit wil je gewoon niet.
Tja, je kan ook automatische security updates installeren aanzetten.
Maar dit gaat om een bug in de client-versie, tenzij je server ook als client functioneert maakt het niet veel uit, hoewel updaten natuurlijk altijd belangrijk is.
stverschoof merkt op dat de vulnerability al erg lang bestaat - niet dat het lang duurt voordat er een fix is. Het automatisch installeren van fixes helpt op dit moment inderdaad het probleem op te lossen, maar het eigenlijke issue is dat dit soort serieuze fouten dus in (open source) software kan zitten - jarenlang totdat iemand het vindt.
Begrijp me goed, dit is geen probleem van opensource software alleen. Maar een van de uitdrukkelijk genoemde voordelen van opensource code is altijd geweest dat iedereen de code kon controleren. En kennelijk doet niemand dat...
1. Het feit dat deze bug ontdekt en gerepareerd is geworden, bewijst natuurlijk net wel dat open source code gecontroleerd wordt...
2. Hoe zeker ben jij dat de SSL en TLS bibliotheken in closed source software vrij is van bugs?
Dat klopt, maar het argument 'open source is veilig' houdt hierna geen stand meer, ookal valt zoiets snel te patchen is het lek er alsnog geweest.
Zeker voor iets wat zo belangrijk is als ssl zouden een hoop mensen de opensource code door moeten nemen, maar blijkbaar doet niemand/te weinig mensen met kennis dit of is de code alsnog zo onleesbaar dat het net zo ontoegankelijk is als closed source (ingewikkelde code bijv.).
Dat neemt het voordeel dat het kán niet weg ;)
Ik denk niet dat je hieruit kunt concluderen dat niemand de code bekijkt. Het ontwikkelproces en merge proces dwingt af dat er wel degelijk naar gekeken wordt. Sommige delen van de code zijn gewoon dusdanig complex dat het niet altijd evident is dat er een fout in zit. Dit is een algemeen bekend fenomeen voor ict'ers... Aka bug ;).
En kennelijk doet niemand dat...
Of de mensen die dit wel ontdekt hebben, hebben zich koest gehouden en het eea aan de NSA ofzo verkocht. ;)
Server én Client (in sommige gevallen inderdaad, bij toegang tot bepaalde remote entiteiten ;) ) inderdaad.
Tja, dat iets open source is betekent dat iedereen de source kan inzien. Het betekent niet automatisch dat iedereen (of zelfs überhaupt één iemand) dat ook doet.

Overigens is het geen toeval dat er nu achter elkaar op verschillende platformen dit soort problemen worden ontdekt. Na Heartbleed zullen zowel closed- als open source developers ineens bestaande code zijn gaan auditen. Er zullen er de komende maanden nog wel een paar volgen die er al maanden of jaren in hebben gezeten...
Externe source code lezen valt niet altijd mee, zeker in projecten waar leesbaarheid niet altijd de juiste aandacht heeft. Toch valt open source wel degelijk te prefereren. Als er namelijk een keer iets niet werkt en je hebt sources dan kan je nog op zoek gaan, iets wat je uit je hoofd laat als je alleen naar assembly moet kijken.
ik denk dat het eerder betekent dat er te weinig kennis en expertise beschikbaar is,
ssl is niet het aller makkelijkste protocol en dat maakt de software die het implementeerd ingewekkeld waardoor er wenig mensen zijn die er mee aan de slag kunnen...

bovendien is opensource ontwikkelen nog steeds niet populair, en ik heb ook niet het idee dat het onderwijs ook maar enige aandacht an dit soort software besteed,
Opensource is behoorlijk populair hoor, het overgrote deel van internet draait bijvoorbeeld op opensource besturingssystemen met opensource webservers, etc. Daarnaast welk bedrijf heeft er nu niet een server of op zijn minst een applicatie in gebruik dat opensource is? Zelfs alle tv's in onze woonkamers hebben linux erop staan tegenwoordig. Android op vele smartphones en nog ontelbaar meer voorbeelden.

Waarom zou het onderwijs aandacht aan opensource software moeten besteden? Het ontwikkelen gebeurd niet anders en het gebruik ervan is ook niet anders???
Dat is onzin, er zijn in de afgelopen paar maanden ook een hele zooi hele erge problemen met Windows en Mac OSX geweest. Voordeel bij Linux is dat je binnen een week een fix kan binnen halen via de gewone updater, bij Windows moet je in eerste instantie meestal eerst een hotfix draaien.
binnen halen via de gewone updater, bij Windows moet je in eerste instantie meestal eerst een hotfix draaien.
Wat dus in praktijk hetzelfde is....
Hotfixes moet je handmatig installeren, in een week of 2 daarna haal je het pas binnen met automatische updates. Dat is hoe het is gegaan met de laatste grote lekken in Internet Explorer.
Omdat na jarenlang gezeik van iedereen over hoe Microsoft omging met Windows updates. Omdat die updates binnen kwamen het moment dat ze klaar waren. Waardoor je bijna elke dag updates binnen kreeg

Zijn ze begonnen met patch Tuesdays. Zodat je er maar 1 keer per maand rekening mee hoeft te houden.
En nog is het niet goed want nu moet men handmatig patches downloaden...
Het probleem is niet dat Windows automatisch updates binnenkrijgt, maar dat Windows voor iedere update wil/moet herstarten. Dat is onpraktisch en onnodig. Het opnieuw laden van programmacode behoeft geen restart zoals Linux al tientallen jaren bewijst.
Microsoft is tussen XP en Vista bezig geweest met een project om de NT kernel updates net als Linux te doen. Zonder herstarts.
Vond Microsoft het niet waard, want het kan gewoon voor onstabiliteit zorgen. (en heb het zelf met Ubuntu en Debian ook regelmatig meegemaakt dat het kreng uit eindelijk toch crashed en daar heb je dan je herstart :P, persoonlijk herstart ik Linux servers ook als ze grotere updates binnen trekken.)
Ze hebben erna met Windows 7 nog heel veel werk gestopt en toen het aantal herstarts met 2/3de weten te verminderen.

Ik kom op de laatste 2 patch tuesdays en in het begin een paar. na Ook bijna elke maand door zonder geforceerde herstarts.

Daarbij, geen enkel systeem is kritiet genoeg dat deze niet 1 uur per maand offline kan zijn. Dan heb je sowieso al een probleem.
De enige reden waarvoor je een linux server zou moeten herstarten is vanwege een kernel update, voor de rest aan software is het gewoon proces herstarten en door laten pruttelen.
Invididuele processen en meeste services niet, zelfde geld over het algemeen over windows.
Maar als er updates de belangrijke libs en dergelijke gaan updaten voer ik zelf liever even een herstart uit. Niet doen gaat over het algemeen ook goed. Maar ik kwam gewoon wel eens tegen dat na wat grotere updates een dag of wat later een server er ineens uitklapt. Sinds ik ze na grotere updates een herstart geef is dat naar mijn ervaring een stuk minder. (is ondertussen allemaal wel 1,5+ jaar geleden, maar betwijfel of het zo verbeterd is)

NT kan net als de Linux kernel alles on the fly loaden en unloaden, windows herstarts zijn met 7 en 8 voornamelijk gewoon precautious herstarts. Omdat als het fout gaat, Microsoft de lul is.
Het probleem is dat je in Windows een dll die geladen is niet kunt weggooien. (Wel renamen, trouwens). Dus is het behoorlijk lastig om die te vervangen zonder opnieuw op te starten. Bij dat opnieuw opstarten wordt de dll vervangen voordat de GUI wordt gestart.

Bij Linux gooi je gewoon de library weg, en vervangt hem. Zodra de laatste referentie naar de oude library is verdwenen (door herstarten van de gebruikende software) is de file echt verdwenen.
De reden dat dit ontdekt wordt is omdat het open-source is. Bedrijven en mensen kunnen hier gratis en voor niets naar kijken, waardoor bugs, zoals deze, gepakt kunnen worden. Bij Windows kan dat niet en daardoor weet je niet hoe veilig het is. Dat we de lek niet vinden in windows betekend niet dat ze er niet zijn en dat niet misbruikt worden.
Niet zo zeer. Als je de details let klopt dat hij in eerste instantie wat zag in de git en op basis van dat gaan kijken is.

Maar hoe hij de exploit gevonden heeft is gewoon ouderwets kutten met het programma zelf.
Dat is net zo bizar als trojans die wel Windows infecteren, maar niet Linux. :P
Microsoft gebruikt geen GPL-libraries in Windows, dus is Windows niet vatbaar. Hetzelfde geldt voor OpenSSL: Microsoft heeft hun eigen implementaties dus die hebben hoogst waarschijnlijk deze bug(s) niet.
Niet echt bizar, deze library is gewoon voor Linux (of *NIX?) geschreven.
Net zoals een Windows Media Player bug niet op Linux zal voorkomen :)
Omdat Windows standaard geen OpenSSH en GnuTLS gebruikt. Er is overigens wel een GnuTLS voor Windows.
Dat weet ik ook wel... maar het gaat er gewoon over dat commerciele software deze bugs niet bevat, en open source wel. Nu ja, vaak is het gewoon ook omgekeerd... dus men heeft kwaliteits issues langs beide kanten.
GnuTLS en openSSL draaien voornamelijk op Linux/*NIX servers, en niet op windows. Beide zijn echter prima beschikbaar op Windows, en bevatten daar ook gewoon deze bugs, al kan ik me voorstellen dat ze daar wellicht niet/moeilijker/anders te exploiten zijn, afhankelijk van hoe Windows en Linux met geheugen omgaan.
Dit klopt niet. Er zijn voor Windows specifieke OpenSSL binaries te vinden, die al dan niet door derden zijn gebouwd en dus ook kwetsbaar zijn als er niet op dit specifieke onderdeel zoveel code wijzigingen zijn doorgevoerd:
http://www.openssl.org/related/binaries.html
http://www.gnutls.org/download.html
Dit maakt het probleem even problematisch als die van heartbleed.
Dat is niet zo heel bizar, zie het als een brandstof fout bij een diesel motor, diezelfde fout zie je ook niet snel bij een benzine motor.
De meeste *nix/bsd/en consorten gebruiken nu eenmaal vaak dezelfde libraries/packages.
Note to self: refresh before reply

[Reactie gewijzigd door GewoonWatSpulle op 2 juni 2014 12:49]

Heartbleed is een bug in OpenSSL. Dat is voor zo'n beetje alle populaire OS-en beschikbaar en in gebruik. Zelfs OS-en waar je normaal niet veel van ziet zoals in switches en routers.
Windows zelf gebruikt het misschien niet maar er is genoeg software voor Windows waarin OpenSSL gebruikt wordt.
Dat is een beetje appels met peren vergelijken. De Heartbleed bug was een server side bug en dat was van toepassing op alle varianten van OpenSSL, welke ook beschikbaar is voor andere besturingssystemen ander dan Linux. En de GnuTLS is de client variant die in dit geval veel wordt gebruikt op Linux, maar ook op Windows beschikbaar is: http://www.gnutls.org/download.html
Dat klopt niet volledig.

Heartbleed trof evengoed Windows indien je er bijvoorbeeld een apache + OpenSSL had op geïnstalleerd. IIS was niet vatbaar (wat de meest voorkomende combinatie is).

In het geval van GnuTLS kan een windows machine ook vatbaar zijn indien het een programma draait die deze library gebruikt. Het enige verschil is dat een aantal linux distributies deze library standaard gebruiken.
Wat veel raarder is, is dat nog steeds heel veel mensen open source, wat een licentiemodel is, verwarren met een kwaliteitsstandaard.
Wow, waar heb je dit vandaan getoverd...? OpenSSL en GnuTLS draaien prima in Windows, BSD varianten, OSX, embedded devices en OpenSSL kan je ook in diverse netwerk appliances tegenkomen. De meesten zijn op Linux of BSD gebaseerd, maar dat neemt niet weg dat je OpenSSL op VxWorks of zelfs Plan9 kan compileren en laten werken.
Omdat de libraries in kwestie niet gebruikt worden op Windows.
Maar ga nou maar niet denken dat Windows veilig is ;) De enige reden dat je het over Linux in het nieuws hoort is omdat Linux open source is en iedereen het dus kan zien; Bij Windows bestaan die bugs maar weten alleen de mensen in de uithoeken van het internet (en de NSA) van het bestaan af.
Kies zelf maar wat jij liever hebt, maar ik ga toch voor de open source-veiligheid denk ik :)
Heartbleed vind je ook op windows. Genoeg software die openssl gebruikt.
Enige bestaansrecht van GnuTLS is overigens licentietechnisch. OpenSSL heeft een advertisement clause in de licentie staan die incompatible is met GPL.
Pure zever. Meer programmeurs is niet perse beter. Uiteindelijk werd de heartbleed bug niet ontdekt door de code te bekijken. En de laksheid van de ontwikkeling van openssl is zo ernstig dat ze het moeten forken naar libressl.
En daarmee stip je direct wel de grote kracht van oss aan. Als OpenSSL de naam ClosedSSL had gehad, dan was LibreSSL een stuk lastiger geworden omdat ze niet de code hadden kunnen forken.

In dat opzicht heeft Netforce2020 dus toch een beetje gelijk. Ondanks de laksheid bij OpenSSL wordt er toch aan een oplossing gewerkt, die er kennelijk anders niet of later was gekomen. De fouten zouden dus eerder kunnen zijn opgelost.
Daarmee stip ik net de zwakte aan. Want moest de heartbleed bug niet gevonden zijn zou er buiten het lakse ontwikkelteam van openssl niemand kraaien naar de ontwikkeling er van.

En zo gaat het met veel projecten die (toch belangrijk zijn maar) weinig of geen aandacht krijgen, laat staan financiele steun.

Ik ben in geen opzicht voorstander van closed source, maar bij die bedrijven zit er tenminste wel financiele backing en een incentive om elk aspect van het product te onderhouden.
Ik ben in geen opzicht voorstander van closed source, maar bij die bedrijven zit er tenminste wel financiele backing en een incentive om elk aspect van het product te onderhouden.
Inclusief de reputatie ervan. En dat is weer een reden om zulke bugs niet naar buiten te brengen. Hoe vaak hebben we geen bericht gezien van een security firm die na 6 maanden ofzo een vulnerability algemeen bekend maakt omdat de producent het simpelweg vertikt heeft de bug te fixen?
En de heartbleed bug zit al jaren in openssl omdat niemand de moeite doet om de code deftig te onderhouden.

Voor elke bug in pakweg windows zijn er evenveel in linux, mar het verschil is de aandacht dat er aan wordt gegeven. Er wordt gewoon meer geklaagd op closed source omwille van de licentie dan de kwaliteit van de code en het eindproduct.
de heartbleed bug zit al jaren in openssl omdat niemand de moeite doet om de code deftig te onderhouden.
En er zijn ook closed source producten waar dit zo is, dus wat is nu eigenlijk je punt? Er zitten in Windows vast ook dll's waar al jaren niks aan is gedaan. Waarom moet Linux anders zijn?

Natuurlijk is er meer aandacht voor een lek in Windows, omdat 90+ procent van de wereld dat op zijn computer heeft. Dat heeft echt niet met een licentie te maken. De licentie van een server met de heartbleed bug zal denk ik hoger liggen dan die van een Windows machine, omdat je op een server een veel zwaarder support abo afsluit. Alleen zijn er ontelbaar meer Windows licenties dan Linux licenties.

En natuurlijk zitten er in Linux waarschijnlijk evenveel bugs dan in Windows. Dat is de wetmatigheid van de complexiteit van de code. Er zitten nu eenmaal gemiddeld x fouten in x regels code. Dus wat je daarmee probeert te bewijzen zie ik niet.

Je lijkt te suggereren dat Open Source inferieur is aan Closed Source, maar je argumenten waarom dat zo zou moeten zijn rammelen aan alle kanten.
Ik sugereer nergens dat open source inferieur, noch superieur is.

Maar ik vind het belachelijk dat er op closed source gebashed word omdat het closed source is. Het staat elk bedrijf of ontwikkelaar vrij om zijn licentie te kiezen.

Maar om dan op closed source te klagen dat het niet onderhouden wordt ... brute pech zolang je er niet voor hebt moet betalen.
Ik sugereer nergens dat open source inferieur, noch superieur is.
Dan heb ik je reacties wellicht niet goed begrepen. Ik meen toch een behoorlijk stuk vrij ongefundeerde kritiek te lezen tov OSS.
Maar om dan op closed source te klagen dat het niet onderhouden wordt ...
Ik heb door de jaren voor diverse pakketten betaald die daarna een stille dood zijn gestorven. Kortom, ik heb dus recht van klagen?
dat er op closed source gebashed word omdat het closed source is
Ik was niet aan het closed source bashen. Ik stipte alleen aan dat forken een exclusief voordeel is voor Open Source, wat Closed Source niet kent. De Heartbleed bug, toont aan dat dit een voordeel is.

Ook bijvoorbeeld TrueCrypt lijkt op die manier een tweede leven te krijgen. Terwijl het als Closed Source bijna zeker exit was geweest.
Het staat elk bedrijf of ontwikkelaar vrij om zijn licentie te kiezen.
Nu gaan we een heel nieuw pad in lijkt het. Ik heb nooit beweerd dat die vrijheid er niet zou moeten zijn... toch?

Maar goed, dit alles terzijde. Ik heb niet de indruk dat we dichter bij elkaar komen.
Om op truecrypt te komen, in de licentie staat 't schijnt nergens vermeld dat het toegelaten noch verboden is te forken. Dus dat is in feite een redelijk grijzen zone zolang ze geen expliciete toelating van de ontwikkelaars hebben.

Nu zijn ze imho niet echt koosjer bezig met hun fork zonder dat er duidelijkheid is van wat ze mogen of niet.

http://en.wikipedia.org/w...se_and_Open_Source_status
Ze zijn niet bezig met een fork, alleen met de voorbereiding ervan. Dat is niet verboden en ook nooit verboden geweest. De projectleider heeft al aangegeven dat eerst de licentieproblemen opgelost moeten worden, dus wat daar niet koosjer aan is mag je me dan nog eens proberen uit te leggen.

En weer valt me op dat je de aanval op open source kiest. Mijn pro-OSS argumenten negeer je en de focus gaat weer volledig naar wegen om iets negatiefs te vinden.

Toch val je tegelijk mij wel aan op een vermeend bashen van closed source. Dat noem ik meten met twee maten.
maar bij die bedrijven zit er tenminste wel financiele backing en een incentive
Ik vind dit het domste argument ooit. Hoe kom je erbij dat achter open source geen backing zou zitten? De beste open source programmeurs doen gewoon gewoon hun werk in dienst van een bedrijf als IBM, Red Hat, Samsung, Google, enz.

Ja er zijn pakketten die verwezen omdat er weinig belangstelling voor is, maar je wil niet weten hoeveel pakketten er voor Windows die op sterven na dood zijn. En dan heb je pas echt een probleem.

Closed source heeft echt niet meer of minder problemen op dat gebied. Alleen open source heeft het voordeel dat sterven niet dood is, maar een kans om weer tot leven te komen als fork. Iets wat je negen van de tien keer met closed source kan vergeten.
ik ben beniuwd of tweakers ook is/was geraakt. volgens m'n certificaat wordt er tls1.2 gebruikt.
@ Soldaatje
Dat zou dan alleen kunnen als Tweakers al gehackt is.
ik bedoelde of tweakers ook de TLS vormt gebruikte die het lek bevatte. ik stel dus niet dat er misbruik van gemaakt is. maar iets als wij hebben onze TLS bijgepatched of onze TLS had dit lek niet.

[Reactie gewijzigd door dezejongeman op 2 juni 2014 13:19]

Dat zou dan alleen kunnen als Tweakers al gehackt is waardoor er van die gemanipuleerde berichten verstuurd kunnen worden of de admins zelf zouden dat doen.
Maar het TLS protocol dat jij bedoelt is iets anders dan de versie van het softwarepakket zelf.
Nu gaat iedereen echt zoeken naar backdoors nu men uitgaat vanb bewuste verzwaking van code.
Laten we het hopen en ook dat bugs direct gemeld worden. Het artikel gaf aan dat het hetzelfde bedrijf was die de HeartBleed bug vond.
Ik kom net thuis van mijn werk, zet mijn computer aan en.... de patch voor dit lek wordt op mijn Linuxbak al aangeboden via de updates. Is dat snel of niet? :9~
:9~ Inderdaad netjes met fatsoenlijke titel een goede beschrijving mocht je de behoefte hebben aan op zijn minst wat globale info anders nog met een URL ter inzage erbij.
Fijn omdat je los van systeem beveiliging misschien al tijdje hoopt op een fix ergens op.
Zo je er gelijk even mee aan de gang kan en het af kan sluiten, als de oplossing al niet op fora's besproken is.

Maar KB28/29... beveiligingsupdate voor Windows 7, zoek maar uit waar het voor is (~15x) werkt ook hoor xD.

Alleen bij de +80 optionele maar toch aanbevolen updates die allemaal problemen met windows schijnen op te lossen, maar dan uiteindelijk alles behalve datgene waar het om gaat :9 begint het wel te kriebelen. En inzetten op losse hotfix is vaak ook een verloren zaak als het een oude bug betreft.
*Ik kan het niet laten, ik word nou eenmaal geacht er mee te werken :X

[Reactie gewijzigd door Canule op 2 juni 2014 22:25]

Ik heb net de ubuntu 14.04 usb stick zover dat ie persistence heeft, en dus kan saven en op internet kan, krijg je dit. Je kunt een live usb niet updaten.
Ik heb net de ubuntu 14.04 usb stick zover dat ie persistence heeft, en dus kan saven en op internet kan, krijg je dit. Je kunt een live usb niet updaten.
Niet? Ik kan me herinneren dat het voorheen wèl kon. Alleen nieuwe(re) kernels konden niet op een persistent stick geïnstalleerd worden. Maar beveiligingsupdates en applicatie-updates wèl. Misschien is dat tegenwoordig veranderd?

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True