OpenSource en het fixen van bugs..

[Martijn van Buul]

Een bijzonder pijnlijk bewijs van het ongelijk van de stelling dat Open
Source wezen per definitie winst oplevert:

http://lists.debian.org/debian-security-announce/2008/msg00152.html

Zie vooral ook het commentaar op

http://www.links.org/?p=327

En dat allemaal omdat Debian een "bug" "fixt".

[Fred Mobach]

Post by Martijn van Buul
Een bijzonder pijnlijk bewijs van het ongelijk van de stelling dat
http://lists.debian.org/debian-security-announce/2008/msg00152.html

Nu nog even aantonen dat Closed Source Software het beter doet en je
hebt een punt.

Het is niet zonder reden dat we hier nog steeds niet Debian willen
inzetten in een productie omgeving. Ofschoon ik nog steeds twijfel heb
bij welke distributeur dan ook. ;-)

[unknown]

Post by Fred Mobach

Post by Martijn van Buul
Een bijzonder pijnlijk bewijs van het ongelijk van de stelling dat
http://lists.debian.org/debian-security-announce/2008/msg00152.html

Nu nog even aantonen dat Closed Source Software het beter doet en je
hebt een punt.

Alleen Debian bevat deze specifieke bug. Alle CSS die van de 'stock'
OpenSSL gebruik maakt is dus niet aangetast door deze bug en doet het op
het vlak van het seeden van de RNG dus beter.

[Jeroen Beerstra]

Post by unknown

Post by Fred Mobach

Post by Martijn van Buul
Een bijzonder pijnlijk bewijs van het ongelijk van de stelling dat
http://lists.debian.org/debian-security-announce/2008/msg00152.html

Nu nog even aantonen dat Closed Source Software het beter doet en je
hebt een punt.

Alleen Debian bevat deze specifieke bug. Alle CSS die van de 'stock'
OpenSSL gebruik maakt is dus niet aangetast door deze bug en doet het op
het vlak van het seeden van de RNG dus beter.

En alle OSS die van de 'stock' OpenSSL gebruikt maakt ook, slecht voorbeeld
dus. 't Lijkt me trouwens ook niet makkelijk om aan te tonen dat dit soort
genante problemen *niet* met CSS kunnen optreden en juist wel met (F)OSS.
Wel dat het net zo goed kan met CSS, daar heb je maar 1 voorbeeld voor
nodig.

Je kunt hooguit stellen dat bij FOSS elke oen kan meedoen en dat dat dus in
het ergste geval dit soort gevolgen heeft, maar aan de andere kant is er
geen enkele reden dat CSS domme fouten uit zou sluiten, dus daar kan het
net zo goed.

Denk dat dit alles meer aantoont dat je er maar beter een goede ontwikkel
structuur op na kunt houden. In elk geval met peer review of beter nog een
zekere hierarchie, CSS of OSS! Zo kun je er bijvoorbeeld vanuit gaan dat
bij een vanilla Linux kernel een patch niet zonder meer wordt toegevoegd.

[unknown]

Post by Jeroen Beerstra

Post by unknown

Post by Fred Mobach

Post by Martijn van Buul
Een bijzonder pijnlijk bewijs van het ongelijk van de stelling dat
http://lists.debian.org/debian-security-announce/2008/msg00152.html

Nu nog even aantonen dat Closed Source Software het beter doet en je
hebt een punt.

Alleen Debian bevat deze specifieke bug. Alle CSS die van de 'stock'
OpenSSL gebruik maakt is dus niet aangetast door deze bug en doet het
op het vlak van het seeden van de RNG dus beter.

En alle OSS die van de 'stock' OpenSSL gebruikt maakt ook, slecht
voorbeeld dus.

Ik zie niet in waarom het een slecht voorbeeld is, ik toon het punt aan
waarnaar gevraagd wordt.

Wellicht had ik er nog even een disclaimer onder moeten zetten dat het
natuurlijk flauwekul is om de ernst van deze bug af te laten wegen door
te kijken naar CSS. Alsof OSS geen bestaansrecht heeft zonder CSS.

[richard lucassen]

On Tue, 13 May 2008 21:14:37 +0200

Post by Fred Mobach

Post by Martijn van Buul
Een bijzonder pijnlijk bewijs van het ongelijk van de stelling dat
http://lists.debian.org/debian-security-announce/2008/msg00152.html

Nu nog even aantonen dat Closed Source Software het beter doet en je
hebt een punt.
Het is niet zonder reden dat we hier nog steeds niet Debian willen
inzetten in een productie omgeving. Ofschoon ik nog steeds twijfel heb
bij welke distributeur dan ook. ;-)

Gelukkig maar dat de diverse distro's met hun vingers van de kernel
afblijven en gewoon met de vanilla versie in zee gaan. Ze zouden zomaar
een distro-specifieke bug erin kunnen "fixen".
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Martijn van Buul]

Post by richard lucassen
Gelukkig maar dat de diverse distro's met hun vingers van de kernel
afblijven

Deden ze dat maar.

[richard lucassen]

On Tue, 13 May 2008 20:00:23 +0000 (UTC)

Post by Martijn van Buul

Post by richard lucassen
Gelukkig maar dat de diverse distro's met hun vingers van de kernel
afblijven

Deden ze dat maar.

Ik was ook ietwat cynisch ;-)

En zoals toch wel licht gesuggereerd is zoiets echt niet Debian
specifiek want ik zie bij de changelogs van de vanilla versies
toch regelmatig de zin "this bug was introduced in version ${version}".

Om nog maar te zwijgen van van het feit dat bij OSS het euvel toch maar
even duidelijk aan het licht gebracht kan worden terwijl zoiets bij CSS
toch ook wel weer heel gemakkelijk onder een heel dik tapijt geschoven
kan worden.

Dus wellicht toch winst voor OSS?
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[unknown]

Post by richard lucassen
Om nog maar te zwijgen van van het feit dat bij OSS het euvel toch
maar even duidelijk aan het licht gebracht kan worden terwijl zoiets
bij CSS toch ook wel weer heel gemakkelijk onder een heel dik tapijt
geschoven kan worden.

Als die lastige onderzoeker deze bug niet had gevonden had Debian ook
stilletjes een nieuwe versie van haar OpenSSL-fork kunnen uitbrengen
waarin de bewuste bug gefixt was. En waarschijnlijk op zo'n manier dat
niemand er argwaan in zou krijgen.

Toegang tot broncode is nuttig om op te sporen waardoor een
veiligheidsprobleem veroorzaakt wordt, maar is meestal niet nodig om een
veiligheidsprobleem te kunnen detecteren.

Vandaar ook dat veiligheidslijsten over het algemeen ook een flinke
dosis CSS-vulnerabilities bevatten.

[richard lucassen]

On 14 May 2008 05:59:14 GMT

Post by unknown

Post by richard lucassen
Om nog maar te zwijgen van van het feit dat bij OSS het euvel toch
maar even duidelijk aan het licht gebracht kan worden terwijl zoiets
bij CSS toch ook wel weer heel gemakkelijk onder een heel dik tapijt
geschoven kan worden.

