A hibát Luciano Bello találta, aki megállapította, hogy a Debianban található OpenSSL csomag véletlenszám-generátora megjósolható kimenetet ad. A "könnyítés" egy nem megfelelő Debian patch-csel került be a rendszerbe.
A DSA szerint minden, a Debianban lévő és 0.9.8c-1-es verziónál újabb (értelemszerűen a most javítottnál korábbi) OpenSSL segítségével létrehozott összes kulcsot célszerű lecserélni. Továbbá az összes -érintett Debian rendszeren- aláírásra, vagy autentikációra használt Digital Signature Algorithm (DSA) kulcsokat kompromittáltnak érdemes tekinteni.
A 0.9.8c-1 verziószámú, hibás OpenSSL 2006. 09. 17-én került bele az akkori unstable disztribúcióba és onnan került vissza az etch-be is. A sarge nem érintett ezzel a hibával.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Ezért veszélyes -nem hozzáértőként- patchelgetni más kódját. Szerintem sokkal rosszabb a Debian "tartsuk a verziót és próbáljuk patkolni az új hibák megismerése után", mint ha rendesen frissítenék a programokat az épp adott legújabb verzióra...
(a kernel detto, csak az nem Debian-betegség)
- A hozzászóláshoz be kell jelentkezni
Ez miert lenne Debian only problema?
Masreszt ezzel a hozzaallassal soha senki nem fejlestzhetne mas kodjat, csak az, aki elkezdte.
Harmadreszt igy meg mindig kevesebb hiba kerul a produktion rendszerekre.
Negyedszer pedig a disztribeknek a kernelt kell patchelniuk. Ez Linus ajanlasa, tetszik vagy nem.
tompos
- A hozzászóláshoz be kell jelentkezni
Az advisory szerint debian-specific, a CVE-2008-0166-ot probaltak annak idejen javitani debian-specifikus modon.
A kriptografiaval kapcsolatban en is azt gondolom, hogy aki nem ert hozza az ne nagyon nyuljon ezekbe a kodokba, keves mas terulethez kell ilyen alapos elmeleti hatterismeret.
- A hozzászóláshoz be kell jelentkezni
Sajnos nem pontosan ugy van, a CVE-2008-0166 konkretan a debian-specifikus bugrol szol. Maga a problema 2006-os, ez okoz komoly fejfajast az etch/lenny/sid hasznaloknak.
- A hozzászóláshoz be kell jelentkezni
Jogos, legalabb az evszam feltunhetett volna a CVE szamozasban :)
A masodik tippem a changelogot olvasva az, hogy a 363516-os bug javitasat sikerult ennyire lelkesen vegezni.
- A hozzászóláshoz be kell jelentkezni
Igen, ahhoz a szokáshoz, hogy a debian régi verziót patchel, ennek semmi köze.
Bra cikkének rossz a címe, az eredeti patchnek semmi köze nem volt a securityhoz, az eredeti patch semmilyen hibát nem javított, csupán egy vélt hibát. Az, hogy az a vélt hiba nem is hiba, egyértelmű volt az akkori openssl fejlesztői dokumentációjából és forráskódjából is.
Ezek a seggfejek egyszerűen megjavították azt, ami nem is volt rossz. Közben bevezettek egy _nagyon durva_ security bugot. Megnézve a diff-eket, látható, hogy az openssl maintainere egyáltalán nem ért a C-hez, nem tudja mi az az #ifndef és nem tud megkülönböztetni out meg in paramétereket. A bevezetett security hibát szép csöndben kijavította egy május 7-ei unstable feltöltésben, aki olvasott changelogot, akkor kiszúrhatta a durva sebezhetőséget, mégis csak ma szóltak róla.
A hiba TÉNYLEG kihasználható és nem csak elméleti. Az elmúlt két évben a hibás szoftverekkel generált kulcsok egy 2^18 nagyságú halmazból kerülnek ki, nem pedig az elvárt 2^80 - 2^160 szokásos nagyságrendűből.
Egy könnyen előállítható szótár segítségével tetszőleges nyilvános kulcsról megmondható a titkos kulcsa, illetve egy nem hibás szoftverrel generált, de bármikor is hibás szoftverrel felhasznált DSA kulcshoz az aláírás ellenőrzője (tehát pl. a szerver keyauth esetén) meg tudja mondani a titkos kulcsát.
NEM ELEGENDŐ a szoftvercsomagok frissítése, az összes DSA kulcs törlése és a 2006-nál újabb RSA kulcsok törlése szükséges. Továbbá minden olyan kommunikációt, amit ilyen kulcsokkal végeztünk plaintext csatorna fölött végrehajtottnak célszerű feltételezni, azaz a jelszavainkat is változtassuk meg!
Soha nem írok ilyen webes fórumokba, azért tettem kivételt, mert ez most komoly.
Gergő
- A hozzászóláshoz be kell jelentkezni
Soha nem írok ilyen webes fórumokba, azért tettem kivételt, mert ez most komoly.
Nem kellett volna, főleg, hogy fekete a kalapod... :P
- A hozzászóláshoz be kell jelentkezni
Valóban, javítottam a címet, remélem jobb lett. :)
- A hozzászóláshoz be kell jelentkezni
Nem követtem ezt az egészet, mert tegnap dolgom volt, de ha csak a debianos OpenSSL-t érinti, akkor a cikk címének talán jobb lenne a
"Biztonsági hiba az debianos OpenSSL-ben egy debianos patch miatt"
cím, hacsak a debianos patch nem érinti az upstream-et is. :)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
So-so, mert az Ubuntut is érinti, viszont nem tudni még pontosan, hogy kik vették- és kik nem vették át a nem-hiba javítását.
--
- Name ONE thing that your Linux computer can do that my MAC can't!
- Right click.
- A hozzászóláshoz be kell jelentkezni
A mai (tegnapi?) frissítés, amiben valami 2×93000 kulcsot blacklisteltek az ezzel kapcsolatos?
szerk: igen, az ismert sebezhető kulcsokat tartalmazza.
- A hozzászóláshoz be kell jelentkezni
--8<--
Package: debian-keyring
Priority: optional
Section: misc
Installed-Size: 25652
Maintainer: James Troup
Architecture: all
Version: 2007.12.04
Recommends: gnupg (>= 1.0.6-4)
Filename: pool/main/d/debian-keyring/debian-keyring_2007.12.04_all.deb
Size: 20600706
MD5sum: 2625bdad6930ef0b9bd6177daa483946
SHA1: df006a96a855777aa9a0320b7e03c6176f2e3e6b
SHA256: 460afdbe2f691525f71b0fc7429a071cbd7287f1576c2dc2c77fa994169c4155
Description: GnuPG (and obsolete PGP) keys of Debian Developers
The Debian project wants developers to digitally sign the
announcements of their packages with GnuPG, to protect against
forgeries. This package contains keyrings of GnuPG and (deprecated)
PGP keys of developers.
Tag: role::app-data, security::authentication, suite::debian
-->8--
fincsi lesz ...
debian gnu/linux @ linux-2.6.22.24-op1 | patch
info
- A hozzászóláshoz be kell jelentkezni
De ezek elavult GnuPG kulcsok, amik amúgy sem érintettek. Csak az ssh-k. Szóval szerintem nem egyről beszélünk.
- A hozzászóláshoz be kell jelentkezni
Jah. Azért mondtam, hogy "de ha csak a debianos OpenSSL-t érinti", mert elsőre ez volt az infó.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Azt, ami a Debianból származik, de nem tudtam rájönni, hogy lehetne szépen, szóismétlés (debianos) nélkül megfogalmazni ezt.
- A hozzászóláshoz be kell jelentkezni
Miért? "Elpecselte a Debian az OpenSSL-t" vagy "Félrepecselt OpenSSL Debianéknál" :)
- A hozzászóláshoz be kell jelentkezni
Mondj egy disztribúciót ami naprakész, ellenőrzött és ritkábban fordul elő benne ilyen baklövés.
--
the tide is turning
- A hozzászóláshoz be kell jelentkezni
FreeBSD :)
debian gnu/linux @ linux-2.6.22.24-op1 | patch
info
- A hozzászóláshoz be kell jelentkezni
Naprakész, ritkábban (sokkal, mert nem pancsolnak ennyit a forrással) fordul elő ilyen. Viszont a Debiannal szemben nem ellenőrzött, hiszen abban minden port kőkeményen nyomon van követve, a hibás részeket a """"fejlesztő"""" újraírja a saját ízlése szerint, stb.
- A hozzászóláshoz be kell jelentkezni
Incidentally, while I am talking about vendors who are bad for security, it saddens me to have to report that FreeBSD, my favourite open source operating system, are also guilty. Not only do they have local patches in their ports system that should clearly be sent upstream, but they also install packages without running the self-tests. This has bitten me twice by installing broken crypto, most recently in the py-openssl package.
Ahaha. :D
Nem tud valaki egy junior sheep administrator állást valahol? :)) Nincs kedvem cserélgetni a kulcsokat . :/
--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.
- A hozzászóláshoz be kell jelentkezni
Azért a kettőt ne hasonlítsd össze, teljesen más.
- A hozzászóláshoz be kell jelentkezni
a junior sheep admin allast meg a kulccseret?
igazad van, az elso nyugisabb :)
- A hozzászóláshoz be kell jelentkezni
"Ez miert lenne Debian only problema?"
Mert ők a bug szerzői.
"Masreszt ezzel a hozzaallassal soha senki nem fejlestzhetne mas kodjat, csak az, aki elkezdte."
A Debian nem fejleszti az OpenSSL-t (és más csomagokat), hanem kiválaszt egy verziót, azt beleteszi a $RND_TYSTRY nevű kiadásába, majd befagyasztja a kódot, ahhoz már csak bugfixeket ad ki.
Ez meg azért veszélyes, mert az 1.0.0-ás eredeti kód helyett két év múlva már a 3.5.4-nél tart a fejlesztő, majd kiderül, hogy van egy bug.
A Debian csomagolónak el kell döntenie, hogy ez érinti-e az 1.0.0-át. Nem mondanám, hogy ez triviális feladat. Aztán ha úgy gondolja, hogy igen (itt már elvileg érti a régi és az új kód működését is), adaptálnia kell az eredeti fejlesztő javítását a régi verzióra.
Ezt elég sok helyen el lehet rontani, és új hibákat is hozhat (lásd fent).
"Harmadreszt igy meg mindig kevesebb hiba kerul a produktion rendszerekre."
Ezt azért bizonyítanod kellene. Rendszeresen olvasom az általam használt programok changelogjait és bizony a legtöbbnek már elég stabil kódbázisa van ahhoz, hogy ezek a changelogok nagy része bugfixekről szóljon, azaz nem új funkciók, hanem hibajavítások kerülnek be.
Szerintem egy apache 2.2.8 kevesebb hibát tartalmaz, mint a 2.2.0. Csak a hasamra ütöttem, de hogy ne mondjak hülyeséget, azért az előző mondat leírása után megnéztem a changelogját is:
http://www.apache.org/dist/httpd/CHANGES_2.2.8
Szerintem teljesen egyértelmű, hogy nagyobb kockázat 2.2.3-as apache-ot futtatni (a Debian-féle kókányolással meg főleg), mint frissíteni 2.2.8-ra.
"Negyedszer pedig a disztribeknek a kernelt kell patchelniuk. Ez Linus ajanlasa, tetszik vagy nem."
Szerencsére nem érint. Sem mint fejlesztőt (a hajam kitépném), sem mint felhasználót.
De azért még tarthatom rossznak, ugye?
- A hozzászóláshoz be kell jelentkezni
A velemenyem nem egyezik a Tieddel.
:)
tompos
- A hozzászóláshoz be kell jelentkezni
Ez persze megengedett, de pontosan mivel nem értesz egyet?
- A hozzászóláshoz be kell jelentkezni
Ez meg azért veszélyes, mert az 1.0.0-ás eredeti kód helyett két év múlva már a 3.5.4-nél tart a fejlesztő, majd kiderül, hogy van egy bug.
A Debian csomagolónak el kell döntenie, hogy ez érinti-e az 1.0.0-át. Nem mondanám, hogy ez triviális feladat. Aztán ha úgy gondolja, hogy igen (itt már elvileg érti a régi és az új kód működését is), adaptálnia kell az eredeti fejlesztő javítását a régi verzióra. Ezt elég sok helyen el lehet rontani, és új hibákat is hozhat (lásd fent).
Melyik disztribútor nem így jár el? (komolyabbak közül, pl. Novell, Red Hat. Fedorával kíméljetek, az a másik véglet)
- A hozzászóláshoz be kell jelentkezni
Ha tőlem kérdezed, nem tudom.
- A hozzászóláshoz be kell jelentkezni
Tőled kérdezem, felvetetted a problémát, de ha szinte senki se csinálja máshogy, akkor mégse olyan triviális az általad javasolt megoldás...
- A hozzászóláshoz be kell jelentkezni
Nem követem nyomon a Linux disztribúciókat, ezt értelemszerűen olyannak kellene megválaszolnia, aki igen.
Jellemzően FreeBSD-t használok, a hozzá adott portok ilyenek. Ahol nem kell, nincsenek saját patchek, ahol kell, ott rendszerint OS-specifikus (fusson, elérési utak, stb), illetve sokszor előfordul, hogy ezeket a következő release-nél törli a karbantartó, mert az eredeti fejlesztő beletette a kiadásba.
Nekem nagyon bejött a "stabil" alaprendszer (amelyből szolgáltatásokat tekintve szinte semmit sem használok, szinte minden ports-ból megy), amelyre -teljesen elkülönülve, ez nálunk a menedzsment megoldás miatt is fontos, hiszen külön tudunk OS és ports release-t csinálni- olyan progikat teszek, amiket akarok.
Eddig sehol sem zavart, hogy a 7-es FreeBSD-n 2.2.0-ás apache-ról 2.2.8-asra tudtam frissíteni anélkül, hogy hackelni kellett volna bármit, ha pedig a 2.0.x-ről frissítettem a 2.2.x-re, tudtam, hogy változhatott a konfiguráció, egyebek, ezért előtte utánanéztem, kipróbáltam, hogy mivel jár ez.
Ez a te döntésed, de nem úgy, mint a Debianban, ahol "unstable", meg "testing" csomagokat kell használnod (amelyek ugye ugyanazon ágból hivatkoznak librarykra, meg rossz esetben az "egész OS-re").
Nekem logikusabb és használhatóbbnak tűnik, mint a debianos megoldás.
- A hozzászóláshoz be kell jelentkezni
Nem Debian jelenség. Az OpenBSD licenc okokból még mindig 1.x-es saját Apache fork-ot terjeszt.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
http://hup.hu/cikkek/20080513/biztonsagi_hiba_az_openssl-ben_egy_debian…
Amúgy meg az OpenBSD-ben sem túl gyakori eset ez, ennél azért több nagyságrenddel más a Debian.
- A hozzászóláshoz be kell jelentkezni
Az OpenBSD-ben pl az openssl 0.9.7 -es masszív 0.9.8 patch hegyekkel....
- A hozzászóláshoz be kell jelentkezni
Nyilván nem újdonság neked, hogy:
- az OpenBSD-sek szeretnek ilyet csinálni (sőt, átvenni, és folytatni a maguk szakállára)
- az alaprendszerben sűrűbben előfordulnak ilyenek
Lehetne még sorolni ezeket, mindenesetre én a magam részéről az elvet tartom rossznak.
- A hozzászóláshoz be kell jelentkezni
"- az OpenBSD-sek szeretnek ilyet csinálni (sőt, átvenni, és folytatni a maguk szakállára)"
debianosok ugyan ezt csinálják
"... mindenesetre én a magam részéről az elvet tartom rossznak."
akkor hogy állunk most?
hibázni meg hibázhat bárki, lehet holnap meg obsd-sek jelentenek be hasonló bugot ...
debian gnu/linux @ linux-2.6.22.24-op1 | patch
info
- A hozzászóláshoz be kell jelentkezni
Egy szóval sem mondtam, hogy szerintem az OpenBSD jól csinálja, nem is én hoztam ide.
A Debian meg tudtommal nem éppen a forkjairól, vagy rewrite-jairól híres (mint OpenSSH, OpenCVS, meg kitudja még mi).
Hogy állnánk? Szerintem az OS vendor próbálja követni azoknak a programoknak a verzióit, amelyekből építkezik, ne pancsolja a kódot csak azért, hogy öt évig 2.2.0 lehessen a programból.
- A hozzászóláshoz be kell jelentkezni
"A Debian meg tudtommal nem éppen a forkjairól, vagy rewrite-jairól híres (mint OpenSSH, OpenCVS, meg kitudja még mi)."
Nem az OpenBSD-sek?
- A hozzászóláshoz be kell jelentkezni
""- az OpenBSD-sek szeretnek ilyet csinálni (sőt, átvenni, és folytatni a maguk szakállára)"
debianosok ugyan ezt csinálják"
Nem, nem ugyanazt csinálják.
- A hozzászóláshoz be kell jelentkezni
de sokkal kisebb az esélye, mivel obsd-t használnak 10--en, akkor debiant 1000-en
(nem valós adatok, mielött bárki belekötne :P )
debian gnu/linux @ linux-2.6.22.24-op1 | patch
info
- A hozzászóláshoz be kell jelentkezni
Szerintem itt kár "maszatolni" stb. Ez nagy debian/ubuntu bukta, tény.
Vannak olyan disztrók amik arra törekednek, hogy minél kevesebbet patcheljenek, ami általában működik is.
- A hozzászóláshoz be kell jelentkezni
Természetesen ez nagy probléma. Nem állítottam az ellenkezőjét. Pláne nem beszéltem disztrókról. Az OpenBSD házon belüli forkjáról tettem említést.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Értem ugyan, amit írsz, de remélem, hogy azért aki biztonsági javítást tol egy régebbi kódba egy új alapján, az legalább érti, amit csinál... Legalábbis így kéne lennie.
Az viszont szerintem hasznos dolog, hogy a stabil verzióban nincsenek verzióváltások, mert nekem pl. a laptopomon, ahol testing debian fut, nem egyszer előfordult, hogy aptitude upgrade után valami nem indult el (mert mondjuk új lett a konfig fájl formátuma, vagy ilyesmi).
Ezt stabil rendszeren jó elkerülni.
Szóval van két szempont. Aztán a választás az meg voltaképp az üzemeltetőé, hogy akkor ő most stable-t, testinget, unstable-t, vagy mit tesz fel magának.
G
- A hozzászóláshoz be kell jelentkezni
A "legalábbis így kéne lennie"-vel kapcsolatban csak Gergőt tudnám idézni: "Ezek a seggfejek egyszerűen megjavították azt, ami nem is volt rossz. Közben bevezettek egy _nagyon durva_ security bugot. Megnézve a diff-eket, látható, hogy az openssl maintainere egyáltalán nem ért a C-hez, nem tudja mi az az #ifndef és nem tud megkülönböztetni out meg in paramétereket."
Pedig ő aztán nagyon odavan a Debianért. :)
Szóval sajnos jellemzően nem ez a helyzet. Aki csomagol, az nem feltétlenül gyakorlott programozó és ha ne adj isten az is lenne, akkor sem biztos, hogy van ideje megérteni a változást, vagy egyáltalán átlátja az egészet teljes egészében.
Ezt a témát feszegettem már korábban is (lusta vagyok előkeresni a hozzászólásokat): az, hogy a vendor (jelen esetben Debian csomagoló) önmaga patchelget, biztonsági kockázat (lehet), mert nem feltétlenül érti a kódot, illetve a változást, amit bevitt.
- A hozzászóláshoz be kell jelentkezni
http://marc.info/?l=openssl-dev&m=114651085826293&w=2
Itt a srác levele. Ő javította 2006-ban a nem létező bugot. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516
Szerintem nem úgy tűnik, hogy semmit nem ért hozzá, de az látszik, hogy érthetne többet :-)
Viszont mi többet tehet valaki, aki mondjuk nem ért valamit a maga teljességében, minthogy a fejlesztőket megkérdezi?
Ha meg ott senki nem mondja neki azt, hogy figyelj, ne vedd ki, mert az kell, akkor nem értem, miért ő a hibás.
G
- A hozzászóláshoz be kell jelentkezni
Szerintem a rendszer hibás. :)
- A hozzászóláshoz be kell jelentkezni
szerintem is. túl nagy a kísértés, hogy ilyen és hasonló ismert bakik ismétlődjenek.
- A hozzászóláshoz be kell jelentkezni
Lehet az ok, "pillanatnyi" rövdizárlat is. Volt már rá példa valamelyik sarge kernel frissítésnél asszem, hogy a kernel image csomagolásánál elfelejtették betölteni a kernel configot és kb. modulok nélküli kernel image el jöttek ki első körben.
Meg nem mondom hány csomag van most összességében a debian etchben mondjuk, de még ha 99% os teljesítményt nyújtanának, akkor is úm. "elszarnak" több mint 100 csomagot.
--------------------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni
"Debian GNU/Linux provides more than a pure OS: it comes with __over 18733 packages__, precompiled software bundled up in a nice format for easy installation on your machine."
debian.org kezőoldal ;)
debian gnu/linux @ linux-2.6.22.24-op1 | patch
info
- A hozzászóláshoz be kell jelentkezni
Ez meg azért veszélyes, mert az 1.0.0-ás eredeti kód helyett két év múlva már a 3.5.4-nél tart a fejlesztő, majd kiderül, hogy van egy bug.
Ez szerintem egy kétélű dolog. Egyrészről igazad van, másrészről meg nincsen, mert a 3.5.4 tartalmazhat olyan bugokat amiket az 1.0.0 nem / ha elfogadjuk azt hogy minden programban vannak hibák, akkor azt is el kell hogy minden új funkció által használt programrészekben is, mivel ezek a régi verzióban nincsenek meg, így a régi program ilyen téren "érintetlen" /, harmadrészt lehetnek olyan változások amelyek miatt az 1.0.0 -s verziót használó rendszeren a 3.5.4 már nem fut el. Negyedrészt lehetnek egyéb olyan külső alkalmazások melyek az 1.0.0-t használják és a 3.5.4 essel már nem mennek el.
Szándékosan nem mondtam programnevet sehol sem, csak tisztán elméleti alapon írogatok egy "képzelt" program 1.0.0 és 3.5.4 verziója között. :-)
Szerintem egy apache 2.2.8 kevesebb hibát tartalmaz, mint a 2.2.0.
Nem erről van szó, hanem hogy ezek közül hány olyan "magas kockázatú" (pl. biztonsági) hiba van ami 2.2.8at érintette és 2.2.0 2.2.3-at is?
Ill. hogy konkrét példánál maradjunk a debian etch ben levő apache2 azért elég sok lib* -től, stb. függ. Verzióemelésnél ezt a tényezőt is figyelembe kell venni, mert új apache2 + túl régi lib* környezet okozhat inkompatiblitási problémákat pl. A verziószám lépés nem túl nagy mondjuk, de ez önmagában még nem garancia semmire sem.
--------------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni
Tehat a BSD-k kockazata a legalacsonyabb.
- A hozzászóláshoz be kell jelentkezni
nem nem :)
ott a Debian GNU/kFreeBSD is
debian gnu/linux @ linux-2.6.22.24-op1 | patch
info
- A hozzászóláshoz be kell jelentkezni
Ez miért is következne a fentiekből? A legalacsonyabb semmiképp.
A BSD-k amúgy teljes operációs rendszerek (nem csak egy csomagkezelő és hozzá egy rakás csomag, meg némi saját ragasztó), amelyek "gyártói" hasonlóképpen járnak el sok alkalmazás tekintetében, mint a Debian: az alap OS-ben lévő 3rd party alkalmazások egy részét főverzión belül nem váltják, csak a biztonsági hibák hatására frissítenek.
De -konkrétan a FreeBSD-nél- nincs olyan éles policy, hogy egy STABLE-ben nem lehet sendmail verziót ugrani (meg is teszik nemegyszer), inkább a karbantartóra van bízva, hogy mit választ:
- megpróbálja megérteni az egy-egy hibára adott gyártói bugfixet és azt visszatenni a régebbi kódba (lásd fent)
- ha hiba van és van patch, de még nincs release, patchel és utána frissíti az egész alkalmazást
- ha hiba van, megvárja a release-t és arra frissít
- mindig frissít, ha új verzió van és úgy látja jónak (hiszen ezért karbantartó, hogy kipróbálja a saját rendszerén, utána beletolja a CURRENT-be, majd ha nem volt vele gond, le a STABLE-be)
- A hozzászóláshoz be kell jelentkezni
1. az alaprendszert ők fejlesztik, tehát alaprendszer hibáit ők tudják legjobban kijavítani
2. a 3rd party csomagokból általában upstream által karbantartott verzió van
- A hozzászóláshoz be kell jelentkezni
Az alaprendszer hány százaléka (pld. kódsorban) a saját, és hány a külső program?
Ha az upstream=a fejlesztő(k), erre adhatnál valami hivatkozást is, konkrétan a FreeBSD portoknál nem tapasztalom ezt (érzésre).
- A hozzászóláshoz be kell jelentkezni
mennyi lehet, 25-30%?
--
Segmentation violation -- Core dumped blues
- A hozzászóláshoz be kell jelentkezni
BSD változattól függ.
http://distrowatch.com/table.php?distribution=freebsd
Distrowatch szerint eleg friss a -STABLE ág.
- A hozzászóláshoz be kell jelentkezni
a patcheles elegge gyakori es nem mindig kuldik el es ez neha a karbantartok hibaja.
viszont van, amikor az upstream egyszeruen nem hajlando elfogadni a valtozasokat, es ez a legrosszabb eset.
--
Segmentation violation -- Core dumped blues
- A hozzászóláshoz be kell jelentkezni
Ha jól látom ez a portokról szól, amelyeknek nem sok közük van egy-egy release-hez.
- A hozzászóláshoz be kell jelentkezni
Egyet ertek.
De mi lesz igy az instabil API bullshittel ?
- A hozzászóláshoz be kell jelentkezni
Mi az az egy, amit értesz? Mi lenne, illetve mire gondolsz? Szerinted az apache 2.2.x-nek más az API-ja, mint a 2.2.y-nak?
Jó esetben a vendor dolga, hogy rendben tartsa a szoftverét és ne csak egy HEAD/trunk/akárminek hívják a verziókezelőjében verziót csináljon, amelybe ész nélkül fejleszt, majd minden második hónapban reszel picit és kiadja azt, ami van.
- A hozzászóláshoz be kell jelentkezni
Szerintem (lenyegeben) nem.
De trolljaink maskep gondoljak. :)
Projectol fugg, de altalabn igaz szerintem, hogy az uj verzio kevesebb uj hibat hoz, mint amennyit befoltoz + uj feature-k.
- A hozzászóláshoz be kell jelentkezni
Ezek szerint akkor az
int main (){}
kódban van a legtöbb hiba, a következő verziók már mind jobbak ebből a szempontból?
- A hozzászóláshoz be kell jelentkezni
Nem. Akartam Project korosztalyokrol beszelni.., de vegul meggondoltam magam, mert kiveteleket en is tudnek mondani igy is - ugy is, de nagyabol en igy tapasztalom.
- A hozzászóláshoz be kell jelentkezni
Akkor javaslok egy számolási módot: featureök száma/kiadások száma=hibalehetőség mértéke
Azaz az int main(){return 0;} kód 0 (feature)/1 (kiadás), azaz 0 hibalehetőségű.
Nyilván minden project minősége más, de egy project különböző kiadásait már össze lehet hasonlítani talán ezzel a módszerrel.
- A hozzászóláshoz be kell jelentkezni
Ettol bonyolultabb az egyenlet.
Valoszinuleg kijon, hogy a hosszan karbantartott valtozatok megbizhatobbak egy kicsit.
Alapvetoen ugy szoktak kalkulalni, hogy az l soros szofvarben van n hiba.
A teszteles/hasznalat soran t ido alatt a hibak p reszet ]0.0..1.0[ talaljak meg. A kov t ido intervallumban a maradek p reszet .. stb. (Ez fugg a teszterek szamatol, hibatalasi kepesegeitol) (ebbol lehet diff egyenletet karcolni)
Az egyenlet tovabb bonyolodik, hogy gyakorlatilag ugyan arrol a szoftverrol van szo, de L sor megvaltozott, es feltehetoleg hasonlo sor/hiba aranyban kerultek hibak, mint az elozo verziokba.
Egy olyan szoftvernel amiben hiaba van 10000 hiba felhasznalok nagyobb resze nem talalkozik egyikkel sem, felfedeznek mondjuk 9000 belole es javitjak (mondjuk 1 ev alatt), akkor egy ujabb l/L<0.01 kodvaltoztatas mondjuk hozz 100 uj hibat. Amiek felet par heten belul javitjak. Maradek elhuzodik. Igy mondjuk 1050 vs. 999 rejtett hiba lehet morfondirozni.
Feltehetjuk azt is, hogy fejlesztok is tanulnak es tesztelok (userek) szama is novekedett..
(Ha szofware felhasznali szama novekszik, a hibak felfedezesenek sebbesege is novekszik.)
Most nincs kedvem szamolni..
Hagyhatjuk is, mert ez meg mindig nem a teljes kep :)
- A hozzászóláshoz be kell jelentkezni
Ha jól látom egy dolgot nem veszel figyelembe. Ez pedig az, hogy itt nem arról van szó, hogy egy szoftvert a fejlesztője lineárisan javít/fejleszt és kész, hanem arról, hogy a szoftver halad a maga ütemében, míg a disztribútor leragad egy adott verziónál, amire próbálja rátenni a közben megváltozott szoftverhez készült javításokat.
- A hozzászóláshoz be kell jelentkezni
Az olyanra csak a masodik bekezdes vonatkozik. A bugfix hibathozhat azt nem szamoljuk :), (ritka eset ,hogy kvazi azonal(1-2nap) nincs belole anyazas.)
Ne bonyolitsuk tul, igy is -ugy is rengeteg ismeretlen konstans lesz az egyenletbe, amit nehez merni.
szerk:
(Vagy bugfixalo sorokat lehet mas hiba esellyel szamolni)
- A hozzászóláshoz be kell jelentkezni
bugos amit irtal: nincs return
- A hozzászóláshoz be kell jelentkezni
Csak azért, hogy a következő kiadásban legyen mit javítani.
- A hozzászóláshoz be kell jelentkezni
Ahogy mondod, bullshit, a valosaghoz az egvilagon semmi koze nincs. Altalaban nem minden programot fejlesztenek ugy, mint Linus a kernelet, hogy ma mar egy 2.6.5-hoz fejlesztett akarmilyen driver talan nem is mukodne - pedig csak 20 alverziot ugrottunk. Sokan igyekeznek verziokon at kompatibilisek maradni, es ha uj api van is, ahol lehet megtartjak/emulaljak a regi api-t, es szep lassan etetik meg a fejlesztokkel a valtozasokat. Szal nem rogton Linus fejlesztesi modelljebol kellene talan levezetni minden opensource projekt fejlesztesenek modelljet, mert lehet, hogy nincs igazad...
- A hozzászóláshoz be kell jelentkezni
Pld. OpenLDAP, ha használja valaki...
- A hozzászóláshoz be kell jelentkezni
Most irtam at egy (merokartya) drivert ami 2.2-hez fejlesztettek , valami 6 sor diszeleg 2.4-re valo atallas miatt, most ujabb 6 sorral hoszabb lett (hogy 2.6.9 felett is mukodjon), es uj Makefilet -kapott.
Valoszinuleg wines arc irta mert, olyanok a valtozo nevek benne :)
- A hozzászóláshoz be kell jelentkezni
Ezek szerint vannak még olyan részei a Linuxnak, amelyekhez évek óta nem nyúlt senki.
- A hozzászóláshoz be kell jelentkezni
(Nem a kernel ressze ez a driver , nehogy valaki felre ertse )
PCI busz nem valtozik :)
- A hozzászóláshoz be kell jelentkezni
A Linuxot nem követem figyelemmel, de a FreeBSD-ben a 4-es óta az egyik leginkább piszkált terület pont ez.
Nem hiszem el, hogy az MSI, a PAE és hasonlók miatt semmi nem történt a PCI környékén a 2.0-ás verziótól fogva. Márpedig ha történt, azt sem tudom elhinni, hogy az API végig változatlan marad. Főleg a Linuxnál, ahol függvények neveződnek, tűnnek el és jelennek meg a semmiből subminor verziók között...
- A hozzászóláshoz be kell jelentkezni
kvazi egy fuggveny atnevezes es egy eltolas.
Ez volt benne ketszer, a maradek par sor meg a makrok (if verzio).
- A hozzászóláshoz be kell jelentkezni
Enable deprecated pci_find_* API:
CONFIG_PCI_LEGACY:
Say Y here if you want to include support for the deprecated
pci_find_slot() and pci_find_device() APIs. Most drivers have
been converted over to using the proper hotplug APIs, so this
option serves to include/exclude only a few drivers that are
still using this API.
make menuconfig @ 2.6.25
debian gnu/linux @ linux-2.6.22.24-op1 | patch
info
- A hozzászóláshoz be kell jelentkezni
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.3/0374.html
Memoria kezeles valtozott, igy az eszkozok memoriajanak user fele mapolasa is.
(Kesobb el is tavolitottak deprecated reszt, 6 lepesben fokozatosan..)
- A hozzászóláshoz be kell jelentkezni
"Valoszinuleg wines arc irta mert, olyanok a valtozo nevek benne :)"
Mert a "wines arcok" milyen változóneveket használnak szemben a !win-s arcokkal?
Jó, annyit el tudok képzelni, hogy egy normális fejlesztőkörnyezethez szokott valaki, aki eléggé használja az autocompletet, az inkább ír beszédesebb osztály, függvény és változóneveket, - merthogy úgy se kell kiírni - és kevésbé rövidít.
Visual Studio óta én is egyre inkább beszédesebb neveket használok PHP-ben.
- A hozzászóláshoz be kell jelentkezni
p,dw,i,w -vel kezdodes, wines kodokban szoktam latni.
(Egy idoben en is atvettem, de szerintem csak meg rondabb lett kod tole..)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Asszem néhány perccel lekéstelek a hírküldéssel, bra! :)
- A hozzászóláshoz be kell jelentkezni
érdekes, debianos bakira mindenki jön, mint szarra a legyek :) de solarisos remote bugra senki :P
debian gnu/linux @ linux-2.6.22.24-op1 | patch
info
- A hozzászóláshoz be kell jelentkezni
A vilag mar csak ilyen.:)
- A hozzászóláshoz be kell jelentkezni
ez még érdekesebb akkor lehetne, ha lenne mellette valós (utópia) adat arról, hogy melyik milyen felhasználási gyakoriságú és súlyú :)
--
xterm
- A hozzászóláshoz be kell jelentkezni
Kicsit többen használnak Debiant.
Pláne a Solarisos nyomtatóra szólt, ami megint szűkíti a kört, az az érzésem, hogy az élesben használt Solarisok 90-a (vagy még több) nem használ nyomtatót.
Ez az SSL téma jóval általánosabb, mindenkit érint
-----------------------------
Ubuntu 8.04
- A hozzászóláshoz be kell jelentkezni
Itt: szar=Debian, legyek=mi?
- A hozzászóláshoz be kell jelentkezni
jaja, de szar helyére bármit be lehetne rakni .... solaris, bsd, ...
debian gnu/linux @ linux-2.6.22.24-op1 | patch
info
- A hozzászóláshoz be kell jelentkezni
Figyeld! Már védekezeik :DDDD
--
Aki falra szerelt tehennel vitatkozik, olyan mint vonat kerek nelkul, nem jut sehova.
- A hozzászóláshoz be kell jelentkezni
Mert azon senki nem lepodik meg :)
- A hozzászóláshoz be kell jelentkezni
Sajnos ez a bug nem csak a Debian-t erinti. Mivel a security bug atcsorgott az Ubuntu-ba is: USN-612-1. Valoszinuleg a tobbi Debian leszarmazott disztro is erintett.
A masik problema, ha a rendszeredbe egy user olyan SSH key-eket, stb masolt fel ami az erintett Debian-os/Ubuntu-s verzioju OpenSSL-el generaltak akkor te is sebezheto vagy attol fuggetlenul, hogy a tobbi disztro OpenSSL megvalositasaban nem volt ilyen problema. Ezert aki megenged ilyet a usereknek annak erdemes ellenorizni a kulcsokat a bejelentesben linkel progival, mas disztrok eseten is: Debian/OpenSSL Weak Key Detector
Az OpenSSL-es fejlesztok termeszetesen kiakadtak, ha valaki nem ert valamihez akkor miert nyul hozza. Illetve miert nem komunikalnak tobbet az upstream-el, ha elkultek volna a kerdeses "security" patch-et a fejlesztonek akkor ez nem tortenhetett volna meg. A blog bejegyzes: Vendors Are Bad For Security
- A hozzászóláshoz be kell jelentkezni
atcsorgott az Ubuntu-ba is: USN-612-1.
Öröm a bajban, hogy ezek szerint a 6.06.2 LTS nem érintett.
init();
- A hozzászóláshoz be kell jelentkezni
Viszont máris van javítás.
--
the tide is turning
- A hozzászóláshoz be kell jelentkezni
Ja a javitas is kulon szep volt. Egy hettel ezelott commitoltak, gondolom kozben valakinek szemet szurt, hogy ez egy biztonsagi hiba, es igy most kiadtak egy security advisory-t.
- A hozzászóláshoz be kell jelentkezni
Mit kellett volna tenniük?
--
the tide is turning
- A hozzászóláshoz be kell jelentkezni
hogy magának is Nagyapa imitátornak tetszik lenni?
- A hozzászóláshoz be kell jelentkezni
Időnként igen, de csak viccbül. Most viszont abszolúte nem értem miért tetszik ilyet pofázni.
--
the tide is turning
- A hozzászóláshoz be kell jelentkezni
sot, ha debianon generaltal kulcsot es azt hasznalod barmilyen mas oprendszeren akkoris szivas van. de gondolom a hardcore debian userek mindig puttyal generalnak kulcsot :) (hapedig azis csutortokon mond, jon a frugalware install)
- A hozzászóláshoz be kell jelentkezni
Az USN linkről elindulva megnéztem egy Ubuntus OpenSSL patchet. Masszív, 200kb-s, 6000 soros diff. Ez így tényleg nagyon beteg. Na jó, második ránézésre ebben sok az Ubuntu specifikus komment meg konfigurációs cucc, de a többi? Nem hiszem, hogy egy Ubuntu vagy bármi más disztró használójának olyannyira eltérő OpenSSL-re lenne szüksége. Majdcsak tanulnak belőle.
- A hozzászóláshoz be kell jelentkezni
Nézz meg egy redhatos kernel patchet. Lassan nagyobb, mint maga a kernel.
Ja persze az nem ér, mert a Red Hat ért hozzá, hiszen ott dolgoznak a kernelhackerek.
- A hozzászóláshoz be kell jelentkezni
Ez este mindenkepp bekerul az overlaybe...
- A hozzászóláshoz be kell jelentkezni
Zorp és Shell Control Box userek reszkessenek... (utóbbiak egyébként is ;)
- A hozzászóláshoz be kell jelentkezni
orgyilkos
http://weho.st
never happen if you never try
- A hozzászóláshoz be kell jelentkezni
A ZORP nem érintett mivel Sarge alapú (az openssl egyébként 0.9.8a benne Balabitos patchekkel)
A Balabit elvileg kiad egy Advisory-t, hogy nem értintett, viszont felhívja a figyelmet a problémára.
- A hozzászóláshoz be kell jelentkezni
Mennyire véletlen az a véletlen szám
--
"No trees were destroyed in the sending of this message. However,
a large number of electrons were terribly inconvenienced."
- A hozzászóláshoz be kell jelentkezni
Hogy is volt az a signo? "Barki, aki aritmetikai modszerekkel akar veletlenszamot eloallitani, a bun allapotaban leledzik" vagy valami ilyesmi...
- A hozzászóláshoz be kell jelentkezni
volt egy ilyesmi is:
int rand()
{
int Veletlen_szam=3; //garantaltan veletlen, most dobtam ki 6 oldalu dobokockaval
return Veletlen_szam;
}
- A hozzászóláshoz be kell jelentkezni
tevedsz, a szabvany veletlen szam a 4: http://xkcd.com/221/
(tudomasom szerint a fenti oldal az eredeti forrasa ennek a viccnek)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
az egy idezet Neumann Janostol:
"Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin."
(lsd. pl. http://en.wikipedia.org/wiki/Pseudorandom_number_generator ahol meg a forras is meg van adva)
- A hozzászóláshoz be kell jelentkezni
egy perl progi, amivel lehet detektálni a rossz key-eket
(a lista még nem teljes a program üzenete szerint ...)
http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
debian gnu/linux @ linux-2.6.22.24-op1 | patch
info
- A hozzászóláshoz be kell jelentkezni
legalabb a repo-ba belerakhattak volna...:]
- A hozzászóláshoz be kell jelentkezni
openssh-blacklist - list of blacklisted OpenSSH RSA and DSA keys
igaz nem a script, csak a rossz kulcsok ide-je
szerk.:
man ssh-vulnkey
ssh-vulnkey
debian gnu/linux @ linux-2.6.22.24-op1 | patch
info
- A hozzászóláshoz be kell jelentkezni
A 0.9.8c-1 verziószámú, hibás OpenSSL 2006. 09. 17-én került bele az akkori unstable disztribúcióba és onnan került vissza az etch-be is. A sarge nem érintett ezzel a hibával.
Hiába, Az nem hibázik, aki nem dolgozik, annyiban gáz, hogy ennyi ideig "lappangott".
------------------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni
annyiban gáz, hogy ennyi ideig "lappangott"
manyeyeballs úr mégse dolgozik elég hatékonyan?
- A hozzászóláshoz be kell jelentkezni
hát ha megnézed hány csomag van, és arra mennyi karbantartó+fejlesztő jut, lehet a "many"-t törölnöd is kéne ;-)
---------------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni
"hát ha megnézed hány csomag van (...)"
OpenSSL szintu? Haat, 20 alatt.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Hmm... szvsz inkább számold újra. Azért jóval több "kritikus"-abb csomag van. Kezdheted mindjárt a libc* csomagokkal, kernellel, mielött a "hálózati" csomagokhoz, vagy a biztonsági, titkosító cuccokhoz érsz. ;-)
Ne csak azt számold, amit te használsz... ;-)
Meg aztán próbál(d/játok) egy kicsit más felhasználói szemszögből is.
Nálam pl. az openssl pár éve már nem mission critical. Finoman szólva. :-D
------------------------------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni
"Hmm... szvsz inkább számold újra."
Szamolasrol itt szo sem volt, az ertek hasrautessel jott, de irhattam volna 120-at is, a lenyegen nem valtoztat.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Kicsit utánaolvasgattam a témának:
az látszik, hogy az openssl az entrópiát csak (vagy főként?) inicializálatlan memóriaterületből nyeri. Ezt kivették a debianosok, és akkor jól lecsökkent a kulcsok véletlenszerűsége.
kérdés: ez szerintetek jó eljárás? Amikor még programoztam, simán voltak olyan memóriaterületek, amik egy adott mintával voltak teli, amikor megkaptam. Mondjuk 55 ff 55 ff 55 ff. Ez nekem nem tűnik nagyon jó entrópia forrásnak.
Egyébként meg vicces, hogy itt mindenki fikázza őket, hogy ha nem értenek hozzá, miért javítják... közben ez a Kurt Roecx nevű gyerek még 2006-ban írt az openssl-dev listára, hogy hát itt ez a cucc, és panaszkodik a valgrind, és most akkor mi van... mert talán kivenném az egészet francba, de lecsökken akkor az entrópia
Erre meg azt írták neki, hogy voltaképp nem csinál semmit az egész, vedd ki nyugodtan. :-)
Senki nem írta, hogy eszedbe ne jusson
G
- A hozzászóláshoz be kell jelentkezni
Felettébb ciki. :)
- A hozzászóláshoz be kell jelentkezni
Nem azt irtak neki, hogy forditsa -DPURIFY-al?
http://www.openssl.org/support/faq.html#PROG14
http://wiki.debian.org/SSLkeys / A bit more detail
- A hozzászóláshoz be kell jelentkezni
De. Írták azt is.
Meg valaki más azt írta, hogy nem is kell az, vedd ki nyugodtan.
De azt, hogy figyelj, ki ne vedd, mert az baromira kell, azt nem írta senki.
A -DPURIFY kapcsolóval ha jól értem az volt a gond, hogy nem az a csóka problémázott, aki a hibát javította, és akinek azt mondták, hogy fordítsa purify-jal, hanem ez egy hibajelentés volt, mert valaki nekilátott, és a valgrid ontotta a hibákat.
A hibajegyben ott ment a tökölés, hogy akkor mi legyen, első lehetőség: wontfix. De aztán azt írták, hogy ez így nem lesz jó, mert sokan, akik tesztelnek, itt-ott belefutnak ebbe a hibába.
Ha meg lefordítja -DPURIFY kapcsolóval, és úgy adja ki, az végülis ugyanaz, mint amit a folt csinált: kihagyja belőle ezt az utasítást.
G
- A hozzászóláshoz be kell jelentkezni
NEM!
-DPURIFY-al nem lett volna semmi baj.
Olvassátok már el a kódot!
Vagy itt megpróbáltam leírni a lényeget, meg adtam még egy csomó linket:
http://www.gergely.risko.hu/debian-dsa1571.en.html
Egyébként pedig aki azt mondta, hogy kiveheti, az azt írta oda, hogy "debuggoláshoz kiveheted".
Gergő
- A hozzászóláshoz be kell jelentkezni
"az azt írta oda, hogy "debuggoláshoz kiveheted"."
Pontosabban azt írta, hogy "If it helps with debugging", ez pedig nem azt jelenti, hogy "debuggoláshoz kiveheted".
- A hozzászóláshoz be kell jelentkezni
hát mit jelent?
- A hozzászóláshoz be kell jelentkezni
Azt jelenti, hogy a normális működéshez nincs köze, csak ha debuggolsz, akkor segít.
De egy dolgot értsetek már meg:
Nem arról volt szó, hogy a Deb maintainert zavarta a cucc, mert ő akart debuggolni.
Hanem valami Debian felhasználó valami más program debuggolása során kapta a hibajelzéseket, és ezért egy hibajegyet nyitott.
Teljesen mindegy, hogy XY. újra tudja-e fordítani saját magának debuggoláshoz a libraryt.
Azt próbálták meg elérni, hogy kiadjanak egy libet, ami bárkinél, aki debuggol, nem fog hibákat dobálni.
A srác nem értette, OK. Megkérdezte az OpenSSL levlistán, és ott meg baromira senki nem mondta, hogy figyelj, ez rossz ötlet, nehogy kivedd...
A válaszok alapján az ő helyében simán lehet, hogy hasonlóképp döntöttem volna.
Bár ÉN biztos nem, mert persze én még kevésbé látom át, mint a maintainer, szóval én semmit nem piszkálnék bele abba a kódba :-)
G
- A hozzászóláshoz be kell jelentkezni
>> Azt jelenti, hogy a normális működéshez nincs köze, csak ha debuggolsz, akkor segít.
a debuggolás ideje alatt, és csakis addig
- A hozzászóláshoz be kell jelentkezni
Igen.
Vagyis?
Ha valaminek a normális működéshez nincs köze, csak ha debuggolsz, akkor segít, akkor azt gondolom ostobaság lenne debuggoláshoz kivenni. Nem?
Viszont ha normális működéshez nincs köze, akkor ha nem akarok debuggolni, vagy nincs szükségem a debuggolás közbeni segítségre, akkor kivehetem probléma nélkül.
Én így értelmezném a leírtakat.
És igen, értem, hogy valószínűleg pont fordítva van, mert pont debuggoláshoz nem kell ez a rész (sőt, segít, ha kiveszed, mert nincsenek félrevezető hibaüzenetek), és a normális működéshez meg kellene.
Csak éppen a válaszban nem ez volt. Szegény csóka meg ezek szerint úgy értelmezte a leírtakat, ahogy én is.
Vagy én értek valamit félre? Majd ha lesz időm, újra elolvasom.
G
- A hozzászóláshoz be kell jelentkezni
ennyi erővel akár kiadhatott volna egy libsslfoo-dbg csomagot is, de akkor lehet, hogy még most sem tudnáknk róla, igaz szinte senki nem használná
debian gnu/linux @ linux-2.6.22.24-op1 | patch
info
- A hozzászóláshoz be kell jelentkezni
"a debuggolás ideje alatt, és csakis addig"
Ezt az @openssl.org-os emailcímű emberke írta? (;
- A hozzászóláshoz be kell jelentkezni
ha úgy kérdezed, hogy szájába rágta-e silentfixer barátunknak, hogy a következő napokban milyen billentyűket nyomjon le, és milyen ütemben vegye a levegőt, akkor nem
- A hozzászóláshoz be kell jelentkezni
az látszik, hogy az openssl az entrópiát csak (vagy főként?) inicializálatlan memóriaterületből nyeri.
Hibas. Az openssl rengeteg forrasbol gyujt entropiat, es az egyik ilyen forras az inicializalatlan memoriaterulet. Ha a memoriaterulet alacsony entropiaju, az nem rontja a poolt, ha magas az viszont javitja, tehat nincs vele kockazat.
Ezt kivették a debianosok, és akkor jól lecsökkent a kulcsok véletlenszerűsége.
A Debianosok nem az inicializalatlan memoriaval valo buveszkedest vettek ki, hanem magat entropia pool frissitest (ahol vegul az inicializalatlan memoria olvasasra kerult, es ezaltal a valgrind ott jelzi a problemat).
Szerintem nem kellene teljesen hulyenek nezni az OpenSSL fejlesztoket.
- A hozzászóláshoz be kell jelentkezni
Honnan szerez initcializalatlan memoriat ?
Ujabban divat kinullazni minden lapott, mielott a processe lenne.
- A hozzászóláshoz be kell jelentkezni
1. és? akkor nem hoz be plusz entrópiát, de ettől nem romlik el az algoritmus.
2. "újabban", de nem minden rendszer új ám
3. még ha ki is nullázódik az első hozzáférés előtt, a processz futása közben már mindenféle szemét lesz mindenütt
- A hozzászóláshoz be kell jelentkezni
3. szemet az lesz, de entropia nem lesz belole igy.
- A hozzászóláshoz be kell jelentkezni
csak most akkor ugye miért kell azt a púpozott raklap kulcsot lecserélni, és emberemlékezetig visszamenőleg mindent kompromittáltnak tekinteni
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
ezt mondta v is itt feletted, nem értettem miért pont a memóriaterülettel van gondod az eset kapcsán, de most már értem mire akartál kilyukadni
- A hozzászóláshoz be kell jelentkezni
(Valoban , nem olvastam ujra a szalat mielott valszoltam)
Nem az eset kapacsan, de az a bajom, hogy szerintem rossz entropia forras.
- A hozzászóláshoz be kell jelentkezni
én sem voltam elég körültekintő, elnézést
- A hozzászóláshoz be kell jelentkezni
The second law of debian
The total entropy of any system tends to increase over time, if you don't use stupid debian patches.
- A hozzászóláshoz be kell jelentkezni