Apple dicht groot ssl-gat in OS X

Apple heeft een ernstig beveiligingsprobleem in OS X Mavericks gedicht. Het probleem maakte het mogelijk om de inhoud van https-verkeer te achterhalen. IOS was ook kwetsbaar, maar werd afgelopen zaterdag al gepatcht.

De update waarin het probleem wordt opgelost is inmiddels te downloaden, hoewel Apple in het update-scherm niet aangeeft dat de patch erin is opgenomen. Wel is in een uitgebreider overzicht van de in de update gepatchte beveiligingsproblemen te vinden dat het probleem is opgelost. Dat Apple het probleem relatief stilletjes dicht, is opmerkelijk, omdat het om een relatief ernstig beveiligingsprobleem gaat.

De bug liet kwaadwillenden met beheerdersrechten op het netwerk namelijk een zogenoemde man in the middle-aanval uitvoeren, waarbij het netwerkverkeer kan worden onderschept. Bij http-verkeer is dat sowieso al mogelijk, omdat het verkeer niet wordt versleuteld, maar https is juist bedoeld om vertrouwelijk te communiceren over kanalen die niet per se vertrouwd zijn.

Het beveiligingsprobleem werd veroorzaakt doordat de tekst 'goto fail' twee keer werd geplaatst, waar dat maar één keer had gemoeten. Daardoor werd een server waarbij de code eigenlijk alarm had moeten slaan, alsnog vertrouwd. Volgens sommigen is de bug bewust in de code geplaatst, en gaat het om een backdoor; Apple heeft nog niet op die aantijging gereageerd.

De bug deed zich niet alleen voor in OS X, maar ook in iOS; dat besturingssysteem werd afgelopen weekend al gepatcht. Andere versies van OS X zijn niet kwetsbaar.

Afbeelding: Ashkan Soltani

Reacties (200)

[Anoniem: 474132]

Patch inmiddels geinstalleerd en SSL gat gedicht, getest op https://gotofail.com :

Safe.

We have examined your OS and browser version information and determined that an active vulnerability test was appropriate. Fortunately, your browser correctly aborted loading our test image upon seeing an invalid ServerKeyExchange message.


voor de update kreeg ik op dezelfde site nog een waarschuwing.

[Anoniem: 16328]

Volgens sommigen is de bug bewust in de code geplaatst, en gaat het om een backdoor; Apple heeft nog niet op die aantijging gereageerd.

Dat zou inderdaad interessant zijn. Het is wel een soort bug die men niet snel vindt, maar voor de mensen die het weten wel een makkelijke manier om op de systemen te komen.

[Reactie gewijzigd door Anoniem: 16328 op 23 juli 2024 12:19]

[Maurits van Baerle]

In eerste instantie verbaasde het mij dat een bug zoals dit door de unit-tests kon slippen. Als je echter een beetje gaat graven, de betreffende source is openbaar, kom je er achter dat het extreem moeilijk te testen is. Je zult namelijk een hele eigen TCP stack moeten bouwen die bewust foutief is. Het aantal iteraties is extreem!

Wat wel vreemd is waarom automatische code analyse het niet heeft gevonden. Het moet namelijk niet erg lastig te analyseren dat er een aantal regels code zijn die logischerwijs onmogelijk aangesproken kunnen worden. Dat zou alarmbellen moeten doen rinkelen. Het zal meestal om code gaan die dan veilig verwijdert kan worden. In dit geval echter...

[Carbon]

Wat wel vreemd is waarom automatische code analyse het niet heeft gevonden.

Ik heb het zelf getest, zowel LLVM als de static analyser geven geen 'unreachable-code' waarschuwing.

[bantoo]

Daar heb je een flag voor nodig die niet onder -Wall valt.

[Carbon]

Daar heb je een flag voor nodig die niet onder -Wall valt.

Klopt, je kunt het aanzetten met de '-Wunreachable-code' flag.

Kwalijk is dat het standaard uitstaat.

[Maurits van Baerle]

Volgens mij is het probleem met -Wunreachable dat het al snel tienduizenden false positives vindt. Daarom staat het default niet aan.

[Carbon]

Volgens mij is het probleem met -Wunreachable dat het al snel tienduizenden false positives vindt. Daarom staat het default niet aan.

