Možná je tedy na čase kromě klasického "import" začít uvažovat nad integrací dalších bezpečnostních mechanismů. Pomohlo by to nejen s AI ale i dalšími problematickými situacemi.
Nabízí se třeba:
secimport balicek
* import jen z podmnožiny ověřených balíčků
* kontrola podpisů balíčků
* transparentní izolace běhu balíčků do sandboxovaného prostředí a komunikace s ním přes api identické s běžným použitím
* ...
Když neplatí "můj kód můj hrad" je třeba budovat kolektivní obranu.
Bohužel to bude něco stát na úrovni výkonu, ale s dobrým návrhem a implementací by to nemuselo být tak bolestivé.
Kdo bude ty balicky overovat? AI? ...
Tady ti nikdo nepredklada falesny balicek, takze ti kontrola podpisu nijak nepomuze. Stejne jako ti nepomuze zadny sanbox ... kdyz neco leze treba do databaze, tak tomu pristup do databaze dat musis.
Právě pro to, že není dost kvalifikovaných sil k ověřování všech balíčků, měla by existovat jejich ověřená podmnožina. Nebude to 100% ale bylo by to výrazně lepší, než nemít možnost to rozlišit.
Taková funkce mě napadá s ohledem na ty, kteří potřebují a chtějí vytvářet programy, třeba s pomocí vibecodingu, ale nemají potřebné znalosti, aby si to byli schopní aspoň trochu ověřit.
Sanbox je jen další technika, která se běžně používá.
Ano, tomu co potřebuje a má lézt do databáze můžu dát do databáze přístup, ale nemusí ho mít to, co do ní lézt nemá.
Aktuálně je to tak, že se to na úrovni programu nerozlišuje a bere se, že k databázi má přístup program jako celek.
Samozřejmě můžeme jen žehrat na ten nemilý současný stav, nebo se můžeme zamýšlet a následně podnikat kroky k tomu, aby byly dostupné prostředky, jak to provozovat lépe/bezpečněji.
> Taková funkce mě napadá s ohledem na ty, kteří potřebují a chtějí vytvářet programy, třeba s pomocí vibecodingu, ale nemají potřebné znalosti, aby si to byli schopní aspoň trochu ověřit.
Akorát že tohle je flíkování problému na úplně špatném levelu.
Problém je ten, že takoví lidé z principu dávají obrovská práva kódu, který vznikl procesem na který nemají jakoukoliv páku. A nikdo jim nic nezaručí.
Takže potenciálně nebezpečný a děravý je celý ten navibený kód. že je tentokrát díra v importu je vlastně jen detail. A sandboxovat by to chtělo spíš celý ten nagenerovaný kód. Protože člověk, co si to není schopen aspoň trochu ověřit samozřejmě nebude řešit ani to, jestli jsou knihovny importované správně, nebo ne.
Ono uz k tomu, abys ten kod vygeneroval, porebujes tomu cemusi dat opravneni.
Celkem nedavno se tu kolem povaloval clanek jak nekdo s Aickovym generatorem zprovoznil inteli cpu na desktopovy desce, pro kterou neni urcen. Pokud si pamatuju, trvalo mu to cca 200 pokusu a vysledek byl ze se to "rozsvitilo". Ok, dukaz ze je to ciste SW vec, ale ty si das do svyho PCdla BIOS, o kterym nikdo netusi co vlastne dela? Protoze ten dotycnej to vubec nevedel.
Pritom zrovna bios je pomerne jednoducha vec snadno dekompilovatelna, takze by se snadno dalo dohledat co kde jak. Ve skutecnosti by dost pravdepodobne stacilo vzit serverovej bios, rozlozit ho na jednotlivy komponenty a nejakou z nich vizt a pribalit ji k tomu desktopovymu. Ony totiz jsou ty biosy presne takhle po kouskach skladany.
Ano, realita je taková, že ten vibecoding používají i lidé, kteří v životě nenapsali ani jedinou instrukci, netuší jak funguje CPU, RAM, a celý ekosystém SW.
A i tito lidé dnes mají šanci přijít s užitečným programem, protože mají pro svůj život a pro svou práci specifické požadavky které jim zatím nikdo nepokryl.
Je to podobný stav, jako když se program vytvářel fyzickými propojkami a přišlo se se zadáváním zdrojového kódu. Program vytvářeli zpravidla lidé, kteří měli naprosto přesné znalosti konkrétní architektury, HW detailů a fyziky na které to stálo.
A podobný posun se stal:
* když se zadával zdrojový kód a přišlo se s assemblerem.
* když se psalo v assembleru a přešlo se na (tehdy) vysokoúrovňové platformě méně závislé jazyky
* když se k vlastním zdrojákům začaly ve větší míře používat importované knihovny
* když začaly se používat frameworky
Každý ten přechod odsunul programátory o další vrstvu dál a znamenal i nutná bezpečnostní a funkční opatření na různých úrovních. A Svět se teď nezastaví jen pro to, že se nám už zase zdá, že by programy neměli psát lidé, kteří tomu nerozumí. Z toho důvodu je třeba upravovat současné nástroje a vytvářet nové nástroje, které tenhle svět programování připraví na novou realitu.
Takže souhlas, potenciálně je rizikový celý ten navibený kód. A izolaci bych rád viděl v základu na úrovni OS. tak aby to bylo transparentní a uživatelé to ani nemuseli řešit. Zároveň pokud by chtěli jí za tuto vrstvu ochrany, aby to bylo možné a srozumitelné o co jde. Už teď je těch izolací několik včetně RINGů a chráněného režimu. Chroot je izolace. Virtualizace a kontejnerizace. Instalace knihoven per uživatel. Venv a spol. Izolace v browseru, ...
A izolace se s možností locknout importy pouze ověřenější balíčky se nevylučuje.
Kdybych měl možnost v Pythonu použít funkci pro instalaci/import ověřených balíčků nejlépe i s kontrolou podpisu, tak bych ji využil a učil mé studenty, aby ji po jejich AI nástrojích požadovali.
On už měl FORTRAN hlavní motivaci svého vzniku v myšlence, aby si fyzik/matematik/inženýr mohl programy psát sám a nepotřeboval se učit strojový kód nebo angažovat programátora. Problém vidím v tom, jak se široké laické masy hrnou do programování i poměrně kritických systémů. Chyba není vydání knihy "Domácí lékař", ale když se člověk, omezený na znalosti z takové knihy, pohrne do operací srdce či mozku. A analogie toho se v IT světě (nejen) děje v masovém měřítku. Nepřestává mě udivovat, s jak málo kvalifikovanými experty (ve smyslu označení dané pozice) se čím dál častěji střetávám - expert kyberbezpečnosti pořádně neví, ani co je IP adresa; expert programování PLC neví, co je operace XOR nebo jaký je matematický význam jednotlivých parametrů PID regulátoru - prostě s tím šoupe sem a tam, dokud to za určité konstelace nějak uspokojivě nefunguje s tím, že lépe to, podle něj, vyladit zkrátka nejde; elektrikář netuší, proč mrazák napojený přes dva 50m 3x1,5 prodlužováky nechce fungovat; elektrotechnik se snaží vylovit signál z pod úrovně šumu pomocí zesilovače nebo se diví, že spojení přes modemy určené pro 100ohmovou kroucenou dvojlinku se "záhadně" rozpadá, když tam místo ní "pro sichr" dal 10krát dražší 75ohmový koaxiál, protože výrobce udává, že má super nízký útlum, tak by to přece mělo fungovat ještě lépe než ta dvojlinka za pár korun, že... Ministerským expertem na větrné elektrárny je právník, strategii koncepce energetiky píše sociolog společně se specialistou na retail marketing... A support dodavatele určité technologie vám místo rad posílá bláboly, které mu vyblil LLM.
V tomto vidím obrovské nebezpečí - lidé přestávají rozumět věcem, nebezpečně se spoléhají na technologie, o nichž toho pramálo vědí, neověřují si informace a jsou líní přemýšlet. Přesně na tohle jednou tato civilizace dojede. A jestli k tomu bude i nějaký jaderný ohňostroj, tak "jen" jako důsledek výše napsaného.
RE: "lidé přestávají rozumět věcem":
Že lidé věcem nerozumí, na to žehrali už před tisíciletími.
Většina lidí denně používá spoustu nástrojů (aplikací) o jejichž vnitřním fungování toho moc neví.
I jen obyčejné spláchnutí záchodu je závislé na kaskádě souvztažností s desítkami tisíc komponent.
To co by se mělo dít a do velké míry to funguje je, že lidé, kteří v dané oblasti mají hluboké znalosti by měli pomáhat s návrhem zařízení / služeb pro lidi, kteří ty zařízení / služby / aplikace budou používat a budou mít značně rozdílnou úroveň znalostí.
V našem případě jde programovací jazyk a jeho ekosystém.
Že to tak do značné míry funguje, to vidíme na tom, že jsme se jako civilizace dostali tam kde, po materiální stránce, jsme. Že to nefunguje vždy a všude také vidíme, třeba na případu bezpečnosti IoT zařízení a u mnoha online aplikací (čest světlým výjimkám).
Tam, kde materiálně jsme, jsme se rozhodně nedostali tím, že jsme kozly dosazovali na pozice zahradníků. To je symptom až posledních dekád, jenž nás těch materiálních výdobytků poměrně rychle zase zbaví.
Jsem pro, aby si mohl programování vyzkoušet každý, kdo o to projeví zájem, aby si mohlo nějaké to blikátko ubastlit i dítě, jakmile to motoricky zvládne. Jenže mezi tímto a řídícím systémem elektrárny je ještě dost velká propast, jež musí být nejdříve zaplněna odbornými znalostmi a schopnostmi, než se dotyčný na toto pole může vydat. A technologie jako LLM velmi silně pomáhají v lidech vytvářet dojem neexistence této odborné propasti.
S tím, že neschopní neználci na odpovědných postech jsou nešvar posledních dekád s tím nesouhlasím. IMHO to bylo vždycky.
Že by to tak být nemělo, na tom se shodneme.
Kritické programy by měly být z rukou odborníků, ať už jim při tom bude asistovat GenAI nebo ne.
V nějaké míře to samozřejmě bylo vždycky. Ale pozoruji, že se to postupně zhoršuje - a nejsem zdaleka jediný, kdo to pozoruje.
"On už měl FORTRAN"
SQL je taky jazkyk pro uzivatele, tedy specificky fizlocajty ... aby si mohli sami hledat data... ;D
A dneska ti prumernej absolvent ZS (tzn v prumeru ma trojky) nepozna sroubovak od hasaku. Takze by me celkem zajimalo, copak jako chce delat .. asi nejakej ten vibe coding ...
BTW: Videls nekdy 50m prodluzovak na kterym visi 10 gamesnickejch PCcek? Ja jo, ty plaminky jsou nezpomenutelny.
"Většina lidí denně používá"
Jenze tu se nebavime o pouzivani. Bavime se o tom, ze navrhujes most, nevis jak funguje paka, a bez uzardeni tvrdis, ze "ten most se vazne prodlouzi o 17 metru". Dokud po tom moste chodim, tak nepotrebuju vedet jak funguje.
Na importu není nic nebezpečného, to ho jen nechápeš. Stačí importovat jen balíčky, kterým důvěřuji, což je většinou něco, co stejně pochází od někoho dalšího z firmy. Pokud nevíš co importuješ, není to chyba importu, ergo není potřeba jiný import.
Ty tvoje první dvě věty si docela odporujou. Kdyby na importu nebylo nic nebezpečného, tak můžeš importovat cokoliv.
Import v Pythonu samozřejmě nebezpečný je, protože už během něj se může spustit naprosto libovolný kód.
Inport načte lokálně naninstalovaný modul/balíček. Pokud ho chceš nějak ověřovat, tak při instalaci a ne při importu!
RE: "Inport načte lokálně naninstalovaný modul/balíček..."
I když to není pravda, tak s Vámi souhlasím v tom, že v procesu instalace externích knihoven / balíčků / frameworků / ... může být také řada ochranných mechanismů.
25. 5. 2026, 12:19 editováno autorem komentáře
Docela malé procento, já těch halucinací už viděl. Má nejoblibenější, zrychlení routeru se provede instalací balíčku "kmod-mips-optimize".
Nicméně, nejen z těchto důvodů, už jsem začal koukat, po tom, jak distribuovat vlastní balíky (po schválení). Koukám že Gitea mi má být nápomocná, má repozitáře na všechno, včetně pypi, stejnětak statické instalace se vším.
Doba důvěry "ono se to nainstaluje online" je pryč.
Ta doba duvery nikdy nebyla. Byli jen duveryhodni mamlasove, kteri si jen includovali do projektu kdejakou kravinu. Pripadne *all.
Uz pred 25 lety se delala poloautomatizovana hloupkova kontrola zavislosti. A obcas to znamenalo i konec projektu.
Ono neni vubec spatne ze mam neduveryhodnou komponentu. Jen mysim o ni vedet, oznacit a byt pripraven na kizna rizika ti resit - vyhodit / analyzovat / opatchovat / napsat po svem.
Kdo pouziva vibe coding a nepremysli/nekontroluje si tohle zaslouzi.
23. 5. 2026, 17:17 editováno autorem komentáře
Tady a viz výše Trident, nedůvěryhodné balíčky si můžu dát na oddělený server/virtuálku/kontejner, vytvořit nad ní API a volat zvenku jen to. Např. kdysi dávno jsme měli ve firmě placenou closed-source knihovnu na vytvoření PDF, tak bych volal API do kontejneru s ní a ven by lezlo PDFko. Kód knihovny by nikam ven nemohl, i přístup do firemní sítě a na internet se dá v tom kontejneru zakázat (např. telemetrie).
25. 5. 2026, 10:51 editováno autorem komentáře
Jenze ty resis uplne jinej problem a uplne jinde.
Aby ti to pseudoAI vubec neco vygenerovalo, musis tomu dat pristup ke spouste vecem. O ano, muzes si udelat analyzu, muzes si udelat audit ... a mezi tim bys za 1/10 casu a ceny vyslednej kod napsal rucne.
A co je ti platny auditovat, co to dela, kdyz netusis, proc to dela.
Mimochodem, co myslis, copak asi tak zdejsi soudruzi kontroluji na
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-4…"></script>
Coz je jeden z mnoha. Zeby? Vlastne vubec netusej co to dela, natoz aby tusili co to bude delat za minutu. A presne takhle je zasvineno 99% webu, takze nejak se neni cemu divit ze se totez rozsiruje i mimo web.
Já mluvím o výsledném kódu, ať už 3rd party knihovny nebo kód vygenerovaný AI, který jsem následně důkladně nezkontroloval. Samotný proces generování běží v rámci mého uživatele, pokud si s tím teda nechci hrát. Ale to není běh kódu na produkci.
Sní to senzačně, ale já už se něco navajbil jako hobby i na na produkci a nikdy mi to neexistující balíček nepodstrčilo. Jedině u hůř zdokumentovaných knihoven si to vymyslelo neexistující příkazy. Používám tedy Codex.
"nikdy mi to neexistující balíček nepodstrčilo
"
Však hackeři už ty kdysi neexistující balíčky dodělali :-)