LibreSSL - fork OpenSSL

Vývojáři OpenBSD nedávno forkli OpenSSL za účelem pročištění, odlehčení a opravy chyb. Nyní má tento projekt jméno a oficiální stránku. Po dokončení "čistky" je plánována i podpora jiných operačních systémů (kromě OpenBSD).

22.4.2014 14:55 | Hans1024 | Zajímavý projekt

Komentáře

[Ragzid]

OpenSLL?

[Ladislav Hagara]

Opraveno. Dík.

[gsnak]

Comic Sans FTW!

[Prcek]

Jen počkej, až hipsteři pošlou dost peněz, budeš mít po fontu .

[Šangala]

No tu su zvědaví, dám jim chvíli a pak se juknu, kolik hnoje vynesli, bo zdrojáky OpenSSL se mi fakt nelíbili…

[BigBoss]

V životě jsem ho neviděl, ale jako program,átor většinou nenávidím cizí kód, takže se přidávám...:)

[Šangala]

Se podívej, hledal jsem tam jen alokace a uvolnění paměti…

[Hans1024]

Ja mam takovy pocit, ze dneska rika kazdy o vsech zdrojacich, ze jsou zpraseny humus.

Tak mi prosim nekdo ukazte slusne velky projekt, ktery ma nadherne ciste a krasne prehledne zdrojaky, ve kterych se kazdy vyzna. Aby lidi vedeli, jak se to teda ma delat

[kozzi11]

No to asi nikdo neukaze. Jelikoz zadny takovy projekt ve svete opensource neexistuje :D. Samozrejme ten uzavreny ktery ti nemohou ukazat ten je napsan pekne a ciste.

P.S.samozrejme to myslim jako vtip

[Luk]

Uzavřený bývá zhusta hrouda bláta (s masivním využíváním copy&paste, nalepováním kusů kódu tam a onde, špagetizací...), protože tam nikdo koukat nebude a je potřeba stihnout deadline. Čím víc lidí na tom dělá, tím víc stylů psaní kódu tam je, žádný přitom neodpovídá firemnímu standardu. Okomentované to většinou nebývá, není čas. To už se spíše najdou věty, kterými si někdo do kódu řádně ulevil. A tak dále...

[KS]

Tmux?

[Šangala]

Jak myslíš, ale podívej se do nich, aby tam byl wrapper na wrapper pro wrapper na alokaci paměti přeš několik #define a navíc se pravděpodobně ani nevyužívají (dedukuji podle některých komentářů), tak to zrovna přehlednosti nepřidá. Nemluvě o tom co jsem hledal dál a sekl jsem s tím…

Úmysly byly možná správné a odůvodněné, ale fčil by to chtělo vyčistit - čím méně kódu, tím lépe.

[Ivan]

Uplne stejne to ma udelany OpenLDAP. Ciste teoriticky by to melo pomoct zjistovat kde se jaka pamet naalokovala. Akorat ta zmet #define-s neni nijak dokumentovana. Takze se v tom nakonec memory leaky hledaji mnohem hur.

[Hans1024]

Tak s tim, ze OpenSSL chce vycistit rozhodne souhlasim, jinak bych nepsal tu zpravicku. Ja jsem si spis tak obecne povzdechl, ze vidim lidi casto nadavat na zpraseny kod a nevidim nikde nikoho vychvalovat kvalitni kod

[TM]

Ona je to taková móda. Často tak hovoří "znalci", kteří sami žádný kód neprodukují.

[pavlix]

Zrovna v případě OpenSSL to ale nic nemění na tom, že je to zprasené ukrutně a navíc to má u tohoto typu software fatální následky.

[deda.jabko]

tak treba: https://github.com/postgres/postgres

[karelI]

Funkce dlouhe pres 100 radku a ten styl kdy se promenne deklaruji na zacatku funkce citelnosti moc nepridava...

[potato]

A chápeš rozdíl mezi stylem a standardem C?

[karelI]

Vzhledem k tomu, ze moznost deklarovat promenne kdekoli uvnitr bloku je tu s nami uz docela dlouho, je volba standardu spise veci stylu.

[melkors]

