Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Puni

Me cago en el Log4j y en los desarrolladores modernitos usando frameworks pa escribir logs.

Con cariño de un sys admin para los developers.

4 2 respuestas
desu
#32341Puni:

desarrolladores modernitos usando frameworks pa escribir logs

los loggers son un autentico detector de pajeets

hoy teniamos 15 PR para todos los servicios de java XD

Lecherito

Los loggers son mas o menos necesarios si quieres rotar los ficheros o escribir en disco de manera asincrona (si el servicio no lo usa ni peter entiendo que con un println os sobre). Lo que no es necesario es toda la parafernalia que hay alrededor de ellos.

#32341 que hace un sysadmin haciendo nada con log4j? xd

2 respuestas
Puni

#32343 He puesto sys admin por llamarlo de alguna manera, ni yo mismo sabría definir mi puesto, el título es Enterprise Application Specialist. Vamos, un cajón de sastre donde caen instalaciones, federación, mantenimiento y soporte de apps de terceros que hay que usar en una empresa grande y no quieren contratar un consultor para cada mini cambio. En este caso, la mitad de apps que llevo son java y todas tienen su mierda de log4j.

Aquí estoy, reiniciando apps a ver si con los cambios para desactivar la redirección arrancan normal o alguien ha hecho una tremenda ñapa por debajo para depender de una funcionalidad absurda para un framework de logging.

1 respuesta
Lecherito

#32344 es que tu mismo lo has dicho, es una funcionalidad absurda para un frameworkd e logging, porque le echas la culpa al framework en si? (bueno y ni al framework, al mero hecho de hacer eso) De hecho suelo usar logback antes que log4j y 0 problemas

1 respuesta
Puni

#32345 Sí bueno, pero cuando no eres responsable del desarrollo solo te queda rezar porque algún desarrollador no haya hecho uso de eso para algo. Yo soy responsable del servicio sólo.

2 comentarios movidos a [JS] Grabar con camara desde web app
desu
#32343Lecherito:

o escribir en disco de manera asincrona

expande... anda

1 respuesta
Ranthas

https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

jijijijiji

1 1 respuesta
Lecherito

#32349 no siempre quieres escribir cada evento en disco si no que lo haces en batches (por ejemplo cada segundo), los eventos los escribes a un buffer y ese buffer es el que escribe en disco. He llegado a ver rotaciones de logs de 10 minutos porque los ficheros eran tan sumamente grandes (de la cantidad de requests que habia) que no se podia hacer de otra manera.

2 respuestas
GuaNaGe

#32350 de locos jajaja todo dios mirando las versiones de logj2 que utilizan

1 comentario movido a [JS] Grabar con camara desde web app
eXtreM3

Cómo branchea @Jastro :D

1
wdaoajw

#32351 yo tuve un caso de esos hace poco, los cuales tumbaban nodos cada X tiempo porque llenaban el disco a base de logs... Cada X días tenían algún proceso gordo que llenaba el disco antes de que saltarán las alertas de disco, que las tenemos configuradas al 80% con un grace period de 10mins en nodos de 100G.

Lo peor es que tardaron en arreglarlo semanas y te llamaba a la guardia la monitorización por nodo caído

Ranthas

El típico idiota que te pone el log para las peticiones en los controllers en info y no en debug, colapsando todo

Pero eh primo, que en mi pc todo iba como la seda

1 respuesta
Lecherito

#32356 si y no, hay veces que necesitas tener las request legalmente (o las quieres para troubleshoot).

Pero vamos, yo estoy hablando de que en 1 hora se generaban masde 300 gigas de logs gzipped (sin contar las peticiones, solo logs normalitos)

1 respuesta
Ranthas

#32357 En menudos negocios más turbios andas metido

Ya sabía yo que algo ocultabas

desu

#32351 sabia que ibas por ahi

ahora que cojones tiene eso que ver con la interface desde el cliente?

que ese es mi problema, con la mayoria de gente que tengo esta discusion.

si escribes a stdout o otro buffer deberia ser transparente para ti y todo tu codigo pimpim. lo mismo me pasa con las metricas. la gente escribe el codigo pasando loggers y clientes en lugar de pasar un writer IO. si es async o no en el cliente es una linea de codigo, y luego donde escribas es implementacion.

cada vez que veo una interface logger me dan ganas de pegarme un tiro. acabo antes que pegandoselo a la panda de anormales que por sacarse un FP chustero y saber llamar spring se hacen llamar "profesionales" del sector.

gente que no sabe lo que es una pipe ni un buffer. atontaos.

log4j no deberia existir. ni ningun framework de logging. no tienen sentido en si mismos. la stdlib ya te ofrece capacidades. solo necesitas como mucho una lib.

