@zackster We're running into issues with Lucee 5.3.9 due to it's removal of Log4j v1. Since this is a minor version change, therefore shouldn't be breaking, is there a chance it could ship with the Log4j1 bridge configured: https://logging.apache.org/log4j/2.x/manual/migration.html That way any code relying on Log4j1 will still work, but it'll be using v2. (I'm trying to see if there's any way to distribute it as an extension, but it seems like 5.3.9 shouldn't break stuff)

i'll see what micha says, maybe we can offer that as an extension?

@dswitzer To be clear, you're using custom CFML code that creates java classes from Log4j 1.x and uses them?

Yes, but we're also using libraries that rely on v1.

FWIW, the underlying libraries (and their versions) inside the CF engines have never been part of the public API if you will. In other words, Lucee isn't changing how any CFML functions or tags work, so it can change back-end dependencies all it wants

lot's of older java libs use 1.2

Right, so if you have a Java lib that's a custom installation of your own, it's up to you to ensure you have the log4j 1.x dependency met, right?

You can make that argument for sure. However, I suspect many people will think since this is a minor point release that they should be safe to upgrade, where in fact, it could break installs for lots of applications.

Perhaps, but IMO their original mistake was assuming a given java lib/ver would always be on the classpath when that was never a safe assumption

it does have osgi metadata https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-1.2-api/2.17.2

It should be possible to just drop a Log4j 1.x jar in the classpath yourself to fix this, right?

In theory, yes, but for some reason Tomcat wouldn't load after I did this. Not sure what's going on, so I'm just rebuilding my Vagrant environment.

FWIW, the log4j bridge is very simple. I tried to get it working in Lucee a few weeks back and it was terribly limited.

That's good to know. Hopefully I'll find out soon if it'll work for our use case.

Also note, Lucee 5.3.9 will acitvley DELETE Log4j 1.x bundles. I'm not a fan of this and I warned them against it for reasons like yours, but they didn't listen to me. 🤷

I'll be happy once I'm completely migrated off of ACF, so I don't have to work around some of the cross platform issues I'm having to maintain today

yeah, as an extension it won't fly, micha already has PTSD from the whole log4j experience and if it was possible he would have done it

I don't think Lucee will touch any log4j jars just in your tomcat lib

@zackster Does that mean he couldn't get the bridge adapter to work?

I don't think Micha ever tried to get the Log4j bridge to work

he actually did look into it, but it wouldn't fly

Thanks!

Also note, Lucee 5.3.9 will acitvley DELETE Log4j 1.x bundles.

It does what?

Yeah, it was Micha's idea apparently to make it "more secure". I tried to talk them out of that since I know there will be some people out there with log4j 1.x bundles they need for the time being while they update newer libraries. I'm unclear exactly when and how it deletes them, but Zac and Micha have both mentioned it.

So like if Dan (this thread) had Log4J 1.x installed to serve his own needs, then Lucee will just go "nah, fuck you, deleting that"?

If it's in the bundles folder, I believe that to be true. I'm unclear if it's a one-time operation after the upgrade, or every time. I don't really have the details. @zackster would need to help clarify.

yeah, I'm not a fan of this at all, as previously stated https://github.com/lucee/Lucee/commit/1e1d56d9f6251f5c67f82a95f24212d68af0d42f

That code is inside of the

CFMLEngineImpl

constructor, so it seems it would run on every server start.

yep

keep the C level execs happy with their fancy infosec team

IMO, those people can and should • install a fresh Lucee install • manually remove these bundles as documented by Lucee if they know they're not using them

I'm in furious agreement, anyway, if it causes @dswitzer pain, more ammo for me to advocate to strip that out

Well, we need Micha to be convinced, lol and you're the only person with any regular contact with him

In order to placate one group

I also think that's a largely invented group.

They defo exist-- some of them are our clients and they are incredibly vocal. But they are a minority of total users. Most users are thankful for the security improvements, but really don't care that much about "scanning their hard drives" so long as there aren't any actual attack vectors.

Sorry, I specifically meant "keep the C level execs happy with their fancy infosec team". I don't believe there are C-level execs who expect Lucee to handle anything other than the libs it itself is responsible for. If indeed they have a position on Lucee one way or the other at all, on any subject. Nor do I believe they have "fancy" infosec teams (interested in what's fancy about taking security seriously, btw? No, really, don't answer) who would expect this. I rather more think the FITs would just expect Lucee to deal with its stuff, and they'll deal with their own stuff, and any Other Stuff. I think it's just a mishit in thinking on the part of Lucee. (NB: not associating that quote with you, Brad. I know you didn't say it); that's just the "one group" I believe to be fictitious and a back-ported rationale for Lucee to have decided to do something daft).

lot's of "I believe" going on there mate