Informatika

  • Ha nem vagy kibékülve az alapértelmezettnek beállított sötét sablonnal, akkor a korábbi ígéretnek megfelelően bármikor átválthatsz a korábbi világos színekkel dolgozó kinézetre.

    Ehhez görgess a lap aljára és a baloldalon keresd a HTKA Dark feliratú gombot. Kattints rá, majd a megnyíló ablakban válaszd a HTKA Light lehetőséget. Választásod a böngésződ elmenti cookie-ba, így amikor legközelebb érkezel ezt a műveletsort nem kell megismételned.
  • Az elmúlt időszak tapasztalatai alapján házirendet kapott a topic.

    Ezen témában - a fórumon rendhagyó módon - az oldal üzemeltetője saját álláspontja, meggyőződése alapján nem enged bizonyos véleményeket, mivel meglátása szerint az káros a járványhelyzet enyhítését célzó törekvésekre.

    Kérünk, hogy a vírus veszélyességét kétségbe vonó, oltásellenes véleményed más platformon fejtsd ki. Nálunk ennek nincs helye. Az ilyen hozzászólásokért 1 alkalommal figyelmeztetés jár, majd folytatása esetén a témáról letiltás. Arra is kérünk, hogy a fórum más témáiba ne vigyétek át, mert azért viszont már a fórum egészéről letiltás járhat hosszabb-rövidebb időre.

wolfram

Well-Known Member
2011. július 30.
5 651
3 685
113
Innen: http://htka.hu/kozosseg/discussion/47979/biztpol-oroszorszag-es-a-szovjetunio-utodallamai/p102

a) kiszervezett gyártással nincsenek biztonságban: http://www.tripwire.com/state-of-security/security-data-protection/backdoors-hardware-attacks-backdoors-inserted-gate-level-4/ (ez nem kamu cikk, az eredeti is megvanvalahol, valamelyik nagy tudományos folyóiratban adták le, az arXiv -on találtam)

Na igen, eléggé durva (egyébként én is olvastam valamikor, csak már nem emlékeztem rá). Elméletben elképzelhető és tényleg nagyon nehéz lenne észrevenni/kivédeni, amennyiben bérgyártóval gyártatsz. De! A cikkben taglalt eljárás, ha jól értem, leginkább a dedikált hardveres véletlenszámgenerátoroknál (és talán az AES-NI és hasonlók hardveres gyorsításáért felelős részeknél) működhetne igazán, tehát, amennyiben tisztán szoftveres eljárásokat használsz (ez ugyan lassabb lesz és a véletlenszámok generálása esetén talán nem is annyira "véletlen", mint egy nem mókolt hardveres, de ez az ára az akár megalapozott paranoiának), akkor nem akkora veszély.


Mellesleg a windows forráskódját is ismerik, az MS megfelelő bizalmi szintű partnereknek átadja azt. Akár újra is fordíthatják maguknak, ha abban jobban bízak, csak tovább nem adhatják.

Ez igaz. De ha speciális igényeik is vannak, akkor még mindig jobban járnak egy Unix/Linux variánssal, ahol tetszőlegesen bele is nyúlhatnak a kernelbe.

A Linux us tele van hátó kapukkal,

Szintén igaz lehet, bár én nem a "hátsó kapu", inkább a "biztonsági hiba" kifejezést használnám arra, amivel esetleg "<b>tele</b> van". És Windowsban legalább ennyi van, plusz a szándékos hátsó ajtók, csak ugye, a zárt forrás miatt jóval kevesebben láthatnak rá.

de persze mind "ártalan programozási hibának" van álcázva, mint pl az OpenBSD pár éve felfedezett hibája, amikor "elfelejtették" a véletlenszám generátorban az egész tározót megkutyulni, csak 1 byteot randomizáltak...

És ezzel mégis mi a fenét akarsz mondani? Hogy minden Unix-szerű, valóban nyílt forrású oprendszer csakis azért létezik, hogy a biztonság hamis illúzióját keltve jól átverje az embereket? :D Igen bazdmeg, előfordulnak minden kódban hibák és néha átcsúszhat pár a validáción is, ha van olyan, akár még szándékos rosszindulatú kód is. Na és? Aztán észreveszik, javítják. 100%-ig hibátlan és biztonságos szoftver nem létezik.

Az elbrus oprendszere lehet, hogy linux, de: https://www.youtube.com/watch?v=mceI07NeIt0

Szuper, futtatja a Windowst, az x86 utasításkészlet emulációjával, és? Mit akarsz ezzel mondani?

A Linux biztonságosabb csak egy legenda. Biztonságosabb az open source alapból? OpenBSD random pool, debian openssh random pool patch, heartbleed... csak hogy az igazán súlyosakat említsem.

Ismét csak, és? A nyílt forrás nem azt jelenti, hogy emiatt teljesen hibamentes, vagy te azt hitted? XD A Windowsban (és a többi májkrémszaft termékben) persze egy hiba sincs (backdoorról nem is beszélve), nem volt és nem is lesz, ugye? :D És, hogy biztonságosabb-e az open source által nyújtot transzparencia? Naná!

Ami azt illeti, az arrogáns opensource fejlesztők további biztonsági funkciók beépítését szabotálják úgy,hogy közben visszafele sem kompatibilisek.

Forrás, vagy valami a szándékos szabotálásra?

megmondjam hányan validálják a változásokat? sehányan! Aztán linux elkezd bunkó anyázó leveleket írni, hogy hogy csinálhattál ekkora fszságot, ha kilóg a lóláb! Sírnak-rának, hogy az MS miért hetek, hónapok után ad javítást egy hibára, és miért csak gyorsfixet ad elsőre. Megmondom, mint a SW iparban dolgozó: validálják a változásokat! Tesztelik hogy milyen mellékhatásai lennének, a kompatibilitásra hogyan hat, többezer különféle SW-re, többezer különféle hw konfiguráción. Mi van a Linux esetében erre? ha linuxnak a reptéren lefordul a kernelfa, akkor kiadja. Ennyi.

Persze, senki nem validálja....Linus meg egy seggfej, ugye? Meg mindenki más, akinek tetszik a nyílt forráskód és veled ellentétben nem cuppan rá önzetlenül a Ballmer-félék hosszúcicijére, ahányszor csak alkalma adódik rá. Hát tudom én! XD
 

wolfram

Well-Known Member
2011. július 30.
5 651
3 685
113
Nem arról beszéltem, hogy egy ember fejleszti, hanem egy műsorban amikor Linus Torvalds meg volt hívva, feltették neki a kérdést, hogy kapott-e az amerikai kormánytól olyan parancsot, hogy backdoort építsen be a kernelbe. Ezt elárulni bűncselekmény Amerikában, szóval nem mondhatta el. A válasza "nem" volt, de közben úgy bólógatott, hogy a vak is láthatta mi van.
http://www.youtube.com/watch?v=7gRsgkdfYJ8