Osobne davam prednost tomu, ze definice jsou na jednom miste, takze clovek pak hned vi, kam se jit podivat a nemusi jak trotl prolezat hromadu kodu. Ale de gustibus nullo disputandum

[karelI]

Kdyz to je na zacatku, tak vidis hromady promennych, ale nevidis jak se s nima zachazi. Tak jak tak musis do kodu. A tim z toho primo vychazi, ze problem je v te hromade kodu. Jinymi slovy - bud je kod dlouhej, pak idealni reseni neexistuje, nebo je kratkej, pak neexistuje problem s promennyma.

Omlouvam se, ale tvoje teze, o jednom miste mi prijde ponekud naivni. Mam zkusenosti s opravdu hroznym kodem. Kdyz ma funkce 6000 radku, tak ti je fakt jedno kde to je deklarovany, stejne se v tom musis hrabat.

[pavlix]

Osobne davam prednost tomu, ze definice jsou na jednom miste, takze clovek pak hned vi, kam se jit podivat a nemusi jak trotl prolezat hromadu kodu.

Pokud jsou definice na jednom místě, tak to časem vede na to, že jsou na jiném místě než kde se budou používat, což vede právě na to, že je člověk musí věčně hledat. A ukrutně to komplikuje podmínečnou kompilaci.

[Jendа]

Pokud jsou definice na jednom místě, tak to časem vede na to, že jsou na jiném místě než kde se budou používat, což vede právě na to, že je člověk musí věčně hledat.

Ještě štěstí, že existují textové editory, které definici umí zobrazit inplace.

A ukrutně to komplikuje podmínečnou kompilaci.

To je pravda.

[Ivan]

MSVC 2010 to treba neda. Pro jen je C = C89.

[Pev]

Tak mi prosim nekdo ukazte slusne velky projekt, ktery ma nadherne ciste a krasne prehledne zdrojaky, ve kterych se kazdy vyzna. Aby lidi vedeli, jak se to teda ma delat

Je jich mnoho, z těch, do kterých jsem koukal já např.:

• Python (implementace v C) (C)
• Linux kernel (C, Assembler)
• Chromium (C++)
• youtube-dl (Python)
• coreutils (C)
• Nette (PHP – ale fuj)

[Michal Kubeček]

Linux kernel (C, Assembler)

No… jak která část.

[lnykryn]

systemd

[melkors]

Horrory az vecer

[for_example]

http://www.ctan.org/tex-archive/systems/knuth/dist/tex

[www]

Cokoliv od djb blahe pameti - qmail, djbdns, ucspi-tcp atd. Jsou to sice slusne male projekty, ale to se tak v unixu ma pry delat

[pavlix]

Na druhou stranu mám za to, že djb vždy ignoroval, jak se věci v unixu dělaly nebo měly dělat.

[Michal Kubeček]

Nejen v Linuxu, když na to přišlo, klidně ignoroval i RFC nebo cokoli jiného, co nezapadalo do jeho představy, jak by svět měl fungovat. Tohle platí i o Poetteringovi, ale ten má bohžel lépe propracované PR a schopnost přesvědčit ty, kdo rozhodují, že se má svět řídit podle něj.

[trekker.dk]

Nejen v Linuxu, když na to přišlo, klidně ignoroval i RFC nebo cokoli jiného, co nezapadalo do jeho představy, jak by svět měl fungovat

Nějaké příklady?

[Michal Kubeček]

Vypnuli Google? Třeba [1], [2], [3], …

[trekker.dk]

tinydns doesn't use BIND-ese zone format

To je porušení RFC? A i kdyby jo, tak +1 pro DJB, protože BIND formát je hnus. Veselá je ta poznámka v původním článku, že jde snadno převést tinydns data do BIND formátu - schválně si to zkuste obráceně (tím mám na mysli jakékoliv strojové zpracování BIND formátu, je už jedno, za jakým účelem)

Please apply IPv6 patches to djbdns

Tohle je taky porušení RFC? A i kdyby bylo, djbdns IPv6 záznamy vracet umí.

Ostatní možná OK, i když mi ty články přijdou jako "nemám rád djbdns, tak si najdu pár porušení RFC a k tomu napíšu hromadu věcí, aby celkový stav vyzněl ještě hůř, než jaký ve skutečnosti je"

