Title: Key protection algorithm not found
Type: Severity: normal
Components: Library Versions: Jython 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: jeff.allen, stefan.richthofer
Priority: normal Keywords: Java Roadmap, test failure causes

Created on 2018-10-21.12:59:47 by jeff.allen, last changed 2018-10-26.18:18:36 by jeff.allen.

msg12148 (view) Author: Jeff Allen (jeff.allen) Date: 2018-10-21.12:59:45
In test_ssl I notice that in a couple of places we have disabled tests when running on Java 9 or beyond (in BasicSocketTests.test_errors and ContextTests.test_load_cert_chain). I am experiencing what looks to be the same failure in test_socket_jy (on Java 9) in SSLSocketConnectTest.test_connect_ex_workout .

test_ssl contains the comment:
# Possible FIXME similar issue as seen in
# test_load_cert_chain - apparently this RSA 1024 cert is too weak and gets a
# Key protection  algorithm not found before the
# ValueError raised on earlier versions of Java;
# but we need to confirm this is truly the case on Java 9
(The test is supposed to raise a ValueError but fails creating the socket, I think.)

I'm raising it as an issue here so we do not just forget it. I cannot tell yet whether this is just a problem with the test material or a real problem in use.
msg12149 (view) Author: Stefan Richthofer (stefan.richthofer) Date: 2018-10-21.14:05:34
Is this related to failing Travis CI on OSX?
Currently in Travis CI significantly more tests fail on OSX than on Linux.
On Linux only test_urllib2net fails while on OSX we get:

     [exec] 10 tests failed:
     [exec]     test_codecencodings_tw test_dict test_dict_jy test_import_jy
     [exec]     test_os_jy test_re_jy test_signal test_socket_jy test_ssl
     [exec]     test_unicode_jy

Just asking because the log complains a lot about certs and test_ssl is also failing here.
msg12151 (view) Author: Jeff Allen (jeff.allen) Date: 2018-10-21.16:53:33
I would say so. "platform: java10.0.1" is the clue. The list is the same that I see (or saw) on Java 9. I hadn't noticed we were testing on 9+  *<:(

I have eliminated some of these failures this weekend, and the ugly reflective access warnings (except from jnr.posix). I have a couple more in my sights, then will push as a batch to save possible merges.

Another thing to mention is that the idiom:
    if support.get_java_version() < (1, 9):
will not work reliably, so test_ssl (it appears) is not skipping the problematic code. But this also is fixed on my repo.

Do we intend to test on 10? I think this has happened because we allow it to choose the default Java. It's useful to see, but it will be red for a while. Or rather, given our CI *is* running on versions 9+, we should make it run cleanly by skipping (and raising an issue). I can easily do that, and for a couple of them, fixing them is as quick.
msg12154 (view) Author: Stefan Richthofer (stefan.richthofer) Date: 2018-10-21.19:36:18
Alright, I had overlooked "platform: java10.0.1", just saw OSX platform. Java 9+ is of course an enlightening explanation for the additional failures.
msg12160 (view) Author: Jeff Allen (jeff.allen) Date: 2018-10-26.18:18:35
Skipped on Java 9+ for now in:
Date User Action Args
2018-10-26 18:18:36jeff.allensetmessages: + msg12160
2018-10-21 19:36:18stefan.richthofersetmessages: + msg12154
2018-10-21 16:53:33jeff.allensetmessages: + msg12151
2018-10-21 14:05:35stefan.richthofersetnosy: + stefan.richthofer
messages: + msg12149
2018-10-21 12:59:48jeff.allencreate