Vlákno názorů k článku
GitHub zadarmo oskenuje vaše repozitáře, jestli nechtěně nesdílíte privátní klíče od Filip Jirsák - Tuhle službu už podle mne GitHub nabízí několik...

To je právě ten problém, že reagujete na něco jiného, než o čem se diskutuje.

Tak jinak. Reagoval jsem na komentář od "cc". Nebo to je taky váš účet?

Komentář od „cc“ reagoval na můj komentář a nic o externích službách tam nepsal.

Tak asi nebudu potřebovat secrety pro věci uvnitř kódu, že jo.

Budete. Příklady jsem psal ve svém prvním komentáři.

Ty které mají fakt zůstat utajeny.

Ty, které fakt mají zůstat utajeny, samozřejmě v repository nechcete. Jenže pak je potřeba umět GitHubu říct, které utajeny zůstat nemusí. A tedy je má ignorovat. Na což jsem se ptal, zda je to možné. Jak jsem zjistil později, možné to je.

A proč mi to píšete?

Domníval jsem se, že vaše komentáře měly mít nějaký smysl. Ale ukázalo se, že píšete buď věci, které už byly v diskusi napsané před vámi, nebo reagujete na věci, které nikdo nenapsal.

Já se nedivím, že vám to nedává smysl. Můj komentář vůbec nepatřil vám, ale stejně mi sem píšete romány.

Váš komentář nepatřil vůbec nikomu. Začal jste řešit mock služeb ve vlákně, kde nikdo o žádných službách nepsal.

A nerozhoduje o tom nahodou autor? Bez ohledu na to co si nejaky nahodny kolemjdouci mysli?

Ne, nerozhoduje. To, že vy si myslíte, že je vaše reakce k tématu, ještě neznamená, že to tak doopravdy je.

Na Rootu tedy adresata urcuje Jirsak ;-)

Zase jste netrefil, o čem je řeč.

Napisete "Váš komentář nepatřil vůbec nikomu.", ja na to zareaguju a pak se tvarite, ze jste napsal neco jineho. Nekdo se tu netrefuje, ale ja to nejsem.

Jenom jsem se vám snažil naznačit, že i když jste před napsáním svého příspěvku stisknul tlačítko „Reagovat“ u komentáře uživatele „cc“, ve skutečnosti jste nereagoval na nic, co bylo ve vlákně předtím napsáno. Tedy ani na to, co napsal „cc“.

Asi dokážu žít s tím, že si to myslíte.

Lepší by bylo, kdybyste se nad tím zamyslel a příště nekomentoval věci, ke kterým nemáte co říct.

Takhle na první pohled to vypadá skoro jak výhružka. Co přesně se stane, když sem, podle vás, takový komentář přidám?

Vidím, že je potřeba to zobecnit. Zkuste se více soustředit na obsah komentářů ostatních, abyste pochopil, co se v nich doopravdy píše. Ten čas, který teď věnujete psaní „odpovědi“, která je úplně mimo, raději věnujte pochopení komentáře, na který jste chtěl reagovat. Nejspíš pak zjistíte, že k vaší odpovědi není důvod.

To už jste psal a nezajímalo mě to předtím ani teď. Radši se podívejte na co reagujete a odpovězte si alespoň pro sebe na tu otázku, co jsem vám tam položil.

Vaše otázka vychází z premisy, že „lepší by bylo“ je výhrůžka. Tato premisa ovšem neplatí, takže ta otázka nedává žádný smysl a nemá smysl pokoušet se na ni odpovědět.

Ono to není zas tak těžké. Nestane se nic.

Nebo bude tráva fialová. Nebo vyhrajete milion. Nebo cokoli jiného. Prostě na otázku, která vychází z nesmyslných předpokladů, můžete odpovědět úplně cokoli, a všechny ty odpovědi mají stejný smysl – neznamenají vůbec nic.

U zaheslovaných privátních klíčů je výhoda, že vám nebudou chodit automaticky generované stížnosti, což je téma tohoto čánku.

Většina klíčů, které GitHub detekuje, ovšem neumožňuje ochranu heslem.

Používat na ukládání privátních klíčů formát, který neumožňuje ochranu heslem, to je ovšem velký úlet. V takovém případě GitHub varuje naprosto oprávněně.

Mít uložený privátní klíč chráněný heslem a hned vedle heslo ochranu nijak nezlepšuje. Většina tajemství na tom seznamu GitHubu jsou přístupové tokeny k různým službám, nedává žádný smysl je v konfiguraci nějak šifrovat.