[Michal Kubeček]

Netrvdil jsem, že souhlasím úplně se vším do posledního písmenka - ale i tak tam zbyde dost relevantních věcí. Ale pokud opravdu chcete tvrdit, že podpora IPv6 v djbdns je dostatečná i bez jakýchkoli third-party patchů, pak asi další diskuse na toto téma nemá smysl, protože náš pohled na problematiku je příliš rozdílný.

[trekker.dk]

Ale pokud opravdu chcete tvrdit, že podpora IPv6 v djbdns je dostatečná

Nechci, konfigurovalo by se to blbě. Nicméně pokud by někdo chtěl tvrdit "djbdns porušuje RFC, protože neumí AAAA záznamy", kecá.

[Michal Kubeček]

Jak jsem řekl, nemá smysl pokračovat.

[trekker.dk]

- Ale pokud opravdu chcete tvrdit, že ... pak asi další diskuse na toto téma nemá smysl, protože náš pohled na problematiku je příliš rozdílný.
- Nechci to tvrdit
- OK, nemá smysl pokračovat

Ehm, fajn, asi fakt ne

[Michal Kubeček]

Napsal jsem tohle:

klidně ignoroval i RFC nebo cokoli jiného, co nezapadalo do jeho představy, jak by svět měl fungovat

IPv6 do jeho představy světa nezapadá, tak ho ignoruje. A ne, to, že lze za cenu drbání se levou nohou za pravým uchem z djbdns AAAA záznamy vymáčknout mechanismem, který byl navržen pro nestandardní rozšíření, nic jiného než ignorování není. Možná chcete slovíčkařit a tvrdit, že to není porušení RFC, ale jeho neimplementování, ale na tom opravdu nesejde.

I příkladů přímého porušení RFC bylo v těch odkazech dost - jen vy jste si z nějakého důvodu vybral těch pár, které jimi nejsou.

[pavlix]

Já si to neumím vysvětlit jinak než jsem popsal zde.

[Michal Kubeček]

Já to prostě jen nechtěl říct takhle na plnou ústa. :-)

[pavlix]

Hehe, zajímavé, že mě vždycky setřeš jak nic ;).

[trekker.dk]

A ne, to, že lze za cenu drbání se levou nohou za pravým uchem z djbdns AAAA záznamy vymáčknout mechanismem, který byl navržen pro nestandardní rozšíření, nic jiného než ignorování není.

Taky neříkám, že djb AAAA záznamy neignoroval. Pouze tvrdím, že tinydns je umí vracet.

Možná chcete slovíčkařit a tvrdit, že to není porušení RFC, ale jeho neimplementování, ale na tom opravdu nesejde.

Teď slovíčkaříte vy.

[pavlix]

Tady nezbývá než souhlasit s Michalem, že další diskuze nemá (a neměla) smysl.

[www]

djb vždy ignoroval, jak se věci v unixu dělaly nebo měly dělat

Ne, on to neignoroval a uz vubec ne vzdy. Napada me z hlavy treba ten jeho pokus o zavedeni adresare /package, ale podivejte se po ruznych unixech a najdete tam (pro nekoho) podivne adresare na (pro nekoho) nezvyklych mistech. To ale podle me s tim zakladnim a spolecnym dedictvim unixu moc nesouvisi.

Co se tyka tech RFC, tak jeho "zmeny" pokud vim nenarusovali interoperabilitu s jinyma implementacema a byly vzdycky zduvodnene a napravovaly podstatne chyby. Ono kdyz se pisou RFC podle stavajicich implementaci, tak to tak proste nekdy dopadne, ze ty RFC stoji zcela nebo misty za prd.

[pavlix]

Chápu, v době lp se mnozí potřebují upnout ke svatému grálu třeba zrovna v podobě djb. Kdyby podobně dopadl djb, vybrala by se jiná osobnost, která by představovala světlo na konci tunelu.

[Foo Bar]

Moc radosti ve mne tato zpráva nevzbuzuje. Nenabyl jsem pocitu, že je zapotřebí nad OpenSSL zlomit hůl, a udělat nový fork, o který se bude nakonec starat ještě méně lidí než o OpenSSL. Naopak souhlasím s článkem Heartbleed OpenSSL Bug Reveals the True Cost of Open-Source Software, že je zapotřebí do OpenSSL trochu zainvestovat (myšleno hlavně v lidských zdrojích).

