- A hozzászóláshoz be kell jelentkezni
Hozzászólások
"WireGuard, at just under 4,000 lines of code, aspires to be simpler and more easily audited.
Compare that to 100,000 lines of code for OpenVPN, which also requires OpenSSL, another 500,000 lines of code. Or consider Linux XFRM, an IPsec implementation that spans about 13,000 lines of code and may be used alongside StrongSwan for the key exchange, which runs about 400,000 lines of code."
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Koszonom az osszefoglalot.
Le a kalappal a fejleszoje/i elott.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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ű.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nem lesz az olyan gyors menet: https://lkml.org/lkml/2018/8/1/136
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
> 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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
szerk.: tévedtem :)
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Linus öregszik, mi ez a dicsérgetés :D
- A hozzászóláshoz be kell jelentkezni
+1 :D
- - -
TransferWise
- A hozzászóláshoz be kell jelentkezni
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…
- A hozzászóláshoz be kell jelentkezni
Ezek még mindig emailben code review-znak? Nem gáz ez egy kicsit 2018-ban?
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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…
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Pontosan mik ezek a feature-ök? Mert nekem pont ellentétes a tapasztalatom pl. egy Gitlab vagy Gerrit vs Email tekintetében.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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... :) )
- A hozzászóláshoz be kell jelentkezni
ipsec-nek csak egy nagyon pici resze van a kernelben, a melo nagy reszet az userspace gany toolok (racoon/setkey) vegzik.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni