Názory k článku Reprodukovatelná kompilace aneb Debian proti CIA
-
Tydyt (neregistrovaný)
Fedora software and technical information may be subject to the U.S. Export Administration Regulations (the “EAR”) and other U.S. and foreign laws and may not be exported, re-exported or transferred (a) to any country listed in Country Group E:1 in Supplement No. 1 to part 740 of the EAR (currently, Cuba, Iran, North Korea, Sudan & Syria); (b) to any prohibited destination or to any end user who has been prohibited from participating in U.S. export transactions by any federal agency of the U.S. government;
Simply - Fedora is not trusted.
-
Nix-based systémy, tedy původní Nix(OS) a GNU Guix*, se o to snaží už dlouhou dobu (i když hlavní cíle jsou trochu jinde), ale pořád i tam je mnoho balíků které si prostě chtějí pamatovat čas buildu a jiné věci a zatím to nikdo neopatchoval. Samozřejmě, odpadly tam featury aktivované automaticky podle toho co zrovna bylo při buildu nainstalováno.
Je to pěkně hnusná práce tohle řešit, třeba perl se snaží zjistit i e-mailovou adresu administrátora a strčit ji do výstupu (bůhví proč). Dle mého názoru bychom především měli tlačit na upstream(y), aby tohle zlepšili.
A zbavení se nedeterminismu má i jiné výhody...
-
[Argumentační fauly si příště prosím nechte do hospody nad pivo...]
Ten rozdíl je poměrně zásadní. Zatímco RPM balíček jde ověřit samostatně (rpm -L <package>.rpm), tak v Debianu jsou balíky podepsané jen v případě, že jsou *součástí repozitáře*, a to ještě jen checksum checksumů - viz obsah /var/lib/apt/lists/.
V případě, že balíky do repozitáře nahrávám, tak je podepsaný .dsc a .changes soubor, ale individuální balíky podepsané nejsou.
Což mimo jiné znamená, že když si stáhnu někde RPMko z náhodného webu, tak si můžu ověřit jeho digitální podpis. V případě DEB balíku to můžu udělat jen v tom případě, že použiji celý repozitář jako zdroj do APT. Integrita DEB balíků mimo použité repozitáře se tak ručně ověřuje mnohem hůře než v případě RPM.
-
REMET (neregistrovaný)
Ted tomu uplne nerozumim, Debian se snazi, aby bylo mozne cely Debian vcetne balicku prekompilovat na lokalnim stroji?
Debian nepouzivam, ale docela me to prekvapilo - to do ted neslo? Pouzivam FreeBSD a tam je tohle standard od prvopocatku (minimalne od verze 2.2.5). Balicky (ports) muzu bud kompilovat nebo stahovat binarni a stejne tak cely system (world). Neresi to mozna napadeni kompilatoru, ale tady je to napsane, jakoby si clovek nemohl doma prekompilovat cely Debian...
-
Jenda (neregistrovaný)
Samozřejmě že jde.
Rozdíl je v tom, že když si FreeBSD port zkompilujeme já a ty a porovnáme to, nejspíš se budou výsledky lišit. Buď proto, že já jsem NSA, nebo proto, že to prostě nekompiluje deterministicky. Debian se snaží o to, aby se výsledky nelišily, a nebyl tak prostor pro spekulace.
-
Petr M (neregistrovaný)
Najdi si příručku C a podívej se, co dělají třeba makra __DATE__, __TIME__,...
Jinak někde jsou u kompilátoru další "bezpečnostní" funkce - rozhází v binárce data a funkce náhodně, aby hacker měl problém se k funkcím/datům v binárce dostat automaticky. Tam po diffu bude stejných tak 3-5%, a to ještě v případě, že binárka bude zkompilovaná na jednom stroji v jednom dni...
-
Tak cílem toho projektu je právě všechna tato "makra" a jiné build-time závislé řetězce nahradit něčím deterministickým. Co se týče CPP maker, tak je to popsáno zde ve wiki stránce TimestampsFromCPPMacros.
A úplně konkrétně odstranění náhodnosti v buildu může vypadat například takto pro libjpeg-turbo
S tou randomizací address space myslíte ASLR (PIC a PIE) nebo ještě něco jiného - viz poznámka o linkeru od andre+?
-
Pavel TišnovskýZlatý podporovatelZkus si například spustit Vim a dát příkaz :ver
Já mám hned na prvním řádku řekněme mám:
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jan 2 2015 19:05:59) potom Compiled by tisnik atd.Ty tam budeš mít na 99% něco jiného, minimálně těchto pár bajtů tedy bude v binárce odlišných. Dtto JVM a asi i stovky dalších aplikací...
-
j (neregistrovaný)
Upresnim, pricipielne jde predevsim o to, ze kdyz si vemes zdrojaky, udelas jejich audit, zjistis, ze v nich neni nic zavadnyho a prekompilujes je, ziskas binarku, ktera je do posledniho bitu totozna s tou, kterou ti posle distribuce.
Aktualni stav je totiz takovy, ze ty mas zdrojaky a binarku ale nejsi schopen overit, zda ta binarka je vysledkem kompilace tech zdrojaku, nebo je v ni jeste neco dalsiho. A pokud mas jako bonus cinknutej kompilator, tak ti nepomuze ani to, ze si vse kompilujes sam (z tech proverenejch zdrojaku).
-
REMET (neregistrovaný)
Princip chapu a rozumim i tomu, ze jelikoz nepouzivam Debian resp.Linux, tak to vidim jinak. Pro me je bezna distribuce ve zdrojacich a kompilace vseho (dela se to koneckoncu automatizovane).
Chapu to spis tak, ze nejak chteji resit prave moznost cinknuteho kompilatoru. A to me zajima...
-
j (neregistrovaný)
No a prave aby to resit mohli, potrebujou zajistit, ze kdyz tisicovka lidi neco prekompiluje, je to vzdycky stejny. Pak mas slusnou sanci, ze tvoje stejna binarka cinkla neni. A nebo je ... stejne jako u ty tisicovky ;D.
IMO to je stejne ponekud sisyfovska prace. Vzdycky to totiz bude zaroven o totoznych verzich vsech dev nastroju.
-
zxz (neregistrovaný)
No ja nevim, jestli to ta tisicovka bude kompilovat tim samym kompilatorem (a pod 'tim samym' myslim kompilatory, ktere alespon nekdy v minulosti byly zkompilovany stejnym kompilatorem) tak to stejne zadny dukaz neni.
To jde jedine pomoci bootstrapu, kdy nejprve primitivnim minikompilatorem psanem primo v asembleru, jehoz nezavadnost si muze kazdy overit, zkompilujeme nejaky slozitejsi, u nejz nam jiz staci overit bezzavadnost zdrojaku, a to opakujeme, dokud se nedostaneme ke gcc :)
-
xyz (neregistrovaný)
Staci, ked par ludi bootstrapne balicek kompilatoru. Ti potom mozu zverejnit, ze balicek s gcc ma checksum XYZ. Dalsi si to mozu overit rovnako ako ti prvi, alebo tym prvym budu verit (preto, ze to potvrdil niekto pre nich doveryhodny).
Ludia IMHO nemusia vediet, cim kompiluju. Proste to skompiluju a ked nezavisly stroj overi spravne checksum vygenerovaneho baliku, tak sa balik skompiloval spravne a bud sa (umyselny) bug v kompilatore neprejavil alebo sa prejavil vsetkym rovnako. Staci jeden doveryhodny clovek, co si tym presiel od bootstrapu a ten by odhalil problem.
-
zxcvzxcvzxcvzxc (neregistrovaný)
<humor>
jine reseni, je mit vsecko v systemu ulozeno jako zdrojaky.
a v okamziku kdyz spustim prikaz, tak se duveryhodnym kompilatorem
zkompiluje kompilator a pak se zkompiluje binarka.
po ukonceni behu se binarky zas odstrani z pameti, na disku zadny binarni
spustitelny soubor nebude.
</humor> -
Pavel TišnovskýZlatý podporovatel
Tak u jazyků, u kterých je překladač pro bootstrap na pár bajtů to jde :-) Což je tak FORTH a potom už nic...škoda
-
Pavel TišnovskýZlatý podporovatel
U céčka a podobných molochů se obávám, že to pro naprostou většinu lidí (včetně mě) není možné, ale u zmíněného FORTHu je bootstrap interpret (překladač netřeba) doslova na pár bajtů ve strojáku a to se už dá v pohodě ověřit i na binárce (dokonce ani asm zdrojáky netřeba).
-
Nejde ani tak o to, aby si člověk sám překompiloval Debian. To nikdo dělat nebude (proč taky?) Jde o to zaručit, že binárky jsou opravdu z daných zdrojáků, který kompiler je konkrétně generoval, ideálně s kterými verzemi knihoven, kterými přesnými options atd. To je v dnešní době důležitá věc a jsem rád, že to Debian chce řešit. Zbývá doufat, že se navržený přístup nejen osvědčí, ale že se i rozšíří na další hlavní distra.
-
Clock (neregistrovaný)
Musel bych ted resit, zda nekdo nemuze podstrcit infikovane binarko, zda v programu neni bug a exploit, zda nekdo nemuze do zarizeni potaji nahrat svuj vlastni kod (ho flashnout), zda je kod na webu podepsan MD5 nebo SHA, zda ma muj server https,.klice, certifikaty atd.
Takhle jsou tam logicka hradla co delaji funkci natvrdo sletovanou do logickeho obvodu. Nijak programovatelne to neni.
Jako bonus se to navic z principu nemuze zaseknout. Zarizeni ma fixni stavovy cyklus asi 18 milisekund cili i kdyby praskl blesk a nejak se to poblaznilo, tak to zase bude pokracovat v tom cyklu.
-
Ondra Satai NekolaZlatý podporovatelJa jsem rad, ze jsem si na cesty do prace poridil litacku a ne Silent Eagla ;)
-
Lael Ophir (neregistrovaný)
Prvním krokem pro ověření původu binárky je kontrola digitálního podpisu. Pokud chcete srovnávat "doma" zkompilované binárky proti těm od autorů SW/distra, tak se pochopitelně budou lišit, protože ty "domácí" nebudou podepsané (nebo ne stejným klíčem). Technicky sice není problém srovnat binárky se zanedbáním podpisu, Jak to ale jde dohromady se snahou aby byla "doma" vytvořená binárka na bit stejná?
-
Lael Ophir (neregistrovaný)
Nějak jsem nepředpokládal, že na Linuxu podobnou základní věc nemáte.
Ad widle to delaji jedinym spravnym zpusobem, a proto je na nich 99,99% binarek nepodepsanych - LOL. Binárky OS jsou podepsané, stejně jako binárky ostatních MS produktů. Vyjma toho vidím podepsané namátkou následující: Adobe Photoshop, CorelDRAW, Eclipse, Firefox, LibreOffice, Foxit Reader, Paint.NET, Java, WinRAR... A co se namátkou koukám, vidím podepsané i hry koupené přes Steam. Takže s těmi 99.99% binárek zjevně kecáte. Proč mě to nepřekvapuje?
-
Lael Ophir (neregistrovaný)
Jistě, to chápu, a snad je to jasné i z mého prvního příspěvku v tomto threadu. Nicméně digitální podpis binárky umožňuje zjistit alespoň jestli je ta binárka opravdu od autora. Ověření překladem, což je oproti kontrole podpisu dost náročná operace, bych viděl až jako druhý krok pokud nevěříte autorovi binárky.
-
Filip JirsákStříbrný podporovatelJak je napsáno v článku, binárka může být cinknutá, i když autor kompiluje ten správný zdrojový kód.
-
Lael Ophir (neregistrovaný)
Takže na nainstalovaném systému nelze nijak snadno zjistit jestli binárky pocházejí z distribuce? To moc nepotěší, a reprodukovatelná kompilace tomu moc nepomůže. Abych zjistil jestli můj bash pochází z distribuce, tak bych ho musel zkompilovat ze zdrojáku a srovnat výsledek.
-
karlik (neregistrovaný)
To to trvalo, než jsi přišel...
A prosím tě, snaž se trochu víc, tvé argumenty jsou slabé a znalost problematiky chabá.
Takhle si nepředstavuji dobře odvedenou práci, za kterou tě platí.
Pozor, aby tě nevyměnili za někoho výkonnějšího!
Nepozoruješ to sám na sobě, zvláště takhle k večeru? :-) -
Lael Ophir (neregistrovaný)
To je pouze jedna z možností. A upřímně řečeno ta méně pravděpodobná. Daleko pravděpodobnější je že si stáhnete binárku z nakaženého serveru, nebo že vám ji někdo po hacknutí stoje vymění. Proto má svou roli jak digitální podpis binárek, tak reprodukovatelný překlad.
Ale myslím že otázka je uzavřena. Ptal jsem se, jestli se nebudou mlátit digitální podpisy binárek s reprodukovatelnou kompilací. Zjevně nebudou, protože binárky nejsou podepsané. Za mě zodpovězeno.
-
Filip JirsákStříbrný podporovatel
To je pouze jedna z možností. A upřímně řečeno ta méně pravděpodobná. Daleko pravděpodobnější je že si stáhnete binárku z nakaženého serveru
To se ovšem týká Windows. Linuxové distribuce to "stažení binárky z nakaženého serveru" už léta řeší distribucí software přes důvěryhodné repozitáře, takže tenhle problém mají dávno vyřešený. Proto teď řeší tu méně pravděpodobnou možnost, tj. modifikaci binárky přím opři kompilaci.Ptal jsem se, jestli se nebudou mlátit digitální podpisy binárek s reprodukovatelnou kompilací.
K tomu není důvod. Podpis je vždy něco, co vzniká vedle podepisovaného objektu, pouze pro zjednodušení pro lidi se pak někdy podpis spojí s původním objektem do jednoho souboru. Ale i když chcete ověřit podpis souboru s připojeným podpisem, musíte být schopen s toho souboru s připojeným podpisem získat původní soubor bez podpisu. Takže stejný způsob lze použít i pro ověřování podepsaných binárek - prostě získáte nepodepsanou binárku (stejným způsobem, jako byste chtěl ověřit podpis), a tu pak porovnáte s tou, která vypadla z kontrolní kompilace. A nebo ty podpisy prostě necháte uložené vedle, v samostatném souboru. -
Filip JirsákStříbrný podporovatel
Ale jsou elektronicky podepsané, to je důležité. A i v době, kdy podepsané nebyly, bylo stahování softwaru z takového repozitáře pořád řádově bezpečnější, než stahování nějakého EXE bůhvíodkud (a taky přes HTTP).
-
Osobně jsem pro nasazení TLS úplně všude, takže jsem rozhodně pro nasazení https, ale nikoli z důvodů důvěryhodnosti přenášených binárních souborů.
Vaše znevážení toho, že se software distibuuje přes http, pramení spíše z nepochopení problematiky, než z faktické situace.
a) https přináší bezpečnost přenosového kanálu. Nic víc, nic mín - máte pouze garanci, že data nezměnil nikdo po cestě (pomineme-li ty všechny pěkné falešné certifikáty, které byly v posledních letech vydány). Tj. pokud na mém fake-mirror.debian.xyz nasadím https, tak v manipulaci s archívem zabrání pouze digitální podpis onoho archivu (repozitáře).
b) teoretický přínos by mohl být ve zvýšení soukromí - padouch po cestě nevidí, co přenášíte. Bohužel metadata komunikace a přístup k obsahu archivu nakonec poměrně spolehlivě prozradí, co jste plus mínus přenášel. Samozřejmě to není tak spolehlivé, jako odposlech http.
Takže nakonec zůstáváme u toho, že nasazení TLS pro repozitáře Linuxových distribucí by mělo jen jediný pořádný efekt, a tím je přidání "šumu", který je zapotřebí analyzovat, a tím pádem čistý efekt zůstane v tom, že to budou mít padouši, kteří dělají všudypřítomné a neustálé sledování provozu, těžší.
-
xyz (neregistrovaný)
Ne, TLS by zvysilo bezpecnost pred padouchy.
Bez HTTPS vam muzu zobrazit starsi verzi repo. To je zajimave, kdyz se nalezne kriticka chyba treba v sitovem demonu. Padouch potrebuje nalezt, co presne se zmenilo, napsat exploit a nekam jej podvrhnout. S TLS na to ma cas do nejblizsiho updatu a to nedava. Bez TLS neni cas omezen. Navic system uzivatele neupozorni, ze je v stahovani chyba.
-
-
Lael Ophir (neregistrovaný)
Ad Linuxové distribuce to "stažení binárky z nakaženého serveru" už léta řeší distribucí software přes důvěryhodné repozitáře - což funguje přesně do té doby než potřebujete zjistit, jestli soubory na vašem systému pocházejí opravdu z distribuce, nebo jsou od někdo pozměněné přímo na vašem stroji. Předpokládám že kvůli kontrole nebudete chtít tahat kompletní zdrojáky a kompilovat je.
Ad Podpis je vždy něco, co vzniká vedle podepisovaného objektu, pouze pro zjednodušení pro lidi se pak někdy podpis spojí s původním objektem do jednoho souboru - pravda, podpisy nemusejí být součástí souboru. Ale je to tak výrazně praktičtější.
Ad když chcete ověřit podpis souboru s připojeným podpisem, musíte být schopen s toho souboru s připojeným podpisem získat původní soubor bez podpisu - ano, ale pak podepsaný soubor není přesně shodný z nově přeloženým (který je bez podpisu). Souhlasím že to nemusí být problém.
-
han (neregistrovaný)
Co to meles ty pomatence? Pozmenene soubory? Jestli se ti nekdo hrabal v systemu, tak NEMAS SANCI zjistit, jestli jsi stale kompromitovany. Muzes mit zmenene jadro, nebo nastroje pomoci kterych ten podpis overujes, nebo datove soubory ktere nejsou podepsane. I moje babicka ma lepsi predstavu o bezpecnosti nez ty. Nauc se zaklady. Dneska si vyplatu od Microsoftu nezaslouzis.
-
Jenda (neregistrovaný)
> Ve visualku ve widlich napises helo world ... a vyleze ti z toho 5MB exe.
Nevím, jak to děláš, ale já mám ve VS v .NET program implementující síťový protokol včetně SSL velký 14 kB, a to jsem se o žádnou optimalizaci nesnažil (například protože to bylo moje první setkání s C# a vůbec tomu nerozumím). (k nakoukání zde)
-
Což ovšem neznamená, že to na Linuxu nejde udělat lépe...
$ cat hello.c
#include <stdio.h>
int main(void) {
puts("Hello, world!");
return 0;
}
$ diet gcc -Os -ohello hello.c
$ ./hello
Hello, world!
$ ls -l hello
-rwxr-xr-x 1 ondrej ondrej 4408 Sep 11 17:21 hello
$ strip hello
$ ls -l hello
-rwxr-xr-x 1 ondrej ondrej 2296 Sep 11 17:25 helloAle i se standardními knihovnami to nejde do MB:
$ gcc -Os -static -ohello-gcc hello.c
$ ls -l hello-gcc
-rwxr-xr-x 1 ondrej ondrej 825328 Sep 11 17:24 hello-gcc
$ strip hello-gcc
$ ls -l hello-gcc
-rwxr-xr-x 1 ondrej ondrej 742864 Sep 11 17:24 hello-gcc -
dasdadad (neregistrovaný)
To je ale nedostatok kompilatoru, nie? Hlavne teda pri statickom linkovani, kde by sa to mozno dalo po analyze volani vyhodit (nie som si isty, ci sa na to nieco nespolieha). Pri dynamickom linkujes vsetko, takze tam to zmysel nedava.
U ELF z asm som sa u mna dostal na 254 B, ale to uz je na urovni, na ktorej by asi nikto nechcel pisat kod.
Toto je ukazka, ze sa setrit da, ale ked to porovnas s kodom Ondreja Sureho, tak uvidis, ze to uz nie je ono.nasm -f elf hello.asm
ld -m elf_i386 -s -o hello hello.o
section .text
global _start_start:
; syscall(sys_write = 4, stdout = 1, worldmsg, length);
mov edx,worldmsg_end - worldmsg
mov ecx,worldmsg
mov ebx,1
mov eax,4
int 0x80; syscall(sys_exit)
mov eax,1
int 0x80worldmsg:
db 'Hello, world!',0xa
worldmsg_end:
-
V Gentoo, kde se stahují zrojáky s hashem je situace o poznání lepší.
Samozřejmě existuje celá řada dalších vektorů průniku, ale v základu, pokud mám ověřený kompilátor (a je několik cest, jak mít "ověřený" kompilátor), stahuji ověřené zdrojáky ověřenými linkami z ověřených zdrojů, pak si mohu kompilovat binárky podle mých podřeb (CFLAGS, USE, ... ) a mám je vcelku bezpečné. Po kompilaci si k nim můžu udělat hashe, ty uložit na bezpečné (napříkald Read Only) místo a zpětně si ty binárky porovnávat. Třeba takhle udělat si vlastní "antivir" s whitelistem.Zpět k Debianu.
Když budu mít homogenní prostředí a výstupem budou stejné binárky. Jestli to pak pro některé útočníky nebude jednodušší, že expolity pro bitově shodné binárky budou moc sáhnout na konréktní místo v binárce a tu si upravit, s větší pravděpodobností, že se strefí na správné místo.No a kromě těchto hrátek se zdrojáky a binárkami je dobré nezapomínat na ty spousty dalších možností, které se klukům z NSA nabízí.
Kdysi se tomu říkalo paranoia, dnes tomu říkáme realita :)
Tak ať se daří. -
Ondřej CaletkaZlatý podporovatelU toho Gentoo by to ale ještě chtělo ověřovat a vynucovat digitální podepisování ebuildů, což se zatím neděje. Jinak je tam ta situace naopak podstatně horší než u jakéhokoli distribuce, která aspoň podepisuje binární balíky, protože ty ebuildy k vám přichází naprosto nezabezpečene Rsyncem nebo po HTTP.
-
Mintaka (neregistrovaný)
Cite z rsync man:
For remote transfers, a modern rsync uses ssh for its communications, but it may have been configured to use a different remote shell by default, such as rsh or remsh.Digitální podpisy ebuildů by neškodilo, a ani by to nemuselo být komplikované.
Momentálně je to tak, že kontrolu lze provést přes Manifest e-buildu.
Obsah z /usr/portage/net-analyzer/wireshark/Manifest-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256AUX wireshark-1.11.0-oldlibs.patch 776 SHA256 0b4b23ad3ce7022809187ce970733a4c6bdb9fed31099853b399498fde8dee66 SHA512 dde2cbfd839409c594562b71783204279c37697939d44ee56ce4966d7dd4
3d04ab5837bd51551c416ec789b56f8efd0016e6ecc2311af8b3109e987da301bef6 WHIRLPOOL 57fb7f67166440208c5fe023f8c7e62a4f860ae5fecf02df6e9b8b45fe31c999f7eeeee83914bbfc26c656c69bfceee75c9
4f9ac80c64ebd0c1d6db792b66665
AUX wireshark-1.11.3-gtk-deprecated-warnings.patch 1068 SHA256 0211d3f345617554add63f3101a548a990e26219b31b28003e4dbf607d38de88 SHA512 9ea643e8f707d9f9fe3ce61b875ae1828c77cd81c63
6423fc5572420fd3b103042e078f89541c5145db49f133828d333c55d1c2c3b9a162f0756051ef9d946b9 WHIRLPOOL b04cad3b70bc37b9cbc833227bdf9c32c17e67ad067902d3fb35f467fb76520546ecd508de1805ef81
0b76ebe4f0b686e483817c790cb4ede75c229505596502
AUX wireshark-1.6.13-ldflags.patch 230 SHA256 bb56440fb9de9ed480b992d202feac93a53003e9fa47869f54c6f2f30d315720 SHA512 c4a2c66e6ea9b523ca9f5a3e37411221f5aa630de07d7bf84633855ac44d
a60b3b493671e578dbfd67de94e87ab1c79203f9b80b57f9460f2a81ee39f58171b3 WHIRLPOOL ca20e190c7a8d7ca69c6d90cfb28f8f1c8896b6793b9a026567ec4df4f7080ca6424ab249d01754db1059891d3236244417
8272489b4425e895f3031a0e1e0f7
DIST wireshark-1.12.1.tar.bz2 29059989 SHA256 82b26bd416ec15903b27785e35a622687008a743342054e96eaaeaa249be584b SHA512 840f348c8cdaa0e4d96c34e0a752f3d575d975ac8e61b31f6456a0eba4b4
84268651c96b943cfe213a6c40edcb18670ec921564413c052fcafdf32b2c8523929 WHIRLPOOL f98131bde6680370943cf6070cb44c6ad96d42060573e521051b81ad9d934b03741bb4d75a1d30762eebf5f22387f9eb715
8acee4caee2503c4eafff52a12ada
EBUILD wireshark-1.12.1.ebuild 5439 SHA256 85e392623cbf466e784386f781471c315ca14e19c6c7260c7b82d992934fed8b SHA512 9eac78d3911bcb471cc61dfcb191d9a62627c5b05235633b0d1aad4a4f2f368
89f62426bcb67a5de5d7a9966989fe7770f0cc191fa3180d517f33f9ab69f9452 WHIRLPOOL 06110f7000b4385d6607b30cd4cce44c2efe46d881c9916d6be7ced180674fcc8e90483cf8a25f8b7c9f6bce8afa5b7ac5d76f
8430509b165bc6693b21c5716e
MISC ChangeLog 95709 SHA256 26c4a798b2efa2522cef58aab62e77988d53eebe676f586fd418f32d679aaf43 SHA512 9739bc8286e9bcf275d05d36ada306492c8201029350880764b39c6be06e67f3b7b8eb6d1c39f9
b4c628299119f6103f860017fc0356d185aa270f75115b75a2 WHIRLPOOL 745d20f1bb580ebf759f684f3086fcf5deac54da9589d727af2ced22495eb44bc0aaa661e1091777b37ea879aa25ca7807d9bae5ebfbdbc18013c
40da2bb363f
MISC metadata.xml 2372 SHA256 be7d784e5fc20f46fe7d7dc96c63a8d15692e8db80dee6f3fc8980f13e99cc52 SHA512 6249bd454d51ad91bec2355770e918c04f8034c6e7ba1f7b73874e00ba4df11ba5430d3a1ea0
6a7b353590f46e1c217e860666265386a3bf4041da1a647ba885 WHIRLPOOL 42a010b8903920f1f18a4605e8ab52c9b1d4e6cb3453c4dd0da3fd2e9507475514edeaac811d317c51c735db77c81c85b26632ae2ad13d71248
9372d166be25c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2iEYEAREIAAYFAlQmmGwACgkQVWmRsqeSphO1cACeM+Or/TPQ0vgB25/Qh69G56uN
ZYIAn3if38pWpCztZCTYgvweEAdhGPcp
=VW+a
-----END PGP SIGNATURE----- -
Ondřej CaletkaZlatý podporovatel
Jenomže portage se šíří nešifrovaným rsync protokolem, nikoli po SSH. Ano, GPG podpisy manifestů jsou, ale zatím na dobrovolné bázi a zatím se neprovádí automatická validace.
