Archives 2022

Después de estar años dando tumbos sin un destino cierto, parece que la situación de Thunderbird se va aclarando y que el proyecto tiene planes ambiciosos, ya que su llegada a Android podría producirse más temprano que tarde según ha dicho uno de los principales responsables de la aplicación.

La historia viene de una conversión de Twitter en la que intervinieron Adam Overa, redactor en Tom’s Hardware, y Jason Evangelho, conocido divulgador sobre Linux y desde hace poco gerente del marketing de Thunderbird.

Overa preguntó como respuesta al tweet en el que Evangelho anunció su nuevo cargo si era posible pulir la interfaz de usuario y que hubiera una aplicación para móviles. Evangelho respondió diciendo que iba a preguntar a sus ahora compañeros sobre la posibilidad de que el cliente de correo llegara a móviles, y ahí apareció Ryan Lee Sipes, gerente de desarrollo de productos y negocios de Thunderbird, diciendo que la aplicación para móviles está en camino.

La razón de por qué hemos dicho Android al principio en lugar de móviles es debido a que Sipes retuiteó un montaje de Overa en el que se puede leer en inglés la frase “liberar fichero APK”, o lo que viene a ser lo mismo, un paquete de instalación para Android.

Por ahora no parece que haya más información al respecto, pero viendo el tono de la conversación y la posterior imagen publicada por Ryan Lee Sipes, no es descabellado pensar que podríamos ver al menos un APK de Thunderbird para Android (que no necesariamente un lanzamiento estable) durante el transcurso del presente año, pero aquí solo estamos especulando sin nada sólido.

Que Thunderbird llegue a Android no tiene por qué significar que se haya descartado una versión para iOS, pero Mozilla Corporation tiene un margen de maniobra mucho mayor en el sistema de Google debido a que le permite implementar su propio motor de renderizado, mientras que en iOS todos los navegadores o aplicaciones que hagan uso de renderizado web tienen que apoyarse obligatoriamente en el WebKit impuesto por Apple.

Profundizando en las especulaciones, lo lógico es pensar que el futuro Thunderbird para Android reutilizará la base tecnológica de Firefox para el mismo sistema operativo: Fenix. Dicha base tecnológica ha dejado divididos a los usuarios entre los que elogian la mejora en el rendimiento que ha supuesto en comparación con lo que había antes y los que critican la pérdida de funcionalidades.

Thunderbird, un cliente de correo que llegó a tener decenas de millones de usuarios y que destacó por su facilidad de uso y ser software libre, estuvo dando tumbos durante años para acabar prácticamente en el mismo lugar, aunque bajo una organización diferente. Su llegada a Android podría ser de utilidad, por ejemplo, a usuarios corporativos, pero el hecho de que la aplicación de Gmail venga preinstalada en casi el 100% de los smartphones Android podría desincentivar su uso.

Fuente: https://www.muylinux.com/

No es la primera, la segunda, la tercera, la cuarta, ni siquiera la quinta vez que en los últimos años tenemos noticias de China en relación a Linux por uno u otro motivo, normalmente con intenciones de adopción y, por lo tanto, abandono de Windows. Pues he aquí una más en el mismo sentido.

Según recogíamos en MC, China «habría dado la orden para que las oficinas gubernamentales y las empresas respaldadas por el estado reemplacen los equipos informáticos de marcas extranjeras por otros que puedan ser mantenidos totalmente dentro de sus fronteras» con «la intención de llevar el plan a cabo en los próximos dos años y solo en las agencias del gobierno central se podrían reemplazar 50 millones de ordenadores.»

Así, marcas como Dell, HP u otras de origen estadounidense serán las primeras perjudicadas de una nueva política que tampoco es ajena en su territorio, en el que en nombre no tanto de la independencia tecnológica, como se arguye ser el caso de China, como de la seguridad nacional, se ha hecho el vacío a marcas chinas para con su contratación y uso en instituciones oficiales, especialmente de carácter gubernamental.

Y al revés: donde unas marcas se van a ver afectadas, otras van a aprovechar la oportunidad para colocarse mejor de lo que están en uno de los mercados más importantes del mundo, no solo a nivel domético, sino estatal. Se trata de marcas chinas, sobra decirlo, y son unas cuantas más aparte de Lenovo, Huawei, Xiaomi y otras, que también están bien situadas en el nuevo marco.

Por supuesto, aunque esta nueva orden se refiere solo al hardware, también implica de manera intrínseca al software y ya sabemos cuál es el sistema de reemplazo de Windows mejor posicionado para un proyecto como el chino, de independencia tecnológica, de control y desarrollo propios. Ahí están distribuciones como Deepin o Ubuntu Kylin… u otras más desconocidas, pero con mucho más potencial, véase a modo de ejemplo Inspur K-UX, derivada de Red hat Enterprise Linux y una de los pocas distribuciones Linux con certificación Unix.

Con todo, ahora toca ver hasta dónde se llega con la medida, porque si bien es cierto que los chinos han avanzado mucho en la adopción de Linux, no lo es menos que se han servido de estos movimientos para sacarle a Microsoft lo que no está escrito, de expansiones del soporte de sistemas muertos en el resto del mundo como Windows XP, a muchas otras ofertas en la forma generalizada de licencias de software casi regaladas.

Fuente: https://www.muylinux.com/

Según un estudio llevado a cabo por Instaclustr y Forrester Consulting del que se hacen eco en VentureBeat, cada vez son más las empresas que transitan hacia tecnologías de código abierto, no sin dificultades. Algunas de esas dificultades, las más habituales cuando se realizan este tipo de consultas, ya las conocemos, aunque hay derivadas interesantes.

Resulta interesante también el hecho de que las encuestas en las que se basa este nuevo estudio se han dado en compañías que ya utilizan tecnologías de código abierto, pero no en su totalidad, aun cuando el deseo es hacerlo, adoptar «alternativas puras de código abierto». ¿Por qué no lo hacen? Por la tradicional «falta de talento» que otros estudios sacan a la luz regularmente.