Én úgy értettem (párszor meghallgattam), hogy azt mondta, "do", vagyis hogy beletette és bólogatott hozzá. Nekem viccelésnek tűnik, amin nevettek is.

Tudom, hogy open source, csak ez biztonsági szempontból semmi pluszt nem ad.

Szerintem meg igen. Egyrészt, mert nyílt, ezért a "több szem többet lát" érvényesül, másrészt, mert feltételezhetően a fejlesztők túlnyomó többségének nem érdeke, hogy szándékosan backdoort, vagy más rosszindulatú kódot tegyen bele. Míg egy cégnél, mint a Microsoft, elég csak a vezetőknek kiadni a parancsot és már megy is bele a kívánt kód.

Tudod, hogy ez hány sornyi kódot jelent? Tízmilliónál is sokkal többet. A szándékosan elhelyezett backdoor-okat pedig semmivel sem könnyebb észrevenni, mint a véletlen programozói hibákat. Mégis hogyan állítanád össze a csapatot, amely megbízható módon ellenőrzi a kernelt?

Ja, úgy 20 millió sor körül lehet most. Hát, rá kéne állítani jópár embert, az biztos. De ha annyira biztosra akarnak menni...

Szerintem CAD/CAM témakörben az AC(nem, nem Assasins Creed kedves kocka Barátaim hanem AutoCAD) illetve a személyes szerelmem az Inventor viszi a prímet. Mind a kettőhöz igény esetén lehet plusz modulokat vásárolni, melyek egy-egy adott szakterületre vannak beállítva. A professinonal verziót lelehet szedni ingyenesen student licenszel (én otthon ezt használom, iskolában pedig más licenszet használtunk).
http://www.autodesk.hu/products/autodesk-inventor-family/overview

Mondjuk a CAD-nél én a komolyabbakra, mint pl. a CATIA gondoltam, amikkel hajókat, tengókat, meg repülőket terveznek. :) De ingyenes, nyílt forrásúak között ott van a BRL-CAD is, bár az ugye eléggé kötődik az amerikai hadsereghez. :D
 

xeqev

Member
2013. szeptember 19.
130
0
16
Ez igaz. De ha speciális igényeik is vannak, akkor még mindig jobban járnak egy Unix/Linux variánssal, ahol tetszőlegesen bele is nyúlhatnak a kernelbe.
Ja, aztán a változtatásaikat szépen ki kellene adniuk, legalábbis ha be akarják tartani a felhasználási feltételeket. :)
Szintén igaz lehet, bár én nem a "hátsó kapu", inkább a "biztonsági hiba" kifejezést használnám arra, amivel esetleg "tele van". És Windowsban legalább ennyi van, plusz a szándékos hátsó ajtók, csak ugye, a zárt forrás miatt jóval kevesebben láthatnak rá.
Jelenleg nincs bizonyíték arra, hogy backdoor-ok lennének a Windows-ban, talán vannak, talán nincsenek. (Szerintem vannak.) De az oroszoknak ez a bizonytalanság elfogadhatatlan (kellene, hogy legyen), csakhogy ugyanez a bizonytalanság fennáll a Linux esetében is, az sem elfogadható, nincs rá ok, hogy más elbírálás alá essen, csak azért, mert nyílt forráskódú rendszer.
100%-ig hibátlan és biztonságos szoftver nem létezik.
Ezt a kijelentésedet nem hiszem, hogy alá tudod támasztani valamivel.
Linus meg egy seggfej, ugye? Meg mindenki más, akinek tetszik a nyílt forráskód
Éppenséggel Linus valóban az, elég csak elolvasni néhány megnyilvánulását a fejlesztői levelezőlistákon. A nyílt forráskóddal meg nincs baj, csak néhány túlbuzgó rajongójával akik olyan állításokkal állnak elő amiket nem tudnak objektív tényekkel megtámogatni.
 

xeqev

Member
2013. szeptember 19.
130
0
16
Szerintem meg igen. Egyrészt, mert nyílt, ezért a "több szem többet lát" érvényesül, másrészt, mert feltételezhetően a fejlesztők túlnyomó többségének nem érdeke, hogy szándékosan backdoort, vagy más rosszindulatú kódot tegyen bele. Míg egy cégnél, mint a Microsoft, elég csak a vezetőknek kiadni a parancsot és már megy is bele a kívánt kód.
A kernelfejlesztők túlnyomó része amerikai cégek alkalmazásában áll, és feltételezhetően ők is azt teszik amit a feletteseik utasítanak nekik.
Ja, úgy 20 millió sor körül lehet most. Hát, rá kéne állítani jópár embert, az biztos. De ha annyira biztosra akarnak menni...
Ja, de hogy állítod össze azt a csapatot amely 100%-os bizonyossággal megtalálja az összes sebezhetőséget/backdoor-t? Mert ha csak 90%-os valószínűséggel találnak meg egy biztonsági hibát, az a rendszerbe vethető bizalom szempontjából éppen olyan, mintha 0%-os valószínűséggel találnák meg.
 

bartinieffektus

Well-Known Member
2012. december 4.
1 122
267
83
<blockquote rel="bartinieffektus">Ezzel dolgozok. Az nem a Linux hibaja, hanem rosszul volt felallitva az infrastruktura
A statisztika amit linkeltem a Linux kernel 2.6-os ágában azonosított sebezhetőségekről (biztonsági hibákról) szól. Nincs ennek köze más szoftverhez, sem üzemeltetési dolgokhoz. Bocs, de a hozzászólásaid alapján az önbizalmad amellyel az állításaidat előadod a Dunning–Kruger hatásból ered: http://hu.wikipedia.org/wiki/Dunning%E2%80%93Kruger_hat%C3%A1s.

Amúgy én boldogan folytatom a diskurzust, de szerintem eljutottunk oda, hogy inkább másik helyen kellene... (Ahogy arra Joker is utalt.)</blockquote>

Komolyan, nezzel utanna, hogy mi a kulonbseg a Linux Kernel es egy Linux Server kozott.
 

Veér István

Well-Known Member
2011. február 14.
3 416
6 652
113
Először is: szoftver fejlesztő vagyok, talán több rálátásom van ezeknek a működésére, mint pl. egy gépésznek vagy "áltaános managernek". Ezért is nem hegesztéses témánál osztom az észt. Akinek nem inge ne vegye ezt magára.

