[
https://issues.apache.org/jira/browse/SOLR-14844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211772#comment-17211772
]
Erick Erickson edited comment on SOLR-14844 at 10/10/20, 7:59 PM:
------------------------------------------------------------------
This is a little weird. BasicHttpSolrClientTest.testCompression has a couple of
clauses like:
{code}
try {
client.query(q);
} catch (BaseHttpSolrClient.RemoteSolrException ignored) {}
assertNotNull(DebugServlet.headers.get("Accept-Encoding"));
{code}
Problem is that master and 8x (with the previous version of Jetty) don't throw
an exception here. I changed the clause to be just
{code}
catch (Exception ignored) {
int breakme = 51;
}
{code}
and stepped through it, the breakme line is never hit.
Master with the new version of Jetty doesn't throw an exception of any kind
either.
However, 8x with the new version of Jetty throws a
SolrServerException/IOException.
I can make the test pass by catching a SolrServerException, but that's just
masking anomalous behavior. Anybody have any clues?
[~samuelgmartinez], [~houstonputman] it looks like you were the last folks to
touch that code, but since no error was thrown anyway I don't think those
changes are relevant, at least in the test. Certainly wouldn't have been caught
in the tests since they only surfaced with the Jetty upgrade.
Why in the world the Jetty upgrade changed this and why only on 8x is a
mystery. I'll dig into whether changes to HttpSolrClient might have some
bearing. Or maybe I'm hallucinating again.
was (Author: erickerickson):
This is a little weird. BasicHttpSolrClientTest.testCompression has a couple of
clauses like:
{code}
try {
client.query(q);
} catch (BaseHttpSolrClient.RemoteSolrException ignored) {}
assertNotNull(DebugServlet.headers.get("Accept-Encoding"));
{code}
Problem is that master and 8x (with the previous version of Jetty) don't throw
an exception here. I changed the clause to be just
{code}
catch (Exception ignored) {
int breakme = 51;
}
and stepped through it, the breakme line is never hit.
Master with the new version of Jetty doesn't throw an exception of any kind
either.
However, 8x with the new version of Jetty throws a
SolrServerException/IOException.
I can make the test pass by catching a SolrServerException, but that's just
masking anomalous behavior. Anybody have any clues?
[~samuelgmartinez], [~houstonputman] it looks like you were the last folks to
touch that code, but since no error was thrown anyway I don't think those
changes are relevant, at least in the test. Certainly wouldn't have been caught
in the tests since they only surfaced with the Jetty upgrade.
Why in the world the Jetty upgrade changed this and why only on 8x is a
mystery. I'll dig into whether changes to HttpSolrClient might have some
bearing. Or maybe I'm hallucinating again.
> 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
>
> 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