Pero comencemos por el principio: ¿qué lleva a las empresas a adoptar soluciones de código abierto? El sector profesional no se oculta y el ahorro de costes de licencia, la reutilización des código y el respaldo de la comunidad son los principales atractivos del código abierto para el mundo empresarial. Nada de cumbayá por estos lares, si bien esta ha sido la tónica tradicional en la empresa que ha situado al modelo de desarrollo donde se encuentra hoy en día.

A este respecto es bueno recordar las palabras de Linus Torvalds acerca del éxito de Linux, y es que para el padre de la criatura todo se ha debido al egoísmo: colaboro y eso que me ahorro. Y lo que ha funcionado con Linux se puede extrapolar perfectamente al código abierto en general y al software libre más en particular, pues incluso quienes lo hacen por amor al arte tienen objetivos personales.

Volviendo con la información que nos ocupa, si los motivos de atracción del código abierto para las empresas son evidentes, las dificultades a las que se enfrentan no lo son menos, a razón de la cantidad de años que llevamos leyendo lo de que «falta talento» en tal o cual tecnología puntera. Pues bien, estamos en pleno 2022 y la cosa no ha cambiado apenas, aunque sí hay matices.

Así, el estudio arroja datos como que un 39% de las compañías encuestadas achacan el miedo al salto a la necesidad de un liderazgo cohesionado capaz de aplicar una estrategia consistente entre departamentos, mientras que el 31% menciona la falta de soporte integral como principal causa; el 29% habla de la falta de habilidades internas como freno en la adopción de nuevas soluciones de código abierto. Todo gira, sin embargo, en torno al tema del talento o, dicho con mayor propiedad, del conocimiento disponible.

El dato diferente a lo ya conocido y más significativo, es el de la necesidad de contar con soporte, esto es, con compañías de terceros que puedan ofrecer para ayudar en la transición. En concreto, el 41% de los encuestados coinciden en que el «acceso a asistencia calificada y experta de partes externas» es primordial y, por lo tanto, se convierte en un elemento de bloqueo cuando no lo hay. Hasta un 70% aducen esta y la falta de estrategia como los motivos de no avanzar en el uso de más código abierto.

A modo de curiosidad, otro elemento que ejerce de bloque en la adopción de tecnologías de código abierto es la incompatibilidad con las licencias utilizadas por el software ya integrado en los procesos del negocio, de acuerdo a un 29% de las empresas que han participado en este estudio. Aunque, tal vez con la asesoría pertinente y que tanto cuesta encontrar según dicen, podrían solventar esta clase de impedimento.

Fuente: https://www.muylinux.com/

Creé mi primera cuenta de GitHub en la universidad, luego no la toqué durante tres años. Si bien escuchaba constantemente sobre el código abierto y los beneficios de involucrarse en el ecosistema, tenía mucho miedo de comenzar porque pensaba que el código abierto era solo para desarrolladores experimentados, no para novatos como yo

Después de graduarme de la Universidad de Portland, trabajé como ingeniero de software integrado de integración de Linux en IBM durante cinco años. Si bien el rol no contribuyó explícitamente con funciones o correcciones de errores a las comunidades de código abierto, interactuamos con mucho código fuente abierto. Como resultado, tuve una pequeña muestra de algunos elementos de código abierto: buscar errores abiertos, buscar parches y corregir errores. Si bien este nuevo mundo de código abierto fue extremadamente interesante, en realidad no estaba contribuyendo a estas comunidades. Después de beneficiarme del ecosistema de código abierto y el conocimiento de la comunidad durante tanto tiempo en IBM, estaba listo para comenzar a retribuir.

En mi función actual, trabajo en VMware como mantenedor de código abierto para Tern , una herramienta de inspección de contenedores que genera listas de materiales de software (SBOM) para imágenes de contenedores. Disfruto de tener la libertad de proponer funciones y recibir comentarios de otros mantenedores y miembros de la comunidad. Interactuar con otros explorando lo que es útil y lo que nuestros usuarios quieren hace que mi cerebro de mantenedor se pregunte: ¿Qué es factible? ¿Qué tiene sentido? ¿Qué es técnicamente posible? Como ocurre cuando se desarrolla cualquier producto de software, lo que los usuarios quieren no siempre es lo que es posible, pero aún desea que la comunidad encuentre útil su software. Definitivamente hay que lograr un equilibrio entre lo que tiene sentido y lo que los usuarios realmente usarán.

No siempre pensé que sería posible para mí ser un colaborador habitual del código abierto, pero debido a que entré a través de mi trabajo, ha sido gratificante mostrar a los recién llegados que el código abierto es más accesible de lo que creen. Eso es algo de lo que nos enorgullecemos como mantenedores de Tern: queremos que el proyecto sea accesible para todos, incluso si no eres un experto en Python o en contenedores (como yo no lo era). Antes de comenzar, el mensaje que escuché fue que tienes que ser muy hábil para contribuir al código abierto. Me gusta cambiar esa percepción cuando puedo.

Antes de comenzar, el mensaje que escuché fue que tienes que ser muy hábil para contribuir al código abierto. Me gusta cambiar esa percepción cuando puedo.

Todavía somos falibles incluso cuando somos expertos

Me atrajo el puesto en VMware porque implica trabajar con contenedores, que era (y sigue siendo) una tecnología omnipresente central en la forma en que creamos e implementamos software moderno. Dada mi experiencia en Linux y el hecho de que los contenedores no son más que un proceso que se ejecuta en Linux, pensé que tenía suficiente conocimiento básico para tener éxito en el puesto y al mismo tiempo dejar mucho espacio para crecer. Cuando busco nuevas oportunidades, me gusta asumir desafíos que me intimidan o me asustan un poco porque hay satisfacción en demostrarte a ti mismo que puedes hacer cosas difíciles.

