Tak asi je ten kod taky zly, ze sa zanho hanbia, ako inak. Preto blokuju zverejnenie. Potom je otazka, ci to nehranici so zneuzivanim pravomoci verejneho cinitela.
A mne sa teda podmienka “Z uvedeného vyplýva, že vytvorený zdrojový kód je dostupný len pre orgán vedenia a orgány riadenia.” zdá v priamom rozpore s §15.2.d.1 zákona o ITVS (kompatibilita s EUPL).
Konkrétne v rozpore s požiadavkou “Poskytovanie zdrojového kódu: Pri rozširovaní alebo poskytovaní rozmnoženín diela poskytne nadobúdateľ licencie strojovo čitateľnú rozmnoženinu zdrojového kódu diela alebo uvedie zdroj, kde je tento zdrojový kód ľahko a voľne dostupný počas celého obdobia, keď nadobúdateľ licencie rozširuje alebo poskytuje dielo.”
1 Like
hmmm zjavne aj kvalita právnych oddelení na OVM-kách pokulháva … najprv vymenujú N-stranovú Licenčnú zmluvu a potom to zaklincujú vetou, ktorá je s tou zmluvou v rozpore … Alebo to tam nejaký manažér prepisuje tie templejty bez toho aby tomu rozumel …
Súhlasím, že to čo si uviedol, tj. riešenie sprístupňovania kódu MIRRI-SKIT je hanba. 
Zároveň dodávam, že vo vzťahu MIRRI-MFFUK_Praha nič také nie je, naopak, tam sa držíme zákona 95/2019 §15 (opensource v rámci EÚPL). 
Navyše, nová zmluva ktorá bude uzatvorená medzi MIRRI-(zatiaľ neznámy realizátor Webového portálu pre NKOD) bude z pohľadu zverejňovania zdrojových kódov ešte lepšia, ktorá bude prikazovať zverejňovanie zdrojového kódu nielen na konci (pri konečnom odovzdaní), ale aj pri prechode medzi etapami. Uvedená zmluva je navrhnutá aby sa stala príkladom pre ostatné projekty.
Chápem ale, že chceš hovoriť o tom čo je zlé a nie čo je dobré. Keďže toto bolo pre nás dôležité od začiatku a podarilo sa nám to dosiahnuť, potreboval som to tu uviesť. Navyše, verím že sa nakoniec zverejnia aj predmetné egov aplikácie ,ktoré robí SKIT. Tým naozaj nechcem situáciu zľahčovať, pretože ako som povedal, je to naozaj hanba ako zverejňovanie kódu predmetných aplikácii vyriešilo.
Akými etapami sa mysli? Podla 85ky? Tzn. napr. prikáže zverejniť este neotestovany kód?
Chceli by sme zaviesť (zatiaľ minimálne na projekte OD2.0) pricíp zverejňovania zdrojového kódu už od začiatku, nasledovaním odporúčania UK:
Prvá časť projektu opendata, tj. SPARQL Endpoint bol presne takto vyvíjaný. Zdrojových repozitárov bolo viac, tu je pár:
Pokiaľ viem ide i to, aby sa do kódu nevkladali natvrdo žiadne tokeny, heslá alebo iné citlivé údaje. Ak sa tento princíp dodrží, tak je to v poriadku. Alebo sa mýlim? Ide aj o to, že keď sa už kód úplne odovzdá na konci, stratí sa možnosť jeho pripomienkovania a vylepšenia. No a aby sa tento princíp nejako formalizoval, tak sa to naviazalo na etapy. Tu nižšie môžeš vidieť návrh zmluvy, budem rád keď nám ju spripomienkuješ(te). Možno sa to dá urobiť ešte lepšie, budeme len radi.
- ZDROJOVÝ KÓD INFORMAČNÉHO SYSTÉMU
10.1 Zhotoviteľ je povinný pri akceptácii Informačného systému alebo jeho časti odovzdať Objednávateľovi funkčné vývojové a produkčné prostredie, ktoré je súčasťou Informačného systému alebo jeho časti.
10.2 Zhotoviteľ je povinný odovzdať Objednávateľovi Vytvorený zdrojový kód v jeho úplnej aktuálnej podobe s označením verzie:
a) po ukončení etapy implementácie Informačného systému alebo jeho časti,
b) po ukončení etapy testovania Informačného systému alebo jeho časti,
c) po nasadení Informačného systému alebo jeho časti do produkcie.
10.3 Zhotoviteľ odovzdá Objednávateľovi Vytvorený zdrojový kód prostredníctvom GitHubu Dátovej kancelárie spoločne s relevantnou dokumentáciu, ktorá vznikla vo vzťahu k dodávke Informačného systému alebo jeho časti vrátane administrátorských prístupov; Objednávateľ poskytne Zhotoviteľovi potrebné prístupy do GitHubu Dátovej kancelárie pre splnenie jeho povinnosti. Za odovzdanie Vytvoreného zdrojového kódu Objednávateľovi sa na účely tejto Zmluvy o dielo rozumie jeho odovzdanie Oprávnenej osobe Objednávateľa, a to postupom podľa prechádzajúcej vety. O odovzdaní a prevzatí Vytvoreného zdrojového kódu bude oboma Zmluvnými stranami spísaný a podpísaný preberací protokol. Pre zamedzenie pochybností, povinnosti Zhotoviteľa týkajúce sa Vytvoreného zdrojového kódu platia i na akékoľvek opravy, zmeny, doplnenia, upgrade alebo update Vytvoreného zdrojového kódu a/alebo vyššie uvedenej dokumentácie, ku ktorým dôjde pri plnení tejto Zmluvy o dielo alebo v rámci záručných opráv.
10.4 Vytvorený zdrojový kód musí byť v podobe, ktorá zaručuje možnosť overenia, že je kompletný a v správnej verzii, t. j. v takej, ktorá umožňuje kompiláciu, inštaláciu, spustenie a overenie funkcionality, a to vrátane kompletnej dokumentácie zdrojového kódu (napr. interfejsov a pod.) Informačného systému alebo jeho časti. Zároveň
odovzdaný Vytvorený zdrojový kód musí byť pokrytý testami (aspoň na 90 %) a dosahovať rating kvality (statická analýza kódu) podľa CodeClimate/CodeQL a pod. (minimálne stupňa B).
10.5 Vytvorený zdrojový kód vrátane jeho dokumentácie bude prístupný pre verejnosť bez obmedzenia [aktuálne podľa § 31 ods. 4 písm. a) Vyhlášky č. 78/2020]; týmto nie je dotknutý osobitný právny režim vzťahujúci sa na Preexistentný zdrojový kód. Objednávateľ je oprávnený sprístupniť Vytvorený zdrojový kód okrem orgánov podľa predchádzajúcej vety aj tretím osobám, ale len na špecifický účel, na základe riadne uzatvorenej písomnej zmluvy o mlčanlivosti a ochrane dôverných informácií.
10.6 Ak je medzi Zmluvnými stranami uzatvorená SLA zmluva, od prevzatia Informačného systému sa prístup k Vytvorenému zdrojovému kódu vo vývojovom a produkčnom prostredí, vrátane nakladania s týmto zdrojovým kódom, začne riadiť podmienkami dohodnutými v SLA zmluve.
10.7 Nebezpečenstvo poškodenia zdrojových kódov prechádza na Objednávateľa momentom prevzatia Informačného systému alebo jeho časti, pričom Objednávateľ sa zaväzuje uložiť zdrojové kódy takým spôsobom, aby zamedzil akémukoľvek neoprávnenému prístupu tretej osoby.
10.8 Zmluvné strany s dohodli, že okrem odovzdania Informačného systému alebo jeho časti, poskytne Zhotoviteľ Objednávateľovi tiež primeranú a nevyhnutnú súčinnosť za účelom zverejnenia dokumentácie na verejne prístupnom úložisku (podľa inštrukcie Objednávateľa) v súlade s platnými a účinnými právnymi predpismi (aktuálne § 31 Vyhlášky č. 78/2020).
Podľa celej tej formulácie to vyzerá, že právnici dostali jasné biznis zadanie “zhora”, ktoré sa snažili prepísať do formálnej reči. A to je ešte horšie ako keby išlo o chybu alebo nepozornosť.
Plus teda áno, zjavne na samotnom Mirri málokto tuší, čo vôbec príslušná požiadavka zákona, resp. EUPL znamená.
1 Like
Ano, ale nejde len o citlivé údaje, ale aj o ošetrenie spracovania vstupov a X ďalších bezpečných programatorskych praktik.
Nespochybnujem ten princíp, len v slovenských podmienkach mi to príde ze ideme urobiť tri schody naraz. Pilotný projekt na niečom menšom z dielne SKIT by možno ukázal ci to je reálne. Paušálny bigbang tohto typu narazi na nepripravenost na všetkých stranách.
Ináč kde a kto na strane nasho štátu je schopný pripomienkovať a vylepšovať kód štátnych IS?
Pilotný projekt už nastal a volá sa Národný katalóg otvorených dát, ktorý realizovala MFF UK a potvrdil, že sa to dá. Projekt sa vývijal na Githube od začiatku, v zmysle horeuvedeného princípu. Ak sa pridá 
aj SKIT, budeme len radi.
Nebál by som sa niečoho až takéto, pretože každá zmluva sa robí špecificky pre každý projekt, to ako to robíme na OD2.0 môže predstavovať len príklad, ktorý nemusí byť do písmenka zopakovaný. Každopádne, aj pre Webový portál pre NKOD plánujeme postupovať rovnako. Projekty, ktoré budem realizovať ja, pôjdu jedine týmto spôsobom.
Musia to cele vypnut, hned a teraz, lebo z povahy veci prevadzkuju “tikajucu bombu” a rizko pre stat? Zaroven potom podla SLA (zrejme) MUSI dodavatel neodkladne konat a nedostatky odstranovat, inak penale. Atd. a pod.
Pointa je, ze podla UK metodik sa ten “citlivy kod” ma vyclenit mimo ako separatny modul a nasledne sa zverejnuje vsetko okrem citliveho modulu. V dokumentacii k “ne-citlivym” modulom sa popise API a naznaci, co asi tak, zhruba, priblizne, ten citlivy modul robi a preco. A teda sa aj zdovodni, preco ten “citlivy modul” nie je zverejneny. A my si to precitame, pohmkame, a (asi) povieme, “OK, v poho, ten zbytok nam staci”.
Za pilotny projekt ja osobne povazujem uz ten data.gov.sk 1.0 (nie 2.0, ale uz rovno 1.0), ktori visi na GitHub-e od cca 2014-2015. Bol tam uz pocas vyvoja, PRED odovzdanim do PROD a fakturaciou, t.j. za mna “best practise” ako vysity. (A ano, su tam muchy, ale v porovnani s aktualnym stavom inych projektov su to uplne male, malucicke zanedbatelne musky.)
3 Likes
Bolo by fajn v rozumnej miere to adaptovať a zaviesť ako mandatorne pred každým zverejnením kódu…
OWASP_Code_Review_Guide_v2.pdf (2.3 MB)
3 Likes
Ďakujem za materiál, vážim si jeho zdieľanie.
Vyzerá to skvele. Preposielam kolegom a dám vedieť čo vieme s tým spraviť.
1 Like
Ako to ide? Stretlo sa to s pozitívnou odozvou @liska ?
1 Like
Ahoj. OWASP metodiku som posunul kolegom riešiaci túto oblasť, odozva bola určite pozitívna. Čo sa týka jej reálneho zapracovania, resp. zahrnutia, myslím že sa na tom stále ešte pracuje. Keď výjde nejaká verzia, zverejním ju tu na pripomienkovanie, budem sa snažiť samozrejme ešte pred tým, ako naberie platnosť.
Mrzí ma, že to ide tak pomaly. K oddeleniu architektúry mám dôveru, takže verím že aj napriek pomalému rozbehu to nakoniec skončí dobre.
Každopádne veci sa predsa len hýbu pomaly dopredu. Nedávno pribudol do repozitára (zatiaľ privátneho - súčasný metais), a rovnako sa vytvorili repozitáre pre SvM, KAV, a spolu so SKITom as pripravuje ich nahratie. Predpokladám že to bude presne ten okamih, kedy sa prenesie najväčší fokus na túto bezpečnostnú metodiku.
A takisto sa zriadil repozitár pre MetaIS3, predpokladám že sa zdrojový kód zverejní ešte skorej ako po úplnom konci projektu.
Budúci týždeň bude k tomu pracovné stretnutie, dám vedieť aké sú ďaľšie kroky.
3 Likes
Na to som zvyknutý. Úspech je ze to vôbec ide. Ale ked sa to zadari, vycisti sa podstatná bariéra pri zverejnovani .
2 Likes
Ahojte, krátky update:
- Už máme skripty, ktoré vytvoria databázu pre KAV v Githube, zatiaľ je to neprístupné. Verím že ale toto sprístupníme čoskoro, nakoľko tu asi naozaj nie je nič, čo by mohlo byť citlivé.
- Sme už v pokročilom rokovaní so SKITom pre získanie zdrojových kódov SvM a predpoklad je, že by sa to už nemalo nijako zastaviť
- Čo sa týka prípavy metodiky, ktorá je kľúčom pre zvernenie množstva repozitárov, preposielam info od kolegu Peťa Viskupa, ktorý pracuje na všeobecnej metodike odovzdávania kódov ISVS:
FYI – prešiel som ten OWASP dokument teraz celý.
Z druhej kapitoly o „Secure Code Review“, konkrétne „5.3 What is the difference between Code Review and Secure Code Review?“
citujem
„Secure Code Review is an enhancement to the standard code review practice“Z tohto pohľadu naše zameranie vnímam ako širší „Standard Code Review“ zameraný aj na oblasti, ktoré v danom OWASP dokumente nie sú pokryté, avšak v pripravovanej metodike bude aj časť zameraná na bezpečnosť, v ktorej intormácie z tohto dokumentu budú použité.
Samozrejme sme vďační za vstupy.
Čoskoro danú metodiku zverejníme na pripomienkovanie.
3 Likes
Tak fajn, som zvedavý na metodiku. A ešte zvedavsi ci sa podľa nej aj bude postupovať. Ale signály su sľubné:)
1 Like
Ahojte, malý update. Už máme zdrojové kódy Slovenska v mobile. Je to pekne štruktúrované do 24 osobitných repozitárov (Androidy, iOS, či rôzne znovapoužiteľné komponenty). Súčasne pracujeme na odovdaní zdrojákov CAMPu a snažíme sa získať aj zdrojáky CSRU, DI, CIP a MOU.
Takže teraz už len dokončiť metodiku sprístupňovania/odovdzávania kódov, verím že sa nám to čoskoro podarí dotiahnuť.
7 Likes
…a potom uz len “malickost” - implementovat metodiku do praxe a riadit sa nou ) Na to som fakt zvedavy.
24 repozitarov? Wowza. Uz trosku zacinam rozumiet preco ten deployment tak trva.
2 Likes