[
https://issues.apache.org/jira/browse/SOLR-14844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17212352#comment-17212352
]
Erick Erickson commented on SOLR-14844:
---------------------------------------
[~samuelgmartinez]
JIRAs can only be assigned to committers, so I'll leave it assigned to me. I
see all the changes that happen here, so I'll be monitoring. When it's ready
I'll commit it.
It's a bit confusing at present because master is built with Gradle and 8x with
ant.
At root, you have to change versions.props for master and
lucene/ivy-versions.properties in 8x. Then there's some magic incantations you
have to do that regenerate checksums and similar that are different in each.
Which shows a lot of file changes for just a few code changes.
I've attached a couple of patches that, absent this problem they are what I
would have committed if it had "just worked". So you should be able to apply
them, then fix whatever you need to. When you're ready, submit a PR or patch
(whichever is more comfortable) and I'll take it from there. That should allow
you to get to the real problem without getting frustrated by all the fiddly
bits.
Do change solr/CHANGES.txt in both versions to give yourself credit for fixing
this. The convention I use for something like this where someone else does the
heavy lifting is: "(Samuel Garcia Martinez via Erick Erickson)". That way you
get credit for the work and I get the blame if something goes wrong ;)
Finally, when switching back and forth between master and 8x there may be cruft
left over that fails precommit. "git clean -dxf" is your friend in those cases,
although that'll also erase your IDE files and you'll have to "ant idea" in 8x
or just open the project in master. Real Soon Now I'll look at worktree to
avoid this... Oh, and on master "gradlew check" sometimes runs out of memory
on my machine, although I haven't heard other's complain so maybe I'm just
lucky. If that happens, you can bump the memory gradle uses in gradle.properties
And thanks!
[^SOLR-14884-8x.patch] [^SOLR-14844-master.patch]
> Upgrade Jetty to 9.4.32.v20200930
> ---------------------------------
>
> Key: SOLR-14844
> URL: https://issues.apache.org/jira/browse/SOLR-14844
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 8.6
> Reporter: Cassandra Targett
> Assignee: Erick Erickson
> Priority: Major
> Attachments: SOLR-14844-master.patch, SOLR-14884-8x.patch
>
>
> A CVE was found in Jetty 9.4.27-9.4.29 that has some security scanning tools
> raising red flags
> ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17638]).
> Here's the Jetty issue:
> [https://bugs.eclipse.org/bugs/show_bug.cgi?id=564984]. It's fixed in
> 9.4.30+, so we should upgrade to that for 8.7
> -It has a simple mitigation (raise Jetty's responseHeaderSize to higher than
> requestHeaderSize), but I don't know how Solr uses Jetty well enough to a)
> know if this problem is even exploitable in Solr, or b) if the workaround
> suggested is even possible in Solr.-
> In normal Solr installs, w/o jetty optimizations, this issue is largely
> mitigated in 8.6.3: see SOLR-14896 (and linked bug fixes) for details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