Dicho esto, todavía no me sentía totalmente calificado para postularme para el puesto porque, hasta donde yo sabía, era más adecuado para alguien con más experiencia en código abierto. A menudo nos decimos a nosotros mismos que solo debemos postularnos a trabajos si estamos 100% calificados, pero no hay crecimiento allí. Así que me dije a mí mismo que debía postularme de todos modos y, si tuviera la oportunidad, podría hacer el 50 % del trabajo el primer día y recoger el otro 50 % en el camino.

Usamos un software de control de versiones diferente en IBM, por lo que no estaba tan familiarizado con los flujos de trabajo de GitHub cuando comencé a contribuir con Tern. Como colaborador de código abierto relativamente nuevo, trabajar con GitHub fue un poco intimidante. Si bien entendí que cometer errores era una parte inevitable del trabajo, los errores que cometes en GitHub son de dominio público para siempre. En mis primeros meses como mantenedor de código abierto, tuve la oportunidad de poner a prueba esta teoría cuando accidentalmente reescribí el historial de confirmaciones de Git para 80 confirmaciones en la rama principal de Tern. ¡Hablando de traumatizar! Me sentí extremadamente estúpido.

Cuando comete un error, especialmente uno que impacta negativamente o incomoda a otros, existe ese período inicial de pánico y duda (es decir, «¡NO estoy calificado para hacer esto!»). Pero como sabemos, el espectáculo debe continuar. Eso significa aceptar tu error y preguntarte qué vas a hacer para seguir adelante. La mejor manera que he encontrado para seguir adelante después de un gran error es poner salvaguardas para evitar que vuelva a suceder.

En este ejemplo específico, implementé medidas de seguridad aprendiendo sobre Git Hooks y cómo pueden evitar que ingrese a ciertas ramas para que me sea imposible volver a cometer los mismos errores. Luego, di una charla al respecto en una reunión técnica local con la esperanza de que alguien más pudiera aprender de mi error o, al menos, encontrar consuelo en el hecho de que incluso un supuesto mantenedor de código abierto también comete errores tontos. Ese es el lado humano del código abierto: Cualquiera puede cometer errores.

A menudo nos decimos a nosotros mismos que solo debemos postularnos a trabajos si estamos 100% calificados, pero no hay crecimiento allí. Así que me dije a mí mismo que debía postularme de todos modos y, si tuviera la oportunidad, podría hacer el 50 % del trabajo el primer día y recoger el otro 50 % en el camino.

Cultivar la confianza y encontrar el ajuste adecuado

Siempre he sido una persona extremadamente competitiva. Practiqué deportes en la escuela secundaria, obtuve sobresalientes y me gradué tercero en mi clase en la universidad. Cada vez que dudaba de mí mismo frente a un desafío, mi naturaleza competitiva me impulsaba a seguir avanzando hacia el éxito. Esto no quiere decir que nunca haya fallado o dudado de mí mismo, pero la voz competitiva en mi cabeza continúa empujándome. Todavía dudo de mí mismo a menudo. Veré los elogios de alguien con quien fui a la universidad o de un extraño al azar en Internet y me convenceré de que estoy muy atrasado en mi carrera y que debería pasar más tiempo libre codificando. Creo que dudar de tus habilidades es parte de ser ingeniero. Cuando estás constantemente tratando de resolver problemas que aún no tienen una respuesta y trabajas con personas tan inteligentes y talentosas, es

Estudié ingeniería eléctrica en la universidad. A pesar de que había una (relativamente) buena cantidad de mujeres en nuestra clase, constantemente recibía comentarios como «¡Debe ser difícil estar en esa especialidad cuando está tan dominada por los hombres!». Comentarios como este siempre se registrarían como un desafío para mí para ser tan bueno o mejor que mis compañeros masculinos. Incluso cuando mis compañeros de clase masculinos no sabían la respuesta, siempre confiaban en sus habilidades. Aprendí mucho observándolos y traté de proyectar la misma confianza en mis estudios, incluso cuando estaba convencido de que iba a reprobar. «Fíngelo hasta que lo logres» es un cliché, pero es muy aplicable en situaciones en las que es posible que aún no tengas confianza en ti mismo.

Tuve que aplicar este mantra de «fingir hasta que lo consigas» para mi entrevista con VMware. Sabía que solo estaba calificado para ciertas partes del trabajo. Decirle a un entrevistador que no tenía ninguna experiencia con contenedores no contribuiría a un resultado positivo de mi entrevista. En cambio, expliqué cómo podía aprovechar mi experiencia pasada para tener éxito en este nuevo rol y di ejemplos de situaciones en las que no sabía algo y tuve que aprender el tema por mí mismo. Terminé consiguiendo el trabajo y, como resultado, me convertí en un mantenedor de código abierto.

En la escuela, pensé que era importante saberlo todo de la cabeza. Al ingresar al mundo laboral, rápidamente se da cuenta de que no lo llevará muy lejos. No puede memorizar todo e incluso si pudiera, la tecnología está cambiando demasiado rápido para mantenerse al día. Saber cómo encontrar la respuesta es más importante que saber inmediatamente la respuesta.

Cuando comencé a hacer entrevistas para trabajos fuera de la universidad, me advirtieron sobre la temida «entrevista de codificación». Para prepararme, trataría de memorizar todas las posibles soluciones optimizadas para problemas de codificación comunes. Cuando me di cuenta de que esto era imposible para mí, mi confianza se destrozó por completo. Sin embargo, a medida que he crecido como ingeniero, me doy cuenta de que la entrevista se trata tanto de encontrar una pareja para mí como para la empresa. Si una empresa necesita un ingeniero que pueda resolver cualquier problema de codificación en 20 minutos, probablemente no tendría mucho éxito en ese puesto.

Incluso cuando mis compañeros de clase masculinos no sabían la respuesta, siempre confiaban en sus habilidades. Aprendí mucho observándolos y traté de proyectar la misma confianza en mis estudios.

Eliminación de barreras de entrada para otros