Als die lastige onderzoeker deze bug niet had gevonden had Debian ook
stilletjes een nieuwe versie van haar OpenSSL-fork kunnen uitbrengen
waarin de bewuste bug gefixt was. En waarschijnlijk op zo'n manier dat
niemand er argwaan in zou krijgen.

Maar t.o.v. CSS wel zichtbaar uiteindelijk.

Post by unknown
Toegang tot broncode is nuttig om op te sporen waardoor een
veiligheidsprobleem veroorzaakt wordt, maar is meestal niet nodig om
een veiligheidsprobleem te kunnen detecteren.
Vandaar ook dat veiligheidslijsten over het algemeen ook een flinke
dosis CSS-vulnerabilities bevatten.

Uiteraard. Maar ik beweer ook niet dat OSS heilig en zonder
vulnerabilities is, maar men heeft niet de mogelijkheid zoals bij CSS
fouten of andere kwaadaardige code te verbergen.

Beter goede kwaliteit CSS dan troep OSS (en er is heel veel troep onder
OSS)

R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[unknown]

Post by richard lucassen
On 14 May 2008 05:59:14 GMT

Post by unknown

Post by richard lucassen
Om nog maar te zwijgen van van het feit dat bij OSS het euvel toch
maar even duidelijk aan het licht gebracht kan worden terwijl
zoiets bij CSS toch ook wel weer heel gemakkelijk onder een heel
dik tapijt geschoven kan worden.

Als die lastige onderzoeker deze bug niet had gevonden had Debian ook
stilletjes een nieuwe versie van haar OpenSSL-fork kunnen uitbrengen
waarin de bewuste bug gefixt was. En waarschijnlijk op zo'n manier
dat niemand er argwaan in zou krijgen.

Maar t.o.v. CSS wel zichtbaar uiteindelijk.

Dat is zo, maar de introductie van de bug in de Debian-fork was ook
zichtbaar. Toch heeft het een hele tijd geduurd alvorens iemand er
achter kwam wat die 'gefixte' code nou precies deed, en mijn vermoeden
is dat de bug niet is ontdekt tijdens het doorbladeren van code maar
door blackbox testen van gegenereerde sleutels o.i.d.

Post by richard lucassen

Post by unknown
Toegang tot broncode is nuttig om op te sporen waardoor een
veiligheidsprobleem veroorzaakt wordt, maar is meestal niet nodig om
een veiligheidsprobleem te kunnen detecteren.
Vandaar ook dat veiligheidslijsten over het algemeen ook een flinke
dosis CSS-vulnerabilities bevatten.

Uiteraard. Maar ik beweer ook niet dat OSS heilig en zonder
vulnerabilities is, maar men heeft niet de mogelijkheid zoals bij CSS
fouten of andere kwaadaardige code te verbergen.

Misschien niet verbergen in theoretische zin, maar in praktische zin kan
het best. Bijvoorbeeld door de foute code te vervangen door 10KLOC aan
nieuwe code.

[richard lucassen]

On 14 May 2008 15:07:17 GMT

Post by unknown

Post by richard lucassen
Maar t.o.v. CSS wel zichtbaar uiteindelijk.

Dat is zo, maar de introductie van de bug in de Debian-fork was ook
zichtbaar. Toch heeft het een hele tijd geduurd alvorens iemand er
achter kwam wat die 'gefixte' code nou precies deed, en mijn vermoeden
is dat de bug niet is ontdekt tijdens het doorbladeren van code maar
door blackbox testen van gegenereerde sleutels o.i.d.

Ongetwijfeld, maar ik zou er echt niet m'n kop onder durven te verwedden
dat er in de laatste kernel geen remote exploitable vulnerability zit.
Dat wordt meestal bij toeval gevonden. Net zoals deze "fix" vermoed ik.

Er wordt nu trouwens een package "openssh-blacklist" meegeleverd die je
hostkeys van ssh test. Is-ie niet goed dan wordt er een nieuwe
gegenereerd.

Post by unknown

Post by richard lucassen
Uiteraard. Maar ik beweer ook niet dat OSS heilig en zonder
vulnerabilities is, maar men heeft niet de mogelijkheid zoals bij
CSS fouten of andere kwaadaardige code te verbergen.

Misschien niet verbergen in theoretische zin, maar in praktische zin
kan het best. Bijvoorbeeld door de foute code te vervangen door 10KLOC
aan nieuwe code.

Ok, maar de kernel source zal er echt niet veel groter door worden ;-)
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[unknown]

Post by richard lucassen
On 14 May 2008 15:07:17 GMT

Post by unknown

Post by richard lucassen
Maar t.o.v. CSS wel zichtbaar uiteindelijk.

Dat is zo, maar de introductie van de bug in de Debian-fork was ook
zichtbaar. Toch heeft het een hele tijd geduurd alvorens iemand er
achter kwam wat die 'gefixte' code nou precies deed, en mijn
vermoeden is dat de bug niet is ontdekt tijdens het doorbladeren van
code maar door blackbox testen van gegenereerde sleutels o.i.d.

Ongetwijfeld, maar ik zou er echt niet m'n kop onder durven te
verwedden dat er in de laatste kernel geen remote exploitable
vulnerability zit. Dat wordt meestal bij toeval gevonden. Net zoals
deze "fix" vermoed ik.

Ik denk dat je vermoeden klopt. Ik denk ook dat de meeste
vulnerabilities gevonden worden zonder dat er toegang tot de broncode
voor nodig is, te meer omdat een beetje zinnige programmeur tegenwoordig
z'n code test op overduidelijke bugs (...) zoals mogelijke
bufferoverflows of formatstring-attacks.

(de ironie wil dat dat juist in dit geval tot een probleem leidde: de
Debianmaintainer wilde gezeur van valgrind over uninitialized memory
oplossen en heeft zich niet gerealiseerd dat het juist de intentie was
van de OpenSSL-ontwikkelaars om dat stukje geheugen niet te
initialiseren)

[richard lucassen]

On 15 May 2008 05:38:17 GMT

Post by unknown

Post by richard lucassen
Ongetwijfeld, maar ik zou er echt niet m'n kop onder durven te
verwedden dat er in de laatste kernel geen remote exploitable
vulnerability zit. Dat wordt meestal bij toeval gevonden. Net zoals
deze "fix" vermoed ik.

Ik denk dat je vermoeden klopt. Ik denk ook dat de meeste
vulnerabilities gevonden worden zonder dat er toegang tot de broncode
voor nodig is, te meer omdat een beetje zinnige programmeur
tegenwoordig z'n code test op overduidelijke bugs (...) zoals
mogelijke bufferoverflows of formatstring-attacks.

"een beetje zinnige programmeur" wel ja. En bij OSS is nog enigzins te
zien of het "een beetje zinnige programmeur" betreft. Zoek maar eens op
het woord "fuck" in de kernel sources ;-)

Post by unknown
(de ironie wil dat dat juist in dit geval tot een probleem leidde: de
Debianmaintainer wilde gezeur van valgrind over uninitialized memory
oplossen en heeft zich niet gerealiseerd dat het juist de intentie was
van de OpenSSL-ontwikkelaars om dat stukje geheugen niet te
initialiseren)

Naar wat ik begrepen had had hij daar ook een mail voor naar de OpenSSL
developers gestuurd, maar blijkbaar had men daar zoiets van "wat
zeurt-ie nou over een paar warnings"

