Microsoft .Net: si può guardare il codice sorgente

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/softwar...nte_22804.html

Il codice sorgente di alcune librerie appartenenti a Microsoft .Net può essere visualizzato ma non copiato


Click sul link per visualizzare la notizia.

[black-m01]

..né migliorato, né risolte falle di sicurezza.

Ed in caso di riscontro di violazione di brevetti da parte di Microsoft, decade la licenza per continuare ad accedere in sola lettura ai sorgenti.

[Barone di Sengir]

If you begin patent litigation against the Licensor over patents that you think may apply to the software (including a cross-claim or counterclaim in a lawsuit), your license to the software ends automatically.

Penso di aver detto tutto...

[r.chiodaroli]

Originariamente inviato da black-m01

..né migliorato, né risolte falle di sicurezza.

Pardon, fonte di questa affermazione? Ho appena controllato su Secunia:

Versione 2.0:
http://secunia.com/product/6456/

Versione 3.0:
http://secunia.com/product/14766/

[black-m01]

Fonte, la stessa licenza del software.

Microsoft con la sua licenza non permette ad alcun sviluppatore di accettare la licenza, per poi, scovato un errore di programmazione, importare i sorgenti in un proprio ramo di sviluppo, risolvere il problema e pubblicare le modifiche, o redirezionarle anche alla sola Microsoft.

Sarebbe violazione di copyright, legge su cui le licenze software si basano.

Il post era da leggersi come virtuale continuazione del secondo titolo di notizia; ma credo non sia così chiaro, chiedo scusa.

[r.chiodaroli]

Originariamente inviato da black-m01

Il post era da leggersi come virtuale continuazione del secondo titolo di notizia; ma credo non sia così chiaro, chiedo scusa.

Non c'è problema. Sempre meglio chiarirsi.

[APekos]

Ma solo io uso reflector per decompilarlo e studiare come è fatto dentro?

[MenageZero]

Originariamente inviato da black-m01

Fonte, la stessa licenza del software.

Microsoft con la sua licenza non permette ad alcun sviluppatore di accettare la licenza, per poi, scovato un errore di programmazione, importare i sorgenti in un proprio ramo di sviluppo, risolvere il problema e pubblicare le modifiche, o redirezionarle anche alla sola Microsoft.

Sarebbe violazione di copyright, legge su cui le licenze software si basano.

Il post era da leggersi come virtuale continuazione del secondo titolo di notizia; ma credo non sia così chiaro, chiedo scusa.

va beh il codice è loro, se non vogliono che terzi ci mettano le mani, non è che si può "pretendre" qualcosa, anche solo "moralmente"

[share_it]

forse è un piccolo passo avanti, ma è certo che non vogliono far si che ci si possa fidare. Anche java era così.

[Fx]

il fatto che non lascino ricompilare mi sembra ovvio... la MS fornisce una libreria con i codici, tu ci metti dentro le mani e la distribuisci; se poi accade qualcosa la libreria è quella di MS, quindi risponde lei

bisogna anche vedere con che garanzie viene fornito il software. è ovvio che se parliamo di linux, nelle cui licenze c'è scritto a caratteri cubitali che "il presente software viene fornito senza garanzia alcuna", il problema non sussiste. nel caso in cui invece fornisci delle garanzie, mi sembra davvero più che ovvio che ti tuteli dal dover rispondere di modifiche fatte da terzi.

poi ovviamente se viene rilevata una falla di sicurezza, non è che questa deve rimanere lì, ma deve semplicemente esser corretta da MS, com'è ovvio che sia.

detto questo, vorrei sapere com'è messa la concorrenza a riguardo. linux ok, è tutto open quindi il tema non sussiste nemmeno, però è anche vero che dietro non c'è un'azienda che lo sviluppa. prendiamo apple, e prendiamo le parti di mac os x che ha scritto di suo pugno (ad es. carbon, cocoa, quartz, eccetera)... si può vedere il codice? sono aperti?

con questo voglio dire che va bene criticare, però ogni tanto sarebbe bello leggere delle critiche circostanziate. MS fa un passo in una direzione, penso auspicabile da tutti, e ci si lamenta perchè non ne ha fatti 10... mah

[r.chiodaroli]

Originariamente inviato da APekos

Ma solo io uso reflector per decompilarlo e studiare come è fatto dentro?

Giusta osservazione, ma il Reflector non è in grado di restituire i commenti. Senza, capire alcuni namespace è piuttosto arduo (o addirittura impossible).