Siempre me ha interesado estudiar a las personas y sus comportamientos en diferentes escenarios. A nivel personal, empezó cuando era niño. Mis padres pasaron por un desafortunado divorcio y aprendí mucho observando sus interacciones y comportamientos. Si uno de los padres decía «no» a algo, hacía que el otro dijera «sí»; fue fascinante para mí entender sus motivaciones conductuales. No sabía que esta experiencia de navegar intereses contrapuestos a una edad temprana me estaba preparando para mi futuro trabajo en comunidades de código abierto.

Los comportamientos humanos y los patrones de comunicación se ponen bajo una lupa en código abierto. La comunicación es especialmente única porque normalmente se comunica a través de medios escritos a través de GitHub/Slack/email. Por eso, siempre trato de ser consciente de cómo diferentes personas pueden interpretar el mismo texto. ¿Cómo influyen las experiencias personales de las personas? ¿Qué nivel de consideración debo darle a esto cuando doy retroalimentación?

Un patrón de comunicación que noto comúnmente en mí mismo es la preocupación de herir los sentimientos de alguien, especialmente con la retroalimentación. Casi me disculpo cuando tengo que pedir cambios en una solicitud de extracción, aunque es mi trabajo como mantenedor. No creo que comunicarse con empatía o compasión cuando se comunica sea necesariamente un problema, pero definitivamente hay situaciones en las que ser «demasiado amable» puede interpretarse como incompetencia, especialmente como mujer.

Cuando creé mi cuenta de GitHub por primera vez, elegí a propósito un identificador unisex y no subí una imagen para ver si mi experiencia sería diferente. Como era de esperar, sentí que recibía mucha menos presión cuando solicitaba cambios si la gente asumía que era hombre. Comunicarme como una cuenta supuestamente masculina me hizo sentir menos presión para ser demasiado complaciente o amable.

Puede que responsabilidad no sea la palabra correcta, pero estoy obligado a ayudar a los nuevos en código abierto porque puedo recordar cómo es. Si hay un colaborador de Tern que quiere comenzar con un problema y veo que está en la escuela o es parte de un grupo demográfico subrepresentado en código abierto, estoy más ansioso por brindar orientación y asistencia. Comenzar con el código abierto tiene menos que ver con el proyecto específico y más con comprender los flujos de trabajo y las expectativas de GitHub. A veces, el consejo más útil que puedo dar a un nuevo colaborador es simplemente explicarle cómo actualizar su solicitud de extracción.

Esta experiencia de navegar intereses contrapuestos a una edad temprana me estaba preparando para mi futuro trabajo en comunidades de código abierto.

Todos han estado allí, y muchos de ellos quieren ayudar.

Existe la idea errónea en el código abierto de que necesita conocer todos los detalles técnicos de un proyecto para participar, ¡pero no es cierto! Puedes aprender mucho sobre la dinámica de la comunidad y el estilo de comunicación de un proyecto simplemente observándolo desde lejos. Una vez que encuentre un proyecto y una comunidad que se ajusten bien, consulte su documentación. Mejorar la documentación es una buena manera de comenzar porque puede practicar para familiarizarse con todos los flujos de trabajo y los revisores antes de fusionar el código real.

El siguiente paso es encontrar un mentor en el proyecto. Mucha gente en código abierto quiere ayudar, quiere que otros se entusiasmen con el proyecto y estuvieron en su lugar en algún momento. Al observar la comunidad, puedes encontrar a esas personas. Es posible que no tengan tiempo para asesorarlo en el sentido tradicional, pero pueden tener 10 minutos aquí y allá para guiarlo a través de algo. Si bien hacer preguntas en una comunidad nueva puede parecer intimidante, piense en ello como si ejerciera un músculo. Cuanto más practique la búsqueda de aclaraciones, incluso cuando se sienta vulnerable, más fortalecerá su confianza.

No tengo mentores «oficiales». Nisha es la otra mantenedora de Tern, y siempre la he considerado una mentora, aunque no nos llamamos estrictamente mentora/mentee. Además de nuestro diálogo regular sobre el proyecto, tenemos muchas discusiones sobre cómo queremos que sean nuestras carreras y nos damos retroalimentación sobre las acciones que debemos tomar para que eso suceda. También aprendo mucho al observar la forma en que redacta los correos electrónicos, responde preguntas, se enfrenta a confrontaciones y toma decisiones sobre hacia dónde debe ir el proyecto. En mi experiencia, las conversaciones formales entre mentor y aprendiz a veces pueden parecer rígidas y centrarse en expectativas poco realistas, en lugar de relaciones que evolucionan naturalmente.

Mucha gente en código abierto quiere ayudar, quiere que otros se entusiasmen con el proyecto y estuvieron en su lugar en algún momento.

Lo correcto moralmente y para los negocios.

A veces puede haber una percepción en el código abierto de que si te pagan por trabajar en él, es menos «código abierto». Y, de manera más general, en nuestra cultura, hay una narrativa falsa que dice que si haces las cosas de la manera difícil, cuenta más que si haces las cosas de la manera fácil. No digo que siempre haya una «manera fácil» de hacer las cosas, pero, especialmente como madre, sé que el sufrimiento no hace que nada valga la pena o sea más gratificante.

La gente debe ser pagada. Si una empresa está utilizando un proyecto de código abierto, debería pagar o contribuir de alguna manera. Es importante desde la perspectiva de hacer lo correcto, pero también desde la perspectiva del riesgo. ¿Desea confiar en un proyecto sin información sobre su ciclo de desarrollo, cómo abordan las correcciones de seguridad o cómo deciden en qué trabajarán a continuación? Simplemente no es una estrategia comercial inteligente. Creo que hay un ajuste de cuentas real en este momento en este espacio, ya que vemos más ataques a la cadena de suministro como Log4j. Vemos algunos intentos de invertir recursos en dependencias de código abierto para grandes proyectos como Kubernetes, pero mi esperanza es que finalmente veamos esto también con dependencias de código abierto más pequeñas.

