Linus szerint a WireGuard "work of art", szereti

 ( trey | 2018. augusztus 4., szombat - 8:53 )

Linus a kernel hálózati alrendszerét, ipsec, crypto api stb. részeit karbantartó David S. Miller-nek írt levelében arról írt, hogy mielőbb szeretné beolvasztani a napokban említett WireGuard-t a mainline kernelbe. Ugyan szerinte lehet, hogy a kód még nem tökéletes, de összehasonlítva az IPsec és OpenVPN ""horrorokkal", művészi munka.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Koszonom az osszefoglalot.
Le a kalappal a fejleszoje/i elott.

Eddig nem tudtam a WireGuard létezéséről, de első pillantásra tetszik és biztos ki is fogom próbálni.

Ellenben pusztán a kódsorok számával dobálózni olyan gyerekes, különben is almát a körtével...
OpenVPN-ben minden részlet paraméterezhető:
Titkosítási algoritmus, tömörítés, transport protocol, kapcsolódási scriptek, per user beállítások, stb.
Nem egy súlycsoport a kettő...
Én leginkább azt szeretem benne, hogy bármin át lehet küldeni. Egyszer felhúztam egy OpenVPN-t tor kapcsolaton keresztül úgy hogy a szerver is hidden service-ként futott.
Jó, persze emlékszem az OpenSSL körüli botrányokra is, tény, hogy lenne még mit "csiszolni" rajta...

A lényeg, hogy rengeteg helyen bőven elég a WireGuard és tök jó, hogy van, de azért az OpenVPN-t se kell kárhoztatni, mert annak is van létjogosultsága bőven.

Egyetértek, jelenlegi formájában korlátozottan alkalmas kliens vpn megoldásnak. Semmilyen konfig push (route, dns, stb) megoldás nincsen benne. Nincs enterprise/ két faktoros authentikáció,authorizáció kezelés pl radius stb...
Beágyazott környezetben (Openwrt) s2s vpn-re kiváló. Gyors,egyszerű.

ahogy neztem ez nem is kliens vpn-re van kitalalva, hanem site2site-ra, kb a GRE vagy raw ipsec (nem l2tp) kivaltasara linuxok kozott.
az a baj, hogy a s2s kapcsolatok tobbsegenel (legalabbis amivel en talalkoztam eddig) is csak az egyik oldal linux. de persze valahol el kell kezdeni, 10-20 ev es elterjed ez is. az openvpn-nel barmi jobb.

Nem lesz az olyan gyors menet: https://lkml.org/lkml/2018/8/1/136

Azert igy mar egesz mas a leanyzo fekvese. :)

TLDR:

- nem 4 ezer sor, hanem 24 ezer
- nem kernel coding style: hosszu sorok, sok architektura egy fileban IFDEF-ekkel (vs kulon fileokban), ...
- le akarja cserelni/ala akar nyulni a kernelben levo Crypto API-t/-nak, raadasul egy darab oriasi patch-csel
- azt mondja magarol, hogy "state-of-the-art and unrivaled", de maris van olyan algo, aminek a jelenleg is kernelben levo megvalositasa gyorsabb
- az emlegetett formalis ellenorzottseg csak egy kis reszere vonatkozik
- nem tamogat crypto hardware-eket
- kerdeses a licenc, egyes ASM file-ok eredete
- egy uj, kulon konyvtarba akarja szervezni a crypto algoritmusokat es primitiveket, pedig -ha tenyleg jobb az uj- le lehetne cserelni azokat a jelenlegi helyukon is.
- Nulla granualitas, egy darab mindent vagy semmit CONFIG_ZINC opcio a kernel configba
- stb.

Szoval valaki bekuldott egy monster peccset, amivel a szokasokkal es a jelenlegi allapottal szembe menve atszabna az egesz crypto temat, mindezt egy "semmitmondo" brand bevezetesevel (Zinc).

Fura Linus reakcioja, pont az ellentetere szamitanek a magam reszerol. Lehet, hogy neki sem tetszik a jelenlegi crypto API es felul a "szar a crypto API, ugyhogy legyen helyette Zinc!" vonatra?

> Lehet, hogy neki sem tetszik a jelenlegi crypto API es felul a "szar a crypto API, ugyhogy legyen helyette Zinc!" vonatra?

Én azt nem értem, hogy a systemd hogyhogy még nem kebelezte magába a crypto-dolgokat (mondjuk systemd-cryptod néven)? Vagy ez már megtörtént? :P :D

- - -
TransferWise

Sok igazság van Erik mondandójában, de úgy nehéz lesz multiplatform cuccot csinálni, hogy a Linux crypto API-t kellejen használni.

ifdef?

Linux kernelen belül futó kódnál logikusnak tűnik. Amúgy is, a kód duplikálása elég baromságnak tűnik.
Tfh. találnak hibát egy adott crypto algo kódjában. A kernel "saját" közös implementációját kijavítják, majd hopp... leesik valakinek X idővel később, hogy ez a zinc-ben nincs javítva. Jó / jobb ez így?
Btw.: Gyanítom, mára mindegyik valamirevaló kernelben vannak modulok a mindenféle crypto algoritmusokra: csak a megfelelőt kell használni, ahová épp hordozzák.

Másrészt: A hordozhatóságot már gyanítom a gpl korlátozza. Minden más kernelhez úgyis kelleni fog egy bsdl vagy bsdl-szerű licenc. Vagy dual-licencelni a kódot gpl és bsdl alatt. (Lehet?)