Alleen in het geval van Objective-C en het gebruik van preprocessor macro's binnen conditionals.

[johnkeates]

Laat Mac OS X sources nou toevallig voor een groot deel uit Objective-C bestaan

[Carbon]

Laat Mac OS X sources nou toevallig voor een groot deel uit Objective-C bestaan

Het opensource gedeelte (waarin deze fout zit) bestaat voornamelijk uit C en embedded C++ code.

[Reactie gewijzigd door Carbon op 23 juli 2024 12:19]

[johnkeates]

Ja, dat is natuurlijk ook zo, maar de kans is groot dat ze -Wunreachable daarom niet by default aan hebben staan.

[BoringDay]

Het zal wel wat lastiger zijn dan slechts ff unit test, het gaat hier om een OS niet om een applicatie.

[Raventhorn]

Een OS is in principe (extreem vereenvoudigd) niets anders dan een verzameling van een kernel, window/desktop manager, een x aantal frameworks en een aantal standaard applicaties om management eenvoudiger te maken en extra functionaliteit te bieden.

Ook een OS zou je dus kunnen zien als een applicatie, alleen dan een met een afwijkende structuur van de gemiddelde applicatie.

Daarnaast bestaat een OS uit code, welke vast ook te testen is met unit tests. Als je je OS alleen kan testen door het te installeren en gebruiken is er iets goed mis met de manier waarop 'ie opgebouwd is...

[johnkeates]

Dat is toch net wat anders... kijk bijvoorbeeld eens naar deze video: http://www.reactos.org/node/718 dat gaat over ReactOS, waarvan de sources een stuk kleiner zijn dan Mac OS X / Windows of een gemiddelde Linux distro.

De problemen die ze alleen al daar hebben zouden al duidelijk moeten maken hoe veel meer een OS t.o.v. een Applicatie is.

[MBV]

Dat heeft rechtstreeks te maken met de goto's: code met goto's is minder gestructureerd en moeilijker te analyseren dan 'nette' code met gewone conditionals als if, for, while enzovoort.

[Anoniem: 154887]

Zaterdag hebben ze het zelf aan het licht gebracht met een iOS patch, en 3 dagen later is het gedicht voor Mac OS. Lijkt me snel opgelost, zeker gezien de reputatie van Apple als het op snelheid van patches aankomt. Kan me niet voorstellen dat dit echt misbruikt is geweest in die korte tijd, tenzij het reeds bekend was bij hackers.

[Reactie gewijzigd door Anoniem: 154887 op 23 juli 2024 12:19]

[zarex]

Dit soort gaten zijn doorgaans langer bekend in de blackhat scene dan bij whitehats...

[ronaldmathies]

Ik vindt deze tekst zo'n dooddoener:

Volgens sommigen is de bug bewust in de code geplaatst, en gaat het om een backdoor;

Bijna iedereen op internet is zo paranoia tegenwoordig dat elke bug als backdoor bestempeld wordt. Dus omdat iemand maar roept dat het een backdoor is is het een backdoor?

Nog beter, ze stoppen dus een backdoor in het open source deel van hun broncode, want deze code was gewoon beschikbaar voor iedereen om te lezen. Dit mag dan wel de meest waardeloze backdoor zijn die er is, als je al een backdoor maakt dan stop je die toch in een closed source deel.

En daarnaast, hoezo stilletjes updaten? er staat letterijk in de release notes welk knowledge base artikel je moet lezen over welke security fixes er gedaan zijn.

Het artikel is voor een groot deel goed geschreven maar mist wel enige nuance. Als ik bij elke bug ga aangeven dat het een backdoor is plaatsen we dan bij elke melding meteen dat dit vermoedelijk zo is?

[Reactie gewijzigd door ronaldmathies op 23 juli 2024 12:19]

[curumir]

In dit geval is er wel meer dan alleen maar geblaat; de timing van de introductie van de bug en de datum van het toevoegen van Apple op de sheets van PRISM. Het blijft (nutteloze, amusante) speculatie, maar Daringfireball heeft er een interessant stuk over op z'n page gezet:
http://daringfireball.net/2014/02/apple_prism

I see five levels of paranoia:
- Nothing. The NSA was not aware of this vulnerability.
- The NSA knew about it, but never exploited it.
- The NSA knew about it, and exploited it.
- NSA itself planted it surreptitiously.
- Apple, complicit with the NSA, added it.