El código abierto puedeser una buena puerta de entrada para ganar experiencia para su currículum, pero también limita quién puede participar si solo esperamos que las personas contribuyan de forma gratuita en su tiempo libre. No soy alguien que quiera programar en todo su tiempo libre, especialmente cuando tengo una familia con la que quiero pasar el tiempo, y especialmente no gratis. La diversidad de experiencias y pensamientos es importante, y no creo que el código abierto estrictamente gratuito promueva ese entorno. Es como decir, solo queremos personas que tengan todas sus necesidades satisfechas; quién puede permitirse trabajar gratis; que pueden no necesitar equilibrio en su vida; que no tienen familia a la que atender; no son padres solteros o alguien que cuida a sus padres ancianos o niños enfermos. Si la expectativa es que tenga mucho tiempo libre para invertir en trabajo no remunerado, limita quién puede participar.

No es un secreto que la participación de código abierto está dominada por hombres. No puedo evitar sentir que este es un efecto secundario general de décadas de expectativa social de que las mujeres, y las madres en particular, se encarguen de la familia y las tareas del hogar. Me gusta pensar que esta mentalidad está cambiando lentamente. Mientras tanto, si me encuentro en una posición frustrante, trato de preguntarme: «¿Qué puedo reconocer sobre esta situación en particular?» Esto puede significar reconocer verdades incómodas, como «No me defendí» o «He sido agradable hasta el punto de que me ha afectado negativamente». Por supuesto, no toda situación desafortunada es resultado de tus propias acciones, pero tratar de encontrar experiencias de aprendizaje en medio de los momentos difíciles es parte del crecimiento como ser humano y profesional. ¡Te lo mereces!

Fuente: https://www.somoslibres.org/

El grupo publicó en su sitio de la dark web que atacó al Ministerio de Hacienda de Costa Rica y solicitó el pago de 10 millones de dólares. En las últimas horas informó que también accedió a información de otras instituciones costarricenses.

A comienzos de esta semana, los atacantes anunciaban que habían atacado al Ministerio de Hacienda los cibercriminales y afirmaron haber robado 1TB con información extraída del Portal de Administración Tributaria (ATV) y documentos internos. En esa publicación en su sitio, los cibercriminales revelaban también que habían solicitado el pago de 10 millones de dólares para recuperar los archivos del cifrado. Además de publicar una muestra para su descarga con una parte de la información robada, amenazaron con publicar la totalidad de los datos el 23 de abril. Con el transcurso de los días fueron actualizando la información que publicaron en su blog sobre el ataque y comenzaron a advertir que los ataques a los ministerios continuarían si no pagan.

En el día de hoy los cibercriminales dieron más detalles y dicen haber obtenido acceso a unos 800 servidores y extraído 900 GB de bases de datos, y 100 GB con documentos internos del Ministerio de Hacienda y bases de datos que contienen nombres completos y direcciones de correo.

Además de extorsionar a la víctima con la información, los atacantes aseguran haber implantado una gran cantidad de backdoors en varios ministerios públicos y compañías privadas. Asimismo, en su sitio de la dark web agregaron en las últimas horas para su descarga cuatro archivos comprimidos con información supuestamente extraída de los sistemas de la víctima.

Imagen 2. Información publicada el 20 de abril en la publicación de su blog sobre el ataque al Ministerio de Hacienda de Costa Rica y que incluye más de 10GB en cuatro archivos para su descarga.

Por su parte, desde el Ministerio de Hacienda comunicaron en un extenso hilo de Twitter que en la madrugada del lunes 18 de abril comenzaron a tener inconvenientes en algunos de sus servidores y que desde entonces están investigando y analizando en profundidad lo que ocurrió. Mientras tanto, suspendieron temporalmente las plataformas ATV y TICA y explicaron que volverán a estar disponibles luego del análisis.

Asimismo, en cuanto a los datos expuestos hasta ese entonces por los atacantes, el organismo manifestó que la información divulgada corresponde a la Dirección General de Aduanas y que la misma es utilizada como insumo y soporte, pero que no es de carácter histórico.

Acerca del ransomware Conti

Conti es un ransomware que opera bajo el modelo de ransomware as a service y que ha sido entre los distintos grupos de ransomware el que más actividad tuvo en 2021, sumando a un mes de finalizar el 2021 unas 599 víctimas. Esta actividad se enmarca en un contexto en el cual la actividad de los grupos de ransomware comenzó a crecer significativamente en 2020 desde el inicio de la pandemia, causando gran preocupación a nivel mundial por el elevado costo de los rescates, la interrupción de las operaciones que provoca esta amenaza en las organizaciones, y por los daños a la reputación.

Este grupo está en actividad desde el año 2019 y en América Latina afectó a organizaciones de Argentina, Colombia, Honduras, Brasil y República Dominicana.

En cuando a la forma de operar de este grupo, desde ESET hemos analizado alguna de sus muestras para ver cuáles son sus principales características de este ransomware. De acuerdo con lo que hemos visto, esta amenaza suele distribuirse a través de correos de phishing que incluyen adjuntos maliciosos que descargan un malware que en instancias posteriores termina en la descarga de Conti en el equipo de la víctima. Otros mecanismos de acceso inicial utilizados por Conti son la explotación de vulnerabilidades o los ataques a servicios RDP expuestos y débilmente configurados.

Para más información sobre cómo opera, compartimos este artículo sobre las principales características del ransomware Conti y cómo operan sus afiliados.

Otros ataques de Conti que tuvieron gran repercusión fueron el que afectó al sistema de salud de Irlanda y que provocó la interrupción en el funcionamiento de sus sistemas. Más acá en el tiempo, este mes el grupo también afirmó ser el responsable de un ataque a Nordex, una compañía muy importante que se dedica a la fabricación de molinos eólicos y que debió interrumpir sus sistemas tecnológicos tras el incidente.

