MySQL ya no es completamente libre. Sólo era un producto libre, no un proyecto. Sin embargo aun nos queda Drizzle.
Tag: Software Libre
Categories
Eclipse XText
Hace un año, algo menos me parece, me enteré de la existencia de Eclipse Xtext. A pesar de haber visto en ese entonces un vídeo mostrando sus características, hasta ahora no había tenido la oportunidad de probarlo realmente. XText es un framework destinado a facilitar el desarrollo de lenguajes de programación o DSLs. Ofrece la posibilidad de crear los compiladores y de poder integrarlos dentro de Eclipse; permitiendo entre otras, la coloración de código, la verificación instantánea de sintaxis, completado de código, etc. Para una pequeña introducción, vean mejor el siguiente video.
Xtext in less than a minute from Xtext Team on Vimeo.
Internamente usa AntLR para generar el parser. De ahí que la sintaxis usada para definir la gramática en Xtext sea casi la misma que la de AntLR. A pesar de haber tenido algunas limitaciones mientras intentaba definir la gramática de un lenguaje existente, me dejado una grata impresión.
Si bien es cierto que llevo desfasado en temas de seguridad y que seguramente soy uno de los menos indicados para hablar de estos temas, me llama mucho la atención cuando alguien opina sin mucho conocimiento del tema en cuestión. Esta vez, en la lectura que suelo hacer diariamente, encontré un artículo que habla sobre la seguridad de software libre, aunque erróneamente el título parezca indicar que sólo se refiere a WordPress.
El problema es que el modelo de código abierto permite que hackers y casi cualquier otra persona se pueda dar el lujo de excavar hasta llegar al núcleo del código de todos los foros y blogs que funcionan a través de dicha plataforma, permitiéndoles descifrar múltiples maneras de irrumpir en la sagrada información de sus usuarios.
¿Qué hacer al respecto?
Hay tres cosas que puedes hacer si no puedes soportar las debilidades del sistema open source:
- Utilizarlo, pero pagarle a alguien más para que te lo mantenga.
- Utilizar un servicio de código cerrado y ser estricto para mantenerlo así.
- Constrúyalo usted mismo. Haga uso de su conocimiento para evitar que otras personas puedan tener algún tipo de influencia sobre la vulnerabilidad de su información.
Yo diría que muchos se ahogan en un vaso de agua, porque olvidamos que el código abierto es por naturaleza vulnerable a hacks, ataques de "gusanos informáticos" y cualquier otra variedad de amenaza que la web nos ofrece hoy en día. Mientras el código esté expuesto, el proyecto que se proponen muchos de romperlo y penetrarlo suena tanto divertido como perverso, pero es algo que todos nosotros ya debimos de haber entendido hace un buen rato, para evitar todo el barullo que se suele hacer en torno al tema de seguridad.
El autor del artículo usa la típica falacia de que si el código está disponible para todos, entonces es más inseguro. En el poco tiempo que me involucré en el tema de seguridad, me quedó bastante claro que si alguien está determinado a vulnerar tu aplicación o sistema, lo va hacer independientemente de si el código está disponible o no.
En mi opinión, creo que la mejor forma de hacer que las aplicaciones de software libre sean más estables, es que justamente seamos nosotros, los usuarios, los que participemos en este proceso identificando bugs, ayudando a otros a mantenerse actualizados o, si no se cuentan con el tiempo o conocimientos necesarios, colaborando económicamente.
Un fenómeno que últimamente noto en relación a WordPress -- al menos en bloggers hispanos, es que cada vez existe menos tolerancia a los errores que se presentan en cada versión. En mi opinión, estos errores se deben principalmente a que el proceso de desarrollo de este CMS y el código en si, son en cierta forma desordenados; pero por otro lado, la comunidad tampoco ayuda mucho en el reporte de errores, me pregunto ¿cuántos de los que lo usan y usualmente se quejan han tomado parte de su tiempo para reportar algún fallo o comportamiento erróneo en el lugar adecuado?.
He leído también por ahí a un blogger que comentaba que con usar y darle "publicidad" (léase enlaces) a WordPress era más que suficiente para de cierto modo "pagar" por el uso de éste, pero particularmente creo ese comportamiento se aleja de lo que debería ser y/o hacerse en una verdadera comunidad de un proyecto de Software Libre.
En fin, todo este desvarío de ideas se debe a un curioso caso que empezó con una entrada que publicó Héctor titulada "Bug grave en WordPress 2.5.1", a lo cual -- probablemente por el título -- otros bloggers escribieron entre otras cosas (negritas intencionalmente resaltadas):
Un gran problema de seguridad presenta la ultima versión de WordPress 2.5.1, gracias a la ayuda de sigt tenemos una simple y rápida solución. S recomienda modificar estos archivos ya que el bug no estara resuelto hasta la proxima version de WP 2.5.2
Pues sí, salió la actualización WordPress 2.5.1, y ya han descubierto un bug de seguridad. Además, si usaban el plugin XML Sitemaps actualícenlo ya a la última versión si no quieren que su servidor eche humo.
[...] Por otro lado, apenas salió la actualización, se encontró un nuevo error bastante crítico, como explican en SigT y Bitperbit, el cual ya tiene solución. [...]
Ahora, supongo que a cada uno le corresponde determinar que tan grave es no poder resetear la contraseña de sus propios blogs, "afortunadamente" para mi, hasta el momento no tuve la necesidad de hacer eso ni una sola vez.
Finalmente, me gustaría acotar que este "gravísimo" error se produjo porque había que corregir un problema de seguridad real y el que hizo la corrección no se percató del código que dependía de dicha funcionalidad -- posiblemente si se usaran pruebas unitarias y de integración se evitarían este tipo de casos.