Me, I’ll go as far as #3.1 In fact, I think that’s actually the optimistic scenario — because we know from the PRISM slides that the NSA claims some ability to do what this vulnerability would allow. So if this bug, now closed,2 is not what the NSA was exploiting, it means there might exist some other vulnerability that remains open.

[drdelta]

Dit mag dan wel de meest waardeloze backdoor zijn die er is, als je al een backdoor maakt dan stop je die toch in een closed source deel.

Het doet niet af aan het feit dat op iOS én OS X er de mogelijkheid was "om de inhoud van https-verkeer te achterhalen". De hele reden waarom er https-verkeer gebruikt wordt, namelijk zodat de inhoud niet te achterhalen is, wordt door Apple onderuit gehaald door hun implementatie. Of dat nu wèl of niet in het open-source deel van hun code zit, het zit in hun code !

Het lijkt mij zeer terecht dat mensen eens achter hun oren krabbelen wanneer een bedrijf als Apple zijn https zo implementeert op zowel iOS als OS X dat het feitelijk nutteloos is. Dat er hier gesteld wordt dat het een backdoor is, is niet vreemd sinds het beveiligd http verkeerd volkomen nutteloos maakte. En zeker gezien de uitgelekte geheime diensten schandalen is dit alles behalve onwaarschijnlijk dat dit gebruikt is om een groep 'verdachten' te pakken.

Edit:
Lijkt er op dat ik de Apple fanboys op hun tenen getrapt heb, voor alle mensen die niet snappen hoe het moderatie systeem werkt:

-1 Ongewenst - "Deze reactie is eem flamebait, troll of belediging naar een andere gebruiker."

Mijn reactie is overduidelijk geen van alle, mijn reactie is een uiteenzetting waarom ik het onvoorstelbaar vind dat Apple een dergelijke blunder maakt, en het persoonlijk niet vreemd zou vinden als dit opzettelijk is gedaan.

[Reactie gewijzigd door drdelta op 23 juli 2024 12:19]

[Armin]

Enkel voor mensen die admin-toegang tot het netwerk hadden. Dus bij de Starbucks de admin van Starbucks zeg maar. Niet de crimineel die een paar tafeltjes verderop zat.

En dan nog enkel directe addressen. Meestal typen mensen https://www.tweakers.net in, en niet het IP.

Dus het was groot nieuws omdat het een blunder was, en een cruciaal onderdeel van het TLS/HTTPS protocol. Echter het merendeel van het HTTPS verkeer was gelukkig gewoon nog steeds veilig.

[IMarks]

Enkel voor mensen die admin-toegang tot het netwerk hadden. Dus bij de Starbucks de admin van Starbucks zeg maar. Niet de crimineel die een paar tafeltjes verderop zat.

Je weet dat een man-in-middle aanval gewoon uitgevoerd kan worden door iedereen op dat netwerk. Admin-toegang is nergens voor nodig. Mocht het netwerk wel dusdanig dicht getimmerd zijn dan kan de crimineel zijn eigen netwerk opzetten met hetzelfde SSID (en wachtwoord indien van toepassing).

[Reactie gewijzigd door IMarks op 23 juli 2024 12:19]

[Armin]

Onzin, tenzij je de routering kunt aanpassen kun jij een direct IP niet manipuleren. Leg jij maar eens uit hoe je de routering denk aan te passen als gewone gast-gebruiker ...

En dat zeg je zelf ook al:

Mocht het netwerk wel dusdanig dicht getimmerd zijn dan kan de crmineel zijn eigen netwerk opzetten met hetzelfde SSID

En dan ben je dus admin.

[Anoniem: 501293]

Het doet niet af aan het feit dat op iOS én OS X er de mogelijkheid was "om de inhoud van https-verkeer te achterhalen". De hele reden waarom er https-verkeer gebruikt wordt, namelijk zodat de inhoud niet te achterhalen is, wordt door Apple onderuit gehaald door hun implementatie. Of dat nu wèl of niet in het open-source deel van hun code zit, het zit in hun code !

