Fragen? Antworten! Siehe auch: Alternativlos
Finde ich eine sehr gute Idee. Wünsche ich mir auch für Linux. (Danke, Leo)
Wenn das schreibend war, dann muss man das als remote exploitbar werten.
Anyway, man kann OpenBSD eine Menge vorwerfen, aber immerhin fangen sie bei sowas nicht zu verhandeln an sondern schließen alle solchen Bugs zeitnah.
Es zeigt aber, was ich schon seit längerem anmerke: Mitigations sind bestenfalls ein Werkzeug zum Verkleinern des Problems, keine Lösung für das Problem.
Update: Der Bug-Finder meint, das sei Remote Code Execution. (Danke, Volker)
post-Spectre rumors suggest that the %cr0 TS flag might not block
speculation, permitting leaking of information about FPU state
(AES keys?) across protection boundaries.Wieso würden AES-Keys in FPU-Registern liegen? Mir fällt da höchstens MMX ein, die ersten Vektorinstruktionen von Intel, bei denen sich MMX und die FPU die selben physischen Register teilen. Ansonsten wüsste ich gerade nicht. Hat jemand ne Idee?Update: Ooooh, Einsender weisen darauf hin, dass bei AES-NI die Schlüssel in den FPU-Registern liegen! Das wusste ich gar nicht. Oh wow. Das ist ja dann natürlich echt krass problematisch, wenn man das per Side Channel auslesen kann.
Update: Es handelt sich, wenn ich das richtig verstehe, um ein NUC, d.h. das Mainboard kommt von Intel. (Danke, Lars)
Hier ist DragonflyBSD dazu. Money Quote:
Unfortunately, the only mitigation possible is to remove the
kernel memory mappings from the user MMU map, which means that every single
system call and interrupt (and the related return to userland later) must
reload the MMU twice. This will add 150ns - 250ns of overhead to every
system call and interrupt. System calls usually have an overhead of only
100ns, so now it will be 250nS - 350nS of overhead on Intel CPUs.[…]
I should note that we kernel programmers have spent decades trying to
reduce system call overheads, so to be sure, we are all pretty pissed off
at Intel right now. Intel's press releases have also been HIGHLY DECEPTIVE.
[…]
These bugs (both Meltdown and Spectre) really have to be fixed in the CPUs
themselves. Meltdown is the 1000 pound gorilla. I won't be buying any new Intel chips that require the mitigation. I'm really pissed off at Intel.
OpenBSD macht drei Kreuze, dass sie zumindest auf ARM nicht betroffen sind.Und von FreeBSD hört man, dass Intel ihnen einen Tag vor Weihnachten (!) Bescheid gegeben hat. Hey, äh, Jungs, öhm, ihr müsst da mal kurz euren Code ein bisschen umschreiben!1!! Ja super!
Update: Hier ein Statement der Linux-Leute, die auch eher unzufrieden wirken.
For now, every on all operating systems, please do the following:Add undocumented "UseRoaming no" to ssh_config or use "-oUseRoaming=no" to prevent upcoming #openssh client bug CVE-2016-0777. More later.
Update: Details sind draußen. Sie sagen, es handele sich um Code im Client für ein Feature, das OpenSSH auf Server-Seite schon länger nicht mehr supported. Und es ist Post-Auth. D.h. jemand müsste den sshd durch einen Bösen ersetzt haben, oder man müsste sich per ssh zu einem unvertrauenswürdigen Server verbinden. Die Auswirkung war anscheinend ein Memory Leak, d.h. potentiell Schlüsselmaterial geleakt. Wer also per ssh Verbindungen zu sshd außerhalb seiner Kontrolle aufgenommen hat, sollte seine Client-Schlüssel mal neu machen.
Der Clou: Der Fix stammt von Keith Bostic und ist 22 Jahre alt.
I do not have enough energy in my life to clean up two poorly written crypto code bases.Immerhin signieren sie jetzt überhaupt, und zwar mit … signify. Nie gehört? Ich auch nicht. Das scheint was ad-hoc schnell selbst gehacktes zu sein. Hier ist das Argument dafür:$ wc -l *.cNun werdet ihr vielleicht sagen: hey, klingt gut, will ich haben. Wo ist der tarball?
29 crypto_api.c
143 mod_ed25519.c
327 mod_ge25519.c
806 signify.c
1305 totalSignify is 1305 *lines* of C code. and it's included in our development
platform. It is not that difficult to install, and
if you can't install it, you could always run OpenBSD in a vm to verify a
signature, it comes with openbsd.
Die Antwort: Es gibt keinen. Ich habe mir mal im Schweiße meines Angesichts die nötigen Teile aus dem OpenBSD-CVS herausgepopelt und in einen unter Linux bauenden Tarball getan. Mit dem ganzen Glue-Code sieht die Statistik schon mal gleich ganz anders aus, da sind wir dann plötzlich bei knapp 8000 Codezeilen (plus libc, natürlich).
Das baut bei mir, und ich kann damit die LibreSSL-Distribution verifizieren. Immerhin. Das ist aber natürlich immer noch voll für den Fuß, weil der public key von deren Signatur auf dem selben FTP-Server liegt wie die Daten. Wenn jemand den Tarball manipulieren kann, kann er also auch einen anderen pubkey daneben legen und keiner merkt was. Bei GnuPG gibt es ja wenigstens das Web of Trust.
Das ist der Todesstoß. Funding für OpenSSL zurückziehen, Foundation zumachen, Laden dichtmachen. Das geht ja mal gar nicht. Was für eine Frechheit. Die sollten sich schämen.
Update: Ganz so einfach ist das auch wieder nicht. Wie sich rausstellt, hat Theo sich für OpenBSD explizit geweigert, auf so eine Mailingliste aufgenommen zu werden. Ich weite das "Die sollten sich schämen" damit auf OpenBSD aus.
Nun habe ich mir für meine SSL-Library gedacht, dass ich nur auf Systemen laufen werde, bei denen es /dev/urandom oder Äquivalent gibt, und nicht versuchen werde, da selber irgendwelche Entropie-Fummeleien zu machen. Das kann eigentlich nur nach hinten losgehen.
Aaaaaaber. Ein Kumpel von mir macht SSL auf einem Rechner, der nicht am Netz hängt, und eine Smartcard mit Hardware-RNG hat. Es gibt Smartcards mit Hardware-Zufall und einem kleinen ARM drauf. Habt ihr mal darüber nachgedacht, woher der Kernel den Zufall in /dev/urandom nimmt? Dafür nimmt man so Dinge wie das Timing zwischen Netzwerkpaketen und die Rotationslatenz von Festplatten. Timing von Tastatur- und Mauseingaben. Gibt es bei Smartcards alles nicht. Auf Smartphones gibt es Eingabegeräte aber keine Festplatten und bei den Netzwerkpaketen musst du davon ausgehen, dass sie ein Angreifer schickt, um deinen Zufall vorhersagen zu können.
Das ist ein echtes Problem in der Praxis. Gerade wenn ein Gerät frisch gebootet wurde, und die ganzen Krypto-Dienste hochfahren und Zufall für temporäre Schlüssel haben wollen. In solchen Fällen ist es wichtig, dass man den Zufallszahlengenerator irgendwie mit echtem Zufall seeden kann. Auch auf Servern mit SSD ist das ein Problem, wenn da keine Eingaben per Maus und Tastatur kommen.
Unter Linux kann man dafür einfach Daten nach /dev/random schreiben. Unter Windows gibt es zwar auch einen RNG in CryptoAPI, aber es gibt keinen Weg, da Zufall reinzuseeden. Die Sache mit dem Bildschirm-Auslesen ist natürlich echt ein Kracher. Aber da einfach die Möglichkeit wegzunehmen, externen Zufall reinzupipen, das macht LibreSSL für viele Anwendungen kaputt.
Übrigens, sowas wie ~/.rng kommt als Idee daher, dass man beim Runterfahren Entropie aus dem Pool ins Filesystem schreibt, damit man nach dem nächsten Hochfahren gute Entropie hat, wenn man ihn braucht. Das ist nicht per se eine doofe Idee.
Was ich sagen will: LibreSSL schießt sich hier gerade ziemlich massiv in den Fuß. Das sollte man dann auch erst mal ein paar Jahre aufhängen und reifen lassen, bevor man das einsetzen kann. Schade eigentlich.
Update: Mich weist gerade jemand darauf hin, dass das unter Windows doch auch geht.
Do not feed RSA private key information to the random subsystem asÄh ja, die Frage stellt sich. Ich stelle mir das ungefähr so vor:
entropy. It might be fed to a pluggable random subsystem….What were they thinking?!
Hey, Cheffe, wir brauchen hier mal Entropie für den Zufallszahlengenerator!Was sagst du? Krypto-Schlüssel haben eine hohe Entropie?
OK, Cheffe, knorke, wird gemacht!
m(
spray the apps directory with anti-VMS napalm.
so that its lovecraftian horror is not forever lost, i reproduce below
a comment from the deleted code.
/* 2011-03-22 SMS.
* If we have 32-bit pointers everywhere, then we're safe, and
* we bypass this mess, as on non-VMS systems. (See ARGV,
* above.)
* Problem 1: Compaq/HP C before V7.3 always used 32-bit
* pointers for argv[].
* Fix 1: For a 32-bit argv[], when we're using 64-bit pointers
* everywhere else, we always allocate and use a 64-bit
* duplicate of argv[].
* Problem 2: Compaq/HP C V7.3 (Alpha, IA64) before ECO1 failed
* to NULL-terminate a 64-bit argv[]. (As this was written, the
* compiler ECO was available only on IA64.)
* Fix 2: Unless advised not to (VMS_TRUST_ARGV), we test a
* 64-bit argv[argc] for NULL, and, if necessary, use a
* (properly) NULL-terminated (64-bit) duplicate of argv[].
* The same code is used in either case to duplicate argv[].
* Some of these decisions could be handled in preprocessing,
* but the code tends to get even uglier, and the penalty for
* deciding at compile- or run-time is tiny.
*/
Da ist man auch als Atheist versucht, nach dem Weihwasser zu greifen.
OpenBSD hat einen Audit angestoßen und der zeitigt erste Ergebnisse.
Und nicht zuletzt: Coverity, einer der bekannteren Code-Scanner, der hat Heartbleed nicht erkannt. Der Firma ist das einigermaßen peinlich, daher haben sie jetzt nach Heuristiken gesucht, um sowas doch zu finden, und dabei hatten sie eine relativ smarte Idee: Endianness-Konvertierung markiert bei denen jetzt Variablen als vergiftet. So gehen Code-Auditoren wie ich auch vor.
Ich habe die Tage erfreut festgestellt, dass PolarSSL auch ECDSA kann inzwischen, EDH eh schon, und jetzt auch GCM. Damit haben sie soweit alle wichtigen Features. Auf Client-Seite ist die Zertifikats-Validierung wohl noch nicht so toll, ich verlinkte neulich die Frankencert-Tabelle. Aber das ist ja serverseitig wurscht, außer man will Client Certs haben, was so gut wie niemand tut. Das ist neben OpenSSL die andere unterstützte SSL-Engine in gatling und von der Codequalität her macht sie einen ganz guten Eindruck. Viel kleiner und ordentlicher und weniger Makrohölle als OpenSSL. Klein genug, dass eine Einzelperson davon realistisch einen Komplett-Audit machen könnte.
Das ist so das widerlichste Verhalten, das man sich überhaupt denken kann.
Log message:
Disable Segglemann's RFC520 hearbeat.I am completely blown away that the same IETF that cannot efficiently
allocate needed protocol, service numbers, or other such things when
they are needed, can so quickly and easily rubber stamp the addition
of a 64K Covert Channel in a critical protocol. The organization
should look at itself very carefully, find out how this this happened,
and everyone who allowed this to happen on their watch should be
evicted from the decision making process. IETF, I don't trust you.
Ich erwähne das, weil das aus meiner Sicht der Grund ist, wieso dieser Code es bis in OpenSSL geschafft hat. Wenn jemand da den reinkommenden Code auditiert, guckt der nach den hochriskanten Bugs. Und nach der langläufigen Einschätzung, die so bei Entwicklern vertreten wird, ist out of bounds read halt viel weniger riskant als andere Bug-Klassen. Ich kann mir gut vorstellen, dass der Auditor einfach nicht nach der Art von Bug geguckt hat. Der hat memcpy gesehen, und hat dann kurz geprüft, dass vorher genug alloziert wurde und das keinen Buffer Overflow gibt, und dann hat der das durchgewunken.
Normalerweise ist es nur meine Aufgabe, Bugs zu finden. Ich bin nicht dafür zuständig, dass die auch gefixt werden. Aber trotzdem kriege ich natürlich regelmäßig mit, wenn die Entwickler dann Bugs schließen, weil sie das Risiko für zu gering halten. Wenn es mal organisatorische Zwänge gibt, dass Bugs gefixt werden müssen, beziehen die sich normalerweise nur auf "wichtige" Bugs wie Buffer Overflows. Und auch da kommt es häufiger vor, dass Entwickler sich weigern, sowas zu fixen, wenn man ihnen keinen Exploit zeigt.
Wenn ich meine Zeit damit verbringe, einen Exploit zu schreiben, finde ich aber keine Bugs in der Zeit. Daher wird das im Normalfall nicht passieren. Wenn Entwickler einen Exploit sehen wollen, geht es nicht um den Bug, sondern das ist der Versuch, den Bug loszuwerden, ohne ihn fixen zu müssen, indem der Gegenseite eine massive Bringschuld aufgebürdet wird. Schon der Einspruch des Entwicklers kostet ihn (mich sowieso) im Allgemeinen deutlich mehr Aufwand, als das Fixen des Bugs gekostet hätte.
Warum schreibe ich das hier alles? Weil ich darauf hinweisen möchte, dass das System im Moment kaputt ist. Die Perspektive von Entwicklern auf Bugs müsste sein: You file it, we fix it. Und zwar sofort. Keine Rückfragen, kein Gezeter, kein Prokrastinieren. Alle Bugs werden sofort gefixt. Wir reden ja hier von professionellen Entwicklern. Die kriegen Geld dafür, ordentlichen Code zu schreiben. Wenn es da einen Defekt gibt, wird der sofort gefixt. Fertig. Und zwar unabhängig davon, ob das jetzt ein Security-Problem ist oder "nur" Defense in Depth. Egal ob man das Szenario für realistisch hält oder nicht.
Einige Firmen haben das mit Incentive-Programmen herbeizuführen versucht. Sowas wie "es gibt Bonus, wenn man höchstens soundsoviele Bugs hat". Das führt leider dazu, dass einige Entwickler einfach alle einkommenden Bugs sofort als ungültig schließen, damit sie nicht in die Statistik gelangen. So einfach ist es halt nicht.
Und bei Open Source ist das natürlich noch mal schwieriger, Qualitätsstandards einzuhalten, wenn du niemandem damit drohen kannst, dass er gefeuert wird, wenn er sich nicht zusammenreißt.
Ein technisches Detail habe ich noch. OpenSSL hat seinen eigenen Allokator gebaut. Theo de Raadt (der Mann hinter OpenBSD) regt sich schön darüber auf, erwähnt aber nur die halbe Problematik. Eigentlich nur ein Viertel. Der Grund, wieso OpenSSL einen eigenen Allokator gebaut hat, ist — so vermute ich jedenfalls — OpenBSD. OpenBSD scheißt auf Performance und macht ihr malloc dafür richtig doll langsam. Auf der Plus-Seite segfaultet das dann sofort, wenn jemand was falsch macht. Kann man vertreten, aber dann sieht das halt in Benchmarks so aus, als sei OpenSSL furchtbar langsam. OpenSSL hatte jetzt zwei Möglichkeiten. Sie hätten mal ihren Code entkernen können, damit der nicht so viel malloc und free aufruft. Das wäre die gute Variante gewesen. OpenSSL hat aber lieber getrickst und sich einen eigenen Allokator gebaut und damit, wie Theo kritisiert, die Sicherheitsvorteile des OpenBSD-Allokators aufgegeben.
Die andere Hälfte der Medaille ist, dass der OpenSSL-Allokator vom System größere Blöcke Speicher anfordert, und dann innerhalb von denen selber fummelt. Das heißt aber, wenn ich jetzt 64k Speicher leaken kann, die aus einem dieser Blöcke kommen, dass da nur OpenSSL-Daten drin sind. Keine anderen Daten, die jemand anderes im Prozess alloziert hat. Das ist es, was diesen Bug so tödlich macht. Ihr habt vielleicht die Speicherdumps gesehen, die gerade so rumfliegen. Das ist der Grund, wieso da immer gleich so saftige Daten drinstehen wie unverschlüsselte HTTP-Dumps mit den Cookies und Passwörtern.
Update: Einen noch. Ich kriege hier gerade von einigen Leuten Flak, weil ich den Namen des Entwicklers gebloggt habe. Als ob der vorher nicht dran gestanden hätte an dem git-Checkout. Ist das legitim, den als Schuldigen zu nennen? Ich finde: Ja. Denn die Entwickler müssen endlich chirurgisch von der Idee befreit werden, dass Fehler halt unvermeidbar sind, und daher ist das nicht so wichtig, dass ich hier ordentlich arbeite. Es geht hier nicht um Shaming, sondern darum, dass alle sehen: Das hat ein Typ wie du und ich geschrieben, und hier hat ein anderer Typ wie du und ich das durchgewunken. Wenn die das falsch machen, muss ich vielleicht auch mein Verhalten ändern? Ja, müssen wir. Alle von uns.
Wir reden hier von einer der zentralen Sicherheits-Komponenten auf der Welt. Es ist völlig unakzeptabel, dass so ein Ranz-Code bei OpenSSL submitted wird. Es ist auch völlig unakzeptabel, dass OpenSSL das dann nicht merkt und diesen Ranz-Code eingecheckt hat. Und es ist völlig unakzeptabel, dass diese Tretmine da jetzt seit Jahren in der Codebasis herumgammelte, und es keiner gemerkt hat. Wir haben hier ein massives Prozess-Problem, und dem müssen wir uns stellen. Das hat mit Shaming nichts zu tun. Millionen von Menschen verlassen sich auf diese Software. Da checkt man nicht mal eben kurz was ein, wird schon gutgehen. Die Wartung von OpenSSL sollte mit einer ähnlichen Verantwortung verbunden sein wie das Warten von Flugzeugen oder Atomkraftwerken. Wir haben schlicht keine Entschuldigungen dafür, dass es soweit kommen konnte.
Natürlich konnte ich auch an dem T-Systems-Joke nicht vorbeigehen, das seht ihr sicher ein. :-)
Hat nicht auch Apple ihren IP-Stack von *BSD "geborgt"?
Update: Bei FreeBSD ist das seit 2007 gefixt. Insofern sind nicht alle BSDs gleich schlecht, das ist besonderes OpenBSD-Versagen. Aber was kann man schon von solchen Leuten hier erwarten.
Hier hat jemand nachgefragt und eine Bestätigung bekommen, dass die Email zumindest echt ist.
Update: Die ersten Leute fühlen sich angesprochen und dementieren.
Assorted improvements and code cleanup:- […]
- TCP responses to highly fragmented packets are now constructed without risking corruption of kernel memory.
Äh, huh? Das klingt für mich wie ein remote kernel exploit, mindestens DoS, wenn nicht code execution. Und das tun die unter "code cleanup" ganz ans Ende?!
most chips support parallel operations. we [sic] cant [sic] do that cos [sic] of kernel lockingEs ist ihnen offenbar auch selber ein bißchen peinlich, wie schlecht sie performen, und so kommt dann dieser Rohdiamant als Zitat:our network stack is not optimized for single fast tcp streams (but very safe)Oh, der stack ist nicht optimiert? Habt ihr das ganz alleine rausgefunden? Im Übrigen meint Henning glaube ich "secure", nicht "safe". Henning ist glaube ich nicht so dämlich wie er hier mit seinem Analphabeten-Englisch rüber kommt, aber man kann es von außen schlecht sagen, weil sein unerträgliches Ego es unmöglich macht, sich mit ihm oder seiner Arbeit länger als 10 Minuten zu beschäftigen. Aber hey, dafür haben wir ja Folien wie diese.Oh, und wenn ihr mal das Bullshit-Meter auf Anschlag bringen wollt: lest die hanebüchenen Ausflüchte, wieso sie die Offload-Engines nicht nutzen wollen. Unglaublich. Für wie blöd halten die ihr Publikum?
Immerhin ist es nicht so, dass sie GAR nichts erreicht haben. pf auf loopback haben sie von 700 mbit auf 900 mbit aufgebohrt. Und lauter so Klopper, hier noch einer:
"dlg did some profiling, because his 10G card was so slow, and spottet the kernel randomness pool stirring from the network stack was a major hit"HAHAHAHAHA! Aber hey, nicht nur der IP-Stack ist bei OpenBSD Dreck, auch das hochgepriesene CARP ist eher eine Lachnummer. (Danke, Ilja)
Danach hab es von Honk einen Vortrag über seine Erfahrungen mit Security-Audits in der Kreditkartenindustrie, und da waren eine echte Schenkelklopfer dabei. Tja, Schadenfreude ist doch die schönste Freude.
Den Lawrence Lessig Talk habe ich mir gespart, da war ich mit ein paar alten Kumpels essen. Ich hätte mir sonst vermutlich den PocketPC-Talk angehört.
Im nächsten Slot lagen sehr unglücklich "Automated Exploit Detection in Binaries" von einem mir vorher Unbekannten, "Pornography and Technology" von Tina, "Sie haben das Recht zu schweigen" von Udo "lawblog.de" Vetter und "Rootkits as Reversing Tools" von einem anonymen Vortragenden parallel. Jeden davon hätte ich gerne gesehen, aber ich bin am Ende zu der Exploit Detection gegangen. War ein Fehler. Das Konzept ist, Binaries zu disassemblieren, Basic Blocks hinterher zu laufen, über Wertebereiche Buch zu führen, und dann Schreibzugriffe von vergifteten (vom Angreifer kontrollierbaren) Daten außerhalb des gültigen Buffers. Klang alles nach Star Trek, und statt einer Vorführung gab es den Hinweis auf irgendwelche Sourceforge-Sachen und einen Exploit in Trillian, den sie offenbar unabhängig gefunden haben. Nicht beeindruckend.
Das lustige an dem 4. Vortrag war, daß der Vortragende gar nicht körperlich anwesend war, sondern per VoIP und TOR-Tunnel vortragen wollte. Ob das geklappt hat weiß ich nicht, aber das finde ich einen enorm coolen Stunt.
Am Abend lagen dann wieder drei coole Dinge nebeneinander, "Hacker Jeopardy" (da mußte ich meinen Titel verteidigen), "Powerpoint Karaoke" (dort war ich verpflichtet worden), und "Schlossöffnung bei der Staatssicherheit der DDR" (hätte ich auch brennend interessiert). Ich bin dann anfangs zum Karaoke gegangen, habe dort eine absolut furchtbare Foliensammlung gekriegt, und bin mit wehenden Fahnen untergegangen bei der Präsentation :-) Es ging offenbar um Zitate aus einem Buch (jeweils ein Satz oder Satzfragment, sowas wie "Anton errötete alsdann jungenhaft" und darunter ein Bild, das mit dem Zitat darüber so gut wie keinen Zusammenhang hatte. Es gab auch keinen roten Faden, keine tatsächliche Aussage, und so gelang es mir nicht, da sonderlich viel raus zu holen.
Dann wurde ich rausgewunken aus dem Raum und mußte zu Hacker Jeopardy rüber, das dieses Jahr auch in Englisch gehalten wurde. Zur Begeisterung des Publikums gab es eine Kategorie "Things Fefe Doesn't Know", mit furchtbaren Fragen wie welche DECT-Nummer man anrufen muss, um das Labyrinth zu kriegen (ich habe kein DECT-Phone und bin mit genau dieser Frage schon letztes Jahr baden gegangen), welche Tastenkombination auf einer Apple-Tastatur das @-Zeichen ergibt (WTF?!), was Windows-Taste+D tut (?!?) und noch zwei Fragen aus dieser Kategorie. Ich war zu dem Zeitpunkt eh unter Einfluß von Wodka (den sie uns beim Karaoke zur Auflockerung gegeben hatten) und vom Schlafentzug verlangsamt, und habe so ziemlich versagt, konnte kaum was beantworten. Eine Kategorie war ASCII-Ports, da haben sie dann sowas wie "n" gehabt, man mußte dazu den ASCII-Wert wissen (110), und dann "Was ist POP3?" fragen. Kann ich gar nicht, denn in C kann man sowas wie return i-'a' schreiben, da muss man keinen Integer-Wert nachgucken. Nicht nur das, bei vielen Ports hätte ich nicht mal mit der richtigen Umrechnung den Dienst dazu gewußt :-)
In der Mitte des Jeopardy stand es dann -500, 0, -200, 0 (die letzte 0 war ich, der ich noch nichts hatte beantworten können), und ich wollte mich schon entspannt zurück lehnen, und mal die anderen gewinnen lassen. Ein bißchen Gegenwehr wollte ich aber schon simulieren, und so habe ich zwei Fragen beantwortet, hatte dann 500 Punkte, und es waren als letzte Felder die 100-400 Fragen von "Things Fefe Doesn't Know" frei. Ich wußte in der Tat keine einzige der Sachen aus der Kategorien, aber die anderen auch nicht. Und die fühlten sich offenbar genötigt, da dann lieber was zu riskieren und falsch zu antworten, wodurch ich am Ende doch noch gewonnen habe. Meine Siegprämie war eine große Flasche Humppa-Bier und ein Plüsch-Puffy, über den sich mein Jüngster freuen wird.
Ich hatte noch auf dem Gang ein lustiges Gespräch mit Wim, der meinte, man könnte ja zu FreeBSD nicht mehr Free sagen, weil sie so viele BLOBs im Kernel haben, und daher würden die OpenBSDler sie jetzt Ersatz-FreeBSD nennen :-) Hach ja, friendly fire wärmt einem doch das Herz zur Winterzeit…
Morgen früh haben sie den armen Ilja um 11:30 in den Saal 1 gelegt, hoffentlich ist der um die Zeit schon wach. Guckt euch das mal an, er hat mir schon mal verraten, daß es einen schönen OpenBSD-0day gibt.
Auf der anderen Seite muss man sich bei der Entwicklung von freier Software im Klaren sein, daß man da kein Geld für kriegt, außer man findet ein Modell, bei dem man schon für die Entwicklung bezahlt wird. Ich habe mich ein paar Mal von Firmen einstellen lassen, die dann sogar wollten, daß ein bestimmtes Projekt weiter entwickelt wird in der Zeit, oder die aktiv einverstanden damit waren, daß ich da Zeit investiere. So muss das m.E. laufen. Goldgräber-Geschäftsmodelle, wo alle darben und einer von 100000 dann einen Millionen-Payout kriegt, sind scheiße. Lieber jeden der 100000 überleben lassen und keiner wird superreich.
Aber, um das mal ganz klar zu sagen: Die OpenBSD-Leute haben Spenden verdient.