Mít privátní klíč chráněný heslem a hned vedle heslo je dobré pro automatické testování, a navíc to uklidní různé automatické analyzátory. Umožní to pak v produkci použít stejný software s privátním klíčem a heslem dodaným odjinud.

Pak ale ten automatický analyzátor nehlídá to, co hlídat má. Je zbytečné na produkci dodávat odjinud heslo k šifrovanému klíči, když můžete odjinud dodat rovnou ten klíč.

Analyzátor hlídá přesně to co hlídat má - jestli se někde nepovalují nezaheslované privátní klíče. Víc po automatickém analyzátoru chtít nejde. Co se týká odstranění nezaheslovaných privátních klíčů z produkčních úložišť (rozdělením na dvě části - zaheslovaný privátní klíč a odjinud dodávané heslo) tak to zabezpečení zvyšuje. Každé z úložišť může mít jiného správce, takže jeden administrátor nedokáže ten privátní klíč ukrást (útoky zevnitř jsou nejčastější).

Analyzátor, který nehlídá nic zajímavého, je k ničemu. Jak asi ten zaheslovaný privátní klíč vznikne – tak, že někdo má dešifrovaný privátní klíč, uloží ho s heslem a každou část někam nahraje. Takže má v tom okamžiku možnost to ukrást.

Nezašifrované privátní klíče ve volně přístupném úložišti jsou zajímavé, takže analyzátor dělá smysluplnou práci. Jen je potřeba přesně vědět co dělá a nedomýšlet si že dělá něco jiného.

Zašifrované privátní klíče s heslem uloženým hned vedle jsou také zajímavé. Když analyzátor principiálně obejdete (tj. neurčíte vybrané klíče, které má ignorovat, ale obejdete ho kompletně), bude vám analyzátor k ničemu – protože stejně, jako ho obejdete pro nějaké nedůležité klíče, ho obejdete i pro ty důležité.

To je vas uhol pohladu. Ten zahrna pokrytie odchyliek mnozstvom suborov s privatnymi klucmi, kde nemate istotu ci mate pokryte vsetky abnormality.

Z mojho uhla pohladu je najlepsie testovat kod proti definici tohoto formatu. Je jedno ci je ta definicia oficialna alebo pokryva aj vystup nejakeho zpraseneho softu.

Proste kazdy podla svojich moznosti.

Rozdíl mezi našimi úhly pohledu je to, že vy jen teoretizujete, zatímco já píšu o zkušenostech z praxe.

Když chcete testovat kód proti definici formátu, tak si nejprve zjistěte, jak taková definice vypadá.

To, že program nebo knihovna, reaguje dobře na abnormality, je dost podstatná výhoda. Určitě mnohem raději používáte program, který vám přesně napíše, kde je chyba a případně i jak ji opravit, než program, který vám prostě napíše, že došlo k chybě a nic dalšího se nedozvíte. Takže testování chování při abnormalitách je užitečné (protože je užitečné mít různé abnormality ošetřené). Přičemž v takovém případě vám definice formátu moc nepomůže, protože obvykle o abnormalitách neříká vůbec nic.

To ze teoretizujem je len vasa domienka.

To ze nieco nieste schopny riesit racionalne, ale ste odkazany na empiricke riesenie, nie je premisa k tomu aby bol takto znevyhodneny uplne kazdy.

Je to ale správná domněnka. Protože kdybyste někdy něco takového implementoval, o problematice byste něco věděl a nepletl byste si veřejný certifikát s privátním klíčem.

Empirické řešení je také racionální. Vaše „řešení“ bohužel není v souladu s realitou. Dobré testy jsou prakticky vždy empirické. Protože účelem testu není to, abyste to, jak jste problém pochopil, implementoval po druhé (poprvé je to v testovaném kódu). Účelem testu je to, abyste kód ověřil co nejvíce nezávisle na původním kódu – a tím se myslí ne jen samotný kód, ale i analýza, úvahy a předpoklady, které k danému kódu vedly. Když kód testujete na konkrétních příkladech, úplně tím obcházíte to, co si o problému myslíte vy. Nevýhoda takového testu samozřejmě je, že neotestujete všechny možné situace – a výběr toho, které případy budete testovat, je zase zatížen vaší představou o podstatě problému. Což je ale pořád lepší, než zatížit tou představou celý test.

V některých případech, kde je potřeba opravdu silně zajistit správnost (třeba zabezpečovací zařízení na železnici) se to opravdu dělá tak, že se problém řeší nezávisle na sobě dvěma cestami – analyzují to různí lidé, kód píšou různí programátoři. Kód pak běží na dvou různých zařízeních a porovnává se výsledek. Tím je zajištěno, že se „testuje“ opravdu každá varianta. Ale to se dá dělat jen u jednoduchých problémů a ještě jen tam, kde je to opravdu kritické a vyplatí se do toho násobného řešení investovat.

