#27 pero la arranca Apache Tomcat, no? Pensaba que sería algo a modificar en algún fichero de configuración
#16 imagino que se refiere a si la utilidad (que funciona adjuntándose a la máquina virtual y redefiniendo el bytecode de JndiLookup::lookup) funciona con JDK1.7 o no, no si Log4Shell le afecta
#8 la propiedad clave, log4j2.formatMsgNoLookups, se añadió en log4j 2.10. Si usas una versión anterior poner la propiedad no tendrá ningún efecto y seguiréis siendo vulnerables
#4 un pequeño recordatorio, el parche no persiste si se reinicia la máquina virtual. Es posible aplicar el parche en modo agente pasando un parámetro a la hora de arrancar, pero si vas a parar la máquina y puedes, la recomendación es actualizar log4j
#14 Hemos probado la utilidad en 8, 11 y 15. Cuando tengamos algo de tiempo subiremos la versión que soporta 17 en caliente, ya que la que hay ahora en github para 17 solo funciona en modo agente.
No se me ocurre un motivo por el que no vaya a funcionar en 7, pero no la hemos probado
#34 Esa variable solo es valida para log4j2.10 y superior, en versiones anteriores no esta presente. Nuestro parche bloquea llamadas jndi que se hacen a base de interpretar Strings
#1 Eso solo es posible contra versiones de OpenJDK que esten configuradas para aceptarlo. Desde OpenJDK 8u191 la configuracion por defecto es deshabilitarlo. Como referencia, esa version tiene mas de tres años.
Aun asi, eso no significa que utilizando una version de OpenJDK mas nueva se este completamente a salvo. La vulnerabilidad en Log4j sigue siendo critica y la recomendacion es actualizar Log4j
#24 eso o deshabilitar la la ejecución desde jdni con la variable "log4j2.formatMsgNoLookups=true"
O desactivar jdni directamente
Desde el equipo de AWS Corretto hemos sacado una utilidad que permite parchear este fallo de seguridad en caliente, sin necesidad de reiniciar la maquina virtual de java:
https://github.com/corretto/hotpatch-for-apache-log4j2
Esto puede ser util para aquellos que tienen servicios criticos que no pueden parar fuera de ventanas de mantenimiento, casos de aplicaciones que se distribuyen con todas sus dependencias y para las que aun no hay un parche o casos donde copias de las clases de log4j estan presentes en un namespace distinto
#77 Hola. Aunque es verdad que lo que describes era posible con antiguas versiones de OpenJDK, ese no es el caso en versiones de OpenJDK desde hace varios años, y otras alternativas tienen que ser utilizadas
Dudo que quede alguien leyendo por aqui, pero esta es una herramienta publicada por el equipo de AWS Corretto (del que formo parte) que permite parchear esta vulnerabilidad en caliente, sin reiniciar la maquina virtual de java:
https://github.com/corretto/hotpatch-for-apache-log4j2
#55 No recomendaria a nadie intentar determinar si estas afectado o no por este problema analizando el comportamiento de tu aplicacion y lo que intenta guardar en los logs. Personalmente recomendaria aquellos utilizando log4j2 que asuman que estan afectados y actualizen
#35 No es necesaria ninguna accion especialmente extraña con Log4j2 para estar afectado por este problema. Si utilizas log4j2, asume que estas afectado por este problema (porque casi seguro, lo estas). La unica opcion es actualizar log4j2 a 2.15+
#54 Que la movida es que te pueden mandar una peticion en la que figure ese texto asi formado, no?
"$"
Para que el jodio log4j se lo coma 
Ejemplo:
POST http://mipagina.com/user
#46 Hola,
Tu mensaje no es correcto. El fallo de log4j2 es critico, y en muchas ocasiones puede utilizarse independientemente de la version de OpenJDK en la que esta corriendo log4j2. La unica opción segura es actualizar Log4j2
#25 Correcto. Esta vulnerabilidad debe seguir considerandose critica y requiere una actualizacion de Log4j2.
#17 El uso de una version mas nueva de OpenJDK (ya sea en referencia a jdk8u121, jdk8u191 o 11.0.1) provee unicamente de una mitigacion parcial del problema. En muchas circunstancias, sigue siendo posible explotar la vulnerabilidad utilizando otras alternativas.
Esta vulnerabilidad debe considerarse critica independientemente de que version de OpenJDK se esta utilizando. La unica opcion para evitar el problema es actualizar Log4j2 a la ultiva version de 2.15 disponible (2.15rc2 en el momento de escribir este mensaje)
#48 una afirmación bastante atrevida. Veo tres formas de interpretar esto. O bien considerando que la mayoría de trabajos en informática son malos (y Java no es la excepción). O porque se desconoce el mercado laboral en el mundo de Java, o finalmente, porque se tiene una preferencia personal muy fuerte en contra del lenguaje. Pero ninguna de esas interpretaciones hacen que los trabajos en Java sean peores que otros
#52 Cuarta: La mayoría de trabajos en Java son para cárnicas que buscan un picacódigos temporales para mantener la aplicación hecha en 2008 para X cliente.
Porque al menos aquí en España no hacen aplicaciones punteras en Android. Ni ningún videojuego exitoso de móvil.
Pocas aplicaciones de escritorio que funcionen bien en Java, algún IDE.
#23 completamente cierto, no me verás a mi negarlo. Pero últimamente en entrevistas de trabajo, donde la gente puede elegir que lenguaje utilizar, la mayor parte opta por otros lenguajes, Python principalmente. No es mayor problema porque la gente espabilada, si luego tiene que ponerse con Java lo hace rapido
#5 Sigue dandose programación en Java? Era mi impresión que a día de hoy sería mas común ver otros lenguajes tipo Python o Javascript. Pero bueno, ya han pasado años
#23 completamente cierto, no me verás a mi negarlo. Pero últimamente en entrevistas de trabajo, donde la gente puede elegir que lenguaje utilizar, la mayor parte opta por otros lenguajes, Python principalmente. No es mayor problema porque la gente espabilada, si luego tiene que ponerse con Java lo hace rapido
#23 sigue siendo el lenguaje más usado
Nop. Según esto es C https://www.tiobe.com/tiobe-index/ según este Python https://pypl.github.io/PYPL.html y según este Javascript https://www.freecodecamp.org/news/stack-overflow-developer-survey-2020-programming-language-framework-salary-data/
#34 Esos estudios pueden servir para hacerse una idea de la evolución de un lenguaje a largo plazo, o para ver lenguajes que empiezan a despegar, pero no para extraer el dato de "el lenguaje más usado". Y mucho menos el TIOBE.
Ya el propio concepto en sí es bastante inasible, pero es que encima el modelado es de traca: TIOBE contabiliza los hits en motores de búsqueda de la query " programming". Eso representa un sesgo enorme hacia los nombres con poca buscabilidad, como C, y perjudica a otros como PHP o Prolog e incluso a otros que también tienen baja buscabilidad y que debido a esto tienen algún término de búsqueda como "golang" o "rustlang".
Y lo peor ya no es eso, sino que quitando a Google las fuentes de lo mejorcito: Amazon, Ebay... pero no stackoverflow o reddit Y así salen métricas como ésta de C (2016: 16%, 2017: 6%, 2018: 15%) o mi preferida:
El lenguaje más buscado en 2013 fue... TSQL WTF?
#23 La mayoría de trabajos que piden Java son malos...
#48 una afirmación bastante atrevida. Veo tres formas de interpretar esto. O bien considerando que la mayoría de trabajos en informática son malos (y Java no es la excepción). O porque se desconoce el mercado laboral en el mundo de Java, o finalmente, porque se tiene una preferencia personal muy fuerte en contra del lenguaje. Pero ninguna de esas interpretaciones hacen que los trabajos en Java sean peores que otros
#52 Cuarta: La mayoría de trabajos en Java son para cárnicas que buscan un picacódigos temporales para mantener la aplicación hecha en 2008 para X cliente.
Porque al menos aquí en España no hacen aplicaciones punteras en Android. Ni ningún videojuego exitoso de móvil.
Pocas aplicaciones de escritorio que funcionen bien en Java, algún IDE.
#17 Un compañero de trabajo ha hecho un fp y lo hizo en Java. Por referencias otra persona había hecho cursos de Java. Si, aún se enseña. En la educación reglada se va a lenguajes con tipados estáticos.
#24 Y tiene sentido, porque pasar de Java a Python es un paseo, pero al revés puede ser un poco más conflictivo. Y ya pasar de Python a C ni te cuento porque, como te toque manejar punteros y no tengas una base de conocimiento bien sólida, estás en un problema
#39 Python solo trabaja con punteros. Pero los punteros de C son bastante más jodidos. Yo hice punteros hace la tira de años en el módulo con Pascal y Delphi. Ya no me acuerdo de nada.
Python o lenguajes de alto nivel, son buenos para aprender, pero sí, creo que es mejor empezar con lenguajes más estrictos. Pero, si quieres torturar a tus alumnos, el mejor lenguaje es ADA. Con ese en teoría se aprende a estructurar el código.
#31 Esto que comentas no es totalmente cierto. La mayor parte de las implementaciones libres de la maquina virtual de java estan basadas en OpenJDK. OpenJDK es la maquina virtual que Sun libero poco antes de ser comprada por Oracle. Aunque al principio no incluia todos los componentes, en las ultimas versiones el JDK que ofrece Oracle es una build de OpenJDK. OpenJDK es GPLv2, por lo que incluso si el juicio hubiera ido a favor de Oracle, esto no habria afectado a OpenJDK (aunque quiza a otras implementaciones como OpenJ9). Igualmente, aunque Oracle no suministrase parches de seguridad, otra gente podria hacerlo (de la misma manera que a dia de hoy, Oracle distribuye parches de seguridad para OracleJDK8, pero para OpenJDK8 los parches de seguridad no necesariamente vienen de Oracle
#22 son parámetros que pasas a la máquina virtual de Java al arrancar, después de java y antes de la clase que quieres que se ejecute (o antes de -jar si estas ejecutando un jar)