Kromě toho si open source svět nepomůže ani licenčně, protože ta licenční hrůza, kvůli které se musí do GPL programů přidávat výjimka, v LibreSSL zůstane.

[kavol]

Kromě toho si open source svět nepomůže ani licenčně, protože ta licenční hrůza, kvůli které se musí do GPL programů přidávat výjimka, v LibreSSL zůstane.

tak naokraj, nevím, co je tady konkrétně za licenční hrůzu (nic závadného tam nevidím), nicméně v poslední době nabývám dojmu, že největší hrůza je právě GPL, tuhle jsem zjistil, že kvůli ní například v Linuxu není podpora dwg ... bezva, jen tak dál, fanatici

[xkucf03]

 * 3. All advertising materials mentioning features or use of this
 *    software must display the following acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"

[Grunt]

? Co je na tom závadného?

[potato]

Praktická nesplnitelnost pro začátek?

[kavol]

myslíš nesplnitelné asi jako obdobné ustanovení u OpenStreetMap?

[xkucf03]

Tak znovu:

 * 3. All advertising materials mentioning features or use of this
 *    software must display the following acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"

Např. když si někde necháš otisknout inzerát o svém skvělém softwaru, tak do něj musíš přidat tuhle větu, pokud jsi v něm OpenSSL použil. Což je velice nepraktické.

Má snad takové ustanovení licence OpenStreetMap? AFAIK ne a stačí uvést autora když šířím ta data, ale ne když mluvím to svém produktu používajícím ta data.

[asdfasdf]

Moment, to uz v ramci "svobody" a trznich hodnot meni i vyznam anglictiny? Nebo snad "All advertising materials mentioning features or use of this software" neznamena "Reklamni materialy, ktere se zminuji o vlastnostech nebo pouziti daneho software (openssl)"?

[kavol]

také mám pocit, že toho kolega vytučnil nějak málo ...

[xkucf03]

Např. když budu propagovat svoji bezpečnou službu a říkat, že klienti se o data nemusí bát, protože šifrujeme, tak už tím naplňuji to „mentioning features“ protože bezpečnost a šifrování jsou „feature“ OpenSSL.

Druhá věc je, jestli to někdo někdy zkoušel vymáhat nebo se dovolával dodržování. Dost možná ne. Ale o to smutnější je, že takové ustanovení v té licenci smrdí.

[Grunt]

Např. když budu propagovat svoji bezpečnou službu a říkat, že klienti se o data nemusí bát, protože šifrujeme, tak už tím naplňuji to „mentioning features“ protože bezpečnost a šifrování jsou „feature“ OpenSSL.

Tam bych fláknul logo OpenSSL už jen tím abych měl čím zaplnit propagační prostor. Furt nevidím problém.

[xkucf03]

Tím bys licenci nesplnil, musel bys tam dát doslovně větu:

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)

[Grunt]

To je blbost. To zas někdo při psaní licence zkoušel „Letošní sezónu“.

[xkucf03]

P.S. Ale hlavně to snad nejde srovnávat s OpenStreetMap, protože tam autora uvádím při šíření dat, ne v reklamních materiálech (ať už jakkoli definovaných), ne?

[Michal Kubeček]

Pak je ale dost důležitá otázka, co všechno pod to spadá. Co třeba věta "komunikace mezi klientem a serverem je šifrovaná"?

[Šangala]

Toš vitaj f klubu

[xkucf03]

v Linuxu není podpora dwg

V Linuxu? Už jsem se lekl, že chtěl někdo cpát DWG do jádra

Z těchto důvodů se právě doporučuje vydávat software pod GPLv2+ (verze 2 nebo vyšší, případně verze 3 nebo vyšší).

[kavol]

pardon, mělo tam bejt malý "l", a ostatně ani to není úplně přesné, týká se to vlastně všeho newokenního (no ... nevim, jak vlastně Mac ...) a zároveň free (aspoň as in beer)

[kavol]

Z těchto důvodů se právě doporučuje vydávat software pod GPLv2+ (verze 2 nebo vyšší, případně verze 3 nebo vyšší).