Je to len domienka. To ze ju na zaklade nedostatku informacii pokladate za spravnu, naopak len dokazuje to ze ste vyhradne odkazany na empiricky pristup.

Takze vy si vlasne testami dokazujete len to ci ste spravne pochopil zadanie? Tak to napriklad ADA a obzvlast SPARK nebude to prave orechove, vsak?

Informací, které tu domněnku potvrzují, mám dost. Testy ověřuji i to, zda jsem správně pochopil zadání. Což je velmi podstatné, protože nejasnost zadání je příčinou velkého množství chyb. Netuším, na co narážíte vaší větou o ADA a SPARK.

Informací, které tu domněnku potvrzují, mám dost.

Akurat ze tie podstatne informacie ignorujete. Napriklad tu ze aj github si mysli ze tie kluce k testovaniu nepotrebujete a preto vam ich neumozni v repozitari ignorovat.

I kdyby to byla pravda, nijak to nedokazuje, že vy jenom neteoretizujete.

Jenže ona to ani pravda není. GitHub totiž umožňuje zvolené adresáře ze skenování vyřadit: Excluding directories from secret scanning alerts for users. A jaké uvádějí příklady, proč něco ze skenování vyřadit? „For example, you can exclude directories that contain tests or randomly generated content.“ Nepřipomíná vám to něco?

Plánujete se dál ztrapňovat, nebo si přiznáte, že tu teorii neznáte tak dobře, abyste dokázal rozumně odhadnout, co je potřeba v praxi?

To ze to neumoznuje pochadza od vas z komentaru korym ste toto vlakno zacal. Sorry, zabudol som ze v priebehu diskusie ste schopny niekolko krat otocit, podla toho ako vam to vyhovuje.

To ze ste zistil ze to odignorovat ide neznamena ze ukladanie tych klucov do repozitara je spravna prax, ale len to ze rovnakych patlalov je viac nez by to bolo zdrave.

To ze to neumoznuje pochadza od vas z komentaru korym ste toto vlakno zacal.
Nikoli. „Nevím, zda něco jde udělat“ neznamená „nejde to“.

Sorry, zabudol som ze v priebehu diskusie ste schopny niekolko krat otocit, podla toho ako vam to vyhovuje.
Zkuste najít jediný takový případ.

To ze ste zistil ze to odignorovat ide neznamena ze ukladanie tych klucov do repozitara je spravna prax, ale len to ze rovnakych patlalov je viac nez by to bolo zdrave.
To, že si teoretik, který takový kód nikdy nepsal, myslí, že je to špatná praxe, zase nedokazuje, že to doopravdy je špatně. Označení za patlala od někoho, kdo nezná teorii a nemá žádnou praxi, je kouzelné.

Domienku ze ste patlal dokazuje najlepsie to, ako ste kazdy svoj omyl schopny obkecat mnozstvom zbytocnych slov. To kazdy nepotrebuje...

Pre svoju domienku ze som teoretik nemate jediny relevantny podklad.

Nevím, jak můžete usuzovat, co dělám s každým svým omylem, z diskuse, kde jsem nic mylného nenapsal.

S tím teoretikem bych to trochu upřesnil – jste špatný teoretik. Podkladem jsou vaše komentáře. Jenže vy to vidět nemůžete – protože jste špatný teoretik.

Například jediné řešení, s kterým jste přišel, je to, že privátní klíče uložíte v nějakém (nejlépe proprietárním) formátu, který GitHub nerozpozná, a vy se pak budete tvářit, že ty klíče v repository vlastně nejsou, i když tam budou.

To nejlepší, co můžu v testu udělat, je tedy to, že vezmu privátní klíč uložený jiným programem a zkusím ho načíst

Je mi líto, ale to je špatná praxe.

V tomto případě máte psát test proti parametrům jaké ten soubor má mít, ne proti tomu co vám vyhodí nějaký program, protože je ten soubor může být špatně. A podrhuji tam tam to slovo "psát".

Pak záleží jak jsou testy organizované, dá se to udělat různě, ale testování pomocí "reálných" vstupů by měly být až uživatelské testy a měly by zahrnovat soubor o kterém bezpečně víte že odpovídá tomu správnému, a soubor který odpovídá tomu špatnému. To proto abyste zajistil, že oba soubory projdou všudy kudy mají a mohl prohlásit feature za plně funkčí. Integrační nebo unit test jsou pouze na půl cesty.

18. 12. 2022, 14:00 editováno autorem komentáře