Příspěvky

2071

Software / Re:Aké povinnosti mám ak používam GPL software

« kdy: 03. 01. 2020, 11:24:51 »

GPLv1 bych neřešil, tu už nikdo nepamatuje a nepoužívá se.

Ad 1) – GPLv2 a GPLv3 se vztahuje na software, který pod ní byl přímo licencován, a na „odvozená díla“. Pokud vaše aplikace bude odvozená od té databáze, musí být i váš software pod GPL. Pokud nebude váš software odvozené dílo, můžete si zvolit jakou licenci chcete. Zrovna u databáze je to jednoduché – pokud budete upravovat přímo tu databázi, je výsledek odvozené dílo a pořád to musí být pod GPL. Vy ale tu databázi nejspíš budete jen používat, tj. bude existovat vaše aplikace a vedle ní ta databáze, se kterou budete jen komunikovat přes nějaké rozhraní – pak vaše aplikace není odvozená od té databáze a licencujete ji jak chcete.

Ad 2 – Pokud byste upravoval a dál šířil tu databázi (která je pod GPL), musel byste zpřístupnit zdrojové kódy těm, komu byste dal tu databázi v binární podobě. Nemusíte jim zdrojáky dávat hned s binárkou, ale musíte dát možnost zdrojáky (zdarma) získat. Přičemž ten, kdo takhle zdrojáky získal, zase postupuje podle GPL – takže může ty zdrojáky vzít, zkompilovat je, binárku šířit dál (klidně za peníze), ale zase k tomu musí poskytnout i ty zdrojáky.

Ad 3) – Nejde o oddělení kódu, ale o to, zda je vaše dílo od té databáze odvozené. Pokud jste vzal zdrojáky té databáze a upravil je nebo k nim něco přidal, musí být výsledné dílo stále licencované pod GPL. Pokud databázi pouze používáte, není vaše dílo odvozené. (Samozřejmě mohou existovat okrajové případy, mohl byste odvozené dílo udělat i tak, že se původních zdrojáků ani nedotknete, a pořád by se na to vztahovala GPL. To ale asi nebude váš případ – a pokud byste se do takové situace dostal, potřebujete hromadu právníků a ne diskutující na Rootu.)

2072

Software / Re:Ověření elektronického podpisu v e-mailu

« kdy: 29. 12. 2019, 15:28:03 »

Pro ověření podpisu e-mailu potřebujete především celý ten e-mail. Např. GMail má v kontextovém menu každého e-mailu položku „Stáhnout zprávu“. Bez celého e-mailu v nezměněném stavu ten podpis neověříte, protože podpis slouží právě k tomu, aby zaručil, že se ve zprávě nezmění ani jediný bit.

Když budete mít ten e-mail, k ověření podpisu můžete použít třeba openssl (konkrétně openssl smime).

Běžní uživatelé pro podpis také používají PKI, PGP je spíš záležitost fandů opensource.

Ověřovat podpis e-mailu můžete u každého poskytovatele, který vám poskytne kompletní e-mail v nezměněné podobě. Takže buď přes POP3 nebo IMAP, nebo v případě webového rozhraní umožní stáhnout původní zprávu. Spíš by mne zajímalo, on to nějaký poskytovatel e-mailových služeb neumí? Nebo chcete poskytovatele s nějakým webovým rozhraním ve kterém to ověřování bude integrované? To bude asi docela výjimečné, protože když chcete umět ověřovat podpis, dává smysl umět i podpis vytvářet. A to je dnes u webových rozhraní problém, protože prohlížeče nepodporují obecnou technologii, která by to uměla. Dříve se pro to používala Java, ale tu prohlížeče přestaly podporovat, takže teď zase musíte mít plugin pro každý prohlížeč zvlášť.

2073

Vývoj / Re:Python, pomoc s kodem

« kdy: 28. 12. 2019, 10:07:35 »

Ale zrovna v tom vašem případě by se stejného výsledku dalo dosáhnout i bez odečítání jedničky, stačilo by místo operátoru menší nebo rovno použít ostře menší:

Tak ne, to by byl stejný antipattern, jako ten původní případ.Todle by se v pythonu mělo napsat buďto pomocí té Tvé druhé varianty

Kód: [Vybrat]

for word in words:

, nebo kdyby byl potřeba i index, tak

Kód: [Vybrat]

for i,word in enumerate(words):

Jakékoli while s counterem je špatně čitelné a tedy blbě (i když to třeba funguje).