Ik heb de source niet bekeken (lui) maar men had er wel bij kunnen
zetten waarom dat stuk niet werd geinitilaiseerd. Een beetje zinnige
programmeur zet de source vol met commentaar IMHO, vooral als het
"special effects" betreft. Wat hier toch echt het geval was.

Maar goed, het is nu wel opgelost iig.

R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Martijn van Buul]

Post by richard lucassen
Naar wat ik begrepen had had hij daar ook een mail voor naar de OpenSSL
developers gestuurd, maar blijkbaar had men daar zoiets van "wat
zeurt-ie nou over een paar warnings"

Nee, daar gaf men zelfs toe dat de entropie van ongeinitialiseerd geheugen
vrij laag is (ik meen me zelfs te herinneren dat OpenBSD en sommige Secure
Linux smaakjes er zelfs voor zorgen dat geheugen dat aan processen wordt
uitgedeeld wordt gewist), en gaf droeg men zelfs de oplossing aan die
OpenSSL *zelf al had geimplementeerd* (compileren met -DPURIFY).

Alleen onze fijne debian maintainer sloeg *dat* advies in de wind, en ging
toch aan het patchen.

De bewuste patch staat hier:

http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c

( Klagen over de lange URL mag bij Debian; http://tinyurl.com/5mmheo )

Zijn "is het goed als ik de volgende patch doe?" mailtje naar OpenSSL
staat hier:

http://marc.info/?l=openssl-dev&m=114651085826293&w=2

De gewraakte wijziging is die op regel 247 - terwijl zijn mailtje vooral over
regel 467 gaat. Merk ook op dat de gegeven context bijzonder klein was, en
dat 'ie nergens de suggestie wekt dat die wijzigingen in een major distro
als Debian zal belanden.

Dus ja, OpenSSL heeft het niet opgemerkt, maar Debian had met zijn tengeltjes
van spullen af moeten blijven.

Post by richard lucassen
Maar goed, het is nu wel opgelost iig.

Nee, het is niet opgelost. Wat er is opgelost is dat er geen rotte keys
meer worden aangemaakt - hoop je. De rotte keys die reeds in omloop zijn
zullen wel een probleem blijven.

[richard lucassen]

On Thu, 15 May 2008 09:08:12 +0000 (UTC)

Post by Martijn van Buul
Zijn "is het goed als ik de volgende patch doe?" mailtje naar OpenSSL
http://marc.info/?l=openssl-dev&m=114651085826293&w=2
De gewraakte wijziging is die op regel 247 - terwijl zijn mailtje
vooral over regel 467 gaat. Merk ook op dat de gegeven context
bijzonder klein was, en dat 'ie nergens de suggestie wekt dat die
wijzigingen in een major distro als Debian zal belanden.
Dus ja, OpenSSL heeft het niet opgemerkt, maar Debian had met zijn
tengeltjes van spullen af moeten blijven.

Mee eens. Maar men zou zich ook druk moeten maken om al het kernel
gepatch van allerlei distro's. Want wie weet wat daar allemaal voor
rottigheid in "gefixt" wordt of juist dat er rottigheid in de vanilla
versie blijft zitten omdat de patch alleen in de "fork" zit.

Post by Martijn van Buul

Post by richard lucassen
Maar goed, het is nu wel opgelost iig.

Nee, het is niet opgelost. Wat er is opgelost is dat er geen rotte
keys meer worden aangemaakt - hoop je. De rotte keys die reeds in
omloop zijn zullen wel een probleem blijven.

Dat is en blijft een probleem. Maar er zit nu wel een tooltje bij om de
keys te checken. Maar dat is ook niet waterdicht. Dus dat betekent dus
"host keys genereren".

Mazzel dat ik SSL-certs genereer op een Sarge en een Lenny machine. Daar
speelt dat niet.

Alle Etch machines hebben inmiddels een nieuwe host-key.

Hoe was het ook alweer? "Iedere dertig regels code bevatten een
potentiele bug" of woorden van gelijke strekking.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Martijn van Buul]

Post by Fred Mobach

Post by Martijn van Buul
Een bijzonder pijnlijk bewijs van het ongelijk van de stelling dat
http://lists.debian.org/debian-security-announce/2008/msg00152.html

Nu nog even aantonen dat Closed Source Software het beter doet en je
hebt een punt.

Hoho, die vlieger gaat niet op.

Er wordt hier te pas en te onpas geroepen dat Open Source veiliger zou zijn
"want iedereen kan meekijken". *die* stelling is onzin; bovenstaand voorbeeld
toont aan dat er namelijk ook volk is waarvan je eigenlijk liever niet hebt
dat ze meekijken, want ze maken verkeerde "verbeteringen", waarvan je maar
moet hopen dat iemand anders *die* fouten weer oppakt.

Mijn weerwoord op de "van meekijken wordt alles beter" stelling is dan ook
dat voor iedere nuttige patch ten gevolge van "meekijken" er zeker zoveel
domme en foutieve patches zijn (lees: debian, dit is niet de eerste keer) of
dat er op een vrij domme en kinderachtige manier om een probleem wordt
geknutseld (lees: samba)

Dat is nochtans een andere stelling dan "Open Source is onveilig", en al
helemaal wat anders dan "Closed source is veiliger". Ik had gehoopt dat jij
die nuance wel wist te maken...

Post by Fred Mobach
Het is niet zonder reden dat we hier nog steeds niet Debian willen
inzetten in een productie omgeving. Ofschoon ik nog steeds twijfel heb
bij welke distributeur dan ook. ;-)

En die twijfel is terecht. Bij welke distributeur dan ook.

[Peter]

Post by Martijn van Buul

Post by Martijn van Buul
Een bijzonder pijnlijk bewijs van het ongelijk van de stelling dat

Wie zegt dat het "per definitie winst oplevert"?

Post by Martijn van Buul
Er wordt hier te pas en te onpas geroepen dat Open Source veiliger zou zijn
"want iedereen kan meekijken". *die* stelling is onzin; bovenstaand voorbeeld

Dit is nu toch ontdekt omdat het open source was?

-peter

[unknown]

Post by Peter

Post by Martijn van Buul
Er wordt hier te pas en te onpas geroepen dat Open Source veiliger
zou zijn "want iedereen kan meekijken". *die* stelling is onzin;
bovenstaand voorbeeld

Dit is nu toch ontdekt omdat het open source was?

Is dat een feit, een vermoeden of een vraag?

[Martijn van Buul]

Post by Peter

Post by Martijn van Buul
Er wordt hier te pas en te onpas geroepen dat Open Source veiliger zou zijn
"want iedereen kan meekijken". *die* stelling is onzin; bovenstaand voorbeeld

Dit is nu toch ontdekt omdat het open source was?

Nee, dit is *veroorzaakt* omdat het open source was, en *ontdekt* omdat iemand
tot de schrikbarende conclusie kwam dat zijn crypto waardeloos was.

[Peter]

Post by Martijn van Buul

Post by Peter

Post by Martijn van Buul
Er wordt hier te pas en te onpas geroepen dat Open Source veiliger zou zijn
"want iedereen kan meekijken". *die* stelling is onzin; bovenstaand voorbeeld

Dit is nu toch ontdekt omdat het open source was?