Innen: http://htka.hu/kozosseg/discussion/47979/biztpol-oroszorszag-es-a-szovjetunio-utodallamai/p102
<blockquote rel="Veér István">a) kiszervezett gyártással nincsenek biztonságban
... és tényleg nagyon nehéz lenne észrevenni/kivédeni, amennyiben bérgyártóval gyártatsz. ... ha jól értem, leginkább a dedikált hardveres véletlenszámgenerátoroknál (és talán az AES-NI és hasonlók hardveres gyorsításáért felelős részeknél) működhetne igazán, tehát, amennyiben tisztán szoftveres eljárásokat használsz ... akkor nem akkora veszély.
</blockquote>
  1. egyáltalán nem felderíthető utólag nem desktruktív módszerekkel
  2. az egész kriptográfia a jóminőségű véletlenszámokon múlik
  3. szoftveres véletlenszám? úgy hiszem nem vagy járatos a kriptográfiában. A lényeg: a szoftver determinisztikus. PRNG lehet sw-es, de az komoly kriptora alkalmatlan.

<blockquote rel="Veér István">Mellesleg a windows forráskódját is ismerik, az MS megfelelő bizalmi szintű partnereknek átadja azt.
Ez igaz. De ha speciális igényeik is vannak, akkor még mindig jobban járnak egy Unix/Linux variánssal, ahol tetszőlegesen bele is nyúlhatnak a kernelbe.
</blockquote>
Lehet bele drivereket írni a kernel módosítása nélkül. Lehet bővíteni, ugynis olyan architektúrát terveztek neki a kezdetektől, hogy a mag módosítása nélkül lehessen bővíteni... Ez nevezik angolul Software Engineering-nek, ami az OSS projektekre ritkán jellemző.

Szintén igaz lehet, bár én nem a "hátsó kapu", inkább a "biztonsági hiba" kifejezést használnám arra, amivel esetleg "<b>tele</b> van". És Windowsban legalább ennyi van, plusz a szándékos hátsó ajtók, csak ugye, a zárt forrás miatt jóval kevesebben láthatnak rá.
A szándékos hátsó ajtó a windowsban semmivel sem valószínűbb, mint a linuxban. Mindkettőbe álcázva csempészik bele fedett ügynökök az ilyeneket. Szok fogalmatlan amatőr hobbista "segít".
http://hup.hu/cikkek/20101215/az_fbi_fejlesztoket_fizetett_azert_hogy_azok_hatso_kapukat_epitsenek_az_openbsd_crypto_keretrendszerebe
Ami azt illeti, az openbsd azt állította, hogy minden commitot megreviewztak. Mégis átcsúszott. Nagyon súlyos következményeyei voltak (mindössze 1 byte entrópia a random poolban: nem véletlenek a véletlenszámok)
Ugyenez a debiannál: http://hup.hu/cikkek/20080513/biztonsagi_hiba_az_openssl-ben_egy_debian-os_patch_miatt
Ugyanez az openssl-nél: http://hup.hu/cikkek/20140408/heartbleed_bug_sulyos_openssl_sebezhetoseget_javitottak

<blockquote rel="Veér István">"ártalan programozási hibának" van álcázva, mint pl az OpenBSD pár éve felfedezett hibája
És ezzel mégis mi a fenét akarsz mondani? Hogy minden Unix-szerű, valóban nyílt forrású oprendszer csakis azért létezik, hogy a biztonság hamis illúzióját keltve jól átverje az embereket? :D Igen bazdmeg, előfordulnak minden kódban hibák és néha átcsúszhat pár a validáción is, ha van olyan, akár még szándékos rosszindulatú kód is. Na és? Aztán észreveszik, javítják. 100%-ig hibátlan és biztonságos szoftver nem létezik.
</blockquote>
Azt akarom mondani, hogy a vallási fanatikusok érveinek ellenére az opensource semmi pluszt nem ad.
Ezernyi példát lehet erre felhozni. Egy példa az említett openbsd-s backdoorra (lásd fent), mivel az openbsd volt sokáig a legnagyobb arcú mennyire biztonságosak vagyunk paprikajancsi banda. Emellett a windowsban több aktív és passzív védelmi rendszer van mint a linuxban, ami még a legjobban áll ilyen téren az open source operációs rendzserek közt (némileg le van maradva, többek közt PaXteam munkásságának szabotálása miatt).
A forráskód egyébiránt a biztonsági elemzéshez egyáltalán nem szükséges. Számos eszköz áll a szakértő kezek rendelkezésére, például a méltán híres IDA Pro.
Szuper, futtatja a Windowst, az x86 utasításkészlet emulációjával, és? Mit akarsz ezzel mondani?
Azt, hogy az x86 emulációt miért tették bele, ha csak linuxot akarnának futtatni rajta? Egyébiránt az elbrus eléggé zsákutcának tűnik. A VLIW jövője kétséges, nem vagyok meggyőzve a megközelítés optimális mivoltáról (hogy miért: az IA64 bukásánál közrejátszó technikai tényezők áttanulmányozását javaslom).
<blockquote rel="Veér István">A Linux biztonságosabb csak egy legenda.
Ismét csak, és? A nyílt forrás nem azt jelenti, hogy emiatt teljesen hibamentes, vagy te azt hitted? XD A Windowsban (és a többi májkrémszaft termékben) persze egy hiba sincs (backdoorról nem is beszélve), nem volt és nem is lesz, ugye? :D És, hogy biztonságosabb-e az open source által nyújtot transzparencia? Naná!
</blockquote>
Májkrémszaft... Rendben, ennek ellenére megpróbálkozom észérvekkel.
Nem a hibátlanság a kérdés. Egyfelől az nehezet (tipikusan sehogy sem) bizonyítható, egyáltalán a helyes működés specifikációja feltétel. Az általános minőség. Amellett, hogy egy kereskedelni vendor számára a profit maximalizálsá fontos, támogatást is ad, és a vevők visszatérését is várja jó esetben (az IBM pl nem ilyen, aki használta már szoftvereik tudja, hogy fájdalom a termékeik többségének használata.)
Az opensource transzparencia semmit sem jelent. Mellesleg a Microsoft rengeteg fontos termékt open sourcccá, de legalábbis nyilvánosan olvashatóvá tett. Az, hogy az opensourcehoz bárki hozzájárulhat, kockázatokat rejt. Az, hogy nem feltétlen felügyelt folyamatok mentén történik a változások befogadása, szintén további kockázatokat rejt.
url az openbsd-s bugra fentebb.

<blockquote rel="Veér István">Ami azt illeti, az arrogáns opensource fejlesztők további biztonsági funkciók beépítését szabotálják úgy,hogy közben visszafele sem kompatibilisek.
Forrás, vagy valami a szándékos szabotálásra?
</blockquote>
http://pax.grsecurity.net/
A kernelbe olvasztásától elzárkóznak a fejlesztők. A (magyar) készítő tavaly életműdíjat kapott az ITsec terén végzett munkásságáért. A windowsban előbb implementálták az általa leírt módszereket hivatalosan, mint a linuxba befogadták volna a rendzseresen küldött patcheit.
Az Ulrich Drepper nevű idióta is híres a hibák letagadásáról, amik többször biztonsági vonatkozásúak is. Szlogenje: stop reopening the bug. Annyi probléma van csupán, hogy a glibc karbantartója.
Az opensource hozzállásról amúgy tanúskodik az is, hogy a bugzilla F/OSS hibakezelőben van olyan kimenetel, hogy WONTFIX. Ez a hozzállásról sokat elmond. Persze önkéntesektől nem vrható el az, hogy a móka és kacagás részen túl (alkotó munka) mondjuk unalmas és pepecs dolgokat is csináljanak (unit tesztek, regressziós tesztek, integrációs tesztek, funkcionális specifikáció, funkcionális tesztek, dokumentáció írás, satöbbi, de ezek másutt megtörténnek. Nem lelkes, nem boldog, de megfizetett emberek által.)
 

Veér István

Well-Known Member
2011. február 14.
3 416
6 652
113
<blockquote rel="Veér István">megmondjam hányan validálják a változásokat? sehányan! Aztán linux elkezd bunkó anyázó leveleket írni, hogy hogy csinálhattál ekkora fszságot, ha kilóg a lóláb! Sírnak-rának, hogy az MS miért hetek, hónapok után ad javítást egy hibára, és miért csak gyorsfixet ad elsőre. Megmondom, mint a SW iparban dolgozó: validálják a változásokat! Tesztelik hogy milyen mellékhatásai lennének, a kompatibilitásra hogyan hat, többezer különféle SW-re, többezer különféle hw konfiguráción. Mi van a Linux esetében erre? ha linuxnak a reptéren lefordul a kernelfa, akkor kiadja. Ennyi.
Persze, senki nem validálja....Linus meg egy seggfej, ugye? Meg mindenki más, akinek tetszik a nyílt forráskód és veled ellentétben nem cuppan rá önzetlenül a Ballmer-félék hosszúcicijére, ahányszor csak alkalma adódik rá. Hát tudom én! XD</blockquote>
</blockquote>
  • Linus egy seggfej
  • a QA annyi, hogy lefordul-e a kód. Néha annyi sem: https://lkml.org/lkml/2013/9/2/402
A hosszúcicis részt nem is veszem figyelembe. Azt kell gyanítsam, hogy bár nem vagy @bartinieffektus szintjén fogalom nélkül a témában, de neked is több előítéleted mint szakértelmed van a szoftver fejlesztésről (te esetleg üzemeltetésben jártas lehetsz, úgy látom)

A lényeg: ez a jéghegy csúcsa. Az opensource szart sem ér biztonsági szempontból. Nem jobb. Nem állítom, hogy szükségszerűen rosszabb. Ráadásul a nagy vevők megkapják a kódot elemzésre. A fordítót is, mindent, ellenőrizhetik, hogy a binárisok azok-e amik a kapott kódból fordulnak. A kódot statikus elemzővel mindenüztt nézik, de egy nagy kereskedelmi cégnél nagyobb valószínűséggel.
 

xeqev

Member
2013. szeptember 19.
130
0
16
Komolyan, nezzel utanna, hogy mi a kulonbseg a Linux Kernel es egy Linux Server kozott.
A kernel az egyetlen olyan komponens amely szükségszerűen
része minden Linux alapú szervernek. És a kernel kódbázisában szereplő hibák ezáltal eljutnak az egyes disztribúciókig. Bár az igaz hogy magasabb rétegekben futó komponensek vagy egyes opcionális kernelmodulok adott esetben megnehezíthetik/ellehetetleníthetik <b>bizonyos</b> sebezhetőségek kihasználását, még így is akad bőven.
 

wolfram

Well-Known Member
2011. július 30.
5 651
3 685
113
Ja, aztán a változtatásaikat szépen ki kellene adniuk, legalábbis ha be akarják tartani a felhasználási feltételeket. :)

Ha belső (kormányzati, stb.) használatra szánják, éspedig arra akarják az ARM-os procijukat is leginkább, akkor ez nem hinném, hogy túlzottan érdekelné őket...


Jelenleg nincs bizonyíték arra, hogy backdoor-ok lennének a Windows-ban, talán vannak, talán nincsenek. (Szerintem vannak.) De az oroszoknak ez a bizonytalanság elfogadhatatlan (kellene, hogy legyen), csakhogy ugyanez a bizonytalanság fennáll a Linux esetében is, az sem elfogadható, nincs rá ok, hogy más elbírálás alá essen, csak azért, mert nyílt forráskódú rendszer.

Teljesen egyértelmű bizonyíték nincs, de ott volt az NSAKEY-ügy, meg most a Win 8-cal és a TPM 2.0-val megy a cirkusz... Szóval az erős gyanú azért fennáll. Igen, a Linux esetében is elképzelhető, hogy akad benne szándékos backdoor. De szerintem kisebb az esélye.


Ezt a kijelentésedet nem hiszem, hogy alá tudod támasztani valamivel.

Igazad van, nem fogalmaztam elég pontosan. Akkor mégegyszer, bizonyos nagyságrendnél, vagyis az akár többmillió soros kódok esetén, nem lehet azt feltételezni, hogy teljesen hibamentesek lehetnek.
Alátámasztás? Nézz szét az űrhajózásban, vagy a katonai rendszereknél, amik pedig a lehető legjobban "hibaellenőrzöttek".

Egy példa, szénné tesztelt OS és programok esetén:
http://www.defenseindustrydaily.com/f22-squadron-shot-down-by-the-international-date-line-03087/
Vagy egy másik:
http://en.wikipedia.org/wiki/Cluster_%28spacecraft%29#Launch_failure
De akad még jópár ilyen és ezek csak a valóban súlyos és publicitást is kapott hibák.



A kernelfejlesztők túlnyomó része amerikai cégek alkalmazásában áll, és feltételezhetően ők is azt teszik amit a feletteseik utasítanak nekik.