Uno dei punti su cui ScottGu ha focalizzato maggiormente è proprio questo, oltre al fatto di poter debuggare linea per linea anche il codice del Framework.

[bist]

Originariamente inviato da APekos

Ma solo io uso reflector per decompilarlo e studiare come è fatto dentro?

Originariamente inviato da r.chiodaroli

Giusta osservazione, ma il Reflector non è in grado di restituire i commenti. Senza, capire alcuni namespace è piuttosto arduo (o addirittura impossible).

Uno dei punti su cui ScottGu ha focalizzato maggiormente è proprio questo, oltre al fatto di poter debuggare linea per linea anche il codice del Framework.

Esatto, è molto più comodo avere tutto integrato in Visual Studio, praticamente nel debugging potrai fare lo step into nelle librerie System.qualsiasicosa. Tra l'altro, se non hai installato i sorgenti in locale, scarica automaticamente da internet quelli interessati, controllando di prendere la versione giusta (utile in caso di aggiornamenti non ancora installati ecc).

Vi consiglio caldamente di leggere questo post, molto più completo di quello linkato nella notizia di hwupgrade:

http://weblogs.asp.net/scottgu/archi...libraries.aspx

[bist]

Se a qualcuno interessa il discorso licenze e/o le ripercussioni su Mono, ne stiamo parlando qui:

http://www.hwupgrade.it/forum/showthread.php?t=1569882

[sari]

Originariamente inviato da r.chiodaroli

Giusta osservazione, ma il Reflector non è in grado di restituire i commenti. Senza, capire alcuni namespace è piuttosto arduo (o addirittura impossible).

Più che di commenti mancanti parlerei di tecniche di offuscamento di solito ampiamente adottate per evitare il reverse. Comunque, più che conoscere il punto di un possibile errore in fase di debug, a cosa serve avere del codice sorgente sotto una licenza simile? Manco il debug è consentito. Insomma, più che di possibilità di guardare il codice sorgente parlerei di risposta a possibili pressioni di software house legate a .Net, quindi niente di eclatante.

Dimenticavo, un appunto al titolo della news è doveroso. E' certamente di effetto, ma non rispecchia minimamente la realtà, da .Net ad alcune librerie legate a .Net la differenza è notevole.

[r.chiodaroli]

Originariamente inviato da sari

Più che di commenti mancanti parlerei di tecniche di offuscamento di solito ampiamente adottate per evitare il reverse. Comunque, più che conoscere il punto di un possibile errore in fase di debug, a cosa serve avere del codice sorgente sotto una licenza simile? Manco il debug è consentito. Insomma, più che di possibilità di guardare il codice sorgente parlerei di risposta a possibili pressioni di software house legate a .Net, quindi niente di eclatante.

Dimenticavo, un appunto al titolo della news è doveroso. E' certamente di effetto, ma non rispecchia minimamente la realtà, da .Net ad alcune librerie legate a .Net la differenza è notevole.

Sinceramente ho usato Reflector su diversi Assembly del Framework, ma non mi è capitato di incappare in aree di codice offuscate... Me ne potrebbe segnalare qualcuna?

Per il resto, concordo con Fx, questo è un piccolo passo, ma pur sempre in avanti e credo lasci buone prospettive per il futuro.

[riva.dani]

Mi auto-quoto:
A me sembra un’enorme vittoria per il mondo open! Non per il fatto che si potrà avere il framework .NET sotto una finta licenza open, quanto per il fatto che la Microsoft ha pubblicamente ammesso che il modello di sviluppo migliore è quello open. Vi rendete conto che niente popò di meno che il GM dell’azienda ha dichiarato che avendo a disposizione il codice si possono scrivere programmi migliori? Che gli sviluppatori traggono vantaggi indiscussi dal modello del software Open Source? La Microsoft ha sempre sostenuto il contrario! Per questo a me sembra una bella vittoria, anche se nessuno dovesse mai vedere il codice di .NET…

PS: Quando parlo delle affermazioni del GM Microsoft, è tutto vero:

Scott Guthrie, general manger Microsoft, ha dichiarato che questa iniziativa servirà soprattutto agli sviluppatori per eseguire un debug appropriato delle loro applicazioni. In particolare ha scritto sul suo blog: “Andando a leggere il codice sorgente sarà più facile avere una visione d’insieme su come le librerie del Framework .NET siano implementate e ciò permetterà agli sviluppatori di creare applicazioni migliori e magari utilizzarle meglio.”