Nee, dit is *veroorzaakt* omdat het open source was,

Een maintainer hieeft iets fout gedaan, had'ie ook kunnen doen als de code
verder closed source was.

Post by Martijn van Buul
en *ontdekt* omdat iemand
tot de schrikbarende conclusie kwam dat zijn crypto waardeloos was.

Mijn vraag is nog steeds hoe die dat ondekte...

-peter

[Martijn van Buul]

Post by Peter

Post by Martijn van Buul

Post by Peter

Post by Martijn van Buul
Er wordt hier te pas en te onpas geroepen dat Open Source veiliger zou zijn
"want iedereen kan meekijken". *die* stelling is onzin; bovenstaand voorbeeld

Dit is nu toch ontdekt omdat het open source was?

Nee, dit is *veroorzaakt* omdat het open source was,

Een maintainer hieeft iets fout gedaan, had'ie ook kunnen doen als de code
verder closed source was.

Als het verder closed source was, had de maintainer zijn vermeende "bug"
niet kunnen fixen.

Nu heeft Debian bij mij een bijzonder slechte naam opgebouwd vanwege
eerdere "bugfixes" van hun kant. In een ver verleden heb ik ooit
debian/macppc gedraaid, en dat was voor een groot deel onbruikbaar vanwege
Debian's "fixes", waarbij compile errors op bigendian systemen onder
het kleed werden geveegd omdat het anders debian/i386 in de weg zou
zitten - inclusief het "fixen" van een probleem door het uitcommentarieren van

#error "This is known to be broken on bigendian systems"

Blijkbaar was het toen gebruikelijk om liever willens en wetens niet-werkende
software uit te leveren. Patches om het *goed* te fixen werden vervolgens
weggedonderd omdat het geen security fix voor debian/i386 zou zijn, etc.

Post by Peter

Post by Martijn van Buul
en *ontdekt* omdat iemand
tot de schrikbarende conclusie kwam dat zijn crypto waardeloos was.

Mijn vraag is nog steeds hoe die dat ondekte...

Geen idee. Waarschijnlijk door eens goed naar zijn openSSL keys te kijken.

[Peter]

Post by Martijn van Buul
Als het verder closed source was, had de maintainer zijn vermeende "bug"
niet kunnen fixen.
Nu heeft Debian bij mij een bijzonder slechte naam opgebouwd vanwege
eerdere "bugfixes" van hun kant. In een ver verleden heb ik ooit
debian/macppc gedraaid, en dat was voor een groot deel onbruikbaar vanwege
Debian's "fixes", waarbij compile errors op bigendian systemen onder
het kleed werden geveegd omdat het anders debian/i386 in de weg zou
zitten - inclusief het "fixen" van een probleem door het uitcommentarieren van
#error "This is known to be broken on bigendian systems"

Als ik het goed begrijp is dit net zo iets. Om valgrind stil te krijgen
is iets ge'fixt'. Valgrind zeurt over het gebruik van ongeinitialiseerd
geheugen, en in de debian patch is dit geheugen gereset. Dit stukje bleek
gebruikt te worden bij het genereren van de ssh sleutels, die dus na de
patch minder random zijn.

(waarom iemand zoiets in de eerste plaats zo programeert is een andere
vraag.)

Post by Martijn van Buul

Post by Peter
Mijn vraag is nog steeds hoe die dat ondekte...

Geen idee. Waarschijnlijk door eens goed naar zijn openSSL keys te kijken.

Vroeger of later horen we het (hoop ik) wel,...

-peter

[Mendel Mobach]

De wet op behoud van ellende noopte

Post by Peter

Post by Martijn van Buul
Als het verder closed source was, had de maintainer zijn vermeende "bug"
niet kunnen fixen.
Nu heeft Debian bij mij een bijzonder slechte naam opgebouwd vanwege
eerdere "bugfixes" van hun kant. In een ver verleden heb ik ooit
debian/macppc gedraaid, en dat was voor een groot deel onbruikbaar vanwege
Debian's "fixes", waarbij compile errors op bigendian systemen onder
het kleed werden geveegd omdat het anders debian/i386 in de weg zou
zitten - inclusief het "fixen" van een probleem door het uitcommentarieren van
#error "This is known to be broken on bigendian systems"

Als ik het goed begrijp is dit net zo iets. Om valgrind stil te krijgen
is iets ge'fixt'. Valgrind zeurt over het gebruik van ongeinitialiseerd
geheugen, en in de debian patch is dit geheugen gereset. Dit stukje bleek
gebruikt te worden bij het genereren van de ssh sleutels, die dus na de
patch minder random zijn.
(waarom iemand zoiets in de eerste plaats zo programeert is een andere
vraag.)

Lees http://www.links.org/?p=328

Dan snap je ook waarom het zo gecode is.....

Post by Peter

Post by Martijn van Buul

Post by Peter
Mijn vraag is nog steeds hoe die dat ondekte...

Geen idee. Waarschijnlijk door eens goed naar zijn openSSL keys te kijken.

Vroeger of later horen we het (hoop ik) wel,...

Misschien deed die gewoon diff

[Peter]

Post by Mendel Mobach

Post by Peter
(waarom iemand zoiets in de eerste plaats zo programeert is een andere
vraag.)

Lees http://www.links.org/?p=328
Dan snap je ook waarom het zo gecode is.....

Merci, dat legt een boel uit,

-peter

[Huub Reuver]

Post by Martijn van Buul

Post by Fred Mobach

Post by Martijn van Buul
Een bijzonder pijnlijk bewijs van het ongelijk van de stelling dat
http://lists.debian.org/debian-security-announce/2008/msg00152.html

Nu nog even aantonen dat Closed Source Software het beter doet en je
hebt een punt.

Hoho, die vlieger gaat niet op.
Er wordt hier te pas en te onpas geroepen dat Open Source veiliger zou zijn
"want iedereen kan meekijken". *die* stelling is onzin; bovenstaand voorbeeld
toont aan dat er namelijk ook volk is waarvan je eigenlijk liever niet hebt
dat ze meekijken, want ze maken verkeerde "verbeteringen", waarvan je maar
moet hopen dat iemand anders *die* fouten weer oppakt.
Mijn weerwoord op de "van meekijken wordt alles beter" stelling is dan ook
dat voor iedere nuttige patch ten gevolge van "meekijken" er zeker zoveel
domme en foutieve patches zijn (lees: debian, dit is niet de eerste keer) of
dat er op een vrij domme en kinderachtige manier om een probleem wordt
geknutseld (lees: samba)
Dat is nochtans een andere stelling dan "Open Source is onveilig", en al
helemaal wat anders dan "Closed source is veiliger". Ik had gehoopt dat jij
die nuance wel wist te maken...

Post by Fred Mobach
Het is niet zonder reden dat we hier nog steeds niet Debian willen
inzetten in een productie omgeving. Ofschoon ik nog steeds twijfel heb
bij welke distributeur dan ook. ;-)

En die twijfel is terecht. Bij welke distributeur dan ook.

Veiligheid gaat uit van vertrouwen ("trust").

Dit betekent vaak dat je bij CSS moet vertrouwen op de leverancier.
Op (F)OSS kun je vertrouwen op:
- de programmeur (bij BSD-licenties is deze altijd bekend, bij GPL vaak);
- testprogramma's (net als bij CSS, zoeken op bekende problemen of
willekeurige tests);
- controle van de code.

