ok, so let's try to not create an endless thread: 1. where is the patch needed to fix the desired CVE? - must be compatible with current svn trunk 2. please attach it to a ticket (or multiple if there are multiple fixes) like LOG4J2-3219 3. if it does not get applied and PMC is opposed to get it applied let's create a thread about it as being an issue and look for options but for now the thread is looking for options which are not needed from my window
Hope it helps ot move the ball forward Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 22 déc. 2021 à 06:24, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> a écrit : > Matt>Nobody in the Logging PMC is blocking a release here. > > Matt, thanks for the reply, however, it is false :( > I see you are positive, however, many more replies were quite negative. > > Ralph Goers says: "We’ve stated several times that we don’t think > resurrecting Log4j 1.x permanently is a good idea." > https://lists.apache.org/thread/vz80p3v78xgposon3pcxbnb9729snnxt > > Gary Gregory says: "As I've stated before, IF there is a 1.2.18, it should > ONLY be for CVEs," > https://lists.apache.org/thread/53h130p0kdkspn4kj2hq39vkgpyzgvp7 > > They both are on Logging PMC, and they both have negative opinions on > making progress with v1. > I do not really understand what "ONLY be for CVEs" means (e.g. does it > allow upgrading from Maven2 to Maven3?), > but I do not want to get accidentally blocked by "oh, this change is not > allowed because it is not a CVE fix". > > Matt>What we don’t want is to falsely advertise that v1 is still under > development > > For instance, I do want to support new versions of v1. > If Logging PMC does not want advertise v1, that is fine. Would you donate > log4j 1.x code > to Incubator or to another PMC? > > Matt>if we resurrect v1, then it’ll quickly become impossible to keep up > with all the activity given the size of the PMC > > log4j v1 and log4j v2 are completely different products sharing the same > name. > So it won't be that surprising to have different people working on them. > > Adding PMC members is one of the solutions. Donating the code to another > PMC is another solution. > > I agree you have an unusual traffic spike now, however, multiple members of > Logging PMC do respond regarding v1, > and the overall intention is "Logging PMC is not interested in v1". > > That is not something I want spending time on. > If I want to get v1 CVE fixed, I want to get it done and released. I do not > want to spend my time on "evangelizing v2, v3, or whatever". > > Matt>we’d prefer to see more than one person working on that, > Matt>especially if we want to add more PMC members to oversee v1 in the > first place > > Matt, this case is really unusual. Do you really want *multiple* > individuals to *actively* contribute to log4j v1 > in order to add them to v1 PMC? > That is impossible. There's not much work to do in v1. There's no way I can > improve v1 code in a consistent and non-trivial way. > > You should not be sitting and waiting for new v1 contributions to come. > > So I would say it is not fair to say "there's not enough Logging PMC". > What needs to be done to add PMC members for v1? > > Matt>users who haven’t bothered to upgrade in 10 years will have to end up > paying astronomical costs > > There **is** possibility to maintain COBOL. > Currently, external contributions, including CVE fixes, are literally > blocked. > > Matt>Or were people still using a mix of make or Ant? > > People use Ant a lot, and there are new Ant releases: > https://ant.apache.org/antnews.html > > Vladimir >
