Třeba tak, že se ve vývojářských nástrojích podíváte, odkud se to stahuje.
a to je ten problém, nejprve musí rozšíření nainstalovat a spustit, to je skvělé pro ty hodně nebezpečné.
Proč je potřebujete stahovat hromadně?
Hromadně právě kvůli dopředné kontrole, kvůli možnosti nastavení automatických procesů, které budou kontrolovat více rozšíření najednou. Např. v jedné firmě s asi 150 uživateli máme dohromady nainstalovaných nějakých 900 různých rozšíření, na které je potřeba dávat oko a ověřovat každou jejich novou verzi.
A já jsem myslel, že se konečně něco dozvím. Zajímalo by mne, kdo a jak podle vás kontroluje zdrojový kód aplikace, než pro ni vznikne ebuild pro Gentoo. A také by mne zajímalo, kdo a jak podle vás kontroluje kód aplikace, než se z něj udělá deb balíček pro Debian.
Mohu třeba citovat Debian guidlines pro mainteinery při aktualizaci balíčků:
8.2 Inspection of the new upstream releaseWhen preparing packages of a new upstream release for the Debian archive, you must check the new upstream release first.Start by reading the upstream changelog, NEWS, and whatever other documentation they may have released with the newPodobná pravidla jsou i jinde. Např. u RHEL ta kontrola je vždy u všech aktualizací, to aspoň slibují v podmínkách. U Gentoo mají vlastní security tým, který slouží jako podpora mainteinerům, jejich QA Reports jsou automatizované, zodpovědnostní mainteinera je právě kontrola zdrojového kódu při aktualizaci.
version.You can then inspect changes between the old and new upstream sources as follows, watching out for anything suspicious:$ diff -urN foo-oldversion foo-newversionChanges to some auto-generated files by Autotools such as missing, aclocal.m4, config.guess, config.h.in,
config.sub, configure, depcomp, install-sh etc.
5. 2. 2021, 21:53 editováno autorem komentáře