Bij CSS kun je ook enkele controle-mechanismen gebruiken, maar meestal
heb je _minder_ middelen om zelf een controle te starten.

Als jij meer vertrouwen hebt in CSS-leveranciers moet je zeker gaan werken
met CSS-software. Je nachtrust is immers ook veel waard.

Mijn voorkeuren baseer ik op ervaringen uit het verleden. Deze bieden helaas
geen garanties voor de toekomst.

Met vriendelijke groet,
Huub Reuver

[Chel van Gennip]

Post by Martijn van Buul

Post by Fred Mobach

Post by Martijn van Buul
Een bijzonder pijnlijk bewijs van het ongelijk van de stelling dat
http://lists.debian.org/debian-security-announce/2008/msg00152.html

Nu nog even aantonen dat Closed Source Software het beter doet en je
hebt een punt.

Hoho, die vlieger gaat niet op.
Er wordt hier te pas en te onpas geroepen dat Open Source veiliger zou zijn
"want iedereen kan meekijken". *die* stelling is onzin; bovenstaand voorbeeld
toont aan dat er namelijk ook volk is waarvan je eigenlijk liever niet hebt
dat ze meekijken, want ze maken verkeerde "verbeteringen", waarvan je maar
moet hopen dat iemand anders *die* fouten weer oppakt.
Mijn weerwoord op de "van meekijken wordt alles beter" stelling is dan ook
dat voor iedere nuttige patch ten gevolge van "meekijken" er zeker zoveel
domme en foutieve patches zijn (lees: debian, dit is niet de eerste keer) of
dat er op een vrij domme en kinderachtige manier om een probleem wordt
geknutseld (lees: samba)

Tja, is deze fout niet gevonden door het kunnen meekijken?

Een vergelijkbaar recente voorbeeld uit de closed-source wat me zo
direct te binnen schiet is de random generator in de OV-chipkaart. Om
daar de stupide random generator te vinden moest eerst de chip met een
polijstmiddel laag voor laag afgeslepen worden, en onder de microscoop
geanalyseerd.

Vergeet vooral ook niet de onzin die TNO de afgelopen maanden
uitgekraamd heeft over de veiligheid van die geheime encryptie.

Hoewel overal natuurlijk fouten gemaakt worden, zijn veiligheidsexperts
wereldwijd het er over eens dat alleen een open implementaties veilig
kan zijn, juist doordat die door anderen bekeken kan worden, waardoor
fouten in de implementatie, zoals ook hier, aan het licht komen.
Misschien had je een snellere ontdekking gewild, maar het is in ieder
geval ontdekt.

[Martijn van Buul]

Post by Chel van Gennip
Tja, is deze fout niet gevonden door het kunnen meekijken?

Deze fout is inderaad niet gevonden door het kunnen meekijken.

Post by Chel van Gennip
Een vergelijkbaar recente voorbeeld uit de closed-source wat me zo
direct te binnen schiet is de random generator in de OV-chipkaart. Om
daar de stupide random generator te vinden moest eerst de chip met een
polijstmiddel laag voor laag afgeslepen worden, en onder de microscoop
geanalyseerd.

.. daar zat geen RNG in, maar goed. Overigens staat "Security through
obscurity" hier niet ter discussie, dat is een heel ander thema. Je kunt
best closed source implementaties maken van een encryptiemethode die
helemaal open is.

[richard lucassen]

On Mon, 19 May 2008 08:57:00 +0000 (UTC)

Post by Martijn van Buul
.. daar zat geen RNG in, maar goed. Overigens staat "Security through
obscurity" hier niet ter discussie, dat is een heel ander thema. Je
kunt best closed source implementaties maken van een encryptiemethode
die helemaal open is.

Waar je vervolgens valgrind op loslaat, een regeltje eruit sloopt, de
OS-community daarop aanspreekt en daar niet te horen krijgt dat je iets
vreselijks aan het doen bent ;-)
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Chel van Gennip]

Post by Martijn van Buul

Post by Chel van Gennip
Tja, is deze fout niet gevonden door het kunnen meekijken?

Deze fout is inderaad niet gevonden door het kunnen meekijken.

Zo, heb jij een link waaruit dat blijkt?

Post by Martijn van Buul

Post by Chel van Gennip
Een vergelijkbaar recente voorbeeld uit de closed-source wat me zo
direct te binnen schiet is de random generator in de OV-chipkaart. Om
daar de stupide random generator te vinden moest eerst de chip met een
polijstmiddel laag voor laag afgeslepen worden, en onder de microscoop
geanalyseerd.

.. daar zat geen RNG in, maar goed. Overigens staat "Security through
obscurity" hier niet ter discussie, dat is een heel ander thema. Je kunt
best closed source implementaties maken van een encryptiemethode die
helemaal open is.

Lees nog eens even wat oud nieuws:
http://www.nrc.nl/wetenschap/article908839.ece/Geheime_software_nekte_ov-chip
"Philips werd in Berlijn uitgelachen, omdat de Mifare Classic-chip
toevalsgetallen gebruikt die afhankelijk zijn van het moment waarop de
chip in de buurt komt van het leesapparaat."

Overigens blijkt uit deze fout dat zelfs als het toegepaste algoritme
goed is de implementatie fouten kan bevatten.

[Martijn van Buul]

Post by Chel van Gennip

Post by Martijn van Buul

Post by Chel van Gennip
Tja, is deze fout niet gevonden door het kunnen meekijken?

Deze fout is inderaad niet gevonden door het kunnen meekijken.

Zo, heb jij een link waaruit dat blijkt?

Ja - het feit dat de oorspronkelijke reporter beweert dat hij het "by accident"
heeft gevonden:

http://community.livejournal.com/lbello_english/7900.html

Je hoeft ook niet echt naar de code te kijken om te zien dat het goed mis
is, de output van openssl eens kritisch bekijken doet al wonderen, zie

http://mag.entropy.be/blog/2008/05/13/how-badly-debianubunutu-openssl-is-fscked-up/

Post by Chel van Gennip

Post by Martijn van Buul
.. daar zat geen RNG in, maar goed. Overigens staat "Security through
obscurity" hier niet ter discussie, dat is een heel ander thema. Je kunt
best closed source implementaties maken van een encryptiemethode die
helemaal open is.

http://www.nrc.nl/wetenschap/article908839.ece/Geheime_software_nekte_ov-chip
"Philips werd in Berlijn uitgelachen, omdat de Mifare Classic-chip
toevalsgetallen gebruikt die afhankelijk zijn van het moment waarop de
chip in de buurt komt van het leesapparaat."

Vooruit - in het artikel wat die Nohl gast zelf heeft gepresenteerd was dat
niet eens het grootste probleem, maar hij zal er wel geen verstand van
hebben:

http://www.cs.virginia.edu/~kn5f/pdf/Mifare.Cryptanalysis.pdf

Ik citeer: "Our attack exploits statistical weaknesses of the cipher"
en "Our specific attack can be mitigated by using true random numbers on the
reader. This does not fix the underlying weaknesses of the cipher, however, and
more elaborate attacks will emerge. Instead of starting an arms-race around
the security of a fundamentally flawed cipher, systems should upgrade to more
secure cards that use publicly scrutinized cryptography."