Razer es un fabricante que no tiene mucho aprecio a Linux, hasta el extremo de que el soporte para su hardware depende de proyectos comunitarios mantenidos por voluntarios. Sin embargo, eso no ha impedido que una empresa llamada Lambda haya tomado su portátil Advanced Blade 15 para convertirlo en un equipo orientado al sector profesional y con Linux preinstalado.

Sí, estamos ante el primer ordenador Razer que viene con Linux preinstalado, aunque quizá no tanto. Al parecer lo que ha hecho Lambda es realizar un proceso de rebranding con la bendición de Razer para crear un portátil bautizado como Tensorbook (o Razer x Lambda Tensorbook). Aunque oficialmente tiene el foco puesto en la Inteligencia Artificial y sobre tecnologías como PyTorch, Tensorflow, CUDA y cuDNN, el hecho de incorporar una gráfica RTX para consumo hace que pueda funcionar perfectamente como equipo para Linux Gaming.

El Tensorbook incluye un Intel Core i7-11800H como procesador, 64GB de RAM, un SSD NVMe de cuarta generación de 1TB para el sistema operativo, otro SSD NVMe de cuarta generación de 1TB para datos, una NVIDIA RTX 3080 Max-Q con 16GB de VRAM como gráfica dedicada, una pantalla de 15,6” que funciona a 165Hz y una resolución nativa de 1440p y una batería de 80Wr que con la gráfica integrada debería de ofrecer unas 9 horas de autonomía. El sistema operativo es Ubuntu 20.04 LTS.

En cuanto a conexiones, el Tensorbook cuenta con lector de tarjetas SD de tamaño completo y soporte UHS-III, Wi-Fi 6E, Bluetooth 5.2 (no especifican la marca de la Wi-Fi y el Bluetooth, así que esperemos que no sean de Broadcom), dos puertos Thunderbolt 4, tres puertos USB 3.2 Gen 2 Type-A (rectangulares) y un conector jack de 3,5mm para micrófono y auriculares. Las dimensiones del equipo son de 16,9 x 355 x 235 milímetros y su peso de aproximadamente 2,1 kilogramos.

El Tensorbook se sirve a través de tres modelos: Base, Standard y Enterprise, cuyos precios son de 3.499, 4.099 y 4.999 dólares respectivamente. Todos tienen las mismas características a nivel de hardware, así que se diferencian por la garantía y el soporte técnico ofrecidos. Con el modelo Base se ofrece un año de garantía y los modelos Standard y Enterprise incluyen respectivamente dos y tres años de soporte premium de Lambda. Los modelos Base y Standard ponen a disposición la opción de introducir un arranque dual con Windows a cambio de 500 dólares más, mientras que el modelo Enterprise se sirve forzosamente con arranque dual.

Como ya hemos dicho, y más viendo sus exageradas características, estamos ante un equipo más orientado al sector profesional que a los gamers y usuarios comunes, pero la gráfica que incorpora sirve para el gaming y a la hora de la verdad todo queda reducido a las personas dispuestas a pagar su precio. Quién sabe, igual Lambda pone los cimientos para un acercamiento oficial de Razer a Linux, más viendo que el Tensorbook cuenta con su bendición, tal y como se puede ver en su canal oficial de YouTube.

Fuente: https://www.muylinux.com/

A todos nos puede pasar.

Estamos fuera de casa entretenidos, descuidamos por un rato el celular y cuando revisamos el bolsillo, el bolso o donde lo teníamos colocado ya no está allí.

Los ladrones pueden ser muy habilidosos a la hora de robarnos celulares en un momento mínimo de descuido.

Además de hacernos sentir mal, el robo de un celular puede comprometer documentos privados y datos personales y originarnos un agujero en nuestros ahorros a la hora de reemplazarlo.

Por eso te ofrecemos algunas indicaciones sobre qué hacer para evitar daños mayores en caso de que sufras un robo de tu teléfono móvil.

1. Bloquear el dispositivo

Si te roban tu celular, el primer paso es bloquear el dispositivo inmediatamente después de la pérdida del objeto, según Emilio Simoni, especialista en seguridad digital y director de dfndr Lab, del grupo CyberLabs-PSafe.

«Es muy importante ponerse en contacto con el operador solicitando la cancelación del chip para que el celular quede inutilizado», explica. Los canales de contacto se pueden encontrar en los sitios web de los operadores.

Es posible hacerlo mediante el IMEI (Identidad Internacional de Equipo Móvil), un registro internacional que permite deshabilitar el celular más rápidamente. Por eso es importante anotar el código y tenerlo siempre a mano.

Por lo general, el IMEI se puede encontrar en la caja del dispositivo o en el propio teléfono celular.

Una manera fácil de averiguar el IMEI es escribir el siguiente código en el teclado de llamada del dispositivo: *#06#

2. Cambiar la contraseña de tus aplicaciones

Según Simoni, debes cambiar la contraseña de las aplicaciones que están en el celular ya que otras personas podrían acceder a ellas.

Esto se debe a que el delincuente podría acceder fácilmente a tu información personal y confidencial, como otras contraseñas y contactos familiares.

«Por lo general, las aplicaciones bancarias no se autentican automáticamente. Pero otras herramientas, como el correo electrónico y las redes sociales, permiten que quien tenga el dispositivo modifique la contraseña a través de la autenticación por SMS«, dice Simoni.

Algunas de estas aplicaciones permiten cambiar la contraseña en los sitios web de la herramienta, lo que permite al dueño del dispositivo cambiarlo todo rápidamente.

En las redes sociales, como Facebook e Instagram, el cambio de contraseña se puede realizar en las secciones de Seguridad e Inicio de sesión en los sitios web de la plataforma. En Gmail, el cambio de contraseña se encuentra en la sección sobre información personal.

3. Informar a instituciones financieras

Informar a tu banco y otras instituciones financieras es un paso recomendado para cualquier persona a la que le hayan robado su teléfono móvil.

Como resultado, el banco puede bloquear la aplicación en el celular y también posibles transferencias que el delincuente intente realizar a cuentas de terceros.

