Please create a new release with the log4j patch

[mtrea]

Hi,

We use a compiled release of browserup downloaded from the tags page: https://github.com/browserup/browserup-proxy/tags

Is it possible to build a new release with the urgent log4j fix that was submitted in 11a9d57 ? Thank you!

[chao-xian]

Hi a big ➕ for this as we're trying to build a patched version, but the build is failing on a broken test.

[jamietanna]

It should be possible to manage this yourselves - if you're using any of the pre-built libraries, simply adding the Log4J JARs (2.15.0 or 2.16.0) to the classpath should take priority over the versions as indicated in 2.1.2 of BrowserUp

[ericbeland]

Let us know how this works @jamietanna and chao-xian.

I'm both sad and happy to announce that we are deprecating the BrowserUp Proxy.

We have instead moved over to the BrowserUp fork of the mitmproxy. It is available here The reasons:

• After multiple tries, we could not make the current architecture support websockets and http/2. without a massive rewrite. Http/3 will complicate things even further.

• Mitm Proxy is great

• It has HTTP/2 Support

• It has Websocket Support

• It has amazing maintainers

• Our fork uses OpenAPI to generate Clients in many languages: Java, Ruby, Python, Javascript

• Our fork generates a HAR with websocket traffic included

• Our fork adds traffic verifications (like assertions) against the HAR

[580]

Hi @ericbeland,

Thanks for the information. I'd love to try your mitmproxy fork. I have some questions at the moment:

• Is there a Docker Image available for the server part?
• Does it support to intercept with response content? (I need to search and replace content from HTTPs Response body)

Any help would be appreciated, Thanks again.

[valfirst]

Hi @ericbeland,

Do you have plans to transfer ownership (transfer this repository to another user or to an organization)? Or should the community proceed with one more fork?

Thanks

[ericbeland]

I'm happy to bless a fork if there's someone looking to carry the ball forward in a serious way, or failing that, maintain dependency updates. We can direct others to that fork if they are looking to just stick with this particular proxy for legacy reasons. We can't directly turn over ownership as it has our brand on it and is directly associated to us, so putting the code out of our control isn't possible.

I do plan on taking a look to see if I can make artifacts for this particular issue, but I don't know if my availability aligns with the urgency others may have.

[richardTowers]

Thanks for the clear comms @ericbeland!

For the log4j issue specifically, I've created a release on a fork of 2.1.2 which patches log4j to 2.16.0. I've uploaded the distZip of -dist I built locally:

https://github.com/richardTowers/browserup-proxy/releases/tag/v2.1.2-patch-log4j

We haven't tested this yet, but if people are struggling to find a build to use in the short term, feel free to try that.

Longer term, I imagine we'll switch to mitmproxy or your mitmproxy fork (so not volunteering to take on maintenance).

As always, thank you for all the work you and the other maintainers have put in to this!

[valfirst]

I've created a fork: https://github.com/valfirst/browserup-proxy

@ericbeland I have a couple of questions:

1. are you ok if I keep naming: BrowserUp Proxy? (it refers to your company as I understand)
2. are you ok if I release 2.1.3 under my maven coordinates, but with base package name com.browserup? I'll change the base package name in 3.0.0.

[valfirst]

2.1.3 is released from the fork.

[ericbeland]

@valfirst Yes, you can keep the name on the fork--that's useful so people can find it.