Post by Chel van Gennip
Overigens blijkt uit deze fout dat zelfs als het toegepaste algoritme
goed is de implementatie fouten kan bevatten.

Inderdaad.

[Chel van Gennip]

Post by Martijn van Buul

Post by Chel van Gennip

Post by Martijn van Buul

Post by Chel van Gennip
Tja, is deze fout niet gevonden door het kunnen meekijken?

Deze fout is inderaad niet gevonden door het kunnen meekijken.

Zo, heb jij een link waaruit dat blijkt?

Ja - het feit dat de oorspronkelijke reporter beweert dat hij het "by accident"
http://community.livejournal.com/lbello_english/7900.html

Wat doet een Debian package beheeerder wel eens "bij toeval"? Kijken wat
andere packages voor wijzigingen in standaard sources aanbrengen.

Post by Martijn van Buul
Je hoeft ook niet echt naar de code te kijken om te zien dat het goed mis
is, de output van openssl eens kritisch bekijken doet al wonderen, zie
http://mag.entropy.be/blog/2008/05/13/how-badly-debianubunutu-openssl-is-fscked-up/

Dat is typische achteraf wijsheid: Als je 10.000 keys maakt dan zitten
er dubbele tussen.

Post by Martijn van Buul

Post by Chel van Gennip

Post by Martijn van Buul
.. daar zat geen RNG in, maar goed. Overigens staat "Security through
obscurity" hier niet ter discussie, dat is een heel ander thema. Je kunt
best closed source implementaties maken van een encryptiemethode die
helemaal open is.

http://www.nrc.nl/wetenschap/article908839.ece/Geheime_software_nekte_ov-chip
"Philips werd in Berlijn uitgelachen, omdat de Mifare Classic-chip
toevalsgetallen gebruikt die afhankelijk zijn van het moment waarop de
chip in de buurt komt van het leesapparaat."

Vooruit - in het artikel wat die Nohl gast zelf heeft gepresenteerd was dat
niet eens het grootste probleem, maar hij zal er wel geen verstand van

Op zijn sheets van Chaos
http://events.ccc.de/congress/2007/Fahrplan/events/2378.en.html
lees ik:

Random Number Generator
16(!!)-bitrandom numbers
LFSR –based
Value derived from timeof read
Our Attack:
Control timing
=(OpenPCD)= control random number (works for tag and reader!)
= break Mifare security :)

In de video legt hij dat ook netjes uit.

Post by Martijn van Buul

Post by Chel van Gennip
Overigens blijkt uit deze fout dat zelfs als het toegepaste algoritme
goed is de implementatie fouten kan bevatten.

Inderdaad.

Dus is het goed als de broncode geverifieerd van worden.

[Martijn van Buul]

Post by Chel van Gennip
Wat doet een Debian package beheeerder wel eens "bij toeval"? Kijken wat
andere packages voor wijzigingen in standaard sources aanbrengen.

Dat is net zo geloofwaardig als de observatie dat iemand die zich
bezighoudt met security eens kritisch naar zijn eigen keys kijkt.

Eigenlijk vind ik dat laatste geloofwaardiger, maar goed.

Post by Chel van Gennip

Post by Martijn van Buul

Post by Chel van Gennip
Overigens blijkt uit deze fout dat zelfs als het toegepaste algoritme
goed is de implementatie fouten kan bevatten.

Inderdaad.

Dus is het goed als de broncode geverifieerd van worden.

Jammer genoeg laten mensen het niet bij verificatie.

[Chel van Gennip]

Post by Martijn van Buul

Post by Chel van Gennip
Wat doet een Debian package beheeerder wel eens "bij toeval"? Kijken wat
andere packages voor wijzigingen in standaard sources aanbrengen.

Dat is net zo geloofwaardig als de observatie dat iemand die zich
bezighoudt met security eens kritisch naar zijn eigen keys kijkt.
Eigenlijk vind ik dat laatste geloofwaardiger, maar goed.

Laten we het er maar op houden dat het in jouw ogen waarschijnlijker is
dat de fout niet gevonden is door het verschil tussen de officiële
broncode en de Debian variant te bekijken, en dat het in mijn ogen
waarschijnlijker is dat iemand die zich bezighoudt met security begint
met kritisch te kijken naar de verschillen tussen de officiële broncode
en een door hem te gebruiken variant.

Post by Martijn van Buul

Post by Chel van Gennip

Post by Martijn van Buul

Post by Chel van Gennip
Overigens blijkt uit deze fout dat zelfs als het toegepaste algoritme
goed is de implementatie fouten kan bevatten.

Inderdaad.

Dus is het goed als de broncode geverifieerd van worden.

Jammer genoeg laten mensen het niet bij verificatie.

Dat zal vast niet alleen bij OS voorkomen. De kans dat dit soort fouten
uitkomen is bij OS veel groter. Zoals uit het OV-Chipkaart voorbeeld
blijkt, hoef je niet chips met een polijstmiddel laag voor laag af te
schuren, het resultaat onder de microscoop te leggen en dat te
analyseren, maar is een eenvoudig diff voldoende. Ik leg alleen twee
voorbeelden van exact dezelfde fout, een voorspelbare random generator,
(OK, de OV-Chipkaart zat vol met fouten en dit was er één van) naast
elkaar, en vergelijk de (mogelijke) manieren van detecteren.

Bij voorbeelden ben je helaas beperkt tot uitgewerkte
praktijkvoorbeelden. Ik nam een in het oog springend voorbeeld, maar er
zijn er natuurlijk meer:
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9048438
Ook dit voorbeeld toont aan dat dit soort fouten meestal gevonden worden
door het feitelijke algoritme te bekijken, wat zonder broncode best wel
lastig is. Ik zou voorzichtig met de fix zijn, veel systemen crashen van
SP3. (Dat schijnt wel vrij random te gebeuren ;)

[user]

Post by Martijn van Buul
Een bijzonder pijnlijk bewijs van het ongelijk van de stelling dat Open
http://lists.debian.org/debian-security-announce/2008/msg00152.html
Zie vooral ook het commentaar op
http://www.links.org/?p=327
En dat allemaal omdat Debian een "bug" "fixt".

Wij hadden ooit een probleem met een closed src systeem, je kon "superuser"
worden(een eerlijke student had het aangebracht). Dat is toen wel
opgelost, maar de firma is kort nadien wel opgehouden te bestaan. Wat
dan???

Het ging om CDC, anno 1994, een unix die EP/IX heette.

Aan de andere kant, ik had de srces van TeX/LaTeX van 1994 op een schijf
bewaard. Zonder probleem kon ik die compileren op een systeem van 2002.

Veel plezier ermee, met uw closed src.

Bij open src hebben ze hetzelfde prob als bij cmlosed: als de programmeeur
heeft afhgehaakt, moet iemand anders inspringen. Bij open src heb je
wellicht betere specialisten, wantr er is een groter aanbod... Hoe kun je
mensen in een bedrijf uit alle 5 continenten samenbrengen??

[Martijn van Buul]

