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

Lun Abr 18 10:17:14 CLT 2005

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.

-- 
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