Předpokládám, že shockwave čte nějakou příručku pro začátečníky, a že tohle byl příklad na přístup k poli přes index. I když pak je divné, že tam to indexování od nuly není vysvětlené. Jinak souhlasím s tím, že v normálním kódu je lepší použít konstrukce na vyšší úrovni abstrakce, když je jazyk má, takže v Pythonu použít uvedený for … in.

2074

Vývoj / Re:Python, pomoc s kodem

« kdy: 27. 12. 2019, 21:44:56 »

Funkce len() vrací počet prvků pole, ve vašem případě tedy 3. Prvky pole jsou indexované od nuly, tedy první prvek pole má index 0, tj. words[0] == "dog", words[1] == "cat", words[2] == "hint". Index posledního prvku v poli je tedy o jedničku menší, než počet prvků v poli.

Indexování prvků pole od nuly je zvyk z doby, kdy se přistupovalo přímo k paměti. Adresa prvku pole pak byla adresa pole + index * velikost prvku pole.

Ale zrovna v tom vašem případě by se stejného výsledku dalo dosáhnout i bez odečítání jedničky, stačilo by místo operátoru menší nebo rovno použít ostře menší:

Kód: [Vybrat]

words = ["dog","cat","hint"]
counter = 0
length = len(words)

while counter < length:
    word = words[counter]
    print(word + "!")
    counter = counter + 1

2075

Vývoj / Re:Soapui, otestování funkční url

« kdy: 23. 12. 2019, 11:42:19 »

To vám ale nikdo neporadí, to musíte vy vědět, co chcete testovat. Nevím, jak poznáte, že web „funguje“ nebo „jede“. Podle stavového kódu? Nebo podle obsahu?

2076

Vývoj / Re:Soapui, otestování funkční url

« kdy: 22. 12. 2019, 23:16:50 »

Ale jak to udělat přes ten HTTP Request? Děkuji

Netuším, v čem máte problém, takže vám bohužel nemůžu poradit. Já bych to udělal normálně, fakt netuším, v čem by mohl být problém.

2077

Vývoj / Re:Soapui, otestování funkční url

« kdy: 22. 12. 2019, 17:34:15 »

Proč to chcete testovat zrovna přes SoapUI? To je určené k něčemu jinému. Jinak ano, přes HTTP request v SoapUI se dá otestovat i to, zda web funguje. Ale mnohem jednodušší budete mít, když tu webovou adresu prostě zadáte do webového prohlížeče.

2078

Vývoj / Re:Ukládání různých typů produktů do databáze

« kdy: 21. 12. 2019, 11:46:47 »

Já moc nechápu, proč vlastně uvažujete o relační databázi. Tohle je podle mne vzorový příklad pro použití nějaké NoSQL dokumentové databáze. Máte nějaký důvod ji nepoužít? Nebo máte nějaký zvláštní důvod použít SQL databázi – třeba že už máte vybudovanou infrastrukturu s SQL databázemi pro jiné projekty?

2079

Odkladiště / Re:Firemní certifikát vs. certifikát pro elektronickou pečeť

« kdy: 20. 12. 2019, 14:34:14 »

Pochopitelně, ale proč to nezašifrují veřejnou částí mého kvalifikovaného certifikátu a musím si dělat komerční.

V předchozím příspěvku jste psal, že šifrujete vy. Vám ČSSZ posílá něco šifrovaně?

Přeci podepisování a šifrování je něco jiného.

Technicky je to to samé.

Tak alspoň si nepletu dešifrování a podpisování ...

Já si to také nepletu. Technicky je totiž podepisování a dešifrování to samé. Vezmete vstupní blok dat, aplikujete na něj kryptografickou funkci, jejím parametrem je privátní klíč, a dostanete výstupní blok dat. Pokud je na vstupu otisk dokumentu, říká se té operaci podepisování, pokud jsou na vstupu zašifrovaná data, říká se té operaci dešifrování.

ještě se mi nestalo, že "můžete si myslet, že něco dešifrujete, a zatím byste podepsal něco, co jste podepsat nechtěl."

To, že se vám něco nestalo, je bezpečnostně relevantní argument? Ještě se vám nestalo, že by vás chtěl někdo vykrást, tak nebudete zamykat?

2080

Odkladiště / Re:Firemní certifikát vs. certifikát pro elektronickou pečeť

« kdy: 20. 12. 2019, 08:02:34 »

Proč se nemůže šifrovat mým kvalifikovaných to nechápu.

Protože šifrovat se musí certifikátem příjemce. I když nerozumíte technickým detailům, dá se to odvodit následujícím způsobem: Příjemce šifrované zprávy je něčím jedinečný, má to být pouze on, kdo dokáže zprávu dešifrovat. Jedinečný je v tom, že je jediný, kdo má (svůj) privátní klíč. Vy jeho privátní klíč mít nemůžete, pro šifrování už vám tedy zbývá jenom jeho veřejný klíč.