Post by user
Wij hadden ooit een probleem met een closed src systeem, je kon "superuser"
worden(een eerlijke student had het aangebracht). Dat is toen wel
opgelost, maar de firma is kort nadien wel opgehouden te bestaan. Wat
dan???

Is dat met Open Source werkelijk anders dan? Wie houdt er nog XFree86 bij?
X.org is nog lang niet altijd een alternatief. Als Broadcom morgen failliet
gaat, wie zou er dan nog zorgen dat Linux op hun processorbordjes blijft
werken? Sterker nog, hoe bruikbaar is Debian/m68k nog?

Ja-je-hebt-de-source. Dat helpt - vraag maar aan debian en openssl.

Post by user
Aan de andere kant, ik had de srces van TeX/LaTeX van 1994 op een schijf
bewaard. Zonder probleem kon ik die compileren op een systeem van 2002.

Dat zegt meer over die LaTeX sources dan over Linux.

Overigens had je op een beetje fatsoenlijk systeem die sources niet eens
hoeven te compileren, en had je gewoon die binary kunnen draaien.

Post by user
Veel plezier ermee, met uw closed src.

Ik weet niet welk punt dat je wou maken, maar het komt niet echt hard aan.

Post by user
Bij open src hebben ze hetzelfde prob als bij cmlosed: als de programmeeur
heeft afhgehaakt, moet iemand anders inspringen.

En dat gebeurt dus niet. Kijk maar naar al die Open Source projecten
die doodbloeden.

Post by user
Bij open src heb je wellicht betere specialisten, wantr er is een groter
aanbod...

Nee, je hebt precies evenveel specialisten, en een hele zwik mensen die
niet weten waar ze mee bezig zijn. Met name Debian heeft er een paar.

Post by user
Hoe kun je mensen in een bedrijf uit alle 5 continenten samenbrengen??

Niet - over het algemeen ben je daar niet mee gebaat.

Overigens zijn er 7 continenten. Ik weet dat Belgie 50 jaar achterloopt, maar
Australie en Antarctica zijn al *lang* geleden ontdekt.

[Dick Hoogendijk]

Post by Martijn van Buul
Overigens had je op een beetje fatsoenlijk systeem die sources niet
eens hoeven te compileren, en had je gewoon die binary kunnen draaien.

En wat versta jij onder een fatsoenlijk systeem? Zoveel zijn er niet
hoor, die API compatible blijven in de loop van jaren.

Post by Martijn van Buul

Post by user
Veel plezier ermee, met uw closed src.

Ik weet niet welk punt dat je wou maken, maar het komt niet echt hard aan.

Dat kan komen omdat uw huid wat dik is.

Post by Martijn van Buul
Nee, je hebt precies evenveel specialisten, en een hele zwik mensen
die niet weten waar ze mee bezig zijn. Met name Debian heeft er een
paar.

Heerlijk, dat afgeven op Debian, omdat ze zojuist een fout hebben
gemaakt. Ben je zelf foutvrij?

Post by Martijn van Buul
Overigens zijn er 7 continenten. Ik weet dat Belgie 50 jaar
achterloopt, maar Australie en Antarctica zijn al *lang* geleden
ontdekt.

Die continenten mogen ontdekt zijn. Dat kan niet worden gezegd van uw
omgangsnormen. Die zijn van laag peil. Afgeven op Debian, schoppen tegen
een volk. En met welk recht .. Ach, laat ook maar.

[Martijn van Buul]

Post by Dick Hoogendijk

Post by Martijn van Buul
Overigens had je op een beetje fatsoenlijk systeem die sources niet
eens hoeven te compileren, en had je gewoon die binary kunnen draaien.

En wat versta jij onder een fatsoenlijk systeem? Zoveel zijn er niet
hoor, die API compatible blijven in de loop van jaren.

Meer als je denkt - en Linux heeft wel een *bijzonder* lage track recod
wat dit betreft.

Post by Dick Hoogendijk

Post by Martijn van Buul
Nee, je hebt precies evenveel specialisten, en een hele zwik mensen
die niet weten waar ze mee bezig zijn. Met name Debian heeft er een
paar.

Heerlijk, dat afgeven op Debian, omdat ze zojuist een fout hebben
gemaakt. Ben je zelf foutvrij?

Nee.

Post by Dick Hoogendijk
Die zijn van laag peil. Afgeven op Debian, schoppen tegen een volk. En met
welk recht

Omdat Debian een kut OS is. Altijd geweest, en zal altijd wel zo blijven
ook.

En kweek eens een relativeringsgevoel, zeg.

[Peter]

Post by Martijn van Buul
Omdat Debian een kut OS is. Altijd geweest, en zal altijd wel zo blijven
ook.
En kweek eens een relativeringsgevoel, zeg.

Hier past alleen een ROFL achter :)

-peter

[Dick Hoogendijk]

Post by Martijn van Buul

Post by Dick Hoogendijk

Post by Martijn van Buul
Overigens had je op een beetje fatsoenlijk systeem die sources niet
eens hoeven te compileren, en had je gewoon die binary kunnen draaien.

En wat versta jij onder een fatsoenlijk systeem? Zoveel zijn er niet
hoor, die API compatible blijven in de loop van jaren.

Meer als je denkt - en Linux heeft wel een *bijzonder* lage track
recod wat dit betreft.

Kun je er wat noemen?
Je zegt dat de TeTex uit 1994(!) gewoon als binary had kunnen draaien op
een fatsoenlijk systeem. Welke linux systeem doet dat?

[Cor Gest]

The entity, AKA Dick Hoogendijk <***@nagual.nl> wrote :
(selectively-snipped-or-not-P)

Post by Dick Hoogendijk
Kun je er wat noemen?
Je zegt dat de TeTex uit 1994(!) gewoon als binary had kunnen draaien op
een fatsoenlijk systeem. Welke linux systeem doet dat?

eh, ... Slackware-2.2 ;-)

Maar de huidige versie is TeTeX-3.0 uit 2005.
(overigens re-compiled voor x86_64 voor slamd64-V12)

Cor

[unknown]

Post by Cor Gest
Maar de huidige versie is TeTeX-3.0 uit 2005.

<ot>
teTeX is alweer een jaar of 2 abandonware, tegenwoordig is er TeX Live.
</ot>

[Cor Gest]

The entity, AKA {n.c.o.l.d}@allyourbass.org.invalid (robert) wrote :
(selectively-snipped-or-not-P)

Post by unknown
<ot>
teTeX is alweer een jaar of 2 abandonware, tegenwoordig is er TeX Live.
</ot>

maar ik mac noch windooz, dus dat spul in die TeX-distro boeit me
verder niet echt.

TeX-3.0 is tenslotte reeds jaren "The Final Version" ;-)

Cor

[unknown]

Post by Cor Gest
(selectively-snipped-or-not-P)

Post by unknown
<ot>
teTeX is alweer een jaar of 2 abandonware, tegenwoordig is er TeX Live.
</ot>

maar ik mac noch windooz...

"with binaries for most flavors of Unix, including GNU/Linux"

Post by Cor Gest
dus dat spul in die TeX-distro boeit me verder niet echt. TeX-3.0 is
tenslotte reeds jaren "The Final Version" ;-)

Aan TeX zelf verandert niet zoveel, maar er verschijnen nog steeds mooie
packages en support voor moderne zaken als Unicode en OTF (zodat je een
TeX-PDF niet meteen herkent vanwege dat vreselijke CM font ;).

