Elérhető az OpenSSH for Windows kódja a Github-on

Microsoft, Windows

A Microsoft PowerShell csapatának részéről Angel Calvo júniusban bejelentette, hogy többszöri próbálkozás után ismét megpróbálkoznak az SSH protokoll Windowsba építésével az OpenSSH közösség támogatása és az azzal való együttműködés által. Most Steve Lee adott helyzetjelentést a dolgok állásával kapcsolatban.

A csapat elérhetővé tette a kódot a Github-on, ami mostantól nyitott a közreműködni szándékozók előtt. A bejelentés mellett egy vázlatos útitervet is ismertettek:

  • 1. Update NoMachine port to OpenSSH 7.1 [Done]
  • 2. Leverage Windows crypto api’s instead of OpenSSL/LibreSSL and run as Windows Service
  • 3. Address POSIX compatibility concerns
  • 4. Stabilize the code and address reported issues
  • 5. Production quality release

A céljuk az, hogy 2016 első felére elérjenek az 5. mérföldkőhöz.

Részletek itt.

( freeoli v | 2015. 10. 21., sze – 22:31 )

Nem találok szavakat. Szuper.

Ha jól nézem, a központi, internetes tárolóval rendelkező alkalmazás kezelőt már átvették ami sajnos a függőségeket még nem kezeli automatikusan de sebaj, a rolling release majd megoldja.

A probléma amit köpködnek:

"Leverage Windows crypto api’s instead of OpenSSL/LibreSSL and run as Windows Service"

Vagyis a Microsoft a saját, zárt forrású crypto kódját akarja az OpenSSL/LibreSSL helyett. Ez nyilvánvalóan szembemegy az OpenBSD szemléletével (hacsak nem küldött a Microsoft egy valag pénzt, amivel Theo eladta a lelkét), így valósak azok a reklamációk, hogy ha ez így van, akkor ne nevezze a Microsoft ezt OpenSSH-nak.

Kíváncsi lennék Theo véleményére ezzel kapcsolatban.

--
trey @ gépház

Kerdeses, hogy az ember akkar -e tobb olyan crypto libet a sajat rendszereben egyszerre hasznalni, ami ugyan azt a celt szolgalja.

Logikusnak tunhet egyet hasznalni mindenutt ahol lehetseges.

Hogy menyire logikus zartat hasznalani az mas kerdes..

Amig az OpenSSH kodja nem lesz tull spageti az #ifdef -ektol, ill lasabb amikor OpenSSL/LibreSSL -t hasznal az ember, nem hinem, hogy barkit is zavarna a kodbazisban.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem hiszem, hogy azon problémáznak, hogy sajátot használnak, hanem azon, hogy

- nem OpenSSH-nak kéne akkor hívni
- nem kellene úton útfélen hangoztatni, hogy ők így az OpenSSH közösséggel, úgy az OpenSSH közösséggel, miközben a bejelentésük nagy őrjöngést nem váltott ki. Ráadásul amiben ez áll:

"As part of this, we're looking to contract some experts on SSH and Win32 to collaborate with us on the Win32 port. Our focus is to contribute to OpenSSH - not to create a private fork."

Elég hamar elcsúszott a fókusz.

--
trey @ gépház

Megfordítva a kérdést: mi lenne az előnye annak, hogy nem a natív API-t használják egy OS-specifikus buildben? Ez önmagában nem veszélyes az upstreamre, oda simán vissza lehet tolni a fejlesztéseket.

A Crypto API-t már elég sok minden használja, ha ne adj' Isten igaza van a cikknek, és backdoor van benne, akkor már úgyis mindegy. :) Az OpenSSL/LibreSSL-fronton is láttunk már izgalmas dolgokat. Értem, hogy ez utóbbiak nyílt forrásúak, tehát by definition biztonságosabbnak kéne lenniük, de a LibreSSL-t pl. auditálta már valaki?

Illetve az sem tiszta nekem, hogy ha nem szándékoznak forkot csinálni, akkor miért tették ki a GitHub-ra a forrásfájukat azzal, hogy az nyitott a közreműködni szándékozók előtt? Akkor a patcheket az upstream-nek (ez esetben az OpenSSH portable fejlesztőknek) kellett volna küldeniük, nem? Oké, ez így nem privát fork, hanem nyilvános... de fork.

--
trey @ gépház

LibreSSL-t pl. auditálta már valaki?

A neves Qualys biztonsági cég a katasztrófális OpenSMTPd audit eredmény publikálása után ránézett az OpenBSD csapat másik üdvöskéjére is egy kicsit és a kevés módosítás ellenére a LibreSSL-ben két biztonsági hibát is találtak, amelyek az OpenSSL-t nem érintik, tehát már a fork után sikerült "belefejlesztenie" a nagyon biztonságtudatos csapatnak...