Egy részük pedig nem és ha ők észrevesznek valamit, akkor azt szóvá teszik. Ezzel szemben egy cégnél ugye van szerződés, meg titoktartási kötelezettség és ezért bármit is "lásson" az alkalmazott, ha nem akar egy komoly pert (amit garantáltan el is veszítene) kapni a nyakába, akkor szépen befogja a pofáját. Ha meg az NSA is benne van, akkor még hazaárulással is vádolhatnák a kiszivárogtatásért, ezért aztán biztosan be is fogja fogni. Snowden sorsán kevesen akarnának osztozni.


Ja, de hogy állítod össze azt a csapatot amely 100%-os bizonyossággal megtalálja az összes sebezhetőséget/backdoor-t? Mert ha csak 90%-os valószínűséggel találnak meg egy biztonsági hibát, az a rendszerbe vethető bizalom szempontjából éppen olyan, mintha 0%-os valószínűséggel találnák meg.

Ha teljesen saját oprendszert írna az a bizonyos csapat, annál sem lehetne 100%-os hibamentesség, mint ahogy írtam is fentebb, ebből következően 100%-os biztonsági hibamentesség sem.
Csak a szándékos backdoort lehetne igen nagy eséllyel kizárni úgy. Akkor meg, ha szerinted csakis a 0%-os hibalehetőség az elfogadható, akkor mi a megoldás?
 

wolfram

Well-Known Member
2011. július 30.
5 651
3 685
113
  1. egyáltalán nem felderíthető utólag nem desktruktív módszerekkel
  2. az egész kriptográfia a jóminőségű véletlenszámokon múlik
  3. szoftveres véletlenszám? úgy hiszem nem vagy járatos a kriptográfiában. A lényeg: a szoftver determinisztikus. PRNG lehet sw-es, de az komoly kriptora alkalmatlan.

1. Minden szériából pár darabot szúrópróbaszerűen szétkaphatnak nyugodtan, vizsgálat céljából. Persze ennek csak akkor van értelme, ha tudják, mit keressenek és hol...

2. Tudom.

3. Nem túlzottan, az igaz. De akkor sem értek egyet azzal, hogy a nem "dedikált hardveres" véletlenszámgenerátor nem alkalmas "komoly kriptora". Tudom, kissé már elcsépelt példa, de:
http://news.techworld.com/security/3228701/fbi-hackers-fail-to-crack-truecrypt/
És feltételezem, az NSA sem szórakozott volna ezzel, ha annyira könnyű lenne törni az olyan titkosítást, amihez szoftveres PRNG-vel generált véletlenszámokat használtak:
http://en.wikipedia.org/wiki/Dual_EC_DRBG



A szándékos hátsó ajtó a windowsban semmivel sem valószínűbb, mint a linuxban. Mindkettőbe álcázva csempészik bele fedett ügynökök az ilyeneket. Szok fogalmatlan amatőr hobbista "segít".
http://hup.hu/cikkek/20101215/az_fbi_fejlesztoket_fizetett_azert_hogy_azok_hatso_kapukat_epitsenek_az_openbsd_crypto_keretrendszerebe
Ami azt illeti, az openbsd azt állította, hogy minden commitot megreviewztak. Mégis átcsúszott. Nagyon súlyos következményeyei voltak (mindössze 1 byte entrópia a random poolban: nem véletlenek a véletlenszámok)
Ugyenez a debiannál: http://hup.hu/cikkek/20080513/biztonsagi_hiba_az_openssl-ben_egy_debian-os_patch_miatt
Ugyanez az openssl-nél: http://hup.hu/cikkek/20140408/heartbleed_bug_sulyos_openssl_sebezhetoseget_javitottak

A BSD-s, FBI-os téma tényleg kemény! De legalább kiderült. A másik kettő meg, nos, előfordulnak ilyenek. Bár, mind a kettő kb. 2 évig "élt", az azért nem kevés...


Azt akarom mondani, hogy a vallási fanatikusok érveinek ellenére az opensource semmi pluszt nem ad.

Szerintem nagyobb eséllyel derül ki (a nyilvánosság számára is) egy nyílt forrású cuccnál akár a backdoor, akár a hiba (ez utóbbi széles körű ismertté válása persze nem feltétlenül jó, ha még nincs rá javítás), mint egy zártnál.


Azt, hogy az x86 emulációt miért tették bele, ha csak linuxot akarnának futtatni rajta?

Nem tudom... Talán szélesebb körben is forgalomba akarták, akarják hozni, konkurenciát akartak állítani (legalább) az orosz piacon az AMD és Intel prociknak, ehhez pedig kell az x86 (és Windows) támogatás. Mert azért úgy minimum 80% a Windowsok részesedése desktopon globálisan is és ezt nem hagyhatták figyelmen kívül.
Egyébként ARM-ra is akarnak x86 emulátort:
http://www.xbitlabs.com/news/cpu/display/20121002212516_Startup_Develops_x86_Emulator_for_ARM_Microprocessors.html


Egyébiránt az elbrus eléggé zsákutcának tűnik. A VLIW jövője kétséges, nem vagyok meggyőzve a megközelítés optimális mivoltáról (hogy miért: az IA64 bukásánál közrejátszó technikai tényezők áttanulmányozását javaslom).

Egyetértek. Én is azt írtam itt korábban, hogy a VLIW, mint olyan, nem szerencsés választás és persze az Itaniummal példálóztam, merthogy adja magát a párhuzam.



Az, hogy az opensourcehoz bárki hozzájárulhat, kockázatokat rejt. Az, hogy nem feltétlen felügyelt folyamatok mentén történik a változások befogadása, szintén további kockázatokat rejt.

Itt ugye állami szintről beszélünk, mármint az oroszoknál és ez esetben. Nekik nem kell minden szart implementálniuk a saját, secure rendszerükhöz, olyasmiket, amivel "bárki hozzájárult".
Fognak egy végletekig lecsupaszított kernelt, aztán tetszőlegesre szabják, meg hozzáteszik, ami nekik kell. Van egy csomó programozó arrafelé, akik jók is, legfeljebb csinálnak egy céget,
aminek a feladata a saját rendszerük karbantartása és fejlesztése lesz, házon belül. Egyfajta hardverre kell optimalizálniuk, a saját ARM-jukra, emiatt rengeteg dolog egyszerűbb is lesz.


http://pax.grsecurity.net/
A kernelbe olvasztásától elzárkóznak a fejlesztők. A (magyar) készítő tavaly életműdíjat kapott az ITsec terén végzett munkásságáért. A windowsban előbb implementálták az általa leírt módszereket hivatalosan, mint a linuxba befogadták volna a rendzseresen küldött patcheit.
Az Ulrich Drepper nevű idióta is híres a hibák letagadásáról, amik többször biztonsági vonatkozásúak is. Szlogenje: stop reopening the bug. Annyi probléma van csupán, hogy a glibc karbantartója.

