SCM: Linus Torvalds (Linux), Larry McVoy (BitKeeper) and Andrew Tridgell (Samba, rsync, etc.)

Lun Abr 18 10:44:28 CLT 2005

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: linux.gb en gmail.com