Guillermo O. Burastero escribió: > rodrigo escribió: > >> El 17/04/05 22:49:14, Guillermo O. Burastero escribió: >> [...] >> >>> Como información adicional, la licencia de cualquiera de las >>> versiones de BK, impedía a cualquier usuario participar en el >>> desarrollo de un software competitivo del mismo (otro SCM) hasta un >>> año después de haber dejado de usar BK. Un poco excesiva no ? Creo >>> que ni M$S tiene una cláusula así en sus licencias. >> >> >> >> supongo que esto se aplica explicitamente al los que firman, ¿o los >> que mandan un parche tambien quedan condenados? >> > Según H.V.B., en otro post de esta lista sobre este tema, la > restricción de no intervenir en ningún desarrollo similar alcanzaba no > solo a los usuarios de BK sinó también a los empleados de la firma > usuaria. Una verdadera exageración IMHO. Es como si por usar MS-Word > no podrías participar en ningún desarrollo de un procesador de textos. > O por acceder como cliente del DBMS MS-SQL no podés hacerlo con tu > propio cliente, con un protocolo conocido y público, y para peor, > tampoco podés participar en ningún desarrollo de una base de datos. > >> [...] >> >>> ... Esto lo hizo sin >>> acceder al programa BK y menos a su código (por lo tanto no está >>> alcanzado por su restringida licencia al no ser usuario del mismo), >> >> >> >> ¿como pudo probar que lo que hacia funcionaba, sin acceder al programa? > > > Porque lo que estaba tratando de hacer primero era un cliente del > repositorio BK, no el servidor BK. De entrada solo aspiraba a > conectarse con él. Es como si usas una base de datos propietaria, > donde guardas datos tuyos y la interfaz de conexión para acceder a > esos datos solo está, sin ninguna documentación, en un programa > binario cliente que es del mismo proveedor de esa base de datos. Lo > que intentó o logró hacer Tridgell es poder acceder a ese servidor BK > desentrañando el protocolo y API que BK usa para esto y crear un > programa cliente FOSS. Esto es lo que se llama interoperabilidad y, > que yo sepa, siempre fue un argumento y objetivo deseable contra los > productos monopólicos. > >> >> [...] >> >>> Linus, a mi entender en forma muy injusta, se alineó con su >>> amigo McVoy y cargó toda la responsabilidad de este problema sobre >>> Tridgell, pero yo me pregunto: ¿Por qué está bien que se halla >>> desarrollado SAMBA así, estudiando el protocolo SMB de MS -un >>> programa "propietario" o no libre- y no está bien que se haga lo >> >> >> >> ¿SMB no fue hecho en una mezcla IBM-MS? >> > No, extraigo del artículo que refiero abajo: "el protocolo que Samba > implementa fue primero inventado por Barry Feigenbaum de IBM en 1983, > lo llamó originalmente "BAF" (sus iniciales), pero luego cambió a SMB > antes de su primera versión oficial. El término CIFS o "Common > Internet File System" fue acuñado por MS en 1996 como un ejercicio de > marketing en un intento de combatir la amenaza percivida por parte de > Sun Microsystems después de su anuncion del WebNFS. El termino "pegó", > y ahora el protocolo SMB es frecuentemente llamado CIFS. Los dos > nombres se refieren al mismo protocolo, como es fácilmente desmostrado > conectando un cliente actual Microsoft CIFS a un servidor Samba SMB de > 1992." > > La implementación de SMB por parte de MS era secreta, no estaba > documentada para terceros. Sugiero leer para mayores precisiones: > > "Myths About Samba" by Andrew Tridgell en > http://www.groklaw.net/article.php?story=20050205010415933 y > > "How Samba was Written" (También conocido como "The French Cafe > Description" en http://samba.org/ftp/tridge/misc/french_cafe.txt > >>> mismo con otro programa propietario (BK) ? También muchoS drivers >>> propietarios de "analizan" o se hace ingeniería reversa de los >>> mismo y a ninguno (que yo sepa) se le ocurre que eso está mal. >> >> >> >> [...] >> >> Si los de BK no quieren que la gente que use el programa trabaje por >> un anho en proyectos similares, sera por que puede que los usuarios >> le cuenten a otros como funciona el programa: capaz que cada vez >> que ocupan una funcion, el programa chorree su codigo fuente ... >> >> y si no quieren que se sepa como funciona su protocolo, ¿por que no >> ocupan un protocolo encriptado? por lo menos asi queda bien claro >> que no quieren compartir con los demas... >> > El protocolo encriptado, si es robusto y está bien implementado, solo > hace privado el intercambio de datos para terceros que intentan > analizar, y aun hacer criptoanalisis, accediendo solo a la información > encriptada, tipicamente fizgoneando en el canal de comunicación. > > Si el proceso de encriptación no se hace desde un hardware inviolable > (temperproof), en donde resida por ejemplo la clave privada que se > utiliza para generar la clave criptográfica simétrica temporaria que > se usará durante la sesión criptográfica, esta clave privada debe > necesariamente estar de algún modo en la memoria del procesador > durante la ejecución y antes en el código ejecutable del programa > cliente y de cualquier manera usando técnicas típicas de la ingeniería > reversa de software como debuggers, desensambladores y otras > herramientas de análisis de código objeto para inpeccionar > directamente el código ejecutable, se podrá llegar a conocer la clave > privada y por lo tanto desencriptar el protocolo cifrado. Lo que está > fallando acá es el modelo de seguridad y no el algoritmo criptográfico > que bien puede ser muy robusto y seguro. > > De este modo se quebró el sistema de protección de contenidos de los > videos en DVD, llamado Content Scrambling System (CCS). El hacker que > lo hizo, creo que en 1999, analizó un programa reproductor de DVD para > Windows que contenía la clave de descifrado (hay unas 400 posibles > claves que funcionan, no me pregunten para qué, ya que vasta con > conocer cualquiera de ellas para poder desencriptar cualquier DVD > cifrado con CCS) y luego escribió un programa que llamó DCCS con > código público, para felicidad de todos los usuarios de Linux que no > podían ver en su querido sistema sus DVD favoritos o bien hacer un > backup de los DVD -legítimamente adquiridos, por supuesto-, etc. Y ese > fue el fin de la eficacia de la protección de contenidos CCS por el > cual la industria del entretenimiento había gastado millones de dólares. > > Fe de Erratas: el sistema de protección de contenidos conocido como "Content Scrambling System" se abrevia (como es obvio) CSS y no CCS, igualmente el programa que lo quiebra se llama DeCSS y no DCCS.
-- Guillermo O. Burastero - Linux Counter User 84879, http://counter.li.org Córdoba 171 - B8000IFC - Bahía Blanca - Buenos Aires - Rep. Argentina Tel +54 (291) 454-6132 - ICQ 97148268 - email: [EMAIL PROTECTED]