Ja, megtaláltam, hát szép... http://bug-chasers.blogspot.hu/2011/03/just-use-supported-kernel-stop.html

A PaX esetén viszont, az hogy nem teszik bele a kernelbe, egy dolog, viszont a grsecurity pakkot a vanilla kernelre bárki felrakhatja, aki akarja.

Az opensource hozzállásról amúgy tanúskodik az is, hogy a bugzilla F/OSS hibakezelőben van olyan kimenetel, hogy WONTFIX.

Nem néztem ugyan utána, de nem hinném, hogy a kritikus biztonsági hibák wontfixet kapnának...


Ez a hozzállásról sokat elmond. Persze önkéntesektől nem vrható el az, hogy a móka és kacagás részen túl (alkotó munka) mondjuk unalmas és pepecs dolgokat is csináljanak (unit tesztek, regressziós tesztek, integrációs tesztek, funkcionális specifikáció, funkcionális tesztek, dokumentáció írás, satöbbi, de ezek másutt megtörténnek. Nem lelkes, nem boldog, de megfizetett emberek által.)

Hát azért most, ha nagyon akarnék, tudnék jópár olyan példát hozni, ahol ismert a hiba, csak a kedves gyártó leszarja és valószínűleg az életben nem lesz rá javítás, vagyis patch. Következő kiadásban (amit persze meg kell venni pénzért) majd javítják...
 

wolfram

Well-Known Member
2011. július 30.
5 651
3 685
113
  • Linus egy seggfej
  • a QA annyi, hogy lefordul-e a kód. Néha annyi sem: https://lkml.org/lkml/2013/9/2/402

Jó, elismerem, néha tényleg seggfej. De ettől még nem lesz mindenki az, akinek tetszik az open source.

A lényeg: ez a jéghegy csúcsa. Az opensource szart sem ér biztonsági szempontból. Nem jobb.

Az USA védelmi minisztériuma szerint elég jó pedig. :D
http://www.spi.dod.mil/lipose.htm

Nem állítom, hogy szükségszerűen rosszabb.

Közelednek az álláspontok. :) Nem rosszabb. Akkor meg miért ne használhatnának open source (alapú) rendszert a "paranoiás" ruszkik? Azzal sem lesz nekik rosszabb, mintha Windowst használnának.


A hosszúcicis részt nem is veszem figyelembe. Azt kell gyanítsam, hogy bár nem vagy @bartinieffektus szintjén fogalom nélkül a témában, de neked is több előítéleted mint szakértelmed van a szoftver fejlesztésről (te esetleg üzemeltetésben jártas lehetsz, úgy látom)

Az annak az arroganciának és személyeskedésednek szólt csupán, amivel indítottál. Amúgy jól látod, nem vagyok szoftverfejlesztő. :) De nem is állítottam ilyet soha.
 

xeqev

Member
2013. szeptember 19.
130
0
16
Ha teljesen saját oprendszert írna az a bizonyos csapat, annál sem lehetne 100%-os hibamentesség, mint ahogy írtam is fentebb, ebből következően 100%-os biztonsági hibamentesség sem.
Csak a szándékos backdoort lehetne igen nagy eséllyel kizárni úgy. Akkor meg, ha szerinted csakis a 0%-os hibalehetőség az elfogadható, akkor mi a megoldás?
Amint azt írtam egy informatikai rendszer biztonsága az én véleményem szerint egy bináris változó: biztonság vagy van, vagy nincs. Ennek ellenére is lennének biztonsági előnyei egy saját rendszer létrehozásának, még akkor is, ha elfogadjuk az állításodat, miszerint nem lehet bizonyos komplexitási szint felett hibátlan rendszert létrehozni. (Bár ez az állítás nem hinném, hogy formális módszerekkel bizonyítható.)

Hogy miért? Onnantól kezdve, hogy egy rendszer hibákat, potenciális behatolási pontokat tartalmaz, már csak a befektethető erőforrások mennyiségén múlik, hogy ezeket sikerül-e kihasználni. Csakhogy amíg a Linux esetében ezt pontosan 0 (nulla) dollár befektetéssel végre tudja hajtani az, aki ismeri a feltehetően jelen lévő backdoor-okat, addig egy új, saját fejlesztésű rendszer esetében ez már tényleges befektetést igényel. A bevethető erőforrások (pénz, ember) pedig véges mennyiségben állnak rendelkezésre, még az amerikai kormányzat számára is.

A másik dolog pedig, hogy egy új rendszer esetében lehetőség lenne végre szakítani azzal a 40 éves architektúrával, amelyre a Linux épül. Ennek biztonsági vonzata is lenne, ugyanis valószínűleg NAGYSÁGRENDEKKEL csökkenteni lehetne a fajlagos hibaarányt a 2014-es év technológiai fejlettségének megfelelő tervezési paradigmák alkalmazásának segítségével.
 

xeqev

Member
2013. szeptember 19.
130
0
16
Bocs, az előző hozzászólásomban szereplő idézetről lemaradt a név. <b>Wolfram</b> hozzászólására válaszoltam.
 

wolfram

Well-Known Member
2011. július 30.
5 651
3 685
113
Amint azt írtam egy informatikai rendszer biztonsága az én véleményem szerint egy bináris változó: biztonság vagy van, vagy nincs. Ennek ellenére is lennének biztonsági előnyei egy saját rendszer létrehozásának, még akkor is, ha elfogadjuk az állításodat, miszerint nem lehet bizonyos komplexitási szint felett hibátlan rendszert létrehozni. (Bár ez az állítás nem hinném, hogy formális módszerekkel bizonyítható.)

Ezt ugye nem gondolod komolyan, hogy a biztonság bináris változó? Ha mégis, akkor elárulom, nem az. ;) A biztonságnak szintjei vannak, de tökéletes biztonság nem létezik, nem létezhet. Szerintem igazából nem is kell magyaráznom, hogy miért nem.

Az meg, hogy hibátlan rendszert létre lehetne-e hozni? Gyakorlatban nem! Ember, az F-22-n a létező legtutibb OS futott, az INTEGRITY DO-187B http://www.ghs.com/products/safety_critical/integrity-do-178b.html

http://www.ghs.com/news/20110316_10th_INT-178B_anniv.html
És mégis becsúszott legalább egy hiba.


Hogy miért? Onnantól kezdve, hogy egy rendszer hibákat, potenciális behatolási pontokat tartalmaz, már csak a befektethető erőforrások mennyiségén múlik, hogy ezeket sikerül-e kihasználni.

