Vennův diagram pro curl a wget

Vennův diagram porovnávající nástroje curl a wget.

4.9.2023 17:55 | Ladislav Hagara | Zajímavý článek

Komentáře

[~]

Sranda je ze ackoli curl ma mnohem vice funkcionality tak mel mene zranitelnosti nez wget.

[..... Izak .....]

Logicky, protoze curl umi jen protokol a de fakto nic moc v nem, zatimco wget parsuje stranky a umi stahovat cele weby - tim padem je nasobne slozitejsi - tvari se jako web browser a hleda tam odkazy a media a ty stahuje

[Webař]

Chápu to správně, že by dávalo smysl, aby wget interně používal curl?

[petr_p]

Pozdě. Mezitím autoři wgetu udělali wget2 (který neumí FTP).

[xkucf03]

Myslím, že těmto programům chybí hlavně modulární architektura (a DI, IoC) a systematický přístup. Taky by neškodilo to psát v něčem vyšším a bezpečnějším, než je céčko (např. D, C++, Rust, Java, Go).

[K&R]

V unixu chceme u utilitky co nejmensi asm kod / binarku, tudiz pouze C ci Rust vyhovuji. Jakmile to pouzije OOP (D, C++) tak to nabobtna a kdyz jeste potrebuje k behu VM (Java) ci interpreter (Go) tak potes koste.

[RealJ]

Prijde sem fakeJ a bude to chtit prepsat do frontend/backend reseni…

[J]

No ne kurna, mrdneme tam wordpress...

