sobota, 15 października 2022

Gradle

Some of them like transitive dependency but not me

Wiadomo są tacy co kochają dependency transitive - ale nie ja

Simple total fuck off transitive dependency for all configuration in build.gradle

Chyba najprostszy sposób i całkowicie globalny aby to wywalić jak to mówią at all

...
configurations {
    forEach {
        c -> c.setTransitive(false)
    }
}

> Custom function for disable transitive dependency
Let's try definne metod for switch off transitive dependency ... of course possible many way as below

Taki mam pomysł aby zrobić to przez funkcję która opakowuje dependency... dla fanów wyższości c++ nad c=c+1 da to uproszczenie! Wystarczy dodać do definiowanego dependency prefix noTransitive, a "fantastyczność" groovy załatwi nam to że zamieni się to na funkcję (metodę) która zmieni nasze dependendcy w nietranzytywne

Based on cloure definition... for groovy looks not so good to long to say is good
Patrząc na podstawową konstrukcję definicji dependency bez tranzytywności przy pomocy colusure albo setera żadna nie wypada przyjażnie

dependencies {
   runtimeOnly("com.haulmont.cuba:cuba-global:7.2.15") {
      setTransitive(false) }
...

or

dependencies {
   runtimeOnly("com.haulmont.cuba:cuba-global:7.2.15")
      .setTransitive(false)
...

So look at alternative solution with function version...

def noTransitive(def dep) { return dep.setTransitive(false) }
def noTransitive(def dep) { dep.setTransitive(false) }
def noTransitive(def dep) { dep.transitive = false }
def noTransitive(dep) { dep.transitive = false }
def noTransitive = { d -> d.setTransitive(false) }

Next define our dependecy in clasic clousure method ... with transitive version
Zdefiniujmy więc jakieś dependency co tak na oko ze 64 pozycje tranzytywne oczywiście wszystko nam będzie "potrzebne" i "niezbędne" bo nie wypada mieć paczki co waży 20M tylko minimum 200M

dependencies {
   runtimeOnly("com.haulmont.cuba:cuba-global:7.2.15")
...

or without tranisitive
a tak by to wyglądało bez transitive

dependencies {
   noTransitive runtimeOnly("com.haulmont.cuba:cuba-global:7.2.15")
...

wtorek, 4 stycznia 2022

log4j 2.x vs 1.2.x jakość kodu

CVE-2021-44228

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

Z wersji 2.x tylko 2.12.2, 2.12.3 oraz 2.3.1 tego nie miały

Podpierając się wydaniami:
https://logging.apache.org/log4j/1.2/changes-report.html

log4j 2.x chamges

 
log4j 2.x problem start

https://logging.apache.org/log4j/2.x/changes-report.html

log4j 1.x changes

 

policzmy jak ktoś miał pecha 2021 - 2013?? = 8 lat z taka dziurą?

fajnie ze przez 8 lat ktoś na to nie wpadł
i się nawet nad tym nie zastanowił
przecież atak jest jak sql injection

U nas czasem błędy też wychodzą po paru latach...
tu na takim mega projekcie przez 8 nie wyszło?
o co comman?

Ktoś może celowo ma teraz lepsza lukę
i tą postanowił poświecić aby podrzucić lepsza


... ale to już taki durny żart hihi

Tak na marginesie w grudniu koniecznie trzeba było wersje zmienić na 2.15 dziś już trzeba na 2.17 ... oby tylko tą

Wersja 1.2 jest od 2002 do 2012 bez krytycznych problemów. Większość projektów korzysta z rolling file appender i pattern formater - problemy jakie tu były na poziomie appederów socket i jms które większość z nas nie używa....

Tak na marginesie jedyne poważne problemy