jo a můžeš to trošku rozvést?

[Jendа]

Z těchto důvodů se právě doporučuje vydávat software pod GPLv2+ (verze 2 nebo vyšší, případně verze 3 nebo vyšší).

To znamená dát FSF bianco šek na veškerou distribuci mého SW a pak se divit, až jim jebne v kouli a GPLv5 bude nějaká magořina.

[xkucf03]

Ten „bianco šek“ ale nemůže odebrat staré licence – stále ten kód půjde šířit pod GPLv2, GPLv3 atd. Takže ta „magořina“ by mohla spočívat leda v přílišném uvolnění podmínek – např. zrušení copyleftu – a toho bych se od FSF moc nebál jinak se tě to nedotkne.

[luky]

největší hrůza je právě GPL, tuhle jsem zjistil, že kvůli ní například v Linuxu není podpora dwg ... bezva, jen tak dál, fanatici

Tak hrozne mi to neprijde, protoze to brani pouze distribuci binarniho balicku. Muzou vytvorit balicek v non-free, ktery po instalaci nainstaluje source balicek freecadu. Podobne je resen treba flash, pripadne nektere fonty.

[kavol]

ehm, promiň, ale vůbec jsem nepochopil tvoji myšlenku ... začněme odzadu, on je k Flashi dostupný nějaký balíček se zdrojáky, máme-li se bavit o tom, že je něco řešeno podobně jako Flash?

[pushkin]

LibreSSL... jak originální...

[Andrej]

...ale ten vlastny malloc a free je "parada"

[x]

Tomu rikam pristup jaky ma byt FIPS mode is not coming back

[Rezza]

Jj, zpatky do linuxoveho sveta uz se asi LibreSSL nepodiva .

[Ivan]

Co to presne dela? Nasel jsem man k FIPS_mode_set a nejsem z toho moudrej.

[kavol]

nevim, jak chceš podrobně to "přesně", ale v principu to řeší exportní licence USA, takže se ti pak stávaj takový věci, jakože mysql padá na hubu, protože vůbec nepočítá s tím, že by mohla selhat funkce crypt, no a vona potvora selže, páč ten její algoritmus taky patří mezi regulovaný ...

[xkucf03]

Podle toho, co píšou u Mozilly: FIPS Mode - an explanation by to mělo bezpečnosti trochu pomáhat (byť asi pochybným a neznatelným způsobem) a trochu omezovat staré/slabé šifry/protokoly/algoritmy (a současně s tím zakazovat i některé moderní a dobré, ale pro Američany neznámé). A hlavně jsem z toho pochopil, že je to zaměřené na americké státní zaměstnance, ne na zahraniční uživatele.

Teoreticky by to mělo chránit jejich lidi např. zákazem MD5. Nebo je výběr udělaný tak, aby to nemohli prolomit „ti oškliví Rusáci a Číňani“ a zároveň to mohla dobře lámat NSA a odposlouchávat svoje lidi?

BTW: používáte někdo Camellii nebo jedete všichni na AESu?

[trekker.dk]

Podle toho, co píšou u Mozilly: FIPS Mode - an explanation by to mělo bezpečnosti trochu pomáhat

Tak to nepochybně, FIPS povinně vyžaduje implementaci minimálně jednoho podezřelého (že je v něm backdoor) algoritmu. Navíc implementace v OpenSSL úspěšně prošla FIPS certifikačním procesem a pak teprve se ukázalo, že je v ní chyba, která způsobí zásek/pád programu.

https://lwn.net/Articles/578375/

[xkucf03]

FIPS povinně vyžaduje implementaci minimálně jednoho podezřelého (že je v něm backdoor) algoritmu.

A myslíš, že je to záměr? Resp. že si věří natolik, že dokáží přesně vybalancovat to, co dokáží lámat oni sami, ale co nedokážou lámat jejich nepřátelé (ať už vnitřní nebo vnější)?

[Hans1024]

Tak neco s tim tucnym rozpoctem delat musi

[trekker.dk]

A myslíš, že je to záměr?

Myslím, že to vyvrací tvrzení, že by to mělo pomoci bezpečnosti.

[Michal Kubeček]