Cada banco tiene su propio canal para este servicio. Por lo general, están disponibles en el sitio web de la institución. Los contactos telefónicos de los bancos también se pueden encontrar en Google.

4. Avisar a familiares y amigos

Informar a familiares y amigos cercanos sobre el crimen es otra tarea importante para quienes perdieron o les robaron su teléfono celular.

«A menudo, los delincuentes descubren el contacto de familiares en aplicaciones de mensajería o redes sociales y se dirigen a ellos para intentar estafarles, pidiendo dinero o datos bancarios», explica Simoni.

5. Pon una denuncia

Registrar robos de un celular (o de cualquier otro objeto) contactando a la policía o acudiendo a comisaría es fundamental para acreditar que se ha cometido el delito.

El documento de denuncia policial puede ser requerido por tu banco, aseguradora o autoridades como justificante ante cualquier gestión.

Muchas veces, junto al celular, tenemos también documentos de identidad que pueden ser sustraídos. Si debemos permanecer unos días sin identificación, tener a mano la denuncia policial como justificante puede ser muy útil.

Para Simoni, otro beneficio de la denuncia es que pone sobre la policía «el deber legal de investigar el delito».

Aunque sea difícil recuperar el dispositivo, tu denuncia puede ayudar a identificar lugares específicos donde se estén cometiendo este tipo de delitos con frecuencia.

De esta forma, pueden emitirse avisos públicos que alerten a los ciudadanos, faciliten la actuación policial y permitan que se conozca más sobre las actividades de los criminales.

Fuente: https://www.bbc.com/

Prácticamente un año después del lanzamiento de la anterior versión mayor, ya tenemos entre nosotros a QEMU 7, que continúa con el desarrollo y la evolución de este conocido emulador de procesadores, el cual es además uno de los principales pilares de la virtualización sobre Linux.

Durante el desarrollo de QEMU 7 se enviaron más de 2.500 commits procedentes de 255 autores. Centrándonos en las novedades, las primeras cosas que se pueden destacar son el soporte para registrar eventos del invitado a través de la interfaz ACPI ERST y los progresos en RISC-V, que abarcan el soporte para KVM; las extensiones de Vector 1.0 ratificada, Zve64f, Zve32f, Zfhmin, Zfh, zfinx, zdinx y zhinx; soporte de máquina ‘spike’ para la carga del binario OpenSBI; soporte de máquina ‘virt’ (plataforma virtual genérica) para 32 núcleos; y soporte para AIA.

En lo que respecta a ARM, tenemos el soporte de placa ‘virt’ para ‘virtio-mem-pci’ especificando la topología de la CPU invitada y habilitando PAuth cuando se usa KVM/hvf, soporte de placa ‘xlnx-versal-virt’ para PMC SLCR y emulación del controlador de memoria flash OSPI, además de que ‘xlnx-zynqmp’ ahora modela el control CRF y APU.

Para PowerPC se ha incorporado el soporte de emulación de ‘pseries’ para ejecutar invitados como un hipervisor de KVM anidado, un nuevo soporte para el dispositivo ‘spapr-nvdimm’, mejoras en la emulación de ‘powernv’ para XIVE y PHB 3/4 y un nuevo soporte para XIVE 2 y PHB5.

Para x86 nos encontramos con la inclusión del soporte de AMX de Intel, mientras que el soporte para las etiquetas de seguridad de ‘virtiofs’ ha mejorado junto a una flexibilidad mejorada a la hora de realizar copias de seguridad, incluyendo la compatibilidad de imágenes que no son ‘qcow2’.

Todos los detalles de QEMU 7 están publicados en el anuncio oficial y la lista de cambios. El software puede ser obtenido a partir de la correspondiente sección de descargas en el sitio web del proyecto. Si bien está estrechamente ligado a Linux, también ofrece soporte a nivel de anfitrión para Windows y macOS, por lo que en realidad es un desarrollo multiplataforma.

QEMU es una solución muy potente que ofrece un alto rendimiento y es posible utilizarlo de forma independiente o junto a Xen o KVM, aunque sacarle todo el partido puede requerir de tener profundos conocimientos. Algunos de sus componentes están integrados en la popular VirtualBox, mientras que en lo que respecta a su combinación fácil con KVM se puede recurrir a GNOME Boxes o a la áspera interfaz virt-manager.

Fuente: https://www.muylinux.com/

Las nuevas preocupaciones sobre la cadena de suministro de software surgieron en la comunidad de código abierto cuando una popular biblioteca de Javascript comenzó a eliminar todos los archivos en los sistemas de Bielorrusia y Rusia como protesta por la guerra en Ucrania

Node-ipc, una biblioteca npm que es una dependencia del extremadamente popular marco Javascript frontend Vue.js, se actualizó la semana pasada para incluir código malicioso que sobrescribía archivos en sistemas con direcciones IP bielorrusas o rusas. El mantenedor de Node-ipc, RIAEvangelist, pronto revirtió el código para simplemente dejar caer un archivo titulado «CON AMOR-DE-AMERICA.txt» que contenía un mensaje que pedía paz.

«Este comportamiento está más que jodido. Claro, la guerra es mala, pero eso no justifica este comportamiento (por ejemplo, eliminar todos los archivos para los usuarios de Rusia/Bielorrusia y crear un archivo extraño en la carpeta del escritorio). F** k tú, vete al infierno. Acabas de arruinar con éxito la comunidad de código abierto. ¿Estás feliz ahora @RIAEvangelist ? «, Escribió un comentarista en Nopde-ipc Github.RIAEvangelist negó que haya una carga útil destructiva; sin embargo, la carga útil fue bien documentada por la comunidad de Github y Snyk .

Cuando RIAEvangelist actualizó Node-ipc, también actualizó los números de versión, lo que provocó la actualización automática del código para muchos usuarios intermedios.“Obviamente querían enviar un mensaje en un momento en el que estamos teniendo muchas crisis en todo el mundo, hay un dolor comprensible. Puedo entender eso. También me gustaría decir que esta no es la mejor manera de hacerlo. «, dijo Liran Tal, director de defensa de desarrolladores en Snyk, a SC Media.