És ez pontosan így van minden rendszernél. Mert tartalmaznak hibákat, amik aztán ki is használhatóak, ha felfedezik azokat. Ha nem, a brute force még mindig ott van. Sok esetben persze ez "hasznos" idő alatt nem végrehajtható, legalábbis az ismert eszközökkel és módszerekkel. Na de lehetnek új matematikai megközelítések, avagy hardverek is erre. pl.: http://www.extremetech.com/computing/173898-the-nsa-is-building-a-quantum-computer-to-crack-encryption
És akkor máris +b.szhatod a tutinak <b>hitt</b> biztonságodat.


Csakhogy amíg a Linux esetében ezt pontosan 0 (nulla) dollár befektetéssel végre tudja hajtani az, aki ismeri a feltehetően jelen lévő backdoor-okat, addig egy új, saját fejlesztésű rendszer esetében ez már tényleges befektetést igényel. A bevethető erőforrások (pénz, ember) pedig véges mennyiségben állnak rendelkezésre, még az amerikai kormányzat számára is.

Igen, ez így van. Viszont, egy teljesen saját rendszer megírása a nulláról elég sok időbe és pénzbe kerül, na meg az aztán nem nagyon lesz kompatibilis semmilyen jelenlegi programmal, API-val, framework-el... Tehát minden alkalmazást, amire szükségük van, a grafikus API-tól kezdve az összes programig, nekik kell megcsinálniuk a rendszerükre, ha natívan akarják futtatni, ez pedig mégtöbb idő és pénz. Igaz, ez is növelné a biztonságot.

A másik dolog pedig, hogy egy új rendszer esetében lehetőség lenne végre szakítani azzal a 40 éves architektúrával, amelyre a Linux épül. Ennek biztonsági vonzata is lenne, ugyanis valószínűleg NAGYSÁGRENDEKKEL csökkenteni lehetne a fajlagos hibaarányt a 2014-es év technológiai fejlettségének megfelelő tervezési paradigmák alkalmazásának segítségével.

Így is lehet nézni, na meg úgy is, hogy a "40 éves" rendszer legalább kiforrott már, ezzel szemben egy új meg nem. Szóval szerintem a nem szándékos hibákat nagyságrendekkel azért nem lehetne csökkenteni.
 

wolfram

Well-Known Member
2011. július 30.
5 651
3 685
113
http://www.hwsw.hu/hirek/52557/cray-trinity-szuperszamitogep-intel-xeon-phi-cielo-opteron.html
 

xeqev

Member
2013. szeptember 19.
130
0
16
Ezt ugye nem gondolod komolyan, hogy a biztonság bináris változó? Ha mégis, akkor elárulom, nem az. ;) A biztonságnak szintjei vannak (...)
Az informatikában, ott bináris változó, más területeken nem feltétlenül. Mégis milyen metrika alapján tennél különbséget két NEM biztonságos informatikai rendszer között, milyen alapon jelentenéd ki, hogy az egyik biztonságosabb, mint a másik?
Az meg, hogy hibátlan rendszert létre lehetne-e hozni? Gyakorlatban nem!
Közelítsünk rá a dologra a másik irányból: van az a komplexitási szint, amely alatt még nem csak álom a hibamentesség, ebben egyetértesz? (Gondolhatunk akár egy egyszerű „Hello world” programra, bár az nem végez hasznos feladatot.) Ha ezt elfogadod, akkor viszont adódik a kérdés: hol húzod meg azt a határt, amely felett már lehetetlen hibamentes rendszert összerakni. 100 kódsor még belefér, de 101 már nem?

Nem könnyű ezt a problémát matematikailag megfogni, már csak azért sem, mert egy rendszer komplexitását nem éppen egyszerű számszerűleg kifejezni. De az azért belátható, hogy ahogy nő a rendszer komplexitása, úgy nő a hiba (vagy hibák) előfordulásának esélye, és lényegében ezzel párhuzamosan csökken a „hibamentesség” esélye, de ez soha nem éri el a nullát. (Nem tudom, mennyire jól fogalmaztam ezt meg, de azért remélem átjött a mondanivaló.)
Igen, ez így van. Viszont, egy teljesen saját rendszer megírása a nulláról elég sok időbe és pénzbe kerül, na meg az aztán nem nagyon lesz kompatibilis semmilyen jelenlegi programmal, API-val, framework-el...
Persze, én ezt tudom, írtam is még korábban (a másik helyen) hogy egy saját operációs rendszer megalkotása iszonyatosan drága lenne a járulékos költségekkel együtt.
Így is lehet nézni, na meg úgy is, hogy a "40 éves" rendszer legalább kiforrott már, ezzel szemben egy új meg nem. Szóval szerintem a nem szándékos hibákat nagyságrendekkel azért nem lehetne csökkenteni.
A Linux az elképzelhető legegyszerűbb, monolitikus architektúrára épül. Ez a modell már a Linux megalkotásakor is elavultnak számított, előnye nincs, (biztonsági) hátránya annál inkább.

Nem tudom, mondanak-e neked valamit a Midori, illetve a Singularity szavak:

http://en.wikipedia.org/wiki/Singularity_%28operating_system%29
http://en.wikipedia.org/wiki/Midori_%28operating_system%29

Két kísérleti operációs rendszerről van szó, mind a kettő a Microsoft fejlesztése, ez egyiknek a forráskódja is hozzáférhető. Mindkét projekt célja egy olyan operációs rendszer megalkotása, amelyben a natív kód aránya a lehető legkisebb, és a rendszer (beleértve a kernelt és a drivereket is) legnagyobb része menedzselt kódból áll. Nem tudom mennyi programozási tapasztalatod van, szóval megpróbálom kicsit közelebb hozni, hogy ez mit is jelent. A menedzselt kód esetében a programozók nem tudnak elkövetni olyan memóriakezelési (és más típusú) hibákat, amelyeket natív kód esetében igen. Ezen hibák elkövetésére a használt programozási nyelv (és az azt támogató infrastruktúra) egyszerűen nem ad lehetőséget, ugyanúgy, mint a Java és C# esetében.

Hát például ilyen tervezési alapelvek felhasználásával lehetne csökkenteni a fajlagos hibaarányt, és szerintem nem túlzás azt feltételezni, hogy nagyságrendekkel.
 

wolfram

Well-Known Member
2011. július 30.
5 651
3 685
113
Az informatikában, ott bináris változó, más területeken nem feltétlenül. Mégis milyen metrika alapján tennél különbséget két NEM biztonságos informatikai rendszer között, milyen alapon jelentenéd ki, hogy az egyik biztonságosabb, mint a másik?

Szerencsére nem nekem kell különbséget tennem. :D De az EAL pl. egy jó közelítés:
http://en.wikipedia.org/wiki/Evaluation_Assurance_Level