Het lijkt mij zeer terecht dat mensen eens achter hun oren krabbelen wanneer een bedrijf als Apple zijn https zo implementeert op zowel iOS als OS X dat het feitelijk nutteloos is. Dat er hier gesteld wordt dat het een backdoor is, is niet vreemd sinds het beveiligd http verkeerd volkomen nutteloos maakte. En zeker gezien de uitgelekte geheime diensten schandalen is dit alles behalve onwaarschijnlijk dat dit gebruikt is om een groep 'verdachten' te pakken.

Je doet nu net alsof je deze "bug" vanaf buiten kan benaderen maar je moet toch echt in hetzelfde netwerk zitten als degene die net op dat moment gebruik maakt van het https protocol.

Ik vind de "bug" een beetje opgeblazen

[drdelta]

Een bug die veroorzaakt dat mensen MitM aanvallen succesvol uit kunnen voeren lijkt mij niet 'opgeblazen'.

[AutCha]

Dat doet me denken aan het nieuwsbericht van eerder vandaag: nieuws: Britse geheime dienst wil reputaties schaden via weblogs en fora

Als je maar vaak genoeg roept dat er overal misschien een backdoor in kan zitten, dan raken mensen gedesinteresseerd, murw of cynisch, waardoor men het lang niet zo erg meer vindt als er écht ergens een backdoor in gevonden wordt.

[bantoo]

Het was algemeen bekend sinds in ieder geval dit weekend, het is triviaal om te misbruiken. Tevens is dit iets dat door iedere compiler opgepakt wordt aangezien er nu dode code achter de goto staat. Het is niet onnaannemelijk dat er mensen zijn die hier op testen.

[Anoniem: 154887]

Kan je dit uitleggen?
Waarom zou er dode code achter de goto staan? Ik hoop toch dat ze alles gewoon gefixt hebben zoals het hoort?

[jorikc]

Voor de fix stond er een goto-regel 2x. Een keer achter een if, maar ook een keer erna. Er werd dus altijd naar het fail-label gesprongen en de code tussen de tweede if en het fail-label kon nooit uitgevoerd worden. Voor meer info zie:
http://nakedsecurity.soph...plus-an-unofficial-patch/

[BoringDay]

Welke code? broncode van OSX? denk niet dat ze die hebben hooguit een versie van Darwin.

Maar dan nog traceren, uitwerken, valideren, testen en uitrollen kost eenmaal tijd.

[Maurits van Baerle]

Een groot deel van OS X is open source. Zo ook deze library. Iedereen met internet en een browser kan hem gewoon downloaden van opensource.apple.com en de code analyseren...

[BoringDay]

Volgens mij loopt Darwin altijd wat achter op versies.

[Anoniem: 445817]

Als je die link van Maurits nou even volgt dan kan je zien dat dat niet zo is. De Security-55471 download die je daar vind ik de nieuwste versie, waarin de bug is opgelost. Ook andere downloads komen overeen met de versies in 10.9.2.

[CyBeR]

Welke code? broncode van OSX? denk niet dat ze die hebben hooguit een versie van Darwin.

Die versie van Darwin is de versie die in OSX zit.

[AutCha]

En dat is juist de reden waarom er aangeraden wordt áltijd curly braces te gebruiken ook al is het een one line statement. En blijkbaar niet onterecht: zelfs op professioneel niveau worden dit soort slordigheden gemaakt.

Deze gaat in mijn "kleine-bug-groot-effect" verzameling. Als software tester is het altijd leuk een handvol van dit soort voorbeelden te hebben.

[Reactie gewijzigd door AutCha op 23 juli 2024 12:19]

[Soldaatje]

Misschien moeten ze hun code even herschrijven en geen goto's meer gebruiken, de alternatieven zijn overzichtelijker.

[bantoo]

Dit is compleet onwaar, dat iedereen aangeleerd wordt dat gotos kwaardaardig zijn is idioot, het is zeer standaard om ze te gebruiken voor error handling

[Armin]

Inderdaad, gewoon een standaard copy-plak fout. Niks mis met goto's indien goed gebruikt. Dit is een typisch goed of in ieder geval veel voorkomend gebruik.

Die copy-plak fout, is slordig maar ik zie er niet meteen een backdoor in. Eerder een code-review faal.

[CyBeR]

Wie spreekt van kwaadaardig ? Ze maken spaghetti code, waar de programmeur in kwestie niet meer weet wat er in z'n flow van code gebeurt.