lo mismo me pasa con los allocadores de memoria, suerte que la gente que trabaja en Java, Go y demas no sabe ni lo que es, si usas uno generalizado, uno fixed, uno que limpia al terminar la ejecucion porque haces un cli o un server y lo tiras por threading.... panda de atontaos.

1 respuesta
eisenfaust

entre logs, tracing y metrics tanto la persistencia como el scheduler se vuelven locos, pero al menos puedes ver en un grafico html5 que tu aplicacion va como el culo :thumbsup:

#32359desu:

suerte que la gente que trabaja en Java, Go y demas no sabe ni lo que es, si usas uno generalizado

suerte y desdicha al mismo tiempo, pero los gc son el mayor boost de productividad y seguridad que ha habido en decadas para los desarrolladores

esta un poco de moda echar peste de estos con cosas como zig y rust pero estos resuelven (mal) problemas que el 99% de devs no tienen

1 respuesta
desu

#32360 si no digo que sean malos, me parecen geniales.

tener una roomba de esas en casa que cada dia te aspira el suelo esta genial.

pero si vives como un cerdo rebolcandote en tu propia mierda y meandote en los platos que después usas para comer entiende que me des asco.

saber un mínimo de memòria no debería ser pedir una locura...

edit: en otro tema, menuda porqueria de codigo estoy viendo hoy

NSFW

casi bug pero no, https://www.androidsnippets.com/create-a-md5-hash-and-dump-as-a-hex-string

xq cojones hizo esto asi? a parte de para que fuera lento. no me entra en la cabeza.

1 respuesta
r2d2rigo

#32361 el que de todo? Para cifrado de toda la vida:

  • Haces query del algoritmo de cifrado por nombre.
  • Lo que cifras son datos binarios, asi que si tienes que cifrar texto has de obtener los bytes a traves de su encoding.
  • Para devolverlo en string mas de lo mismo, format de esos bytes en modo hex.
1 respuesta
desu

#32362 si conceptualmente esta bien

pero es 1 liner paco

Para seguridad de toda la vida:

  • nunca hagas mas de lo necesario
  • hazlo todo con las librerias de crypto

ademas del codigo que he puesto de androidsnippets, se me ocurren otras 2 maneras en que ese codigo puede dar problemas

en fin, con este mensaje queda claro que lo de log4j no sorprende a nadie XDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD

1 respuesta
Ranthas

#32363 Déjate de tirarte el rollo y postea el snippet correctamente.

El único fallo que tiene es que no controla un input null (saltará un NullPointerException en s.getBytes). Como mejora podría usar el enumerable StandardCharsets (Java 1.7 o superior) para pasar el encoding y así esquivar el UnsupportedCharsetException. Para buildear la string en un bucle lo más rápido es usar StringBuffer, supongo que sabrás como funciona el String pool en Java.

Así que te repito, ¿cuál es el snippet correcto? No te me vayas por las ramas ni empieces a spamear HAHAHA, postea el snippet.

1 1 respuesta
desu

#32364 la implementacion de aws por ejemplo

NSFW

yo recomiendo no usar java para empezar, pero bueno, aceptemoslo

  • el string buffer es una de las cosas que podia ir mal, alguien no puede saber que eso es bueno puede realizar multiples realocaciones por hash.
  • segundo el memory layout de esa string y la representacion final puede ser optimizado, porque sabes el tama;o y los bytes a pillar
  • si en lugar de concatenar strings haces hexs, si no es ascii peta, link que he puesto, la signature esta mal, deberia aceptar bytes
  • tambien se me ocurren maneras de joderlo por little endian/big endian que cuando daba clase en la uni y haciamos algos de hash a mano los alumnos siempre me hacian del reves
  • por ultimo, este detalle no podrias saberlo sin el contexto, pero el utf16 es completamente inecesario. en caso de "necesitarlo" volver al punto de porque java? como tratas las strings en tu codigo? xq seguramente no sepas lo que es una string en memoria.

solucion? voy a citar a una de las mentes mas prodigiosas de este pais

Para seguridad de toda la vida:

nunca hagas mas de lo necesario
hazlo todo con las librerias de crypto

Edit obligatorio: lo de la string pool lo dices mal, ese buffer no se usa por nada de string pool, se usa para minimizar alocaciones. asique no tengo ni idea de porque dices ese termino. supongo que te sonara.

edit obligatorio a posteriori:
AHAHAHHAHAHAHAHAHAHHAHAHA

1 respuesta
Ranthas