No tak… Podle stejné logiky byste mohl tvrdit, že proces review patchů do linuxového jádra (nebo jakéhokoli jiného projektu) nepomáhá snížit jeho chybovost, protože tu a tam přes něj projde pořádná bota (a doložit to jedním příkladem).

Certifikace slouží jako metoda outsourcování takového review. Pokud problematice rozumíte a máte odlišné představy, je pro vás FIPS zbytečnost. Pro (americkou) státní správu a některé velké firmy to je razítko, že určitá autorita, které oni důvěřují, prohlásila, že tato konfigurace je v pořádku. A pro toho, kdo sám problematice dostatečně nerozumí, to smysl má, protože i když nemůže mít absolutní jistotu, že ta autorita je neomylná a nemá postranní úmysly, pořád to bude lepší, než kdyby se snažil seznam povolených algoritmů a jejich kombinací určovat sám.

[trekker.dk]

Jenže tady se nebavíme o tom, že náhodou omylem prošla bota. Podle toho článku se jednalo o úmyslné protlačování podezřelého algoritmu, u kterého bylo vcelku zjevné, že tam něco smrdí. A certifikaci, jejíž kritéria může někdo ovlivňovat tak, aby byly vyžadovány podezřelé alrogitmy, nikdo soudný věřit nemůže.

[Michal Kubeček]

Pardon, špatný kontext. Měl jsem za to, že jsem ve větvi, kde byla řeč o tom, že prošly bezpečnostní bugy, takže certifikace je k ničemu.

[Rezza]

Kazdopadne te ten FIPS a vlada USA zivi :).

[kavol]

já měl zato, že mě živí Fujitsu, ale to už se asi pohybujeme dost na hraně mezi informací veřejnou a veřejným tajemstvím ...

[asdfasdf]

Presne tak, FIPS je picovina^n.

[Polish]

Proc se vice nevyuziva obdobnych knihoven, treba gnutls? Implementaci preci existuje vice.

[Luk]

Třeba proto, že to někdo v minulosti udělal pro OpenSSL a už se mu to nechce měnit Mimochodem například Apache může bez problémů používat i GnuTLS, i když to není výchozí konfigurace.

[xkucf03]

Třeba proto, že to někdo v minulosti udělal pro OpenSSL a už se mu to nechce měnit

Zlatá Java, kde na takové věci bývají abstraktní rozhraní a továrny… (chápu, že někoho to rozčílí, jakmile uslyší Java a Factory, ale smysl to má)

[Rezza]

Tak to je uplne jedno v jakem jazyce, i v te Jave to muzes natvrdo zadratovat. A kdyz se nekdy ta abstrakce prezene (blby network applet v KDE - ten stary, ne od Honzy...).

[xkucf03]

Souhlasím, nešlo mi o jazyk, ale spíš o styl vývoje. Lidi si často dělají legraci z Javy, že je tam na všechno Factory, ale ono to není úplně samoúčelné.

[pavlix]

Abstraktní rozhraní za nikoho práci neudělají.

[xkucf03]

Je otázka, co považuješ za práci. Např. Apache má modul pro OpenSSL a pro GnuTLS, nějakou abstrakci si tam museli udělat nebo to psát dvakrát. Stejně tak kdokoli jiný, kdo chce mít nějaké modulární šifrování a umožnit uživatelům používat šifrovací knihovny dle jejich volby. Stejně tak jsme si mohli „ušetřit práci“ a každý program mohl volat specifické funkce pro nějaký jeden konkrétní souborový systém – místo aby pracoval s obecným rozhraním.

[pavlix]

Např. Apache má modul pro OpenSSL a pro GnuTLS, nějakou abstrakci si tam museli udělat nebo to psát dvakrát.

Ta abstrakce je tam právě pro případy, kdy je potřeba napsat více implementací nebo více connectorů na implementace s rozdílným API. Není tedy na výběr zda něco psát dvakrát nebo udělat abstrakci, ale napíše se to dvakrát se stejným API, které lze nadále používat společně. Abstrakce v tomto případě zajišťuje znovupoužitelnost, přehlednost, testovatelnost a další výhody, které prostým větvením kódu nejdou zajistit.

