Ten postup komplikovaný není.
To, že vy spouštíte aplikaci z nějakého shell skriptu nebo systemd jednotky neznamená, že se tak spouštějí všechny aplikace na světě. Někdy není úplně snadné do cílové aplikace procpat systémovou vlastnost nebo proměnnou prostředí. Navíc vypínat něco nebezpečného tímhle způsobem je znovu nebezpečné, protože nemáte jistotu, že je to opravdu vypnuté. Nastavíte systémovou vlastnost a máte pocit, že máte vyřešeno – a přitom třeba nemáte vyřešeno nic, stačí hloupý překlep v názvu. A do třetice, jak je vidět na příkladu Log4j 2, ten kód rozhodující se podle té systémové vlastnosti může být zase chybný.
Co když se objeví chyba někde jinde, to budou mít pak uživatelé staré verze smůlu?
Je dost velká pravděpodobnost, že než se objeví chyba jinde, bude tohle vyřešené. V Logbacku už je JNDI zpět, omezené jen na protokol java. Pokud někdo opravdu potřebuje konfigurovat Logback pomocí Groovy, už pravděpodobně řeší, jak to udělat ve své aplikaci.
bez zjevného důvodu, jenom, že si nejsou jistí
Ano, je zjevné, že náš pohled na bezpečnost je zjevně dost odlišný. Já RCE opravované na několik pokusů nepovažuju za něco, nad čím lze mávnout rukou.
Za mě je tohle úplně špatně, ten logovací framework by měl umět naprosté minimum a tohle všechno by mělo být jako pluginy. Chcete zápis do DB, jasně umíme, stačí přidat tenhle plugin. Chceš JNDI, jasně přidej tenhle plugin.
Aspoň na něčem se shodneme.