A lényeg: tervezési és kódolási antipatternek használata semmilyen körülmények között nem fogja megkönnyíteni a hordozhatóságot. Sőtt, normálisabb kernelekből valószínűleg, pont ezek miatt a megoldások miatt fogják elhajtani és jó ideig be sem olvasztani, ameddig nem tud "normálisan" kinézni.

Az IPSec tényleg horror, pláne kezdőknek, még szerencse, hogy Mikrotik-en vannak kultúrált módjai a használatának.
De az OpenVPN-t miért nem rázták gatyába eddig és miért rosszabb, mint a WireGuard? Tán az OpenSSL függőséggel vannak gondok?

Trey: Most látom, leginkább azzal, hogy 4000 sorból megoldotta azt, amit mások többszázezerből :)

szerk.: tévedtem :)

Na de milyen sorokkal? :)

"The primary pathology of this patchset is the very long lines; I have
3840 horizontal pixels on my laptop, and I enjoy using all of them.
However, if this is a problem for parent tree maintainers, I'll dutifully
wrap at 80 chars per the norm."

[via]

+1

Linus öregszik, mi ez a dicsérgetés :D

+1 :D

- - -
TransferWise

Oké, de van is annyira jó, mint az OpenVPN vagy az IPSec?

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ezek még mindig emailben code review-znak? Nem gáz ez egy kicsit 2018-ban?

Miért lenne gáz? Úgy nézem, működik nekik, vagy legalábbis tudják használni. Amikor teljesen distributed módon használtuk a git-et, akkor is ilyesmi volt a megoldás.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

A git eleve teljesen distributed, nem értem a második mondatot :).

Itt van legalább három ok, amiért szerintem gáz. Egyrészt az email kommunikáció lossy, ha sok szálon megy a beszélgetés, akkor valószínűleg nem fog minden résztvevő minden üzenetet észrevenni. Másodrészt amikor egy környi review után kiküldi az alkotó a patchset következő verzióját, rohadtul nem fog látszani belőle, hogy pontosan mi változott az előző verzióhoz képest (ezt egy git webinterfészen meg lehet nézni, de akkor minek küldik emailben is, és mi a garancia, hogy ugyanaz van az emailben mint a gitben). Harmadrészt ha egyszer évekkel később vissza akarod követni, hogy egy bizonyos patch miért úgy néz ki, és ki hagyta jóvá, elég nehéz egy email archívumban keresgélni.

Nem lenne olyan bonyolult feltenni egy gerritet, vagy github vagy hasonló oldalon követni a review-kat.

A teljesen distributed alatt arra gondoltam, hogy nem volt központi repository a kódcseréhez.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ezt a módszert viszont nagyon szereti a google kereső, szinte bármilyen kerneles dologra rákeresek, egyből dobja a legrelevánsabb linkeket kapcsolódó patchwork/mail-archive.com@netdev/LWN.net archívum elemre. Ugyan ez a google-s rákeresés már pl. OpenStack-nél nem ilyen szép, sehogy nem találtam meg ami nekem kell. Még a commit keresőjével sem mindig sikerült megtalálnom ami érdekelt.

Mi is azt hasznaljuk es nagyon jol mukodik igy 2018-ban is. A fo ok az, hogy a GUI-s review eszkozok meg mindig nem tudjak azokat az alap feature-ket amit egy egyszeru email biztosit.
--
:wq

Pontosan mik ezek a feature-ök? Mert nekem pont ellentétes a tapasztalatom pl. egy Gitlab vagy Gerrit vs Email tekintetében.

Elorebocsatom, hogy a Gerrit-et nem ismerem, amit ismerek az a Github es a Phabricator. Az elonyoket legyszives ennek fenyeben olvassatok.

* Kulon szalakon folytathato beszelgetesek egy kodreszlettel kapcsolatban.
* Egy email kliensbol elrendezheto az egesz review folyamat (gondolom ez nem sokaknak szempont, de nekem es sokaknak az).
* Rendes patch-series tamogatas, minden patch kulon reviewolhato.
* Rendes patch-series verziozas tamogatas, konnyu uj verziokat kuldeni.
* A patchek minden reszehez hozza lehet szolni, a leirashoz is.
* Nem kell egy bongeszos GUI-val szivni, a review-ot irhatod a kedvenc szovegszerkesztodben is akar, elmentheto felkesz allapotban.
* Pull uzemmod, nem kell egy weboldalra felmenjek es megnezzem, hogy milyen uj patchek varnak review-ra, minden bejon az email fiokomba.

A github ezek egy reszet szinten tudja, az a legjobb rendszer amit eddig hasznaltam, a Phabricator eleg pocsek.

Bonuszok:
* Nem kell kulon infrastrukturat uzemelni. Minden projektnek van egy email-listaja amugy is.
* Reviewolashoz nem kell hozzaferest adni mindenfele rendszerekhez, csak egy listara kell feliratkozni.

--
:wq

hülye kérdés, de az ipsec-hez anno nem kellett Linus hozzájárulása / kódbeolvasztása ? OpenVPN az egy másik kérdés.
Vagy "ő" csak "biztosította" az ipsechez szükséges "dolgokat" a kernelben?

No idea, hülye vagyok ehhez, le lehet hülyézni :) (szerintem sok hülyézés lesz... :) )

ipsec-nek csak egy nagyon pici resze van a kernelben, a melo nagy reszet az userspace gany toolok (racoon/setkey) vegzik.

Hát a fene tudja:

WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come. There are experimental snapshots tagged with "0.0.YYYYMMDD", but these should not be considered real releases and they may contain security vulnerabilities