Goto is niet per definitie evil. D'r zijn legio redenen om ze te gebruiken waar ze gewoon de beste optie zijn.

Hoewel toegegeven dat goto fail, nogal een easy shortcut is; De bug is ook een simpele duplicatie, dat die er bewust is ingeplant, is ongeloofwaardig

Dit is inderdaad duidelijk een foutje van iemand die over z'n editor gestruikeld is, en dat niet opgemerkt heeft. En vervolgens de reviewer, waarvan ik aanneem dat 'ie er is, ook niet.

[Carbon]

Ze maken spaghetti code, waar de programmeur in kwestie niet meer weet wat er in z'n flow van code gebeurt.

Deze manier van foutafhandeling is schering en inslag bij C, kijk maar eens in de Linux kernel sources.

Zelf ben ik fervent voorstander van single-exit code (geen goto's of returns midden in de code), echter voor guards en dit soort code leveren goto's (in C) nog steeds de meest leesbare code.

[Reactie gewijzigd door Carbon op 23 juli 2024 12:19]

[bantoo]

De grote groep mensen die direct kwaad spreken als ze een goto zien. Zoals hierboven, zijn comment was compleet irrelevant aangezien hij niks van C snapt. Het goto gebruik heeft niks met het probleem te maken.

[Pyrone89]

Het is actief misbruikt, zie o.a. Gizmodo. Daarnaast is het een doodzonde om een 0day patch bekend te maken zonder direct de patch te leveren of slechts een gedeeltelijke patch (wel voor iOS, niet voor OSX).

[Chip5y]

Het is pas aan het licht gebracht maar het SSL verificatie issue zou al aanwezig geweest zijn sinds iOS 6. Wat ook de reden is waar iOS 6.1 ook geüpdatet is naar 6.1.6. Dus het gat (en laten we eerlijk zijn het was geen klein issue) is wel degelijk al lang aanwezig.

[Reactie gewijzigd door Chip5y op 23 juli 2024 12:19]

[DexterDee]

Dit was natuurlijk een grote kwetsbaarheid, maar het is niet zo dat per definitie al het SSL verkeer kwetsbaar was voor een "Man in the Middle" aanval. Er was alleen een aanvalsvector als een verbinding rechtstreeks op IP adres werd gemaakt. Verbindingen op basis van een DNS naam waren niet kwetsbaar. En laten nu verreweg de meeste legitieme verbindingen via DNS namen lopen. Uiteraard is dit geen reden om het goed te praten, maar ik heb het idee dat sommigen het aangrijpen om het probleem schromelijk te overdrijven. Ik vind het persoonlijk goed van Apple dat de betreffende sources vrij toegangelijk zijn om in te zien.

/edit: De aanvalsvector blijkt niet zozeer in IP versus DNS te liggen, maar vooral in het gebruik van een specifieke systeemlibrary welke lang niet alle software in OSX gebruikt. Zo was de vulnerability bijvoorbeeld niet uit te buiten in Firefox en Chrome, maar wel in Safari.

[Reactie gewijzigd door DexterDee op 23 juli 2024 12:19]

[Maurits van Baerle]

Ik dacht begrepen te hebben dat dat IP adres verhaal ontkracht was. Maar dat kan ik fout hebben.

Het was overigens inderdaad niet heel makkelijk te exploiten. Je moet ofwel lokaal admin rechten bemachtigen en een stukje malware geinstalleerd te krijgen of je moet een rogue accesspoint beheren en mensen via jouw AP laten surfen. Het is geen remote execution exploit die zo in exploit kit op de zwarte markt opduikt.

[CyBeR]

Dit was natuurlijk een grote kwetsbaarheid, maar het is niet zo dat per definitie al het SSL verkeer kwetsbaar was voor een "Man in the Middle" aanval. Er was alleen een aanvalsvector als een verbinding rechtstreeks op IP adres werd gemaakt. Verbindingen op basis van een DNS naam waren niet kwetsbaar. En laten nu verreweg de meeste legitieme verbindingen via DNS namen lopen. Uiteraard is dit geen reden om het goed te praten, maar ik heb het idee dat sommigen het aangrijpen om het probleem schromelijk te overdrijven. Ik vind het persoonlijk goed van Apple dat de betreffende sources vrij toegangelijk zijn om in te zien.

Dat is zeker niet het geval. SSL op ip-adres werkt (bijna) nooit omdat je geen certificaten kunt krijgen zonder DNS naam erin.

Jij refereert aan dat 'curl' in OSX verkeerde certs toestaat wanneer op IP verbonden wordt. Dat geldt echter niet voor Safari e.d.

Dit was echt een probleem waarmee MitM's uitgevoerd konden worden.

[Rembert]

Zeker niet? Ik lees in deze security update:

curl
Available for: OS X Mavericks 10.9 and 10.9.1
Impact: An attacker with a privileged network position may intercept user credentials or other sensitive information
Description: When using curl to connect to an HTTPS URL containing an IP address, the IP address was not validated against the certificate. This issue does not affect systems prior to OS X Mavericks v10.9.

[CyBeR]

Ik bedoel dat is een apart probleem. De bug waar 't over gaat, is ook van toepassing op Safari en een heleboel andere zaken.

[mashell]

Alleen een update voor Mavericks of ook voor de eerdere OS X versies? Voordat er geroepen wordt de Mavericks update is gratis: Ik kan mijn Snow Leopard niet updaten, MacBook is net te oud daarvoor maar is eigenlijk nog wel ok.

[tobitronics]

De update is naast de fix ook wat andere dingetjes zoals facetimen zonder beeld. Bovendien is het typenummer 10.9.2, dus ik gok dat je echt mavericks nodig hebt om de fix te kunnen krijgen.

[OkselFris]

Dit issue komt niet voor bij eerdere OSX versies.

[Carbon]

Alleen een update voor Mavericks of ook voor de eerdere OS X versies?

Zover ik weet zat het probleem alleen in iOS 6 en iOS 7 en OSX 10.9.

[biglia]

Zit de fout niet in de browser in plaats van het besturingssysteem?

[Maurits van Baerle]

Nee, hij zat in een onderliggende library van het OS. Safari en andere onderdelen en apps die gebruik maken van die lib waren kwetsbaar. Browsers met hun eigen SSL lib zoals Firefox en Chrome waren weer niet kwetsbaar.

[Tsjilp]

Nee, deze bug zit/zat op OS niveau, niet alleen de browser was kwestbaar, ook andere software als mail, facetime, enz.

[BikkelZ]

Daarom is het ook zo vreemd dat mensen klagen over de nesting die Python gebruikt. Vier spaties dieper betekent {, en als je één regel weer vier spaties (een "tab") zakt dan sluit je weer. Dus je code gebruikt altijd precies de zelfde indentatie als je programmaflow omdat het gewoon precies het zelfde is.

Talen die dat niet doen lopen gewoon het risico op dit soort bugs, zeker in zwakkere IDE's die niet aangeven dat er dode code in die functie zit en compilers(ettings) die dit niet afvangen. Ik heb een aantal plekken gezien waar dit soort code wel een buildfail gaf in bijvoorbeeld een msbuild van C# code, maar dat waren custom instellingen.

[Dorank]

Daarom is het ook zo vreemd dat mensen klagen over de nesting die Python gebruikt. Vier spaties dieper betekent {, en als je één regel weer vier spaties (een "tab") zakt dan sluit je weer. Dus je code gebruikt altijd precies de zelfde indentatie als je programmaflow omdat het gewoon precies het zelfde is.

Jouw aannames zijn mijn bezwaren tegen Python, bij mij is een indent level 1 tab die gerenderd wordt als 3 spaties (of naar gelieve de instellingen van andere gebruikers).

Talen die dat niet doen lopen gewoon het risico op dit soort bugs

Gewoon altijd accolades gebruiken. Altijd... ALTIJD!

[supersnathan94]

Standaard is het echter wel gewoon vier. Als je IDLE gebruikt kan je het naar wens instellen, maar out of the box worden vier spaties gebruikt. Uiteraard is dit eigenlijk meer een handigheid dan dat het ook daadwerkelijk nuttig is aangezien ik liever gewoon 1 spatie per indent heb. Zit nu met netbeans te klooien dat ik soms 15 keer op backspace moet rammen om een foutieve enter recht te zetten.

En inderdaad. Altijd acolades ed gebruiken. En fatsoenlijk commentaar toevoegen aan je functies.

[BikkelZ]

Het gaat er om of die accolades danwel een build error bij dead code afgedwongen wordt of niet. Python doet het gewoon standaard goed, veel andere talen hebben de ondersteuning van een IDE nodig. Ik geloof dat als je religieus JSLint gebruikt je zelfs bij JavaScript nog wel redelijk ver komt, maar dan moet je wel een soort integrated build achtig systeem gebruiken na een code checkin om het af te vangen.

[BikkelZ]

Je kunt óf tabs óf spaties gebruiken maar niet door elkaar. Hoe je een tab rendert moet je zelf weten. Het enige wat zeker is in Python is dat het altijd consistent is.

[OkselFris]

Er waren al nieuws sites die zich dit weekend afvroegen waar de OSX patch bleef. Je kon er direct al vanuit gaan dat Apple dit in de Mavericks update 10.9.2 mee zou nemen, gezien die ook al redelijk dicht voor een release stond.
10.9.2 is toch voor velen een lang verwachte en welkome update.

Nu hopen dat 10.9.2 ook de Wifi issues oplost. Op mijn Macbook geen probleem maar op mijn iMac is Wifi nogal wispelturig met Mavericks.
En gaaf... nu ook Facetime audio en wissel gesprekken op de Mac. ;-)

[Keypunchie]

Vind het niet netjes van Apple dat ze gewacht hebben met patchen om hem in de grotere update te integreren.

Snap de gedachte wel "ze zijn al zo lang kwetsbaar, dan maken 2 a 3 dagen ook niet uit", maar dat is niet de manier om met security om te gaan.

Voor mijn part hadden ze dan voor de vorm zelfs 10.9.2 nog een week later kunnen uitbrengen, zodat je niet 2 dagen achter elkaar zit te updaten.

[CyBeR]

Ik denk niet dat je begrijpt hoe software het release proces bij grote bedrijven werkt. Die update zat waarschijnlijk al in 10.9.2 voordat de hele heisa bekend werd.

[Keypunchie]

Leuk dat je me beschuldigt dat ik niet weet hoe bij grote bedrijven release-processen werken, zonder daar ook maar een argument voor aan te dragen.

Maar als je dit beweert heb je absoluut niet opgelet de afgelopen dagen. Apple is overvallen door de openbaring van deze bug en had het _per direct_ zodra hij publiek ging hem moeten fixen in een losse release. (Net zoals op iPhone)

Al zat de fix in 10.9.2, dan is precies mijn argument dat ze dus niet op 10.9.2 hadden moeten wachten. Maar gelukkig kun je argumentloos roepen dat iemand iets niet begrijpt, in plaats van te lezen wat hij zegt.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 12:19]

[Anoniem: 390382]

Ik heb anders geheel geen WIFI probleem onder Mavericks. iMac niet, en Macbook Air niet. Dit in tegenstelling tot de eerste versie van Lion. Ik heb wel alles op 5GHz draaien en maak ik gebruik van de vorige generatie Apple Time Capsule.
FaceTime en wisselgesprek ga ik eens testen.

[OkselFris]

Nee het doet zich schijnbaar in bepaalde gevallen voor. Ik zie er op de Apple forums wel meer vragen over. Ik heb een iMac 2011 met de nieuwste generatie Timecapsule en heb onder Mavericks toch wel eens last van een wegvallende Wifi verbinding. Het valt mij op dat dit gebeurt wanneer er een backup wordt gemaakt. Misschien is het een combinatie van.
Macbook draait als een zonnetje en geen problemen.

[Hazewinkel1989]

Voor mij is dit weer een reden om niet meteen te upgraden naar een nieuw OS, ook al is het gratis. Ik draai nu nog 10.8.5 omdat het stabiel draait en de meeste bugs al zijn verholpen. ik heb ook nog een lange tijd 10.6 Snow Leopard gedraaid omdat ook die snel en stabiel was, en ben niet meteen overgestapt op 10.7 Lion. In mijn ervaring is het dus een goede tip om even te wachten met upgraden.

Zoals ik mij het kan herinneren (ik kan het mis hebben!) wil Apple ieder jaar een nieuwe OSX versie op de markt brengen. Ik ben hier geen voorstander van, problemen -zoals in dit artikel staat- komen dan veel vaker voor. Beter door ontwikkelen en een goed, vernieuwend systeem (zoals 10.6) op de markt brengen dan een half gebakken taart.

[OkselFris]

Nou dat is wel heel erg aan de voorzichtige kant. Had deze bug er dan niet ingezeten als men een jaar langer er aan had gewerkt?
Een product komt nou eenmaal met security leaks, daar is weinig tegen te doen. Foutloze software is niet realistisch.
Wie weet zit er in die versie die jij draait ook wel een ernstig lek welke niemand nog heeft gevonden. of denk je dat je met een 100% foutloos product zit te werken?
Het blijft altijd de vraag of en wanneer iemand de lek ontdekt.

Je kan inderdaad een voorzichtige upgrade strategie hanteren en inderdaad een 0 versie wordt altijd opgevolgd door een belangrijke update.
Maar je doet nu of elk probleem was opgelost als men een jaar later met Mavericks was gekomen.

Apple brengt bewust jaarlijks een nieuwe versie uit. Je zou het ook zo kunnen doen als MS het vroeger deed. een enorme upgrade in een paar jaar, dat verminderd je problemen niet, in tegendeel.
De upgrades van Apple zijn veelal wat geleidelijker en dat heeft zijn voordelen.

[Hazewinkel1989]

Als nog niemand een lek heeft gevonden is het toch product toch foutloos? Niemand kan het misbruiken tot het is gevonden.

Maar het klopt wat je zegt, "Foutloze software is niet realistisch". Toch heb ik meer vertrouwen in een al door ontwikkeld product. Ik blijf dan ook bij mijn mening dat wanneer er langer aan een product wordt gewerkt veel fouten kunnen worden voorkomen.

Misschien dat je deze vraag kan beantwoorden: Ik vraag mij namelijk af waar Apple de focus op legt als ze ieder jaar met een nieuw OS komen? Natuurlijk het nieuwste OS, maar is het dan ook niet zo dat de ondersteuning voor oudere versies eerder verloopt als er elk jaar een nieuw OS uit komt?
Er zijn immers genoeg gebruikers die niet het nieuwste systeem kunnen draaien maar nog prima uit de voeten kunnen met hun huidige Mac.

[OkselFris]

Elk jaar een nieuwe upgrade is een geleidelijker process. Nadeel van 1 maal in de zoveel jaar is dat je gebruikers plots een enorme verandering voorschotelt. Sommigen vinden dat natuurlijk prachtig maar het heeft ook flinke nadelen,alleen kunnen deze upgrades ook voor meer problemen met betrekking tot software compatibiliteit geven.
Microsoft hanteert nu vanaf Windows 8 hetzelfde principe.
Een nog belangrijker punt is dat je sneller nieuwe features bij je klanten krijgen maar het gaat allemaal wat geleidelijker.

Met Mavericks heeft Apple er juist voor gezorgd dat je dit op meer oudere systemen kan draaien. Mountain Lion was toch wat meer restricted.
In principe zou een oudere versie inderdaad wat betreft ondersteuning verlopen, maar het is maar net hoe men dat oplost. Mavericks draait nu op meer en oudere systemen en is ook nog gratis, men probeert dus klanten meer en meer gewoon mee te laten lopen in de upgrades.
Ach en er zijn dan nog steeds genoeg welke nog op een ouder OS blijven draaien omdat het niet hoeft. Ik ken ze ook welke nog op Lion of een SL draaien op een systeem van 7 jaar oud. Lekker laten draaien dacht ik zo.

[Godjira]

Goed dat deze gaten gedicht worden. Bugs zijn er in alle Operating Systems op de markt, daar zijn iOS en OSX echt geen uitzondering op. Het is wel enigszins verdacht dat het zo "stil" gepatcht wordt. Mogelijk dat Apple zich toch echt schaamt hiervoor. Ik geloof echter niet dat er zomaar meer achter zit en het dus een "backdoor" zou zijn...

[Maurits van Baerle]

Ze hebben bekend gemaakt welke producten de bug hebben. Ze hebben aangekondigd dat er een fix aan zat te komen. Ze hebben de fix gepubliceerd op hun website en via automatische updates.

Er is weinig verdachts of stil aan als je het mij vraagt...