[C doesn't rust]

Rust produkuje nekolikanasobne vetsi binarky nez C, oba linkovane staticky. Takzvany "bezpecny jazyk" je termin pro pojidace kolacu a kchatovace kchostu V kazdem jakzyku budete mrvit neco jineho, kdyz nebudete poradne investovat do kvality.

[koroptev]

no to je picovina co

dost jazyku ti napr. neumozni exploit typu buffer overflow, kterymzto muzes potencialne kompromitovat celej system, na kterym ti to bezi..

[O.V.]

proc C

[koroptev]

ten chlapek pravdepodobne nema ani jednu komercni hru a kdyz se na ty jeho vytvory podivas, tak to nesnese srovnani s nicim ani z roku 95..

proc je jeho nazor jakkoli relevantni?

[koroptev]

"Dealing with bugs is huge creative drain. I want to produce less bugs, so I want strict typing, strong warning messages and static code analysis. I want bugs to be easier to find, so I want good debuggers and dynamic analysis."

dobrej humor

[~]

Spis zkusenosti.

[koroptev]

jj, 50+ let historie exploitu zpusobenejch jen a jen ceckovejma srackama..

[xkucf03]

Silně/staticky typovaný jazyk je dobrá volba. Ale to neznamená, že by to mělo být C (mnohem užitečnější jsou ty jiné jazyky, o kterých jsem tu psal). Co se týče těch nástrojů, tak v tom má trochu pravdu - ono totiž čím starší a čím rozšířenější jazyk, tím víc takových nástrojů bude (historicky to štvalo tolik lidí, že ty nástroje napsali a vypilovali). A céčko staré a rozšířené je. Ale nemyslím si, že by to vyvážilo nedostatečnost toho jazyka samotného (správa paměti/zdrojů, ošetřování výjimek, dědičnost, abstrakce…).

[koroptev]

proboha to jsou tu sami idioti? ten humor je i o tom, ze cecko NENI silne staticky typovany jazyk..

[kutr]

Hlavně C není silně typovaný jazyk a i statické typování má z pohledu roku 2023 dost velké limity. Není moc jazyků co ti umožňujou udělat víc chyb a to i když nezmiňuju makra.

Např. ukaž mi typovou bezpečnost tady (na gcc 13.2 se to přeloží bez problému):

``` struct B { int a; int b; };

int main() { int a = 0; void* x = &a; struct B* y = x; return 0; }

```

[xkucf03]

Dá se to aspoň kompilovat C++ kompilátorem, když už člověk musí používat C (g++ vrátí chybu).

Ale osobně to moc nechápu, proč lidi dodnes píší tolik aplikací v C.

[koroptev]

souhlas, pokud je to nejakej historicismus, cecko pochopitelny, ale psat dnes vec v cecku je idiocie, v mezidobi probehla historie, ze ktery vzeslo pouceni

[Kate]

Teď myslíš wget a wget2, nebo wget a curl? Protože zrovna curl modulární celkem je a defaultní http backend bude brzo možná právě v Rustu. Na loňském Eurorustu na to měl hlavní vývojář Curlu fajn přednášku.

[xkucf03]

Modulárností nemyslím nějaké části kódu, které lze pomocí #ifdef zapnout/vypnout, ale mít jasně definované rozhraní pro moduly (např. jeden hlavičkový soubor) a mít možnost je dynamicky přidávat/odebírat (když už ne za chodu – což tady není moc potřeba – tak aspoň při startu programu bez nutnosti ho překompilovat).

Modul pak závisí jen na tom rozhraní a ne na celém programu. Program (jeho jádro) pak závisí taky jen na tom rozhraní a moduly si načte podle toho, které jsou k dispozici / nakonfigurované. Dobrým příkladem, že tohle jde dělat i v céčku, je třeba SQLite. Každá část se dá kompilovat nezávisle a poskládá se to až na počítači uživatele dle jeho potřeb.

Rozhraní modulů je definováno v souboru sqlite3ext.h (neplést s sqlite3.h), který má cca 500 řádek kódu a obsahuje jen signatury funkcí a komentáře – není zde tedy žádný spustitelný kód a jedná se o čistě abstraktní rozhraní. Když píšeme modul, závisíme jen na tomto souboru a kompilátoru, ale nikoli na SQLite jako takovém – náš modul je po kompilaci dynamickou knihovnou a není linkovaný k libsqlite3.so. Dá se říct, že funkce z libsqlite3.so jsou v době běhu do našeho modulu injektovány zvenčí.

Tzn. kdybych chtěl přidat např. podporu ipfs:// do programu typu curl / wget, tak by to mělo znamenat, že vezmu jeden hlavičkový soubor čítající pár řádek (abstraktní rozhraní), implementuji jeho funkce, zkompiluji z toho sdílenou knihovnu a hodím ji do nějakého adresáře (případně přiložím nějaký popisný soubor typu Turtle, jako to má např. LV2).

[petr_p]

Zvláštní, že jsem ještě neviděl distribuci, která by kompilovala SQLite modulárně.

Rozhraní modulů je definováno v souboru sqlite3ext.h (neplést s sqlite3.h), který má cca 500 řádek kódu a obsahuje jen signatury funkcí a komentáře – není zde tedy žádný spustitelný kód a jedná se o čistě abstraktní rozhraní. Když píšeme modul, závisíme jen na tomto souboru a kompilátoru, ale nikoli na SQLite jako takovém – náš modul je po kompilaci dynamickou knihovnou a není linkovaný k libsqlite3.so. Dá se říct, že funkce z libsqlite3.so jsou v době běhu do našeho modulu injektovány zvenčí.

Tohle je snůška nesmyslů. SQLite si za běhu přilinkuje modul a zavolá z něj sqlite3_*_init(), která zpětně volá sqlite3_create_module_v2() nacházející se v SQLite. Jak modul najde sqlite3_create_module_v2()? Inu, sqlite3ext.h includuje sqlite3.h, který jej deklaruje. To znamená, že sqlite3.h je rozhraním pro moduly. A jak modul získá adresu sqlite3_create_module_v2()? V době překladu ponechá symbol nedefinovaný a slepě se spolehne, že aplikace, která modul zavede přes dlopen(), ten symbol už budeme mít v adresním prostoru. Typická bezpečností chyba late bindingu (vašimi slovy „modul je po kompilaci dynamickou knihovnou a není linkovaný k libsqlite3.so“). Stejně blbě jako to dělá Python nebo Perl a distributoři to po nich pak musí opravovat.

[xkucf03]

To, že je tam #include <sqlite3.h>, by šlo ještě napravit/vylepšit. Nicméně by se odtamtud měly používat jen struktury - žádné funkce by se neměly volat na přímo. Od toho je tam ta struktura plná ukazatelů na funkce + ta makra typu:

#define sqlite3_bind_int    sqlite3_api->bind_int

Tzn. modul není linkovaný proti libsqlite3.so, závisí jen na:

        linux-vdso.so.1 (0x00007ffe40d77000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f88fc15d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f88fc3ac000)

a funguje to díky tomu, že ty signatury metod v té struktuře v sqlite3ext.h se nemění a pasuje na ně reálná implementace, se kterou se to propojí až za běhu (SQLite naplní do té struktury ukazatele na skutečné funkce).

která zpětně volá sqlite3_create_module_v2() nacházející se v SQLite. Jak modul najde sqlite3_create_module_v2()? Inu, sqlite3ext.h includuje sqlite3.h, který jej deklaruje.

Viz výše - přes makro:

#define sqlite3_create_module_v2    sqlite3_api->create_module_v2

zavolá funkci, na kterou ukazuje ukazatel v této struktuře:

struct sqlite3_api_routines {
    ...
    int (*create_module_v2)(sqlite3*,const char*,const sqlite3_module*,void*,
                          void (*xDestroy)(void *));

Podobným způsobem funguje JNI a .so knihovny implementující nativní metody, které se pak volají z Javy - ani zde to moje .so nezávisí na konkrétním libjvm.so. Podobně, když používám JNI opačným směrem a mám program v C/C++ a uvnitř něj si ručně spustím JVM – ta moje binárka taky není při kompilaci linkovaná proti knihovnám konkrétní Javy, ale přes dlopen() si načte libjvm.so, kterou jí zadám (to může být třeba parametr na příkazové řádce nebo si to odvodím z $JAVA_HOME atd.). A funkce/metody JNI se pak volají přes JNIEnv, což je zase struktura, uvnitř které jsou ukazatele na funkce, které se tam dosadí dynamicky. Tzn. klidně si tu nativní část můžu zkompilovat s hlavičkovými soubory z Javy 17 a pak si to pouštět s libjvm.so z Javy 8 a bude to fungovat.

[xkucf03]

To znamená, že sqlite3.h je rozhraním pro moduly.

S tímhle tedy souhlasím. Ano, bylo by lepší, kdyby v sqlite3ext.h řádek #include <sqlite3.h> vůbec nebyl a případné společné konstanty/signatury byly třeba ve třetím souboru.

Nicméně si myslím, že to na věci nic nemění, protože hlavní „trik“ spočívá v tom, že se funkce nevolají přímo, ale přes ukazatele v té struktuře, které se naplní za běhu tak, aby ukazovaly tam, kde ty funkce skutečně jsou (a ne tam, kde byly funkce nějaké jiné verze, když se to kompilovalo).

[xkucf03]

P.S. Tohle má čistěji udělané ta Java / JNI:

$ cat /usr/lib/jvm/java-17-openjdk-amd64/include/jni.h | grep '#include'
#include <stdio.h>
#include <stdarg.h>
#include "jni_md.h"

$ cat /usr/lib/jvm/java-17-openjdk-amd64/include/linux/jni_md.h | grep '#include'

Tzn. můžu si zkopírovat tyhle dva hlavičkové soubory na počítač, kde Javu vůbec nemám, tam si v klidu vyvinout program/modul, a pak to dát někomu, kdo si to se svojí Javou spustí. Kdybych si např. chtěl od tebe objednat vývoj nějakých nativních metod, tak bych ti dal jen tohle + hlavičkový soubor se signaturami těch metod, které se mají implementovat (javac -h ...) a ty bys vůbec nemusel mít Javu a byl bys schopný to vyvinout jen na základě specifikace. Tohle je podle mého ideál, jak by to mělo vypadat – vývojář modulu není zatěžován komplexitou celku a vyvíjí jen proti nějakému izolovanému a stručnému rozhraní.

[petr_p]

A k čemu to všechno, když standardní dynamické linkování, které poskytuje ELF, dělá to samé? Jediný rozdíl je, že nepotřebujete mateřskou knihovnu v době překladu a že to funguje na platformách, jejichž dynamický linker stojí za starou bačkoru. A popravdě mám obavy o výsledný výkon, protože pak každé volání funkce znamená dvě dereference. Výkon bude asi důvod, proč se moduly dodávané s SQLite standardně překládají nemodulárně.

[xkucf03]

Původně (#23) jsi tu naznačoval nějaký problém, tak jsem se snažil vysvětlit, jak to SQLite řeší… a najednou to problém není a mohlo by to být standardní dynamické linkování? Tak jak tedy?

A k čemu to všechno…?

Třeba abys mohl ten svůj modul načíst i z programů, které SQLite linkují staticky, což je typicky i příkaz sqlite3. Pokud by se tvůj modul vázal na libsqlite3.so, zatímco program (např. sqlite3) by v sobě měl zakompilované SQLite staticky, tak by tam ty funkce/struktury byly dvakrát a nespojilo by se to.

Díky tomu, jak je to udělané (struktura plná ukazatelů na funkce), tak můžu mít jednou zkompilovaný modul, který nezávisí na libsqlite3.so, a ten si načíst jednou do staticky linkovaného programu (např. sqlite3), který má SQLite zakompilované v sobě, a jindy do dynamicky linkovaného (např. ODBC ovladač pro SQLite), který se váže na libsqlite3.so.

[petr_p]

Původně (#23) jsi tu naznačoval nějaký problém, tak jsem se snažil vysvětlit, jak to SQLite řeší… a najednou to problém není a mohlo by to být standardní dynamické linkování? Tak jak tedy?

Naznačoval jsem, že modul volá (některé) funkce z SQLite a hledá je pomocí dynamického linkování.

Třeba abys mohl ten svůj modul načíst i z programů, které SQLite linkují staticky

Ano, tady to smysl dává. Ono obvykle to fungovat bude, i když by se modul spolehl na late binding dynamického linkování bez explicitního linkování k libsqlite3.so. Ale stačí aby se do procesu přimotala libsqlite3.so z jiného důvodu (třeba jako tranzitivní závislost), a pak se to rozsype, jak jste popsal. To by musel dynamický linker všechny zaváděné knihovny izolovat pomocí RTLD_LOCAL. Ale to by asi přineslo jiné problémy.

[xkucf03]

To by klidně šlo – napsat program, který bude emulovat rozhraní wgetu a uvnitř bude volat curl. Jestli by to dávalo smysl? To je otázka. Na jednu stranu by se autoři takového wgetu mohli soustředit na ty věci navíc (např. stahování/zrcadlení celých webů) a nemuseli by řešit nízkoúrovňové detaily jednotlivých protokolů. Na druhou stranu: konkurence je potřeba a mít víc nezávislých implementací téhož se hodí (už jen pro kontrolu - když je mezi nimi shoda, je to nejspíš správně).

I v případě WWW prohlížečů se řeší problém, že prakticky všechno je dneska buď Chrome nebo převlečený Chrome (nebo Mozilla, která je na Chromu/Googlu závislá a navíc paralyzovaná politickými aktivisty). WWW prohlížeč je něco obrovsky komplexního a i tam je snaha s tím něco dělat a mít víc implementací. Tak by mi přišlo dost škoda tu konkurenci/pluralitu zahodit i u něčeho tak (relativně) jednoduchého, jako je wget/curl.

[nadtržítko]

Prevleceny Chrome je to jen proto ze Chromium je open source. A jednou to Google zarizne jak je u nej zvykem.

[Max]

On zařezává projekty, které jsou pro něj nerentabilní. Web prohlížeč, který mají skoro všichni, mezi ně asi patřit nebude.
Zdar Max

[Trh]

Je to akciovka, kdyz valna hromada rekne ze se za pouzivani Chrome bude platit tak Chromium klidne zariznou.

[Max]

Jasně :DDD
Zdar Max

[Crystal Koule]

A proc ne? Maji 60% trhu nebo 3mld instalaci. Kdyz tam hodi 0.99$ mesicne (existujici ovecky platici youtube, drive atd. to budou mit v cene) tak i kdyby pulka uzivatelu zdrhla tak maji mesicne 1.5mld doma! Zaroven elgantne poslou do prdele MS Edge kteri nevericne budou zirat jak telata ze prisli o engine. Pak MS povede nejake truckonzorcium forkne stary Chrome a budou se o neco snazit a pak to po roce vzdaji protoze bud Chrome utece milovymy kroky anebo se rozhadaji jak mala decka. Netusim co by mohlo nastat driv.

[RealJ]

Libis se mi!

[Max]

Jasně :DDD
Zdar Max

[koroptev]

jak je Mozilla zavisla na Chrome / Google?

[~]

Financne.

[Max]

Google sponzoruje Mozillu, a to hodně, příklad: Why Has Google Spent a Half-Billion Dollars on Firefox?
Zdar Max

[koroptev]

hm, mozna proto vymejslej picoviny a je jim u prdele, ze jim klesa market share

[Palee]

Od kdy byl meritkem coolovosti browseru market share? Jako netvrdim ze Chrome nemam ale v podstate ho na browsovani vubec nepouzivam, jenom na vyvoj webu.

[RealJ]

Co je cool to se pouziva. Funguje to vzdy a vsude. Podivej se na Instagram vs Mastodon. 2.5miliardy aktivnich uzivatelu vs 10 milionu registrovanych uzivatelu.