Re: [Q] 9.1 amd64 openJDK11 error on certificates
Found a work around for this problem.
I am guessing, that, perhaps, not many people using JDK 11 on NetBSD
9.x. It presents itself any time an HTTPS URL is used.
So gradle, maven, any program that uses network classes that rely on
HTTPS protocol would see this
-- script start --
# ts1000: workaround to fix cacert store for OpenJDK 11 on NetBSD 9.1
# this workaround just reimports existing certificates in
$JAVA_HOME/lib/security/cacerts
# into a JKS format store, and then just replaces the cacerts with the
JKS version
# must be done as root
# also assuming keytool is in the $PATH
# that is: we have export JAVA_HOME=/usr/pkg/java/openjdk11
# and export PATH=${PATH}:${JAVA_HOME}/bin
cd /usr/pkg/java/openjdk11/lib/security
keytool -importkeystore -srckeystore
/usr/pkg/java/openjdk11/lib/security/cacerts-destkeystore
/usr/pkg/java/openjdkmv cacerts cacerts.org
ln -s cacerts.jks cacerts
-- script end --
Similar problem was with Docker. I picked up a solution from there
https://github.com/docker-library/openjdk/pull/263/files
I also updated the gnats issue report with the workaround
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=55758
On 2020-10-24 21:00, ts1000 wrote:
Hello,
I have a java project organized by Gradle.
First thing that gradle does, is it downloads dependencies.
But that first step is not working on netBSD-9.1 amd64
I tried with pkgin, as well as building openjdk11 from source.
Error is the same.
I also installed, with pkgin,
ca-certificates-20200601
mozilla-rootcerts-1.0.20200529nb1
But that did not help. Would appreciate any pointers on where to look
The error I am getting is:
-- begin --
nbsd1$ bash gradlew
Downloading
https://services.gradle.org/distributions/gradle-6.5.1-all.zip
Exception in thread "main" javax.net.ssl.SSLException: Unexpected
error: java.security.InvalidAlgorithmParameterException: the
trustAnchors parameter must be non-empty
at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:326)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at
java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1576)
at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:453)
at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:411)
at
java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
at
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1592)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1520)
at
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:250)
at
org.gradle.wrapper.Download.downloadInternal(Download.java:67)
at org.gradle.wrapper.Download.download(Download.java:52)
at org.gradle.wrapper.Install$1.call(Install.java:62)
at org.gradle.wrapper.Install$1.call(Install.java:48)
at
org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:69)
at org.gradle.wrapper.Install.createDist(Install.java:48)
at
org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:107)
at
org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:62)
Caused by: java.lang.RuntimeException: Unexpected error:
java.security.InvalidAlgorithmParameterException: the trustAnchors
parameter must be non-empty
at
java.base/sun.security.validator.PKIXValidator.(PKIXValidator.java:102)
at
java.base/sun.security.validator.Validator.getInstance(Validator.java:181)
at
java.base/sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:300)
at
java.base/sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(X509TrustManagerImpl.java:176)
at
java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:189)
at
java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
at
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:629)
at
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:464)
at
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:360)
at
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
at
Re: HVM virtualization?
On Nov 1, 10:40, Greg Troxel wrote: } Manuel Bouyer writes: } > On Sat, Oct 31, 2020 at 06:36:45PM -0400, Greg Troxel wrote: } >> Manuel Bouyer writes: } >> > On Sat, Oct 31, 2020 at 01:37:17PM -0500, Jeremy C. Reed wrote: } >> >> One of my hosting providers is converting VPSes from PV to HVM=20 } >> >> virtualization due to security issue } >> >> https://xenbits.xen.org/xsa/advisory-286.html } >> >> } >> >> They say NetBSD does not work under HVM mode and can choose a different } >> >> BSD (or Linux). } >> >> } >> >> Can someone tell me about this? I did look briefly at=20 } >> >> http://wiki.netbsd.org/ports/xen/howto/ but don't understand the context } >> >> of the wiki saying it is supported but the hosting provider saying it } >> >> does not work. } >> > } >> > plain HVM, with emulated devices, works without problems (and always has). } >> > If they only support PV devices, then it works only in HEAD (GENERIC supports } >> > it) } >> } >> I have heard that the issue with with qemu "stub domains" and with } >> those, NetBSD ends up with PIO on disks and is thus unusably slow. } >> } >> https://wiki.xen.org/wiki/QEMU_vs_qemu-traditionnal_Feature_Comparison } > } > So running a HEAD GENERIC, which has the PV drivers, would solve this. } } It would work around it, not solve it, but yes getting to a functional } state is really the goal. I would argue that it solves it. } I realize that's a good workaround, but I also wonder if anyone else has } tried 9-stable GENERIC as HVM with a dom0 that is using stub domains for } qemu. Note that HVM (without qualifiers) is full hardware emulation and thus should be capable of running any OS without modification. If the hypervisor isn't providing full hardware emulation then it either isn't HVM or it is broken. This is not a NetBSD fault. } (It seems obvious that NetBSD dom0s do not use stub domains.) No they do not, but that is neither here nor there. The last time I asked a Xen developer about stub domains, I was told that the code is tightely tied to Linux, and isn't portable. I find Xen's infatuation with Linux to be rather interesting since the Linux seems to be hooked on KVM and isn't that interested in Xen (there is/was interest amongst the large cloud providers, but that seems to be changing). FreeBSD has bHyve. As far as I can tell, NetBSD is one of the largest users of Xen, but unfortunately is behind on modern Xen support. For reference, stub domains are an intermediary between dom0 and domU. They are not strictly needed, but likely offer security enhancement. The issue with emulating hardware in dom0 means that a security bug in the emulator exposes the entire box. But, if you put the hardware emulation in a stub domain, then only that stub domain is exposed. It would appear that what is happening in this case is that the VPS is using stub domains and that stub domains don't do full hardware emulation. Running a newer version of NetBSD that can do PVHVM means that the disk and network drivers talk to the hypervisor to exchange buffers with data instead of performing I/O operations which have to be emulated. }-- End of excerpt from Greg Troxel
Re: HVM virtualization?
On Sun, Nov 01, 2020 at 11:38:07AM -0500, Greg Troxel wrote: > > Manuel Bouyer writes: > > > On Sun, Nov 01, 2020 at 10:40:17AM -0500, Greg Troxel wrote: > >> It would work around it, not solve it, but yes getting to a functional > >> state is really the goal. > > > > Having a dmesg of such a system would help. > > True; will see if I can get that. > > > Maybe the qemu in the stub domain is not built with DMA capabilities ? > > No, this is a case of NetBSD working badly, and many Linux flavors, > FreeBSD, OpenBSD all working fine. All of them have PV drivers out of the box, so they won't use qemu for disks and network. > > >> I realize that's a good workaround, but I also wonder if anyone else has > >> tried 9-stable GENERIC as HVM with a dom0 that is using stub domains for > >> qemu. > >> > >> (It seems obvious that NetBSD dom0s do not use stub domains.) > > > > I tried with xen 4.8 but gave up. It was too fragile. > > Do you mean "gave up with pure HVM", or "pure HVM with stub domains"? pure HVM with stub domains. pure HVM worked fine with 4.8, as it does with 4.11 and 4.13 -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: HVM virtualization?
Manuel Bouyer writes: > On Sun, Nov 01, 2020 at 10:40:17AM -0500, Greg Troxel wrote: >> It would work around it, not solve it, but yes getting to a functional >> state is really the goal. > > Having a dmesg of such a system would help. True; will see if I can get that. > Maybe the qemu in the stub domain is not built with DMA capabilities ? No, this is a case of NetBSD working badly, and many Linux flavors, FreeBSD, OpenBSD all working fine. >> I realize that's a good workaround, but I also wonder if anyone else has >> tried 9-stable GENERIC as HVM with a dom0 that is using stub domains for >> qemu. >> >> (It seems obvious that NetBSD dom0s do not use stub domains.) > > I tried with xen 4.8 but gave up. It was too fragile. Do you mean "gave up with pure HVM", or "pure HVM with stub domains"? signature.asc Description: PGP signature
Re: HVM virtualization?
On Sun, Nov 01, 2020 at 10:40:17AM -0500, Greg Troxel wrote: > It would work around it, not solve it, but yes getting to a functional > state is really the goal. Having a dmesg of such a system would help. Maybe the qemu in the stub domain is not built with DMA capabilities ? > > I realize that's a good workaround, but I also wonder if anyone else has > tried 9-stable GENERIC as HVM with a dom0 that is using stub domains for > qemu. > > (It seems obvious that NetBSD dom0s do not use stub domains.) I tried with xen 4.8 but gave up. It was too fragile. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: HVM virtualization?
Manuel Bouyer writes: > On Sat, Oct 31, 2020 at 06:36:45PM -0400, Greg Troxel wrote: >> >> Manuel Bouyer writes: >> >> > On Sat, Oct 31, 2020 at 01:37:17PM -0500, Jeremy C. Reed wrote: >> >> One of my hosting providers is converting VPSes from PV to HVM >> >> virtualization due to security issue >> >> https://xenbits.xen.org/xsa/advisory-286.html >> >> >> >> They say NetBSD does not work under HVM mode and can choose a different >> >> BSD (or Linux). >> >> >> >> Can someone tell me about this? I did look briefly at >> >> http://wiki.netbsd.org/ports/xen/howto/ but don't understand the context >> >> of the wiki saying it is supported but the hosting provider saying it >> >> does not work. >> > >> > plain HVM, with emulated devices, works without problems (and always has). >> > If they only support PV devices, then it works only in HEAD (GENERIC >> > supports >> > it) >> >> I have heard that the issue with with qemu "stub domains" and with >> those, NetBSD ends up with PIO on disks and is thus unusably slow. >> >> https://wiki.xen.org/wiki/QEMU_vs_qemu-traditionnal_Feature_Comparison > > So running a HEAD GENERIC, which has the PV drivers, would solve this. It would work around it, not solve it, but yes getting to a functional state is really the goal. I realize that's a good workaround, but I also wonder if anyone else has tried 9-stable GENERIC as HVM with a dom0 that is using stub domains for qemu. (It seems obvious that NetBSD dom0s do not use stub domains.) signature.asc Description: PGP signature
Re: HVM virtualization?
On Sat, Oct 31, 2020 at 06:36:45PM -0400, Greg Troxel wrote: > > Manuel Bouyer writes: > > > On Sat, Oct 31, 2020 at 01:37:17PM -0500, Jeremy C. Reed wrote: > >> One of my hosting providers is converting VPSes from PV to HVM > >> virtualization due to security issue > >> https://xenbits.xen.org/xsa/advisory-286.html > >> > >> They say NetBSD does not work under HVM mode and can choose a different > >> BSD (or Linux). > >> > >> Can someone tell me about this? I did look briefly at > >> http://wiki.netbsd.org/ports/xen/howto/ but don't understand the context > >> of the wiki saying it is supported but the hosting provider saying it > >> does not work. > > > > plain HVM, with emulated devices, works without problems (and always has). > > If they only support PV devices, then it works only in HEAD (GENERIC > > supports > > it) > > I have heard that the issue with with qemu "stub domains" and with > those, NetBSD ends up with PIO on disks and is thus unusably slow. > > https://wiki.xen.org/wiki/QEMU_vs_qemu-traditionnal_Feature_Comparison So running a HEAD GENERIC, which has the PV drivers, would solve this. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