Fonti: http://www.tuxjournal.net/?p=1286 ; http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx

[Lck84]

Originariamente inviato da riva.dani

A me sembra un’enorme vittoria per il mondo open! Non per il fatto che si potrà avere il framework .NET sotto una finta licenza open, quanto per il fatto che la Microsoft ha pubblicamente ammesso che il modello di sviluppo migliore è quello open. Vi rendete conto che niente popò di meno che il GM dell’azienda ha dichiarato che avendo a disposizione il codice si possono scrivere programmi migliori? Che gli sviluppatori traggono vantaggi indiscussi dal modello del software Open Source? [...]

Non ha propriamente affermato che il modello di sviluppo open sia migliore, anche perché il modello di sviluppo (di .NET) rimarrà lo stesso di prima. La differenza è che - e qui concordo con MS, con FX e tutti - lo sviluppatore di applicazioni potrà eventualmente godere del beneficio di leggersi anche il codice precedentemente nascosto del framework e capirne magari le meccaniche più nascoste (anche se già la documentazione ha sempre fatto un ottimo lavoro su questo punto). Inoltre è sempre possibile implementare dei work-around in maniera pulita di eventuali bug o comportamenti "strani" del framework.
Il framework in sé non si potrà comunque modificare, ma personalmente ritengo che sia un bene: se si scova un bug si riesce comunque a segnalare a Microsoft attraverso i consueti mezzi (magari segnalando anche con il codice colpevole), mentre lo sviluppo del Framework rimane in ogni caso centralizzato. Sarebbe un incubo trovarsi con una miriade di Fork del .NET...

[r.chiodaroli]

Originariamente inviato da Lck84

Il framework in sé non si potrà comunque modificare, ma personalmente ritengo che sia un bene: se si scova un bug si riesce comunque a segnalare a Microsoft attraverso i consueti mezzi (magari segnalando anche con il codice colpevole), mentre lo sviluppo del Framework rimane in ogni caso centralizzato. Sarebbe un incubo trovarsi con una miriade di Fork del .NET...

Sono totalmente d'accordo, anche perché il modello di .Net è ampiamente estendibile e molti aspetti possono essere riconfigurati a piacere, senza però alterare la struttura base del framework. Basti pensare al provider model di ADO.NET oppure ai WebControlAdapters di ASP.NET.

[sari]

Originariamente inviato da r.chiodaroli

Sinceramente ho usato Reflector su diversi Assembly del Framework, ma non mi è capitato di incappare in aree di codice offuscate... Me ne potrebbe segnalare qualcuna?

Per il resto, concordo con Fx, questo è un piccolo passo, ma pur sempre in avanti e credo lasci buone prospettive per il futuro.

Non ho l'hobby di disassemblare codice , la mia era una supposizione. Di solito l'offuscamento mitiga il reverse di prodotti close, quindi che .Net non faccia uso di tecniche di offuscamento più o meno pesanti mi sembra strano. Comunque, un conto è riuscire a decompilare (anche le migliori trasformazioni ad esempio non offrono una protezione completa contro la decompilazione), un conto è capire e riuscire ad utilizzare il codice decompilato.

[sari]

Originariamente inviato da Lck84

Il framework in sé non si potrà comunque modificare, ma personalmente ritengo che sia un bene: se si scova un bug si riesce comunque a segnalare a Microsoft attraverso i consueti mezzi (magari segnalando anche con il codice colpevole), mentre lo sviluppo del Framework rimane in ogni caso centralizzato. Sarebbe un incubo trovarsi con una miriade di Fork del .NET...

E qqui mi sorge un dubbio, cosa torna nelle tasche dello sviluppatore .Net nel segnalare un bug a Microsoft? In questo caso ne guadagna direttamente solo Microsoft, poichè l'onere di scovare e debuggare .Net dovrebbe rimanere, per l'appunto, un onere di Microsoft. Un modello di sviluppo Open è diametralmente opposto. In questo caso, come dicevo nel precedente post, più che intraprendere una strada che porti verso l'Open, vedo più una risposta alle richieste di aziende che sviluppano con .Net. Infondo è capitato anche a me (che sviluppo a livelli infimi) di dover controllare il flusso di esecuzione all'interno di una libreria (libreria open ovviamente), figuriamoci per un vero sviluppatore. Insomma, in questo caso non se ne poteva fare a meno, quindi non penso che Microsoft andrà mai oltre queste rilasci dettati dalle esigenze degli sviluppatori.