Proč se obecně nemůže kvalifikovaný certifikát používat pro šifrování. Chápu, že to je v podmínkách a tak to tak je, ale v čem je rozdíl proti komerčnímu čistě technicky? Je tam nějaké bezpečností omezení?

Je tam bezpečnostní omezení, výše jsem ho psal. Při podepisování vždy musíte vědět, co podepisujete. Kdybyste privátní klíč používal i pro dešifrování, můžete si myslet, že něco dešifrujete, a zatím byste podepsal něco, co jste podepsat nechtěl.

Vy ale potřebujete mít svůj vlastní certifikát pro šifrování tehdy, pokud chcete, aby někdo mohl posílat šifrované zprávy vám. Což není případ kdy vy něco posíláte sociálce. Navíc šifrování není zákonem nijak upraveno – pokud chcete, aby vám někdo posílal šifrované zprávy, musíte si to s ním individuálně dohodnout. A když už si to budete dohadovat, domluvíte se také, jaký certifikát budete pro šifrování používat. Klidně si tedy můžete domluvit nějaký self-signed certifikát a nemusíte za něj platit nic.

Podle mě je to prostě velký kšeft.

Sice nevíte, ale hlavně, že hned máte jasno.

2081

Odkladiště / Re:Firemní certifikát vs. certifikát pro elektronickou pečeť

« kdy: 19. 12. 2019, 12:12:37 »

A tady to máte přímo od PostSignum: Certifikáty pro autentizaci

2082

Vývoj / Re:WebP a samrt server statického obsahu

« kdy: 18. 12. 2019, 21:20:29 »

Myslím, že to je ideální na rozdělení na dvě úlohy – jednoduchý server pro statický obsah, a vedle toho generátor, který vždy při změně souboru vygeneruje druhý formát. Proč tou konverzí komplikovat ten jednoduchý server?

2083

Odkladiště / Re:Firemní certifikát vs. certifikát pro elektronickou pečeť

« kdy: 17. 12. 2019, 23:57:55 »

Od 2. 11. 2019 začala certifikační autorita PostSignum (CA) vydávat certifikáty pro koncové zákazníky dle nových certifikačních politik, které znemožňují používání kvalifikovaných certifikátů pro účely autentizace majitele.

Hlavně ale je rozdíl v tom, co je nastavené jako technický atribut certifikátu a co je legální. Do technických atributů certifikátu se nastavuje leccos, protože různý software si ty atributy vykládá různě. Ale pro kvalifikované certifikáty vždy platilo, že podepisující musí mít kontrolu nad tím, co podepisuje, což u autentizace neplatí.

2084

Odkladiště / Re:Firemní certifikát vs. certifikát pro elektronickou pečeť

« kdy: 15. 12. 2019, 19:26:17 »

Já pro podepisování Adobe Acrobat nepoužívám – pro podepisování PDF používám JSignPdf. A požadavek na heslo závisí na tom, čím podepisuju. Když podepisuju klíčem z PFX souboru, zadávám heslo k tomu souboru. Když podepisuju něco kvůli testování klíčem, který mám naimportovaný do Windows, pouze potvrdím přístup ke klíči. A kvalifikovaný certifikát mám nahraný na čipu občanky, takže když podepisuju jím, zadávám do ovladače čipové karty QPIN.

2085

Odkladiště / Re:Firemní certifikát vs. certifikát pro elektronickou pečeť

« kdy: 15. 12. 2019, 18:37:36 »

Co mě u Acrobatu překvapilo je chování při podpisu (při experimentech). Pokud nastavím podepisování z "Úložiště systému Windows" nechce Acrobat pro vložení el. podpisu heslo. Jediný způsob jak to zabezpečit byl, že jsem certifikát vyexportoval s heslem a pak ho vložil do Acrobatu jako "Soubor digitálního identifikátoru".

To není chování Acrobatu ale Windows. Když při importu privátního klíče do Windows povolíte silnou ochranu klíče, musíte použití klíče potvrdit v dialogovém okně. Privátní klíč jsem bez silné ochrany nikdy neimportoval, ale předpokládám, že pak nevyskakuje ani ten potvrzovací dialog. Privátní klíče v úložišti Windows nejsou chráněné žádným heslem, není tedy, co by po vás Windows vyžadovali. Lepší je, když máte privátní klíč uložený třeba na čipové kartě, pak musíte před použitím privátního klíče zadat PIN.