Tudíž přes všechnu skvělost abstraktních rozhraní, nemusí to mít nutně vliv na to, zda se někomu chce psát podporu pro další krypto API.

[stativ]

Docela stojí za to se podívat na commity – stovky odstraněných řádků s funkcemi, které se v kódu nikde nevolají a ve kterých se najdou i perly jako:

HAS BUGS! DON'T USE

[x]

Pres 90k radku uz odebrano v OpenBSD, k tomu hromada cisteni na mnoha mistech a prepisovani a porty stale bezi. Tomu se rika good job a jen to potvrzuje, jak hrozna prasarna OpenSSL je (a June dalsi projekty). Ten napad EU o financni a klidne I trestni odpovednosti vyvojaru mi zacina pripadat I jako dobry napad. Jenze to by slo sedet tak 90% lidi v komercnim IT neli vice a v RedHatu by zustal asi jen CEO :D

[Luk]

Ten napad EU o financni a klidne I trestni odpovednosti vyvojaru mi zacina pripadat I jako dobry napad.

Pokud by to EU fakt zavedla, tak tím efektivně zahubí prakticky veškerý vývoj SW na svém území (a ten zbytek půjde cenově velmi podstatně nahoru).

Jenze to by slo sedet tak 90% lidi v komercnim IT neli vice a v RedHatu by zustal asi jen CEO

Red Hat by se především zcela stáhl z EU, provozovat tu vývoj by se mu nevyplatilo.

Podobně se už povedlo přispět k likvidaci celých odvětví, resp. jejich přesunu do jiných zemí (byla za tím snaha snížit náklady obecně, ale do značné míry i vyhnout se nákladům na všelijaké vymoženosti EU, například zvýšení cen energií kvůli obnovitelným zdrojům či zákaz použití některých chemických látek) - ta se následně dotují a stejně to není moc platné.

[x]

To byl castecne ironicky povzdech Je mne jasne, ze drtiva vetsina priposranych firem by se stahla uplne jinam nez aby zacali delat veci poradne.

[Michal Kubeček]

Ten napad EU o financni a klidne I trestni odpovednosti vyvojaru mi zacina pripadat I jako dobry napad.

Pokud by to EU fakt zavedla, tak tím efektivně zahubí prakticky veškerý vývoj SW na svém území (a ten zbytek půjde cenově velmi podstatně nahoru).

A supporťáci nebudou mít co žrát… :-)

Ne, vážně, ten nápad je opravdu absurdní. Pan "x" je buď provokatér nebo si neuvědomuje, jak neuvěřitelně by to prodražilo vývoj software, na který by se to vztahovalo - a v důsledu tedy samozřejmě i ten software.

[Luk]

On to zjevně nemyslel tak úplně vážně

Jinak odpovědnost za SW (i trestní) je samozřejmě už teď. Pokud někdo dodává SW na objednávku, může mít ve smlouvě stanovené sankce, pokud je SW vadný. A i pokud tam nejsou, platí obecná odpovědnost za vady díla. Trestní odpovědnost by se uplatňovala v obdobných případech jako u hmotných věcí - tedy při prokázaném úmyslu nebo nedbalosti (celá řada TČ - např. § 180, § 182, § 183, § 230, § 232, § 272, § 273...). To je celkem přirozená věc.

S čím ale nemohu souhlasit, je rozšíření odpovědnosti za vady (někteří právníci tvrdí, že už platí nyní - judikatura ale chybí) i na případy, že někdo vytvoří SW a zdarma (netýká se jen FOSS, ale zde to platí nejvíc) ho poskytne k obecnému použití na vlastní riziko. Je to něco podobného, jako kdyby hudebník zdarma zahrál publiku a některý z posluchačů by si chtěl nárokovat náhradu škody za to, že hudebník hrál falešně.

Nicméně to asi nikdo soudný nezavede, a to ani u proprietárního placeného SW (nevytvářeného na zakázku), kde by to mělo větší logiku. Tam by celá slavná EU narazila už u Microsoftu, který by na to nikdy nepřistoupil a raději by se stáhl z trhu EU. A protože EK a EP jedou velmi zásadně na microsoftím SW (stejně tam mnohé státní správy, včetně té naší), byly by dopady hodně drastické.