Közelítsünk rá a dologra a másik irányból: van az a komplexitási szint, amely alatt még nem csak álom a hibamentesség, ebben egyetértesz? (Gondolhatunk akár egy egyszerű „Hello world” programra, bár az nem végez hasznos feladatot.) Ha ezt elfogadod, akkor viszont adódik a kérdés: hol húzod meg azt a határt, amely felett már lehetetlen hibamentes rendszert összerakni. 100 kódsor még belefér, de 101 már nem?

Nem könnyű ezt a problémát matematikailag megfogni, már csak azért sem, mert egy rendszer komplexitását nem éppen egyszerű számszerűleg kifejezni. De az azért belátható, hogy ahogy nő a rendszer komplexitása, úgy nő a hiba (vagy hibák) előfordulásának esélye, és lényegében ezzel párhuzamosan csökken a „hibamentesség” esélye, de ez soha nem éri el a nullát. (Nem tudom, mennyire jól fogalmaztam ezt meg, de azért remélem átjött a mondanivaló.)

Igen és nem. Abban egyetértek, hogy egy "Hello world"-szintű, méretű kódnál a hiba gyakorlatilag kizárható, vagyis teljesen elhanyagolható az esélye, hogy hibát tartalmazzon, ráadásul, ahány emberrel több nézi meg ezt a kódot, annál inkább csökken az amúgy is csak leginkább elméletben létező esély a hibára. De ez az esély, legyen bármennyire is kicsi, soha nem lehet nulla. És ahogy nőnek a sorok számai, úgy növekszik az esély. Hogy ez az esély pontosan mikor, kb. hány soros nagyságrendnél éri el azt a szintet, amikortól már komolyan számolni kell a lehetőséggel, azt nem tudom (szerintem erre nem is lehetne egzakt értéket megadni) és amúgy is sok mindentől függ (kik, hányan, hányszor nézték át a kódot, meg ilyesmik). Tehát én fordítva látom, szerintem a hiba esélye nem lehet nulla, hanem az elhanyagolhatóan kicsitől indulva folyamatosan növekszik.

De ezt mások is így látják, méghozzá a a legkritikusabb területen:

http://www.cotsjournalonline.com/articles/view/100490
http://en.wikipedia.org/wiki/DO-178B
http://dissertations.ub.rug.nl/FILES/faculties/science/2008/e.kesseler/c4.pdf
Ebből is láthatod, hogy ők is csak valószínűséggel dolgoznak, mert azt nem lehet kijelenteni, hogy biztosan nem lesz olyan szintű (szoftver)hiba, ami katasztrofális következményeket okozhat. A DO-187B minősítés esetén pl. repült óránként kisebb, mint 10 a mínusz 9. az esélye ennek.



A Linux az elképzelhető legegyszerűbb, monolitikus architektúrára épül. Ez a modell már a Linux megalkotásakor is elavultnak számított, előnye nincs, (biztonsági) hátránya annál inkább.


Én is szimpibbnek találom a mikrokerneles megközelítést (pláne, ha még real time is, mint mondjuk a QNX, amit nagyon sajnálok, hogy bekebelezett a BlackBerry, pedig milyen jó lett volna, ha szépen átmegy open source-ba) de hát ez van...


Nem tudom, mondanak-e neked valamit a Midori, illetve a Singularity szavak:

http://en.wikipedia.org/wiki/Singularity_%28operating_system%29
http://en.wikipedia.org/wiki/Midori_%28operating_system%29

Két kísérleti operációs rendszerről van szó, mind a kettő a Microsoft fejlesztése, ez egyiknek a forráskódja is hozzáférhető. Mindkét projekt célja egy olyan operációs rendszer megalkotása, amelyben a natív kód aránya a lehető legkisebb, és a rendszer (beleértve a kernelt és a drivereket is) legnagyobb része menedzselt kódból áll. Nem tudom mennyi programozási tapasztalatod van, szóval megpróbálom kicsit közelebb hozni, hogy ez mit is jelent. A menedzselt kód esetében a programozók nem tudnak elkövetni olyan memóriakezelési (és más típusú) hibákat, amelyeket natív kód esetében igen. Ezen hibák elkövetésére a használt programozási nyelv (és az azt támogató infrastruktúra) egyszerűen nem ad lehetőséget, ugyanúgy, mint a Java és C# esetében.

Hát például ilyen tervezési alapelvek felhasználásával lehetne csökkenteni a fajlagos hibaarányt, és szerintem nem túlzás azt feltételezni, hogy nagyságrendekkel.


Jah, mondanak. Anno réges-régen az 1-es verziójú Singularity-t le is szedtem, hogy kipróbáljam. Azóta sem került rá sor... :D

Gyakorlatilag semmi tapasztalatom nincs programozásban. De ha megnézed, a Singularity-t is assembly-ben, meg C-ben írták jórészt és sem abból, sem a Midoriból nem lett eddig semmi. Szóval szép és jó ez a menedzselt nyelvben megírt oprendszer teória, csak eddig még nem nagyon sikerült senkinek. Mert ugye egy menedzselt nyelven megírt akármihez (jelenleg?) kell egy (natív kódú) futtatókörnyezet is. Emiatt meg lassabb (és "korlátozottabb") a natív(abb) nyelveken írt kódnál. De a Microsoft próbálkozik tovább, hát meglátjuk...
http://www.i-programmer.info/news/98-languages/6786-microsofts-new-language-m.html


Most látom, hogy van ilyen is:
http://en.wikipedia.org/wiki/Phantom_OS
Ez orosz. :)

Aranyos. :) Remélem, sikerül elterjednie. De a kernel ennél sem menedzselt kódban íródott, ha jól látom.
 

silurusglanis

Well-Known Member
2012. augusztus 7.
7 499
5 577
113
Sziasztok! Elég magas szintű topik ehhez a kérdéshez, de remélem nem gond.

A következő felhasználói szintű, vagy az alatti problémám lenne:

A Firefoxban szeretném menteni a felhasznált jelszavakat. Annak rendje és módja szerint az Eszközök->Beállítások->Biztonság->Webhelyjelszavak mentése kvartetten végigcaplatva meg is jelölöm, hogy én bizony menteni szeretném őket. Csakhogy! Bárhová jelentkezek is be (de egy próbát még csinálok a HTKA-val ahogy ezt elküldtem), a Mentett jelszavak gombot inzultálva csak egy maláj géphez mérhető fehérségű felület jön be a megszokott opciókkal (Jelszókezelőként bemutatkozva).

De mentett adat nincs, illetve nem jelenik meg. A régi szép időkben nem nem így volt.

Tipp?

Köszönöm a segítséget.