A crypto egy olyan összetevő, amin a titkosítás múlik. Az meg egy titkosított kommunikációt lehetővé tevő szoftvernél elég fontos funkció. Ha valakinek azt mondod, hogy OpenSSH, az joggal véli azt, hogy az iparban kvázi szabványként ismert cuccot kapja, vele az ismert - jó, rossz tökmindegy - függőségeit is.

Nem egy zárt, ismeretlen valamit, amiben azt rejtenek el, amit akarnak.

Ezeket az aggodalmakat olvastam. És én ezeket validnak találom. Hogy te nem, az a te dolgod. Egyszerűen meg lehetne oldani ezt a problémát. Ezt a forkot nem kéne OpenSSH-nak nevezni. Ennyi.

--
trey @ gépház

BaT meg arról beszél, hogy a függőségek miatt más nevet választani is furcsán adja magát. Pl. az OpenSSH-nál is választhatsz, hogy az OpenSSL vagy a LibreSSL cryptoját használod hozzá, mégsincs OpenSSH és LibreSSH külön-külön.

De mondok jobbat: a Linux disztribúciók legnagyobb része megpatcheli az eredeti OpenSSH portable forrást többekközt a High Performance SSH foltokkal, amelyeket az OpenBSD fejlesztők abszolút nem támogatnak... Akkor ezeket a módosított OpenSSH-kat se hívják a Linux terjesztők a továbbiakban OpenSSH-nak?

Ha engem kérdezel, akkor fork esetén ne legyen ugyanaz a neve. Ha Linuxban van, ha Windowsban. Lásd. Grsecurity esete:

"The aforementioned company has been using the grsecurity name all over its marketing material and blog posts to describe their backported, unsupported, unmaintained version in a version of Linux with other code modifications that haven't been evaluated by us for security impact. Simply put, it is NOT grsecurity – it doesn't meet our standards and at the same time it uses our brand and reputation to further its marketing.

They are publishing a "grsecurity" for a kernel version we never released a patch for. We provided evidence to their lawyers of one of their employees registering on our forums and asking for free help with backporting an EFI fix to their modified version of grsecurity based off a very old patch of ours (a test patch that wasn't even the last one released for that major kernel version). The company's lawyers repeatedly claimed the company had not modified the grsecurity code in any way and that therefore all the references to "grsecurity" in their product were therefore only nominative use of the trademark to refer to our external work. They would therefore not cease using our trademark and would continue to do so despite our objections. This final assertion occurred three months after our initial cease and desist letter. They also threatened to request "all available sanctions and attorneys' fees" were we to proceed with a lawsuit against them."

Aztán akkor nincs ilyen vita.

--
trey @ gépház

Ahogy idézed is, a Grsecurity esetén egyszerűbb a szituáció:

A "Grsecurity" az egy védett márkanév, amelyért rengeteg pénzt fizet a tulajdonosa minden évben és köteles is bejelenteni a hamisításokat, különben elveszti a trademark jogát. Használata szigorú feltételekhez kötött.

OpenSSH esetén tudtommal nincs ilyen jellegű oltalom és a licenc sem köt ki hasonlót. Ezért nem ennyire egyszerű a helyzet, de szerintem is problémás...

A cikket ugyan nem olvastam végig, így összességében nem is akarom véleményezni, de megakadt a szemem az egyik kiemelésen.

“If Microsoft cannot honour Free software and respect the APIs of OpenBSD, OpenSSH, OpenSSL etc. then maybe it’s time to tell Microsoft to take back its ‘bribe’ money and go away, leaving OpenSSH alone (and secure).”

Hát, öh... Erről azért kérdezzük meg az OpenSSH brigádot, merthogy tudomásom szerint az elmúlt években pénzügyi szempontból nem volt éppen biztosítva a projekt jövője, vagy rosszul emlékeznék? Még mintha a villanyszámla kifizetésével is lettek volna gondok 2014 környékén...

A kérdéses cikk írójának üzenném, hogy mielőtt más farkával verné a csalánt más nevében visszautasítaná a támogatást, egy pár forintot ő is dobjon már a perselybe, hogy egyáltalán életben maradjon a projekt.

Különösen, hogy az én olvasatomban szó sincs arról, hogy beletrollkodna bármit a MS az upstreambe, különösen, hogy fenntartásaim vannak a Windows Crypto API linuxos/BSD-s portjának létezésével kapcsolatban. :)

( gemnon v | 2015. 10. 22., cs – 08:43 )

Felesleges, idézném kedvenc szakértőmet, aki kitalálja kiről van szó nem kap semmit :P

"RDP-n keresztül ugye lehet parancssori programokat is futtatni, SSH-n keresztül viszont marha nehéz grafikus programokat futtatni, vezérelni. Ezért előbbi egyértelműen jobb, fejlettebb, mint utóbbi."