You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@spark.apache.org by Bharath Bhushan <ma...@outlook.com> on 2014/03/23 13:38:51 UTC
sbt/sbt assembly fails with ssl certificate error
I am facing a weird failure where "sbt/sbt assembly” shows a lot of SSL certificate errors for repo.maven.apache.org. Is anyone else facing the same problems? Any idea why this is happening? Yesterday I was able to successfully run it.
Loading https://repo.maven.apache.org shows an invalid cert chain.
—
Thanks
Re: sbt/sbt assembly fails with ssl certificate error
Posted by Debasish Das <de...@gmail.com>.
After a long time (may be a month) I could do a fresh build for
2.0.0-mr1-cdh4.5.0...I was using the cached files in .ivy2/cache
My case is especially painful since I have to build behind a firewall...
@Sean thanks for the fix...I think we should put a test for https/firewall
compilation as well...
Re: sbt/sbt assembly fails with ssl certificate error
Posted by Bharath Bhushan <ma...@outlook.com>.
I don’t see the errors anymore. Thanks Aaron.
On 24-Mar-2014, at 12:52 am, Aaron Davidson <il...@gmail.com> wrote:
> These errors should be fixed on master with Sean's PR: https://github.com/apache/spark/pull/209
>
> The orbit errors are quite possibly due to using https instead of http, whether or not the SSL cert was bad. Let us know if they go away with reverting to http.
>
>
> On Sun, Mar 23, 2014 at 11:48 AM, Debasish Das <de...@gmail.com> wrote:
> I am getting these weird errors which I have not seen before:
>
> [error] Server access Error: handshake alert: unrecognized_name url=https://repo.maven.apache.org/maven2/org/eclipse/jetty/orbit/javax.servlet/2.5.0.v201103041518/javax.servlet-2.5.0.v201103041518.orbit
> [info] Resolving org.eclipse.jetty.orbit#jetty-orbit;1 ...
> [error] Server access Error: handshake alert: unrecognized_name url=https://repo.maven.apache.org/maven2/org/eclipse/jetty/orbit/javax.transaction/1.1.1.v201105210645/javax.transaction-1.1.1.v201105210645.orbit
> [info] Resolving org.eclipse.jetty.orbit#jetty-orbit;1 ...
> [error] Server access Error: handshake alert: unrecognized_name url=https://repo.maven.apache.org/maven2/org/eclipse/jetty/orbit/javax.mail.glassfish/1.4.1.v201005082020/javax.mail.glassfish-1.4.1.v201005082020.orbit
> [info] Resolving org.eclipse.jetty.orbit#jetty-orbit;1 ...
> [error] Server access Error: handshake alert: unrecognized_name url=https://repo.maven.apache.org/maven2/org/eclipse/jetty/orbit/javax.activation/1.1.0.v201105071233/javax.activation-1.1.0.v201105071233.orbit
>
> Is it also due to the SSL error ?
>
> Thanks.
> Deb
>
>
>
> On Sun, Mar 23, 2014 at 6:08 AM, Sean Owen <so...@cloudera.com> wrote:
> I'm also seeing this. It also was working for me previously AFAIK.
>
> Tthe proximate cause is my well-intentioned change that uses HTTPS to access all artifact repos. The default for Maven Central before would have been HTTP. While it's a good idea to use HTTPS, it may run into complications.
>
> I see:
>
> https://issues.sonatype.org/browse/MVNCENTRAL-377
> https://issues.apache.org/jira/browse/INFRA-7363
>
> ... which suggest that actually this isn't supported, and should return 404.
>
> Then I see:
> http://blog.sonatype.com/2012/10/now-available-ssl-connectivity-to-central/#.Uy7Yuq1_tj4
> ... that suggests you have to pay for HTTPS access to Maven Central?
>
> But, we both seem to have found it working (even after the change above) and it does not return 404 now.
>
> The Maven build works, still, but if you look carefully, it's actually only because it eventually falls back to HTTP for Maven Central artifacts.
>
> So I think the thing to do is simply back off to HTTP for Maven Central only. That's unfortunate because there's a small but non-trivial security issue here in downloading artifacts without security.
>
> Any brighter ideas? I'll open a supplementary PR if so to adjust this.
>
>
>
Re: sbt/sbt assembly fails with ssl certificate error
Posted by Aaron Davidson <il...@gmail.com>.
These errors should be fixed on master with Sean's PR:
https://github.com/apache/spark/pull/209
The orbit errors are quite possibly due to using https instead of http,
whether or not the SSL cert was bad. Let us know if they go away with
reverting to http.
On Sun, Mar 23, 2014 at 11:48 AM, Debasish Das <de...@gmail.com>wrote:
> I am getting these weird errors which I have not seen before:
>
> [error] Server access Error: handshake alert: unrecognized_name url=
> https://repo.maven.apache.org/maven2/org/eclipse/jetty/orbit/javax.servlet/2.5.0.v201103041518/javax.servlet-2.5.0.v201103041518.orbit
> [info] Resolving org.eclipse.jetty.orbit#jetty-orbit;1 ...
> [error] Server access Error: handshake alert: unrecognized_name url=
> https://repo.maven.apache.org/maven2/org/eclipse/jetty/orbit/javax.transaction/1.1.1.v201105210645/javax.transaction-1.1.1.v201105210645.orbit
> [info] Resolving org.eclipse.jetty.orbit#jetty-orbit;1 ...
> [error] Server access Error: handshake alert: unrecognized_name url=
> https://repo.maven.apache.org/maven2/org/eclipse/jetty/orbit/javax.mail.glassfish/1.4.1.v201005082020/javax.mail.glassfish-1.4.1.v201005082020.orbit
> [info] Resolving org.eclipse.jetty.orbit#jetty-orbit;1 ...
> [error] Server access Error: handshake alert: unrecognized_name url=
> https://repo.maven.apache.org/maven2/org/eclipse/jetty/orbit/javax.activation/1.1.0.v201105071233/javax.activation-1.1.0.v201105071233.orbit
>
> Is it also due to the SSL error ?
>
> Thanks.
> Deb
>
>
>
> On Sun, Mar 23, 2014 at 6:08 AM, Sean Owen <so...@cloudera.com> wrote:
>
>> I'm also seeing this. It also was working for me previously AFAIK.
>>
>> Tthe proximate cause is my well-intentioned change that uses HTTPS to
>> access all artifact repos. The default for Maven Central before would have
>> been HTTP. While it's a good idea to use HTTPS, it may run into
>> complications.
>>
>> I see:
>>
>> https://issues.sonatype.org/browse/MVNCENTRAL-377
>> https://issues.apache.org/jira/browse/INFRA-7363
>>
>> ... which suggest that actually this isn't supported, and should return
>> 404.
>>
>> Then I see:
>>
>> http://blog.sonatype.com/2012/10/now-available-ssl-connectivity-to-central/#.Uy7Yuq1_tj4
>> ... that suggests you have to pay for HTTPS access to Maven Central?
>>
>> But, we both seem to have found it working (even after the change above)
>> and it does not return 404 now.
>>
>> The Maven build works, still, but if you look carefully, it's actually
>> only because it eventually falls back to HTTP for Maven Central artifacts.
>>
>> So I think the thing to do is simply back off to HTTP for Maven Central
>> only. That's unfortunate because there's a small but non-trivial security
>> issue here in downloading artifacts without security.
>>
>> Any brighter ideas? I'll open a supplementary PR if so to adjust this.
>>
>>
>
Re: sbt/sbt assembly fails with ssl certificate error
Posted by Debasish Das <de...@gmail.com>.
I am getting these weird errors which I have not seen before:
[error] Server access Error: handshake alert: unrecognized_name url=
https://repo.maven.apache.org/maven2/org/eclipse/jetty/orbit/javax.servlet/2.5.0.v201103041518/javax.servlet-2.5.0.v201103041518.orbit
[info] Resolving org.eclipse.jetty.orbit#jetty-orbit;1 ...
[error] Server access Error: handshake alert: unrecognized_name url=
https://repo.maven.apache.org/maven2/org/eclipse/jetty/orbit/javax.transaction/1.1.1.v201105210645/javax.transaction-1.1.1.v201105210645.orbit
[info] Resolving org.eclipse.jetty.orbit#jetty-orbit;1 ...
[error] Server access Error: handshake alert: unrecognized_name url=
https://repo.maven.apache.org/maven2/org/eclipse/jetty/orbit/javax.mail.glassfish/1.4.1.v201005082020/javax.mail.glassfish-1.4.1.v201005082020.orbit
[info] Resolving org.eclipse.jetty.orbit#jetty-orbit;1 ...
[error] Server access Error: handshake alert: unrecognized_name url=
https://repo.maven.apache.org/maven2/org/eclipse/jetty/orbit/javax.activation/1.1.0.v201105071233/javax.activation-1.1.0.v201105071233.orbit
Is it also due to the SSL error ?
Thanks.
Deb
On Sun, Mar 23, 2014 at 6:08 AM, Sean Owen <so...@cloudera.com> wrote:
> I'm also seeing this. It also was working for me previously AFAIK.
>
> Tthe proximate cause is my well-intentioned change that uses HTTPS to
> access all artifact repos. The default for Maven Central before would have
> been HTTP. While it's a good idea to use HTTPS, it may run into
> complications.
>
> I see:
>
> https://issues.sonatype.org/browse/MVNCENTRAL-377
> https://issues.apache.org/jira/browse/INFRA-7363
>
> ... which suggest that actually this isn't supported, and should return
> 404.
>
> Then I see:
>
> http://blog.sonatype.com/2012/10/now-available-ssl-connectivity-to-central/#.Uy7Yuq1_tj4
> ... that suggests you have to pay for HTTPS access to Maven Central?
>
> But, we both seem to have found it working (even after the change above)
> and it does not return 404 now.
>
> The Maven build works, still, but if you look carefully, it's actually
> only because it eventually falls back to HTTP for Maven Central artifacts.
>
> So I think the thing to do is simply back off to HTTP for Maven Central
> only. That's unfortunate because there's a small but non-trivial security
> issue here in downloading artifacts without security.
>
> Any brighter ideas? I'll open a supplementary PR if so to adjust this.
>
>
Re: sbt/sbt assembly fails with ssl certificate error
Posted by Sean Owen <so...@cloudera.com>.
I'm also seeing this. It also was working for me previously AFAIK.
Tthe proximate cause is my well-intentioned change that uses HTTPS to
access all artifact repos. The default for Maven Central before would have
been HTTP. While it's a good idea to use HTTPS, it may run into
complications.
I see:
https://issues.sonatype.org/browse/MVNCENTRAL-377
https://issues.apache.org/jira/browse/INFRA-7363
... which suggest that actually this isn't supported, and should return
404.
Then I see:
http://blog.sonatype.com/2012/10/now-available-ssl-connectivity-to-central/#.Uy7Yuq1_tj4
... that suggests you have to pay for HTTPS access to Maven Central?
But, we both seem to have found it working (even after the change above)
and it does not return 404 now.
The Maven build works, still, but if you look carefully, it's actually only
because it eventually falls back to HTTP for Maven Central artifacts.
So I think the thing to do is simply back off to HTTP for Maven Central
only. That's unfortunate because there's a small but non-trivial security
issue here in downloading artifacts without security.
Any brighter ideas? I'll open a supplementary PR if so to adjust this.