Tal escribió la publicación del blog de Snyk, que incluye en términos inequívocos su postura sobre la guerra: «Snyk apoya a Ucrania». El problema, dijo, es que el software destructivo, incluso «protestware», un término acuñado por algunos para Node-ipc, corre el riesgo de dañar los sistemas colaterales y la comunidad de código abierto en general.»El radio de explosión aquí fue grande», dijo.

Muchos desarrolladores ven el software de código abierto como un monolito, una sola comunidad en lugar de un grupo de proyectos individuales. Incluso entre los proyectos populares, estos pueden abarcar toda la gama de grandes organizaciones con juntas directivas y muchos contribuyentes, como dijo XKCD , «un proyecto que alguna persona al azar en Nebraska ha estado manteniendo desde 2003 sin agradecer».

Node-ipc es la segunda instancia importante de un proyecto de código abierto mantenido por un solo individuo que fue saboteado como una forma de activismo el año pasado, luego de un largo período sin activismo alguno. Colors.js y Faker.js, ambos mantenidos por la misma persona, agregaron un bucle infinito al código en enero para protestar contra las grandes empresas que usan software de código abierto sin contribuciones financieras. En ese caso, sin embargo, la protesta estaba ligada al medio: era una protesta de código para los codificadores, en lugar de un tercero.

La lección puede ser incluir proyectos dirigidos por individuos, o proyectos con dependencias de proyectos dirigidos por individuos, como su propio riesgo en un modelo de amenaza.»Tienes que confiar en las personas de las que obtienes los componentes. Y creo que la moraleja de la historia vuelve a la higiene. Cuando eliges qué proyectos usar, debes elegir los de lugares que son respaldado por fundaciones», dijo Brian Fox, director de tecnología de la empresa de cadena de suministro de software Sonatype.

Una organización como Apache, donde una decisión tan radical como agregar un código malicioso requeriría una votación, sería menos probable que hiciera tal movimiento, dijo Fox.

Pero el punto, dijo, no debería ser que el activismo por sí solo sea el problema. En cambio, todo esto juega con un problema mayor, que las empresas siguen sin estar preparadas para los riesgos de la cadena de suministro de software, incluso después de un año mostrando cuántas formas diferentes entran. a SC Media eran para versiones peligrosamente desactualizadas del popular paquete Java.»Si no podemos manejar Log4j después de tres meses, ¿cómo podemos manejar algo que sucedió anoche?», dijo.

Lo merezca o no, el daño causado a la credibilidad del código abierto probablemente no se limitará a proyectos mantenidos por individuos individuales. (Los teléfonos celulares de los proveedores comerciales «probablemente se están volviendo locos ahora», dijo Adam Meyers, vicepresidente senior de inteligencia de Crowdstrike, ya que las empresas buscan una alternativa administrada de manera más profesional).

Para el código abierto en general, «no ha sido un buen aspecto», dijo, incluso cuando la mayoría de las personas en la comunidad de código abierto lo ven como «tremendamente irresponsable».»No había discreción sobre qué tipo de usuarios había en Rusia o Bielorrusia», dijo. «Podría haber sido, ya sabes, infraestructura crítica, cuidados críticos. Extremadamente mal juicio».

Fuente: https://www.somoslibres.org/

Por tercera vez en pocas semanas, investigadores de ESET detectan un nuevo malware del tipo wiper previamente desconocido apuntando a organizaciones ucranianas.

Los investigadores de ESET descubrieron otro malware que destruye datos (wiper) utilizado en ataques contra organizaciones en Ucrania.

Apodado CaddyWiper por los analistas de ESET, el malware se detectó por primera vez a las 11:38 a. m. hora local (9:38 a. m. UTC) del lunes 14 de marzo. El wiper, que destruye los datos de los usuarios y de las unidades conectadas, se detectó en varias docenas de sistemas en un número limitado de organizaciones. Los productos ESET detectan este malware como Win32/KillDisk.NCX.

CaddyWiper no presenta similitudes en el código importantes en comparación con HermeticWiper o IsaacWiper, los otros dos nuevos wipers de datos que han afectado a organizaciones en Ucrania desde el 23 de febrero.

Un nuevo wiper cada semana

En las últimas tres semanas, es la tercera vez que los investigadores de ESET detectan una muestra previamente desconocida de malware que borra datos apuntando a organizaciones en Ucrania.

En la víspera de la invasión de Rusia a Ucrania, la telemetría de ESET detectó a HermeticWiper en las redes de varias organizaciones ucranianas de alto perfil. Estas campañas también desplegaron a HermeticWizard, un gusano personalizado utilizado para propagar HermeticWiper dentro de las redes locales, y a HermeticRansom, un ransomware utilizado como señuelo.

Al día siguiente, comenzó un segundo ataque destructivo contra una red gubernamental ucraniana, esta vez desplegando IsaacWiper.

Ucrania en la mira

En enero de este año, otro wiper de datos, llamado WhisperGate, limpió las redes de múltiples organizaciones en Ucrania.

Estas campañas son solo las últimas de una larga serie de ciberataques que han alcanzado objetivos de alto perfil de Ucrania durante los últimos ocho años. Tal como lo exploraron los investigadores de ESET en un webinario en inglés publicado recientemente, desde 2014 a esta parte Ucrania ha sido el blanco receptor de una serie de ataques cibernéticos altamente disruptivos, incluido el ataque NotPetya que atravesó las redes de varias empresas ucranianas en junio de 2017 antes extenderse a otros países.

ESET Research ahora ofrece un informe de inteligencia de APT privado y una fuente de datos. Por cualquier consulta acerca de este nuevo servicio o investigación publicada en WeLiveSecurity, contáctenos en threatintel@eset.com.

Fuente: https://www.welivesecurity.com/