Vlákno názorů k článku Jiný pohled: jaký by CSIRT měl skutečně být od petr_p - Omezení odpovědnosti za škodu způsobenou softwarem není iracionální...
-
A co teprve léky a přesto za ně výrobce nese nějakou zodpovědnost.
Takže zodpovědnost lze určitě požadovat.Problém je trochu v tom, jakou by nesli zodpovědnost výrobci free software. Jakou by nesli zodpovědnost lidé, kteří by byli zodpovědni za nasazení free software třeba ve státní správě.
Obávám se, že takový přístup by se obrátil proti svobodnému software.
-
Redmarx (neregistrovaný)
Jeste navic k tomu, proc vubec potrebuju zodpovednost za software v situaci v jake se nachazime a ktera je preci naprosto odlisna od situace v oblasti leku. Kdyz neco podela vyrobce leku, tak muze pacient i umrit, kdyz neco podela vyrobce softu, tak preinstaluju maximalne preinstaluju pocitac (server).
A hlavne v oblasti softu resi zodpovednost konkurence a prave svobodny software je jeji vyznamnou soucasti.
A jeste jedna vec - zaruka, u softu se silne nedodrzuji zakony v oblasti zakonne zarucni doby, ale kvuli tomu netreba delat nove zakony, jen vymahat ty stavajici.Co je nejvetsim problemem z hlediska bezpecnosti: Windows, ale mam moznost linuxu a BSD. Java od Oracle, ale mam moznost OpenJDK a IcedTea. A hlavne Flash - tady nemam zadnou jinou moznost, navic to neni tak, ze by se vyrobce zodpovednosti donutil k naprave, Adobe ma derave vsechny produkty a vzdycky melo a dokud nekrachne tak vzdycky bude, resenim je prestat flash pouzivat a na nahrazenio flashe se preci pracuje, takze suma sumarum mame odskrtnuto a ted uz jen donutit alespon statni spravu ty bezpecne softwary pouzivat.
-
Cruiserupce (neregistrovaný)
BTW a co se stane kdyz neco podela vyrobce software pro kardiostimulator, rentgen, ekg ... nebo posledni dobou pouzivane roboticke nastroje pro laparoskopicke operace????
Nebo treba software pro rizeni odpadnich vod?
Bezpecnostni pozarni systemy?
Komunikace na 112, 156,155,158 ?
Cela problematika s tzv free svobodnym problemem je ponekud komplexnejsi ... duvod proc firmy pouzivaji placeny software je ten... ze u placeneho existuje placena podpora a jakesi zaruky (pri dodrzeni specifickych podminek) .. proto se casto pouziva napriklad redHat a podobne ..
Firmy si totiz nemohou dovolit pouzivat free soft bez jakekliv podpory a zaruk!!!
-
zz_indigo (neregistrovaný)
aj na ten najsprostejsi Open Source programcek sa da kupit support ktory castyo bude leposi ako u Redhatu/Oracle/Microsoft a vmware dokopy. (Mal som docinenia zo suportom vsetkych stiroch firiem a ak je moznost to zvalit na niekoho ineho tak to spravia. A to este skor ako sa pozru nato ci je FAKT problem na strane aplikacie/rozsirenia.
Ono je niekedy radost riesit Problem z oracle produktom nad redhatom. Redhat ta posle za Oracle, Oracle za Redhatom. A vo vysledu googils jako keby si to rozchadzal na Vlastnej distribucii linuxu.
Kresne O*****e prachy za ktore nedostanes nic len zvyseny tlak.
-
petr_v (neregistrovaný)
Už jste někdy viděl program o kterém se nedá přesně říct, jak se zachová? Samozřejmě pokud je chybný, obsahuje race conditions, špatně ošetřené vstupy umožňující buffer overflow, tak se chování opravdu špatně předvídá - to neznamená, že to nejde.
Halting problem říká, že neexistuje univerzální program, který by rozhodoval o tom zda program na vstupu zastaví nebo ne. Nicméně toto je velice teoretický koncept a pro většinu programů toto umíme určit pomocí analýzy.
Rozhodně souhlasím, že kdyby každý program měl být otestován na všechny vstupy ze svého okolí a všechny možné okolnosti které mohou nastat (včetně chyb paměti, atd..), tak dneska nemáme Internet, PC by uměly možná psát text jako na stroji a při troše snahy i simulovat kalkulačku. Zjednodušeně, vývoj každého software by byl neskutečně nákladný - stačí se podívat jak náročný je vývoj software pro řízení kritických infrastruktur (elektrárny, letadla, ...). Obecně problém verifikací je stále předmětem výzkumu, praktické použití pro větší programové celky je komplikované (Zde pomáhají specializované programovací jazyky, jako třeba ADA - ale kdo by se v tom učil dělat, když máme C#, .NET, Javu a javascript).
Souhlasím s autorem článku, že pokud je potřeba vytvářet neděravé a bezpečné aplikace, je nutno začít na úrovni OS, jinak to nedává smysl. A vždycky se najdou vývojáři a uživatelé, kteří obětují trochu bezpečí za možnost používat nejnovější technologie a jednoduše konzumovat obsah.
-
Cruiserupce (neregistrovaný)
Uz jsem videl spoustu programu, ktere se chovali jinak nez se predpokladalo, diky vlivu jinych programu v systemu nebo systemu samotnemu...
To co je na freeBSD stabilni jsem videl nestabilni na Ubuntu ...
To co je stabilni a funkcni na RedHatu jsem videl jinde nefungovat ...
Takze v podstate ... ANO videl.
-
petr_p (neregistrovaný)
Ano, viděl jsem takový program. Příkladem je polkit/consolekit, kde do nedávna stačila na konfiguraci bezkontextová gramatika, takže nebyl problém v konečném čase určit, jestli třeba lokálně přihlášený uživatel může, nebo nemůže vypnout stroj. Od té doby, co je konfigurace v javascriptu, tedy turingovsky úplném jazyce, to nejde. A není to vykonstruovaný případ. Dělá se to třeba při automatické validaci zabezpečení systému (SCAP). A to jsem jenom u parsování konfigurace.
Problém zastavení a ověření shody specifikace s implementací jsou ekvivalentní problémy (ekvivalence dvou programů). To není žádná akademická poučka ale tvrdá realita. Proto, jak jste sám napsal, se formální verifikace používá jen na izolované problémy se zjednodušeným modelem, které se za tím účelem implementují ve specifických jazycích. Zbytek se pokrývá testy a různými automatickými kontrolami, které mají tu vyšší tu nižší účinnost, generují spoustu falešných poplachů a prakticky řeší jen známé a opakující se chyby. (Například statické analýzy zdrojových kódů.)
Je tedy zcela normální, že kvalitní kód stojí sakra peníze a může si ho dovolit jen pár nejbohatších zákazníků, takže je bláhové požadovat stejnou záruku pro spotřební zboží, kterým třeba pracovní stanice dnes je.
V podstatě je to jako s pojištěním. Čím více zaplatíte, tím větší ochranu si vysloužíte. Žádná ale není stoprocentní a musí s tím počítat obě strany.
-
> Od té doby, co je konfigurace v javascriptu, tedy turingovsky úplném jazyce, to nejde.
Ale jde. A to triviálně snadno:
1. mějme klasifikaci konfigurací na "může vypnout", "nemůže vypnout", "vadná konfigurace". "Vadnou konfiguraci" považujme za nesplňující specifikaci ať je jakákoli.
2. pod daným uživatelem zkusme stroj vypnout
3. počkejme den
4. vypl se => může vypnout
nevypl se => nemůže vypnout
konfigurace se stále zpracovává => vadná konfiguraceČili to, cos tady předvedl, je klasické chybné vztažení teoreticky dokazatelného abstraktního faktu na prakticky neexistující problém.
Tvrzení, že shoda programu se specifikací je _obecně_ neověřitelná totiž znamená, že existují _nějaké_ programy, jejichž shodu se specifikací neumíme ověřit. K tomu, aby tvoje argumentace byla platná, by bylo potřeba ještě dokázat, že zaručeně mezi těmi programi, jejichž funkčnost skutečně _v praxi_ _chceme_ ověřovat, do této skupiny spadá.
Chceš-li, pak ještě jinak: neověřitelná je jenom funkčnost programu, který má k dispozici **nekonečné** množství prostředků (=>stavů). Jestli potřebujeme nebo nepotřebujeme řešit vlastnosti nekonečných strojů, nechám na posouzení každého.
-
petr_p (neregistrovaný)
Vysvětlovat mi step counter nemusíte. To co tu předvádíte, je právě ono trestuhodné zjednodušení. Vy jste se rozhodl množinu nerozhodnutelných problémů rozhodl ignorovat. Jenže to já nemůžu. Nakonec jste svoji argumentaci pohřbil tím, že se nejedná o praktický problém. To se opravdu není o čem bavit.