#32365

  • El código que has puesto devuelve un string con la representación del array de bytes; tu respuesta devuelve algo completamente distinto, el array de bytes codificado en base64. Un manzanas traigo de manual. Te he dicho como hacer ese snippet correctamente y tu solución pasa por hacer que devuelva una cosa completamente distinta.

  • Si el método usa internamente el charset ASCII, pues será que seguramente su input sea ASCII. Igualmente, debería chequearse (igual que para los nulos) o enviar un array de bytes. Evidentemente, si recibe una string en little endian, va a reventar 100%.

  • El utf16 si lo usa, será para que cada dos caracteres de la string represente un byte. Esto se usa para librerías guarreras que reciben ese string "hexadecimal" y lo trabajan. Te lo ahorrarías trabajando directamente el array de bytes, en eso tienes razón.

Lo de la string pool lo he dicho bien, era una asunción porque la gran mayoría de novatos asocian incorrectamente la clase StringBuffer con la creación de entradas en el string pool cuando es exactamente al revés: el append no interactua con el string pool en absoluto, lo que hace que sea la mejor opción para concatenar strings en bucles enormes (y no enormes)

En fin, que te digo como hacerlo y tu solución es hacerlo de cero, obviando la base y firma del método; si la firma es así, es porque debe ser así. Aunque repito, que es cierto que funcionaría mucho mejor si trabajase con arrays de bytes y no con strings. El snippet tal cual está puesto, está bien y sin fallos, pero bueno, tú en tu línea, lo mismo consigues impresionar a alguno del FP, pero creo que lo tienes crudo.

2 1 respuesta
desu
#32366Ranthas:

El código que has puesto devuelve un string con la representación del array de bytes; tu respuesta devuelve algo completamente distinto, el array de bytes codificado en base64. Un manzanas traigo de manual. Te he dicho como hacer ese snippet correctamente y tu solución pasa por hacer que devuelva una cosa completamente distinta.

HAHAHAHA mira bien el codigo anda.

El primer codigo devuelve en base64, es lo que hace en el stringbuilder, hacer la representacion a mano cogiendo 2 bytes. es el 02x. Tu sabes java???
El segundo codigo tambien devuelve en base64.

He probado los dos codigos, el manual y el segundo esta tarde y devuelven exactamente lo mismo te lo garantizo.

Te he dicho como hacer ese snippet correctamente y tu solución pasa por hacer que devuelva una cosa completamente distinta.

Te he puesto un codigo basico que no eres capaz de comprender??

HAHAHAHAHAHHAHAHAHHAA

xq os humillais asi?

#32366Ranthas:

Lo de la string pool lo he dicho bien, era una asunción porque la gran mayoría de novatos asocian incorrectamente la clase StringBuffer con la creación de entradas en el string pool cuando es exactamente al revés: el append no interactua con el string pool en absoluto, lo que hace que sea la mejor opción para concatenar strings en bucles enormes (y no enormes)

esta muy bien, pero el motivo principal no es ese. el principal te lo he puesto arriba. si quieres te lo explico poniendote ejemplos.

si no entiendes los ejemplos no dudes en volver a hacer el ridiculo.

a mi me da igual echarme unas risas a tu costa. te lo explicare despues de nuevo sin problema. porque yo por mis alumnos me bajo al nivel del subsuelo al que vivis sin problema. podemos empezar hablando de que es un byte.

todas las librerias estandard que trabajen con string de todos los lenguajes usan buffers para ahorrar alocaciones. puedes mirar cualquiera y veras.


toma crack, dices ser un NO-Fpero (tengo mis dudas)

https://datatracker.ietf.org/doc/html/rfc4648

lo mismo se te queda grande

Ranthas

Ya empieza con la huida hacia delante y los HAHAHA

La culpa es mía, quién con niños se acuesta, amanece mojado. Te dejo documentando apis y desplegando un hola mundo en fastapi. Bueno, eso segundo quizás te viene grande.

4 2 respuestas
pineda

#32368 debes haber tenido un día de putísima mierda para caer en el juego :joy:

1 1 respuesta
desu

#32368

HAHAHAHA mira bien el codigo anda.

El primer codigo devuelve en base64, es lo que hace en el stringbuilder, hacer la representacion a mano cogiendo 2 bytes. es el 02x. Tu sabes java???
El segundo codigo tambien devuelve en base64.

He probado los dos codigos, el manual y el segundo esta tarde y devuelven exactamente lo mismo te lo garantizo.

sisi soy yo el de la huida hacia adelante seguro

has hecho un ridiculo que solo le recuerdo a @r2neuronas

si el codigo no hace lo mismo porque no lo ejecutas???????

#32369 queria baitearme y se fue con una master class

le ha salido mal la jugada porque la ha cagado en la respuesta al no ver que el codigo hace exactamente lo mismo

luego ha querido ir de listo hablando de optimizaciones cuando a diferencia de el yo si se lo que es un puntero

Usuarios habituales