[Cor Gest]

The entity, AKA {n.c.o.l.d}@allyourbass.org.invalid (robert) wrote :
(selectively-snipped-or-not-P)

Post by unknown
Aan TeX zelf verandert niet zoveel, maar er verschijnen nog steeds mooie
packages en support voor moderne zaken als Unicode en OTF (zodat je een
TeX-PDF niet meteen herkent vanwege dat vreselijke CM font ;).

Dus alleen nuttig als je het nodig hebt ... ;-)

Cor

[Martijn van Buul]

Kun je er wat noemen? Je zegt dat de TeTex uit 1994(!) gewoon als binary had
kunnen draaien op een fatsoenlijk systeem. Welke linux systeem doet dat?

Geen, voor zover ik weet. Maar er zijn andere operating systems dan Linux.

[Dick Hoogendijk]

Post by Martijn van Buul

Kun je er wat noemen? Je zegt dat de TeTex uit 1994(!) gewoon als
binary had kunnen draaien op een fatsoenlijk systeem. Welke linux
systeem doet dat?

Geen, voor zover ik weet. Maar er zijn andere operating systems dan Linux.

Onder meer mijn hoofdsysteem (solaris), ja, maar ik ging ervanuit dat in
de linux groep jij doelde op een linux systeem. Vandaag mijn vraag.

[Huub Reuver]

Post by Martijn van Buul

Post by user
Aan de andere kant, ik had de srces van TeX/LaTeX van 1994 op een schijf
bewaard. Zonder probleem kon ik die compileren op een systeem van 2002.

Dat zegt meer over die LaTeX sources dan over Linux.
Overigens had je op een beetje fatsoenlijk systeem die sources niet eens
hoeven te compileren, en had je gewoon die binary kunnen draaien.

Post by user
Veel plezier ermee, met uw closed src.

Met de overgang van i386 naar x86_64 zie je toch dat de emulatie altijd
een stukje achterloopt. Bij goede sources kun je met minimale aanpassingen
de sources hercompileren.

Zonder sources kun je alleen het wiel opnieuw uitvinden zonder een kans
te leren van jaren ervaring in bestaande sources.

Code gebruiken in een emulatie is altijd een mindere optie als
hercompileren. Helemaal als de software ook "secure" moet zijn, want de
emulatie kan extra mogelijke exploits opleveren. En dan heb ik het niet
over fouten in compilers, parsers, processorenm etc..

Helemaal met een "foutje" in een "randomizer" heb je extra kans op
een zwak systeem.

Maar gelukkig is volgens jouw een randomizer bekende techniek en zul
jij nooit zo'n fout maken. Anders zou je nooit zo zeker kunnen
antwoorden.

Met vriendelijke groet,
Huub Reuver

[Martijn van Buul]

Post by Huub Reuver

Post by Martijn van Buul

Post by user
Aan de andere kant, ik had de srces van TeX/LaTeX van 1994 op een schijf
bewaard. Zonder probleem kon ik die compileren op een systeem van 2002.

Dat zegt meer over die LaTeX sources dan over Linux.

[...]

Post by Huub Reuver
Met de overgang van i386 naar x86_64 zie je toch dat de emulatie altijd
een stukje achterloopt. Bij goede sources kun je met minimale aanpassingen
de sources hercompileren.

Dat zei ik dus: "Dat zegt meer over die LaTeX sources dan over Linux"; het
betekent namelijk dat die LaTeX sources netjes portable zijn geschreven,
in tegenstelling tot heel veel applicaties. Linux (en gcc) hebben namelijk
geen hoge pet op van stabiliteit voor hun API.

Post by Huub Reuver
Zonder sources kun je alleen het wiel opnieuw uitvinden zonder een kans
te leren van jaren ervaring in bestaande sources.

Dat laatste valt vies tegen. Hoe groter een pakket, hoe kleiner de kans
dat je er nog iets van kunt leren, omdat de source zo ondoorgrondelijk is.
Daar komt nog eens bij dat je met het huidige licentie-mijnenveld er sowieso
van uit moet gaan dat je code niet mag hergebruiken.

Post by Huub Reuver
Code gebruiken in een emulatie is altijd een mindere optie als
hercompileren. Helemaal als de software ook "secure" moet zijn, want de
emulatie kan extra mogelijke exploits opleveren.

Oh, en gcc introduceert geen nieuwe fouten? Hoe betrouwbaar en backwards
compatible zijn al die libraries waar je tegenaanlinkt?

Post by Huub Reuver
En dan heb ik het niet over fouten in compilers, parsers, processorenm etc..

Maar ik wel - ik zie niet in waarom je ze zou negeren.

Post by Huub Reuver
Helemaal met een "foutje" in een "randomizer" heb je extra kans op
een zwak systeem.

Maar dat foutje kan zowel in je nieuwe compilaat als in je oude compilaat
zitten. "nieuw" is nog lang niet altijd "beter".

Post by Huub Reuver
Maar gelukkig is volgens jouw een randomizer bekende techniek en zul
jij nooit zo'n fout maken. Anders zou je nooit zo zeker kunnen
antwoorden.

Misschien denk ik niet zo rechtlijnig als sommigen hier, die nog steeds
geloven in het clubje apen dat wel even Shakespeare kan schrijven. In
theorie zouden ze dat wel kunnen, ja - maar weten ze ook wanneer op te houden?

[Huub Reuver]

Post by Martijn van Buul

Post by Huub Reuver
Maar gelukkig is volgens jouw een randomizer bekende techniek en zul
jij nooit zo'n fout maken. Anders zou je nooit zo zeker kunnen
antwoorden.

Misschien denk ik niet zo rechtlijnig als sommigen hier, die nog steeds
geloven in het clubje apen dat wel even Shakespeare kan schrijven. In
theorie zouden ze dat wel kunnen, ja - maar weten ze ook wanneer op te houden?

GCC en libraries hebben fouten. Dat heeft invloed op hercompileren.
Maar niet op emulatoren? Sorry dat ik dergelijke invloeden wegstreep.
In mijn beperkte visie hebben gcc en libraries invloed op zowel oude
binaries als hergecompileerde code als op emulaties.

Daarom is het in mijn ogen niet meer relevant voor de vergelijking.


En dat random generators binnen een emulator misschien anders werken
dan op een "simpele pc" is natuurlijk een waanidee. Een vergelijking
met een debug-omgeving waarin geobserveerd en ge-experimenteerd kan
worden is natuurlijk helemaal fout.

Waar je met een debugger kijkt wat de code doet, dat onverwacht is voor
de programmeur, ben je tenslotte bij een random generator op zoek naar
het tegenovergestelde.


Ik ben het in zoverre met je eens dat bepaalde code alleen kan ontstaan
door de aanleg, opvoeding en goed gereedschap. Daarbij staat het niet
vast dat elke programmeur dergelijke code kan schrijven.

Praktijk leert dat programmeurs van nu andere zaken hebben geleerd als
programmeurs van vroeger, uit andere werelddelen of met een andere
opleiding. Dus het lezen van code kan altijd nut hebben. Zelfs het lezen
van slechte code.

Met vriendelijke groet,
Huub Reuver