Parece que GitHub es una fuente inagotable de aprendizaje. Traemos hoy [PDF] An empirical study of goto in C code from GitHub repositories. En este caso estudian la utilización de esta conocida estructura de control que permite romper el flujo de cualquier programa cuando se cumplen determinadas condiciones (o dejan de cumplirse).

En general es una estructura de control que está mal vista desde el punto de vista del desarrollo estructurado de programas. Podemos recordar aquí el famoso [PDF] Edgar Dijkstra: Go To Statement Considered Harmful, de Edsger Dijkstra, uno de los padres de la programación estructurada. Sin embargo, es cierto que en algunos casos la estructura del programa puede mejorar mucho si se utiliza con ‘sabiduría’.

El artículo habla del uso del ‘goto’ por parte de los programadores (si lo utilizan y para qué) y su aparición en la correción de fallos después de lanzar una versión.

Se usa. A nivel de fichero:

Considerable use of goto at the file level: We find that 246,657 out of the 2,150,387 files (or 11.47%) examined in our study have at least one goto statement.

A nivel de proyectos:

We find that 3,093 out of the 11,627 projects (or 26.60%) have at least one file with a goto statement. We also find that more than half the projects have about 20% of the files that have at least one goto statement.

Se utiliza, fundamentalmente, para código de sistema y de red, pero también para otras cuestiones. Mirando en las funciones parece que el uso principal es para gestión de errores, limpieza (liberación de memoria, etc.). Otra característica interesante es que la mayoría de los saltos son hacia adelante y raramente se hacen hacia atrás.

We find that, in general, the use of goto is actually well disciplined. Most uses of goto statements are reasonably structured, filling the void of miss- ing higher-level constructs found in other languages. There are of course usages that are unstructured as Dijkstra feared, but they are overall in

Después de publicar una versión la tendencia era a que se mantengan más o menos el mismo número de ‘gotos’ en el código, por lo que los proyectos no parecen considerarlos como algo perjudicial y desaconsejable.

If we assume bugs in the post-release phase of a project as a measure of harm, then the small number of goto statements being removed/modified in bug fixes implies that goto statements were not consid- ered harmful enough to be removed/modified in the post-release phase of the project in most cases.

Interesante.

El National Institute of Standards and Technology publica informes de lo más variado y de vez en cuando le dedica atención a la seguridad informática.

Traemos hoy aquí el informe [PDF] Security of Interactive and Automated Access Management Using Secure Shell (SSH) que habla del protocolo SSH desde el punto de vista de gestión en las organizaciones.

This publication assists organizations in understanding the basics of SSH interactive and automated access management in an enterprise, focusing on the management of SSH user keys.

Los primeros capítulos pueden ser interesantes para alguien que todavía no se haya preocupado de estos temas (a veces los informes sobre temas más complejos nos sirven para entender mejor las cuestiones básicas porque las tratan en los capítulos introductorios). Los siguientes, tendrán interés si queremos ir más allá en los temas de gestión de la seguridad.

En [PDF] A Large Scale Study of Programming Languages and Code Quality in Github nos muestran una investigación realizada examinando el código de los repositorios de GitHub: analizan para diversos tipos de lenguajes la cantidad de fallos, basándose en los ‘commits’ que contienen etiquetas relacionadas con errores (‘error’, ‘bug’, ‘fix’ , ‘issue’, ‘mistake’, ‘incorrect’, ‘fault’, ‘defect’ and ‘flaw’).

El resumen sería (de manera muy básica) que los lenguajes fuertemente tipados son algo mejores que los débilmente tipados. También que los lenguajes funcionales son algo mejores que los demás.

… we report that language design does have a significant, but modest effect on software quality. Most notably, it does appear that strong typing is modestly better than weak typing, and among functional languages, static typing is also somewhat bet- ter than dynamic typing. We also find that functional languages are somewhat better than procedural languages.

En todo caso, el efecto no es muy grande.

Puede que también tengan interés en leer los comentarios del hilo de Hacker News sobre el trabajo A Large Scale Study of Programming Languages and Code Quality in GitHub.

También me gusta destacar el valor que tiene un sitio como GitHub (internet, para el caso) para poder realizar este tipo de estudios que serían bastante difíciles de realizar con el código disponible en ‘casa’ de cada uno que lo tenga.

Es una presentación que ya tiene unos años pero vale la pena guardarla. En Developing Secure Mobile Applications se habla de los diversos aspectos que se pueden tener en cuenta, incluyendo el Top 10 Mobile Risks pero también otros aspectos como los descompiladores, y otros aspectos que podemos transportar directamente del desarrollo seguro genérico.

Traemos un par de lecturas sobre cómo podemos reforzar el acceso a nuestros sistemas, añadiendo seguridad de dos formas (que podrían combinarse entre sí, puesto que se ocupan de diferentes partes: acceso y autentificación a un sistema).

En primer lugar, en Using 2 factor authentication for SSH unas instrucciones sobre cómo utilizar el app Google Authenticator para establecer un sistema de dos factores para el servicio SSH.

La otra posibilidad es habilitar los servicios cuando los necesitemos, de forma que cuando no los vayamos a usar no estén disponibles. En este caso podríamos utiliar Latch. Tal y como cuentan en Fortificar GNU/Linux Ubuntu con Latch: Vídeo Tutorial se puede usar en cualquiera de los sistemas más comunes.