February 2009

UAC y Windows 7. Microsoft escucha.

Hace no mucho hablaban en kriptópolis sobre un fallo de seguridad en la configuración del UAC en Windows 7 que permitía a cualquier programa malicioso cambiar la configuración del UAC sin avisar al usuario, hasta desactivarlo, y por tanto poner en peligro todo el sistema.

Inicialmente en el blog de desarrollo de Windows 7 se descolgaron diciendo que:

Microsoft’s position that the reports about UAC do not constitute a vulnerability is because the reports have not shown a way for malware to get onto the machine in the first place without express consent

que traducido viene a ser que eso no es una vulnerabilidad porque los informes no han mostrado aún una forma de infiltrar malware en una máquina si que se le de consentimiento expreso... lo cual, a decir verdad, nos sonaba a todos como excusa barata.

Por suerte, en un movimiento tardío pero en mi opinión muy acertado, tras recibir bastantes feedback negativos, parece que se han echado atrás y han decidido que, efectivamente, constituye una vulnerabilidad:

we are going to deliver two changes to the Release Candidate that we’ll all see. First, the UAC control panel will run in a high integrity process, which requires elevation. That was already in the works before this discussion and doing this prevents all the mechanics around SendKeys and the like from working. Second, changing the level of the UAC will also prompt for confirmation.

Es decir, en primer lugar el UAC apartir de la release candidate pasará a ejecutar como un proceso de alta integridad, lo cual significa que no se puede atacar con procedimientos comunes (como el SendKeys que permite mandar pulsaciones de teclado a la aplicación) y por otro, TODA acción sobre el UAC que requerirá una elevación de privilegios.

Es sin duda una noticia excelente, por un lado por el fallo de seguridad que, en efecto, consituía el tipo de funcionamiento anterior, y por otro por comprobar que la gente de Microsoft, responde y tiene muy encuenta los comentarios que recibe de sus usuarios.

Test Driven Development (actualización)

Veréis, llevo leyendo el blog de Joel Spolsky cerca de dos años ya, y siempre he considerado que cada opinión suya tiene un enorme valor. Podría decir que cada vez que el habla, yo asiento.

Si escribes un artículo criticando el Desarrollo dirigindo por las pruebas, que es una de las metodologías con más "buzz"1 del momento, esperas que un montón de gente no este de acuerdo o sencillamente piensen que te has vuelto loco... a fin de cuentas el "Test Driven Development" "mola" ¿no?

Dicho esto, cuando Joel y Jeff Atwood hablan de esas cuestiones y básicamente confirman lo que has dicho... bueno, debo decir que me siento halagado. Principalmente porque esos dos tienen un enorme impacto en internet, en segundo lugar porque normalmente coincido totalmente con ellos, y en tercer lugar... bueno, porque está bien tener razón... o por lo menos que la gente "popular" piense lo mismo que tu.

Respecto a lo que dicen (es una transcripción de uno de sus podcasts), bueno, ¿que puedo decir? Solo una pequeña cosa, al final Jeff dice:

...porque lo que importa es lo que entregas al cliente, y como de satisfecho está el cliente con lo que le has entregado. Hay muchas, muchas maneras de llegar ahí.

Bueno, eso es cierto pero, ¿qué tiene que ver con lo que estamos hablando? Todas las metodologías se diseñan teniendo eso en cuenta, todo el mundo quiere entregar un producto excepcional al cliente; bueno, de hecho todo el mundo quiere hacer dinero entregándole ese producto excepcional. Así que claro que hay muchas formas, de lo que hablamos es de elegir la mejor manera de hacerlo, eso es lo que las metodologías proporcionan, una forma de hacer las cosas, una estructura sobre como trabajar.

Al final, las metodologías son solo una parte de la ecuación. Otras partes includen el sentido común para adaptarse a cada situación, el conjunto de herramientas adecuadas y, principalmente, la gente que trabaja en el proyecto. De esa forma, no estoy diciendo que hacer pruebas unitarias es malo, todo lo contrario, hacerlas para todo es lo que es malo. ¿Por qué? Porque fallamos en utilizar nuestro sentid común para decirnos que debe ser probado y qué no necesita serlo.

Y ese es básicamente el problema con el Desarrollo dirigido por las pruebas, puesto que las pruebas dirigen el desarrollo, tienes que hacerlas para todo lo que necesita ser desarrollado, o de otra forma no "dirigirán"...

  1. 1. Buzz es un término ingles que informalmente significa cierta excitación ("a sense of excitement")