Re: [VOTE] Release Apache MINA SSHD 2.13.1
My +1 Built from source, checked teh ASC signature. All good for me. Thanks Guillaume! On 21/06/2024 01:09, Gary D. Gregory wrote: +1 Built 'mvn clean verify' the from src zip (ASC OK, SHA512 OK) using: Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) Maven home: C:\java\apache-maven-3.9.8 Java version: 17.0.11, vendor: Eclipse Adoptium, runtime: C:\Program Files\Eclipse Adoptium\jdk-17.0.11.9-hotspot Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" Gary On 2024/06/20 20:58:19 Guillaume Nodet wrote: Hey, I've staged a candidate release for an SSHD 2.13.1 release. This release does not contain any code changes, the only commit is to fix the release process. The 2.13.0 has reached central, but it did not contain any source jar. *Given this release does not contain any code change, the vote period will be reduced to 24 hours.* Official staging repo: https://dist.apache.org/repos/dist/dev/mina/sshd/2.13.1/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemina-1095 Git tag: https://github.com/apache/mina-sshd/commits/sshd-2.13.1 Please review and vote ! -- Guillaume Nodet - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Missing source files for SSHD 2.13.0 release
Can't you just cancel the 2.13.1 and redo the exact same release? In any case, your commit is not a code commit, so voting the release can be quickly done (maybe asking for a 24h vote instead of 3days could help). On 19/06/2024 21:55, Guillaume Nodet wrote: During the release, I experienced a problem when trying to close the staging repository. One of the signature was wrong and nexus did not want to close the repository. I ended up bypassing the usual release process (mvn release:perform) and did a manual deploy. Unfortunately, I forgot to build the source jars, so none of the jar has an associated source jar in maven central. The problem should have been fixed by my last commit [1]. I don't think there's a way to deploy just the source jars, so should I cut a 2.13.1 release ? Cheers, Guillaume Nodet [1] https://github.com/apache/mina-sshd/commit/50d1d9fd2f4d21a22f8eb978a2e4f47c1349e5bb -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Mina SSHD 2.13.0
My +1: - checked the signature - checked the N files - built from source One side note: on my new M3 mac, the org.apache.sshd.common.cipher.ArcFourOpenSshTest test never finishes. I will relaunch the tests to be sure, but it works just fine on my old Intel mac. (Java 11 on both computers) Thanks Guillaume! On 12/06/2024 17:53, Guillaume Nodet wrote: I've staged a candidate release for an SSHD 2.13.0 release at: Official staging repo: https://dist.apache.org/repos/dist/dev/mina/sshd/2.13.0/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemina-1093 Git tag: https://github.com/apache/mina-sshd/commits/sshd-2.13.0 Changelog: https://github.com/apache/mina-sshd/blob/sshd-2.13.0/docs/changes/2.13.0.md Remember, if you want to try building with tests, *you need docker to be running on your computer* ! Please review and vote ! -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Test of MINA branch bugfix/DIRMINA-1173
Hi Henrik, the thread dump never made it, it was discarded by the ASF mail server. Could you push it in a place we can pull it? Another option is for you to send it to me privately as an attachement. Thanks ! On 27/02/2024 15:51, Baastrup, Henrik wrote: Hi Jonathan, I have this e-mail address from M.V.S. Kishore which have manage the problem with MINA we have, up till now. I would like to inform you, I have tested the branch in subject and attached the dump (kill -3 ) to this e-mail. As you can see we still have the deadlock. I'm ready to try to help out if I get some indications. Regards, Henrik - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Mina SSHD 2.12.1
Hi Gary, I have Docker 2.25.2 running on my Mac. $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b3cfc446e8f4 testcontainers/ryuk:0.3.3 "/app"23 seconds ago Up 22 seconds 0.0.0.0:60997->8080/tcp testcontainers-ryuk-6366f9f8-f922-41c8-b2b1-3e30dd1e4671 or $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1d69e8b3f633 localhost/testcontainers/tx3g8n6fh63vansg:latest "/usr/sbin/sshd -D -…" 2 seconds agoUp 2 seconds 0.0.0.0:61124->22/tcp quizzical_lederberg b3cfc446e8f4 testcontainers/ryuk:0.3.3 so basically, it works. It sometimes asks me for my KeyChain password. On 10/02/2024 17:42, Gary Gregory wrote: I just updated to DD 4.27.2 (137060), it crashed on the restart and asked me to reset to factory settings, I did, then restarted DD. The UI says "engine running" run 'mvn clean verify" and the 1st reported failure is: [ERROR] Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 0.078 s <<< FAILURE! -- in org.apache.sshd.client.auth.pubkey.HostBoundPubKeyAuthTest [ERROR] org.apache.sshd.client.auth.pubkey.HostBoundPubKeyAuthTest.testPubkeyAuth[user01_rsa_sha2_512_2048] -- Time elapsed: 0.075 s <<< ERROR! java.lang.IllegalStateException: Could not find a valid Docker environment. Please see logs and check configuration at org.testcontainers.dockerclient.DockerClientProviderStrategy.lambda$getFirstValidStrategy$4(DockerClientProviderStrategy.java:156) at java.base/java.util.Optional.orElseThrow(Optional.java:408) at org.testcontainers.dockerclient.DockerClientProviderStrategy.getFirstValidStrategy(DockerClientProviderStrategy.java:148) at org.testcontainers.DockerClientFactory.getOrInitializeStrategy(DockerClientFactory.java:146) at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:188) at org.testcontainers.DockerClientFactory$1.getDockerClient(DockerClientFactory.java:101) at com.github.dockerjava.api.DockerClientDelegate.authConfig(DockerClientDelegate.java:107) at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:316) at org.testcontainers.containers.GenericContainer.starting(GenericContainer.java:1066) at org.testcontainers.containers.FailureDetectingExternalResource$1.evaluate(FailureDetectingExternalResource.java:29) I must be missing some requirements. The 'docker' app is not on my PATH. Is it on yours? Can you say 'docker ps' for example? Gary On Sat, Feb 10, 2024 at 11:32 AM Gary Gregory wrote: Hi Emmanuel: Yes: Docker Desktop 4.27.1 (136059) Gary On Sat, Feb 10, 2024 at 11:25 AM Emmanuel Lécharny wrote: Hi Gary, I had it working on my Mac, have you docker running before launching the test? On 10/02/2024 04:10, Gary Gregory wrote: Testing src zip file. - ASC OK - Eyeballing SHA512 is OK but can't be checked with "shasum --check apache-sshd-2.12.1-src.zip.sha512" - On macOS, with Docker running, the tests can't find it or download an image, if that's what it is trying to do: [ERROR] Errors: [ERROR] org.apache.sshd.client.auth.pubkey.HostBoundPubKeyAuthTest.testPubkeyAuth[user01_ecdsa_256] [ERROR] Run 1: HostBoundPubKeyAuthTest.testPubkeyAuth[user01_ecdsa_256] » IllegalState Previous attempts to find a Docker environment failed. Will not retry. Please see logs and check configuration This is with both Java 17 and 11. Any ideas? Gary On Tue, Feb 6, 2024 at 10:35 AM Guillaume Nodet wrote: I've staged a candidate release for an SSHD bug fix 2.12.1 release at: Official staging repo: https://dist.apache.org/repos/dist/dev/mina/sshd/2.12.1/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemina-1091 Git tag: https://github.com/apache/mina-sshd/commits/sshd-2.12.1 Changelog: https://github.com/apache/mina-sshd/blob/sshd-2.12.1/docs/changes/2.12.1.md Please review and vote ! -- Guillaume Nodet - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Mina SSHD 2.12.1
Hi Gary, I had it working on my Mac, have you docker running before launching the test? On 10/02/2024 04:10, Gary Gregory wrote: Testing src zip file. - ASC OK - Eyeballing SHA512 is OK but can't be checked with "shasum --check apache-sshd-2.12.1-src.zip.sha512" - On macOS, with Docker running, the tests can't find it or download an image, if that's what it is trying to do: [ERROR] Errors: [ERROR] org.apache.sshd.client.auth.pubkey.HostBoundPubKeyAuthTest.testPubkeyAuth[user01_ecdsa_256] [ERROR] Run 1: HostBoundPubKeyAuthTest.testPubkeyAuth[user01_ecdsa_256] » IllegalState Previous attempts to find a Docker environment failed. Will not retry. Please see logs and check configuration This is with both Java 17 and 11. Any ideas? Gary On Tue, Feb 6, 2024 at 10:35 AM Guillaume Nodet wrote: I've staged a candidate release for an SSHD bug fix 2.12.1 release at: Official staging repo: https://dist.apache.org/repos/dist/dev/mina/sshd/2.12.1/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemina-1091 Git tag: https://github.com/apache/mina-sshd/commits/sshd-2.12.1 Changelog: https://github.com/apache/mina-sshd/blob/sshd-2.12.1/docs/changes/2.12.1.md Please review and vote ! -- Guillaume Nodet - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: 2.2.X unit tests failing
Most certainly a failure in state-machine, the only place where we use the cglib dependency: [INFO] -< org.apache.mina:mina-statemachine >-- [INFO] Building Apache MINA State Machine 2.2.4-SNAPSHOT [5/12] [INFO] ---[ bundle ]--- [INFO] [INFO] --- maven-dependency-plugin:3.6.0:tree (default-cli) @ mina-statemachine --- [INFO] org.apache.mina:mina-statemachine:bundle:2.2.4-SNAPSHOT [INFO] +- org.apache.mina:mina-core:bundle:2.2.4-SNAPSHOT:compile [INFO] +- com.agical.rmock:rmock:jar:2.0.2:test [INFO] | \- cglib:cglib-nodep:jar:2.1_2:test Looking at it... On 10/02/2024 16:05, Jonathan Valliere wrote: Could not initialize class net.sf.cglib.proxy.Enhancer -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Mina SSHD 2.12.1
Hi, built from the distribution: - once docker is launched, - and Java 11 used got it to work. The README stipulate that Java 8+ is required, the tests are faiking with Java 8. There are a lot of files in sshd-sources and docs that have no AL.2.0 headers, so rat is failing when ran. On 06/02/2024 16:34, Guillaume Nodet wrote: I've staged a candidate release for an SSHD bug fix 2.12.1 release at: Official staging repo: https://dist.apache.org/repos/dist/dev/mina/sshd/2.12.1/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemina-1091 Git tag: https://github.com/apache/mina-sshd/commits/sshd-2.12.1 Changelog: https://github.com/apache/mina-sshd/blob/sshd-2.12.1/docs/changes/2.12.1.md Please review and vote ! -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Mina SSHD 2.12.0
Hi Guillaume! sorry for having missed this vote... I just got discharged from the hospital, and had to catch up with day job. I'll be more cautious next time! On 12/01/2024 14:14, Guillaume Nodet wrote: I've staged a candidate release for 2.12.0 at: Official staging repo: https://dist.apache.org/repos/dist/dev/mina/sshd/2.12.0/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemina-1090 Git tag: https://github.com/apache/mina-sshd/commits/sshd-2.12.0 Changelog: https://github.com/apache/mina-sshd/blob/sshd-2.12.0/docs/changes/2.12.0.md Please review and vote ! -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Personal Feedback to your last board report
Hi Christofer, I presule you aere referring to Result, was: [VOTE] Apache MINA 2.2.3, 2.1.8 and 2.0.25 releases ? I have added the number of binding votes, and alas, this time, I forgot to mention who voted, something I usually do... Please let me know, and in any case, we will try to not forget to mention the voters' name! Thanks for your feedback! On 21/10/2023 16:27, Christofer Dutz wrote: Hi all, while reviewing your projects as part of me reviewing your last bord report, I noticed that the last vote seems to have slightly gone off the rails. For me it was hard to see who voted and how many people voted how. Maybe taking discussions to a parallel [DISCUSS] thread could help keep things clean in the vote thread? In the future, could you please post a “[RESULT][VOTE]” email? I hope the project was able to resolve the disagreements. Thanks, Chris -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [ANNOUNCE] Apache MINA SSHD 2.11.0 released
Great !! FTR, I announced the releases on Mastodon: https://fosstodon.org/@apachemina On 20/10/2023 11:48, Guillaume Nodet wrote: This new minor release provides a bunch of bug enhancements and bug fixes, see the details at: https://github.com/apache/mina-sshd/releases/tag/sshd-2.11.0 -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Apache Mina SSHD 2.9.3
Guillaume, Thomas, thanks for the feedback. Here, I think we are at a crossroad: - some of the tests are pure unit tests (and generally don't require TC) - some other tests are integration tests (and may require some more environment, which may mean TC) I understand the need of having to check that SSHd is working in different envs, I have the exact same issue at ApacheDS, where I need to generate packages for Windows, MacOS, Linux (debian and RH). I can't do that anymore on my mac, due to the deprecation fo some of the tools by Apple. Bottom line, I had two possibilities: - using a Docker image locally to generate those packages - or leaving the burden to the CI (my current choice) What bothers me is that the default tests are now taking 25+ minute son my CoreI9 pretty fast machine, when it was just eating 5 mins more or less a few releases back. Not that I'm running those tests frequently - I just do my duty as a PMC member when a release is called for (and as a side note, I wish all the PMC members do the same for the other MINA projects ;-) - but I'm afraid that with such long tests, committers will start committing before having ran tests. In any case, it's not my decision to make, and I'm just offering my perception. Maybe it would be a valid option, as suggested by Guillaume, to split the tests into 2 categories, as explained at the top of my response, and having the integration ran by the CI only, unless specifically asked for through a profile or a parameter (like a -DintegrationTests for instance) Your call, really. I can perfectly live with the current tests requiring TC, I have Docker installed on my machine. Maybe document this requirement somwehere could be a good option too (a BUILD_README.txt for instance?) Anyway, thanks, and congrats for the release :-) ! On 17/10/2023 08:03, Guillaume Nodet wrote: Le lun. 16 oct. 2023 à 22:02, Thomas Wolf a écrit : On 16.10.23 01:04 , Emmanuel Lécharny wrote: My main concern is that we now need to install Docker to get the test passing, due to the usage of TestContainer. I don't really like it, the build should be self-supported. The use of TestContainers isn't new. Add to that it took 25mins to ran the tests. TC is clearly slowing down the whole tests (it takes around 10 s to start a new container): [INFO] Apache Mina SSHD :: Common support utilits . SUCCESS [01:30 min] ... [INFO] Apache Mina SSHD :: Core ... SUCCESS [08:37 min] [INFO] Apache Mina SSHD :: Mina ... SUCCESS [03:41 min] [INFO] Apache Mina SSHD :: Netty .. SUCCESS [02:56 min] ... [INFO] Apache Mina SSHD :: SFTP ... SUCCESS [04:27 min] [INFO] Frankly, I'm not a fan... Do you know of a better and faster way of testing against different versions of real OpenSSH (running on different OSes)? Some of the tests even capture the OpenSSH debug logging and verify that it indicates certain conditions. I'm not sure there are other ways. However, we could split tests between unit tests and integration tests (if needed) and across different profiles. Some profiles could only be activated by default in CI. Cheers, Thomas - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Apache Mina SSHD 2.9.3
Hi, My +1. I've tje sameremarks thah for the other SSHD vote. Th nks ! ! On 14/10/2023 16:10, Gary D. Gregory wrote: Hi again: I should add that there is no way that I can tell if we've broken binary compatibility (or source compatibility) since there is no use of japicmp (or revapi or ...) Gary On 2023/10/14 14:04:07 "Gary D. Gregory" wrote: Hi All: +1 Lots of comments on this one; I am reviewing the src zip file: - ASC OK - Can't validate SHA file with: shasum --check apache-sshd-2.9.3-src.zip.sha512 This is due to non-standard format for the file. Eyeballing the file looks OK when compared to shasum -a 512 output. - IMO, the VOTE email should include a link to the KEYS file. The KEYS file is not even listed on https://mina.apache.org/sshd-project/downloads.html I had to go hunt for it: https://dist.apache.org/repos/dist/release/mina/KEYS - Non-Blocker: Can't we just have SHA-512, instead of both SHA-512 and SHA-256? - mvn apache-rat:check OK - mvn clean install OK (but...) - Tests fail unless you have admin rights, this should be documented in the README IMO: [ERROR] Errors: [ERROR] org.apache.sshd.common.util.io.IoUtilsTest.testCheckExists [ERROR] Run 1: IoUtilsTest.testCheckExists:74->testCheckExists:91 » FileSystem C:\Users\ggregory\Downloads\apache-sshd-2.9.3\sshd-common\target\IoUtilsTest\folder1\folder2\link: A required privilege is not held by the client [ERROR] Run 2: IoUtilsTest.testCheckExists:74->testCheckExists:91 » FileSystem C:\Users\ggregory\Downloads\apache-sshd-2.9.3\sshd-common\target\IoUtilsTest\folder1\folder2\link: A required privilege is not held by the client [ERROR] Run 3: IoUtilsTest.testCheckExists:74->testCheckExists:91 » FileSystem C:\Users\ggregory\Downloads\apache-sshd-2.9.3\sshd-common\target\IoUtilsTest\folder1\folder2\link: A required privilege is not held by the client - Tests fail randomly because they do not use ephemeral ports. IOW, don't hardwire server socket ports in tests. The tests should report which port is in error, whether or not ephemeral ports are in use. In this case, I had to hunt down what was using port 8080 on my machine and temporarily stop that service. [INFO] [INFO] Results: [INFO] [ERROR] Errors: [ERROR] org.apache.sshd.common.forward.PortForwardingTest.testLocalBindingOnDifferentInterfaces [ERROR] Run 1: PortForwardingTest.testLocalBindingOnDifferentInterfaces:814 » Bind Address already in use: bind [ERROR] Run 2: PortForwardingTest.testLocalBindingOnDifferentInterfaces:814 » Bind Address already in use: bind [ERROR] Run 3: PortForwardingTest.testLocalBindingOnDifferentInterfaces:814 » Bind Address already in use: bind [INFO] [INFO] [ERROR] Tests run: 556, Failures: 0, Errors: 1, Skipped: 8 - Using: Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) Maven home: C:\java\apache-maven-3.9.5 Java version: 17.0.8, vendor: Eclipse Adoptium, runtime: C:\Program Files\Eclipse Adoptium\jdk-17.0.8.7-hotspot Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" Gary On 2023/10/12 14:33:21 Guillaume Nodet wrote: I've staged a candidate release for 2.9.3 at: Official staging repo: https://dist.apache.org/repos/dist/dev/mina/sshd/2.9.3/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemina-1088 Git tag: https://github.com/apache/mina-sshd/commits/sshd-2.9.3 Changelog: https://github.com/apache/mina-sshd/blob/sshd-2.9.3/docs/changes/2.9.3.md Please review and vote ! -- Guillaume Nodet - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Apache Mina SSHD 2.9.3
Hi! My +1. - Checked the signature - Built with Java 8 - test passed green when I installed Docker My main concern is that we now need to install Docker to get the test passing, due to the usage of TestContainer. I don't really like it, the build should be self-supported. Add to that it took 25mins to ran the tests. TC is clearly slowing down the whole tests (it takes around 10 s to start a new container): [INFO] Apache Mina SSHD :: Common support utilits . SUCCESS [01:30 min] ... [INFO] Apache Mina SSHD :: Core ... SUCCESS [08:37 min] [INFO] Apache Mina SSHD :: Mina ... SUCCESS [03:41 min] [INFO] Apache Mina SSHD :: Netty .. SUCCESS [02:56 min] ... [INFO] Apache Mina SSHD :: SFTP ... SUCCESS [04:27 min] [INFO] Frankly, I'm not a fan... On 14/10/2023 16:04, Gary D. Gregory wrote: Hi All: +1 Lots of comments on this one; I am reviewing the src zip file: - ASC OK - Can't validate SHA file with: shasum --check apache-sshd-2.9.3-src.zip.sha512 This is due to non-standard format for the file. Eyeballing the file looks OK when compared to shasum -a 512 output. - IMO, the VOTE email should include a link to the KEYS file. The KEYS file is not even listed on https://mina.apache.org/sshd-project/downloads.html I had to go hunt for it: https://dist.apache.org/repos/dist/release/mina/KEYS - Non-Blocker: Can't we just have SHA-512, instead of both SHA-512 and SHA-256? - mvn apache-rat:check OK - mvn clean install OK (but...) - Tests fail unless you have admin rights, this should be documented in the README IMO: [ERROR] Errors: [ERROR] org.apache.sshd.common.util.io.IoUtilsTest.testCheckExists [ERROR] Run 1: IoUtilsTest.testCheckExists:74->testCheckExists:91 » FileSystem C:\Users\ggregory\Downloads\apache-sshd-2.9.3\sshd-common\target\IoUtilsTest\folder1\folder2\link: A required privilege is not held by the client [ERROR] Run 2: IoUtilsTest.testCheckExists:74->testCheckExists:91 » FileSystem C:\Users\ggregory\Downloads\apache-sshd-2.9.3\sshd-common\target\IoUtilsTest\folder1\folder2\link: A required privilege is not held by the client [ERROR] Run 3: IoUtilsTest.testCheckExists:74->testCheckExists:91 » FileSystem C:\Users\ggregory\Downloads\apache-sshd-2.9.3\sshd-common\target\IoUtilsTest\folder1\folder2\link: A required privilege is not held by the client - Tests fail randomly because they do not use ephemeral ports. IOW, don't hardwire server socket ports in tests. The tests should report which port is in error, whether or not ephemeral ports are in use. In this case, I had to hunt down what was using port 8080 on my machine and temporarily stop that service. [INFO] [INFO] Results: [INFO] [ERROR] Errors: [ERROR] org.apache.sshd.common.forward.PortForwardingTest.testLocalBindingOnDifferentInterfaces [ERROR] Run 1: PortForwardingTest.testLocalBindingOnDifferentInterfaces:814 » Bind Address already in use: bind [ERROR] Run 2: PortForwardingTest.testLocalBindingOnDifferentInterfaces:814 » Bind Address already in use: bind [ERROR] Run 3: PortForwardingTest.testLocalBindingOnDifferentInterfaces:814 » Bind Address already in use: bind [INFO] [INFO] [ERROR] Tests run: 556, Failures: 0, Errors: 1, Skipped: 8 - Using: Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) Maven home: C:\java\apache-maven-3.9.5 Java version: 17.0.8, vendor: Eclipse Adoptium, runtime: C:\Program Files\Eclipse Adoptium\jdk-17.0.8.7-hotspot Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" Gary On 2023/10/12 14:33:21 Guillaume Nodet wrote: I've staged a candidate release for 2.9.3 at: Official staging repo: https://dist.apache.org/repos/dist/dev/mina/sshd/2.9.3/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemina-1088 Git tag: https://github.com/apache/mina-sshd/commits/sshd-2.9.3 Changelog: https://github.com/apache/mina-sshd/blob/sshd-2.9.3/docs/changes/2.9.3.md Please review and vote ! -- Guillaume Nodet - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: License and Notice files
And done on the 3 versions we maintain! On 14/09/2023 10:27, Emmanuel Lécharny wrote: Hi! I did a thorough check on the required N files. I found that a couple of them needed to be updated because of a copyright changed date (the Copyright (c) 2004- part where wasn't up to date). I also removed the ognl license as it's now an Apache project and it has a AL 2.0 license. So no big deal. I will do the same for the 2.0.X and 2.1.X branches. Thanks ! -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
License and Notice files
Hi! I did a thorough check on the required N files. I found that a couple of them needed to be updated because of a copyright changed date (the Copyright (c) 2004- part where wasn't up to date). I also removed the ognl license as it's now an Apache project and it has a AL 2.0 license. So no big deal. I will do the same for the 2.0.X and 2.1.X branches. Thanks ! -- *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 elecha...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Apache MINA 2.2.3, 2.1.8 and 2.0.25 releases
Cutting the drama off, I think an explaination on what a release mean is
important.
Because this is what we do at The ASF: we release softwares that is to
be trusted by the world. And that requires some due diligenc:
"After such a vote, it is a formal offering of the ASF, backed by the
full faith and credit" of the Foundation."
To clarify for devs/users who are not PMC members:
The process is heavy for PMC members. A binding +1 vote is not a mere
appreciation of the release ('yeah! a new version!'), but a validation
that it has been properly baked.
For those interested in the process, here are few valuable links:
* https://www.apache.org/legal/release-policy.html
* https://infra.apache.org/release-publishing.html
* https://www.apache.org/legal/release-policy.html
Being heavy, it's likely we may drop some balls from time to time (not
intentionally), and this process is evolving, so we need to keep us
updated. This is never a finished work!
And please, don't shoot the messenger ;-)
Last, not least, I have to thanks *all* the voters (and all the people
involved in this project), not only the PMC members, but also the
committers and users: you are helping us going on! This is a community
effort, and it's good to know that 17 years after having been promoted a
Top Level Projet, MINA is still kicking !
On 13/09/2023 01:50, jgenen...@apache.org wrote:
Ok… say… answer coming off list… too much drama for dev@.
Jeff
On Sep 12, 2023, at 5:20 PM, Emmanuel Lécharny wrote:
Hi!
Not sure it's about validating how others are validating a release...
Now, I'd like to remind every PMC members that in order to issue a +1, the
following things has to be completed per [1]:
"Before casting +1 binding votes, individuals are REQUIRED to download all signed
source code packages onto their own hardware, verify that they meet all requirements of
ASF policy on releases as described below, validate all cryptographic signatures, compile
as provided, and test the result on their own platform."
Sure thing, it's a bit of work when 3 releases have been issued, and may be we
should start three votes (especially of the required Java version is different
for the voted releases, but this is not the case here).
FTR, when I vote a release (typically the lastest sshd release), here is what I
do:
- I get the source package, check the sign and compile it, running the tests
- I also grab the git tag, compile it, and run the tests (the only difference
is that I don't check the sig here)
Concerning the L files, I check they are present. However, we are dealing
with mature project, and most of the releases are bug fix releases. From time to
time, I check that all the required notices are present, and that we aren't missing
any third party dependency.
The rat plugin protect us from releasing a file that does not contain the
required header.
All in all, it's a pretty dull work, that takes me an hour per release.
I do think we need to automatize it at some point, and most certainly have to
document the process - ideally speaking, we should add the process as an
attached text in the release vote mail.
Please feel free to comment, if you think I'm missing something !
Emmanuel
[1] https://www.apache.org/legal/release-policy.html#release-approval
On 13/09/2023 00:19, Gary Gregory wrote:
I don't understand what Windows has to do with my question.
What did you do to validate the release candidate before voting +1?
Gary
On Tue, Sep 12, 2023, 4:11 PM mailto:jgenen...@apache.org>> wrote:
I don’t use Windows.
Jeff
> On Sep 12, 2023, at 10:11 AM, Gary Gregory
mailto:garydgreg...@gmail.com>> wrote:
>
> You don't remember if you downloaded, built and reviewed all
three src or
> tar files? Are you voting without reviewing?
>
> Gary
>
>
> On Tue, Sep 12, 2023, 9:55 AM mailto:jgenen...@apache.org>> wrote:
>
>> I don’t remember if I voted because I have been voting on a lot
of stuff
>> lately.
>>
>> If I didn’t here is my +1 for all 3.
>>
>> Jeff
>>
>>> On Sep 12, 2023, at 2:29 AM, Emmanuel Lécharny
mailto:elecha...@gmail.com>>
>> wrote:
>>>
>>> Thanks Jeff & Gary.
>>>
>>> Is that for all the MINA versions?
>>>
>>> On 11/09/2023 16:27, Gary D. Gregory wrote:
>>>> I can confirm a failure on Java 17 and Windows:
>>>> [INFO] ---
>>>> [INFO] T E S T S
>>>> [INFO] ---
>>>> [INFO] Running org.apache.mina.core.buffer.IoBufferHexDumperTest
>>>> [INFO] Tests run: 2,
Re: [VOTE] Apache MINA 2.2.3, 2.1.8 and 2.0.25 releases
Hi! Not sure it's about validating how others are validating a release... Now, I'd like to remind every PMC members that in order to issue a +1, the following things has to be completed per [1]: "Before casting +1 binding votes, individuals are REQUIRED to download all signed source code packages onto their own hardware, verify that they meet all requirements of ASF policy on releases as described below, validate all cryptographic signatures, compile as provided, and test the result on their own platform." Sure thing, it's a bit of work when 3 releases have been issued, and may be we should start three votes (especially of the required Java version is different for the voted releases, but this is not the case here). FTR, when I vote a release (typically the lastest sshd release), here is what I do: - I get the source package, check the sign and compile it, running the tests - I also grab the git tag, compile it, and run the tests (the only difference is that I don't check the sig here) Concerning the L files, I check they are present. However, we are dealing with mature project, and most of the releases are bug fix releases. From time to time, I check that all the required notices are present, and that we aren't missing any third party dependency. The rat plugin protect us from releasing a file that does not contain the required header. All in all, it's a pretty dull work, that takes me an hour per release. I do think we need to automatize it at some point, and most certainly have to document the process - ideally speaking, we should add the process as an attached text in the release vote mail. Please feel free to comment, if you think I'm missing something ! Emmanuel [1] https://www.apache.org/legal/release-policy.html#release-approval On 13/09/2023 00:19, Gary Gregory wrote: I don't understand what Windows has to do with my question. What did you do to validate the release candidate before voting +1? Gary On Tue, Sep 12, 2023, 4:11 PM <mailto:jgenen...@apache.org>> wrote: I don’t use Windows. Jeff > On Sep 12, 2023, at 10:11 AM, Gary Gregory mailto:garydgreg...@gmail.com>> wrote: > > You don't remember if you downloaded, built and reviewed all three src or > tar files? Are you voting without reviewing? > > Gary > > > On Tue, Sep 12, 2023, 9:55 AM mailto:jgenen...@apache.org>> wrote: > >> I don’t remember if I voted because I have been voting on a lot of stuff >> lately. >> >> If I didn’t here is my +1 for all 3. >> >> Jeff >> >>> On Sep 12, 2023, at 2:29 AM, Emmanuel Lécharny mailto:elecha...@gmail.com>> >> wrote: >>> >>> Thanks Jeff & Gary. >>> >>> Is that for all the MINA versions? >>> >>> On 11/09/2023 16:27, Gary D. Gregory wrote: >>>> I can confirm a failure on Java 17 and Windows: >>>> [INFO] --- >>>> [INFO] T E S T S >>>> [INFO] --- >>>> [INFO] Running org.apache.mina.core.buffer.IoBufferHexDumperTest >>>> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: >> 0.060 s -- in org.apache.mina.core.buffer.IoBufferHexDumperTest >>>> [INFO] Running org.apache.mina.core.buffer.IoBufferTest >>>> [ERROR] Tests run: 47, Failures: 0, Errors: 1, Skipped: 0, Time >> elapsed: 0.404 s <<< FAILURE! -- in org.apache.mina.core.buffer.IoBufferTest >>>> [ERROR] org.apache.mina.core.buffer.IoBufferTest.testReadOnlyBuffer -- >> Time elapsed: 0.005 s <<< ERROR! >>>> java.nio.charset.CoderMalfunctionError: java.nio.ReadOnlyBufferException >>>> at >> java.base/java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:587) >>>> at >> org.apache.mina.core.buffer.AbstractIoBuffer.putString(AbstractIoBuffer.java:1798) >>>> at >> org.apache.mina.core.buffer.IoBufferTest.testReadOnlyBuffer(IoBufferTest.java:1104) >>>> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >>>> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) >>>> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc
Re: [VOTE] Apache MINA 2.2.3, 2.1.8 and 2.0.25 releases
is a vote for a triple release: * MINA 2.2.3 * MINA 2.1.8 * MINA 2.0.25 Those versions are fixing a Datagram session bug: DIRMINA-996:IoSessionRecycler RemoteAddress Collision DIRMINA-1172:Multiple DatagramAcceptors and the creation of a session object Temporary tags have been created (they can be removed if the vote is not approved) : * MINA 2.2.3: https://github.com/apache/mina/commit/906884d52990b4fce119c462791abf1a5b577a83 * MINA 2.1.8: https://github.com/apache/mina/commit/c7f164cbeecedb4a4e32ba798e7cf435acdc471a * MINA 2.0.25: https://github.com/apache/mina/commit/38ca5a9eb01461a7212b3904ff5010d0364d2f41 The final artifacts are stored in a staging repository: * MINA 2.2.3: https://repository.apache.org/content/repositories/orgapachemina-1086 * MINA 2.1.8: https://repository.apache.org/content/repositories/orgapachemina-1085 * MINA 2.0.25: https://repository.apache.org/content/repositories/orgapachemina-1087 The distributions are available for download on : * MINA 2.2.3: https://dist.apache.org/repos/dist/dev/mina/mina/2.2.3 * MINA 2.1.8: https://dist.apache.org/repos/dist/dev/mina/mina/2.1.8 * MINA 2.0.25: https://dist.apache.org/repos/dist/dev/mina/mina/2.0.25 Let us vote : [ ] +1 | Release MINA 2.2.3 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.2.3 [ ] +1 | Release MINA 2.1.8 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.1.8 [ ] +1 | Release MINA 2.0.25 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.0.25 -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- Guillaume Nodet -- "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Apache MINA 2.2.3, 2.1.8 and 2.0.25 releases
eation of a session object Temporary tags have been created (they can be removed if the vote is not approved) : * MINA 2.2.3: https://github.com/apache/mina/commit/906884d52990b4fce119c462791abf1a5b577a83 * MINA 2.1.8: https://github.com/apache/mina/commit/c7f164cbeecedb4a4e32ba798e7cf435acdc471a * MINA 2.0.25: https://github.com/apache/mina/commit/38ca5a9eb01461a7212b3904ff5010d0364d2f41 The final artifacts are stored in a staging repository: * MINA 2.2.3: https://repository.apache.org/content/repositories/orgapachemina-1086 * MINA 2.1.8: https://repository.apache.org/content/repositories/orgapachemina-1085 * MINA 2.0.25: https://repository.apache.org/content/repositories/orgapachemina-1087 The distributions are available for download on : * MINA 2.2.3: https://dist.apache.org/repos/dist/dev/mina/mina/2.2.3 * MINA 2.1.8: https://dist.apache.org/repos/dist/dev/mina/mina/2.1.8 * MINA 2.0.25: https://dist.apache.org/repos/dist/dev/mina/mina/2.0.25 Let us vote : [ ] +1 | Release MINA 2.2.3 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.2.3 [ ] +1 | Release MINA 2.1.8 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.1.8 [ ] +1 | Release MINA 2.0.25 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.0.25 -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- Guillaume Nodet -- "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Result, was: [VOTE] Apache MINA 2.2.3, 2.1.8 and 2.0.25 releases
Hi! I'm closing this vote with 4 bidning +1 votes and 2 non binding +1. I'll push the packages and annoiunce the releases in the coming hours. Many thanks ! On 11/09/2023 09:42, Jeff MAURY wrote: +1. 2 remarks: - Does not build with Java 17 - Build is failing on Windows On Mon, Sep 11, 2023 at 8:11 AM Guillaume Nodet wrote: +1 Le jeu. 7 sept. 2023 à 05:30, Emmanuel Lecharny a écrit : hi! WARNING: there are 3 votes to cast! This is a vote for a triple release: * MINA 2.2.3 * MINA 2.1.8 * MINA 2.0.25 Those versions are fixing a Datagram session bug: DIRMINA-996:IoSessionRecycler RemoteAddress Collision DIRMINA-1172:Multiple DatagramAcceptors and the creation of a session object Temporary tags have been created (they can be removed if the vote is not approved) : * MINA 2.2.3: https://github.com/apache/mina/commit/906884d52990b4fce119c462791abf1a5b577a83 * MINA 2.1.8: https://github.com/apache/mina/commit/c7f164cbeecedb4a4e32ba798e7cf435acdc471a * MINA 2.0.25: https://github.com/apache/mina/commit/38ca5a9eb01461a7212b3904ff5010d0364d2f41 The final artifacts are stored in a staging repository: * MINA 2.2.3: https://repository.apache.org/content/repositories/orgapachemina-1086 * MINA 2.1.8: https://repository.apache.org/content/repositories/orgapachemina-1085 * MINA 2.0.25: https://repository.apache.org/content/repositories/orgapachemina-1087 The distributions are available for download on : * MINA 2.2.3: https://dist.apache.org/repos/dist/dev/mina/mina/2.2.3 * MINA 2.1.8: https://dist.apache.org/repos/dist/dev/mina/mina/2.1.8 * MINA 2.0.25: https://dist.apache.org/repos/dist/dev/mina/mina/2.0.25 Let us vote : [ ] +1 | Release MINA 2.2.3 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.2.3 [ ] +1 | Release MINA 2.1.8 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.1.8 [ ] +1 | Release MINA 2.0.25 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.0.25 -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- Guillaume Nodet -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Throwing RuntimeException is usually an anti-pattern
... and Apache MINA Team page updated! On 04/07/2023 22:33, Emmanuel Lécharny wrote: Gary has commit rights :-) That makes me realize that I need to update the Team page. And, yes, I do think we should thows some meaningful excection. On 04/07/2023 14:35, Jonathan Valliere wrote: Make a PR On Mon, Jul 3, 2023 at 7:12 PM Gary Gregory wrote: Hi All, I noticed that in org.apache.ftpserver.util.EncryptUtils we explicitly throw RuntimeException. This is usually an anti-pattern as IllegalArgumentException, IllegalStateException, and others are more descriptive. In the case of EncryptUtils, IllegalArgumentException seems more appropriate. Thoughts? Gary - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Throwing RuntimeException is usually an anti-pattern
Gary has commit rights :-) That makes me realize that I need to update the Team page. And, yes, I do think we should thows some meaningful excection. On 04/07/2023 14:35, Jonathan Valliere wrote: Make a PR On Mon, Jul 3, 2023 at 7:12 PM Gary Gregory wrote: Hi All, I noticed that in org.apache.ftpserver.util.EncryptUtils we explicitly throw RuntimeException. This is usually an anti-pattern as IllegalArgumentException, IllegalStateException, and others are more descriptive. In the case of EncryptUtils, IllegalArgumentException seems more appropriate. Thoughts? Gary - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Branch 1.2.X does not compile?
That's on me. I have added two encryption methods (SHA256 and SHA512) because FTPServer was only supporting MD5 and SHA-1. But the EncryptUtils has not yet been committed afaict. I'll check that. On 03/07/2023 23:44, Gary Gregory wrote: Hi All: Did I check out the wrong branch or have bad tooling? Can anyone compile the 1.2.X branch? [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /Users/garydgregory/git/mina/mina-ftpserver/core/src/main/java/org/apache/ftpserver/usermanager/Sha256PasswordEncryptor.java:[37,28] cannot find symbol symbol: method encryptSHA256(java.lang.String) location: class org.apache.ftpserver.util.EncryptUtils [ERROR] /Users/garydgregory/git/mina/mina-ftpserver/core/src/main/java/org/apache/ftpserver/usermanager/Sha512PasswordEncryptor.java:[37,28] cannot find symbol symbol: method encryptSHA512(java.lang.String) location: class org.apache.ftpserver.util.EncryptUtils I'm using: Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f) Maven home: /usr/local/Cellar/maven/3.9.3/libexec Java version: 1.8.0_372, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@8/1.8.0+372/libexec/openjdk.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "13.4.1", arch: "x86_64", family: "mac" Gary - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [FTP Server] Bumping deps
Hi Gary, I'm currently working on FTP Server for a week now. My goals are to get MINA 2.2.2 replace the previous version, and to get a grip on teh FTP serve code base. The first step is pretty much on its way, with a few road blocks: - there were some API changes that needed to be addressed (done) - there is still an issue with the TLS layer when launching a AUTH command. The MINA 2.2.X branch deals with TLS negociation in a different way (see https://mina.apache.org/mina-project/2.2-vs-2.1.html). I have created a StartTLS filter class in FTPServer to deal with the message, but so far, it's not good enough - there is also a confusion in the tests, which are using the getAuth() method to get the AUTH encrypting method (TLS or SSL), and to get the TLS version to use. Thi was not playing well when you were setting the getAuth() return to "TLSv1.2" for instance. I created another method for that purpose, and that should work Bottom line, it's a work i, progress, not totally committed. On 03/07/2023 23:36, Gary Gregory wrote: Hi All, As I was updating Apache Commons VFS' tests to use current versions of Mina libraries, I ran into an issue where FTP Server 1.2.0 is not using the current version of Mina Core (2.2.2). I have tests that use Core directly, but the FTP Server tests fail with a method missing exception. I plan on exploring updating this dependency as well as a few others, so watch for these commits if you care ;-) Gary - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Apache MINA Mastodon account is on!
Hi! we just have created a Mastodon account to inform the world abouut the Apache MINA project evolution. Feel free to follow @apachem...@fosstodon.org ! -- *Emmanuel Lécharny* - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Result, was: [VOTE] Apache MINA 2.2.2, 2.1.7, 2.0.24 releases
Hi! I'm closing this vote with 3 binding +1 (Jeff Genender, Jonathan, and me) and 2 non binding +1 (Christoph and Gary). Thanks for the votes, I'll pushg the releases and announce them! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Apache MINA 2.2.2, 2.1.7, 2.0.24 releases
[X] +1 | Release MINA 2.2.2 [X] +1 | Release MINA 2.1.7 [X] +1 | Release MINA 2.0.24 -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Apache MINA 2.2.2, 2.1.7, 2.0.24 releases
Indeed.
The reason we have both SHA-256 and 512 is historic. We can stop signing
with SHA-256. I'll update the release process to reflect that.
Thanks!
On 04/06/2023 03:53, Gary Gregory wrote:
In the future, it seems to me like we only need sha512 files, not both
512 and 256. Less clutter IMO.
Gary
On Thu, Jun 1, 2023, 18:58 Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:
hi!
WARNING: there are 3 votes to cast!
This is a vote for a triple release:
* MINA 2.2.2
* MINA 2.1.7
* MINA 2.0.24
Those versions are fixing some SSL/TLS issues and bring some added
features:
DIRMINA-1122: support for endpoint identification algorithm (thanks to
Marcin L)
DIRMINA-1157: A fix for a sporadic SSL/TLS connection establishement
for
version 2.0.X and 2.1.X (thanks to Steffen Liersch)
DIRMINA-1169: A fix in the Acceptor for Java 11 and upper (thanks to
Thomas Wolf)
Temporary tags have been created (they can be removed if the vote is
not
approved) :
* MINA 2.2.2:
https://github.com/apache/mina/commit/bd0b2da0c1993c5bbb5498c5542a263e2a69e554
<https://github.com/apache/mina/commit/bd0b2da0c1993c5bbb5498c5542a263e2a69e554>
* MINA 2.1.7:
https://github.com/apache/mina/commit/f112272a3c1c84aad650a2772d82fcf4ac87
<https://github.com/apache/mina/commit/f112272a3c1c84aad650a2772d82fcf4ac87>
* MINA 2.0.24:
https://github.com/apache/mina/commit/ff0dd253fe1416951ebffd2f622bfcb56e5873d3
<https://github.com/apache/mina/commit/ff0dd253fe1416951ebffd2f622bfcb56e5873d3>
The final artifacts are stored in a staging repository:
* MINA 2.2.2:
https://repository.apache.org/content/repositories/orgapachemina-1082
<https://repository.apache.org/content/repositories/orgapachemina-1082>
* MINA 2.1.7:
https://repository.apache.org/content/repositories/orgapachemina-1084
<https://repository.apache.org/content/repositories/orgapachemina-1084>
* MINA 2.0.24:
https://repository.apache.org/content/repositories/orgapachemina-1083
<https://repository.apache.org/content/repositories/orgapachemina-1083>
The distributions are available for download on :
* MINA 2.2.2: https://dist.apache.org/repos/dist/dev/mina/mina/2.2.2
<https://dist.apache.org/repos/dist/dev/mina/mina/2.2.2>
* MINA 2.1.7: https://dist.apache.org/repos/dist/dev/mina/mina/2.1.7
<https://dist.apache.org/repos/dist/dev/mina/mina/2.1.7>
* MINA 2.0.24:
https://dist.apache.org/repos/dist/dev/mina/mina/2.0.24
<https://dist.apache.org/repos/dist/dev/mina/mina/2.0.24>
Let us vote :
[ ] +1 | Release MINA 2.2.2
[ ] ± | Abstain
[ ] -1 | Do *NOT* release MINA 2.2.2
[ ] +1 | Release MINA 2.1.7
[ ] ± | Abstain
[ ] -1 | Do *NOT* release MINA 2.1.7
[ ] +1 | Release MINA 2.0.24
[ ] ± | Abstain
[ ] -1 | Do *NOT* release MINA 2.0.24
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com>
https://www.busit.com/ <https://www.busit.com/>
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
<mailto:dev-unsubscr...@mina.apache.org>
For additional commands, e-mail: dev-h...@mina.apache.org
<mailto:dev-h...@mina.apache.org>
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[VOTE] Apache MINA 2.2.2, 2.1.7, 2.0.24 releases
hi! WARNING: there are 3 votes to cast! This is a vote for a triple release: * MINA 2.2.2 * MINA 2.1.7 * MINA 2.0.24 Those versions are fixing some SSL/TLS issues and bring some added features: DIRMINA-1122: support for endpoint identification algorithm (thanks to Marcin L) DIRMINA-1157: A fix for a sporadic SSL/TLS connection establishement for version 2.0.X and 2.1.X (thanks to Steffen Liersch) DIRMINA-1169: A fix in the Acceptor for Java 11 and upper (thanks to Thomas Wolf) Temporary tags have been created (they can be removed if the vote is not approved) : * MINA 2.2.2: https://github.com/apache/mina/commit/bd0b2da0c1993c5bbb5498c5542a263e2a69e554 * MINA 2.1.7: https://github.com/apache/mina/commit/f112272a3c1c84aad650a2772d82fcf4ac87 * MINA 2.0.24: https://github.com/apache/mina/commit/ff0dd253fe1416951ebffd2f622bfcb56e5873d3 The final artifacts are stored in a staging repository: * MINA 2.2.2: https://repository.apache.org/content/repositories/orgapachemina-1082 * MINA 2.1.7: https://repository.apache.org/content/repositories/orgapachemina-1084 * MINA 2.0.24: https://repository.apache.org/content/repositories/orgapachemina-1083 The distributions are available for download on : * MINA 2.2.2: https://dist.apache.org/repos/dist/dev/mina/mina/2.2.2 * MINA 2.1.7: https://dist.apache.org/repos/dist/dev/mina/mina/2.1.7 * MINA 2.0.24: https://dist.apache.org/repos/dist/dev/mina/mina/2.0.24 Let us vote : [ ] +1 | Release MINA 2.2.2 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.2.2 [ ] +1 | Release MINA 2.1.7 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.1.7 [ ] +1 | Release MINA 2.0.24 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.0.24 -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Release train: 2.0.24, 2.1.7 and 2.2.2 on their way
Hi! I'll cut a triple release in the coming hours. There are substantial fixes in them. It's about time to get those version out. We still have a few important issues to fix, but I'd like to have what is ready out sooner than later. I'll keep you updated. Thanks ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Friendly suggestion to make the dev-list readable again
Hi Christofer, nice work on plc4x! We will look at it and see how to apply to to the MINA project. Many thanks! On 15/02/2023 15:58, Christofer Dutz wrote: Hi, while reviewing your projects activity as part of my board duties, I came to notice, that the dev-list is in an almost unusable state. The vast majority of all emails are auto-generated emails from GitHub. The way the replication is setup per default makes these emails impossible to follow and display in any email client I tried to read it on. After a lot of persuasion Infra introduced a new feature into the .asf.yml to allow custom templates for these auto-generated emails. https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-CustomsubjectlinesforGitHubevents In the PLC4X Project we used these settings to drastically reformat the subject lines of all GitHub emails. https://github.com/apache/plc4x/blob/develop/.asf.yaml#L62 With this we can now read the start of the title in typical columnar layouted email clients as well on phones and the clients are able to do correct threading. Perhaps worth discussing to adopt these or similar changes. The way the list is currently, I doubt anyone is reading it and it makes it impossible for outsiders to get started … well … and it makes it hard for the board to execute it’s oversight. As I said in the subject … it’s not an order to change anything, but a friendly suggestion. Chris -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Delay in message arrival, please help urgent
Hi,
first, can you tell which MINA version you are using? Also what is your
environment (OS, Java version, machine configuration - number of cores,
type of CPU, frequency, ram-)
Is there any valid reason to create two thread pool of 1000 threads?
That sounds overkilling to me. Also are you sure you want to limit the
read buffer size to 2048, Considering you have set the max en/decoder
line to 1M ?
On 2022/11/16 12:21, Nauman Ahmad Khan wrote:
Hi,
I have built a server based on MINA. Sometimes the message arrives late. Client
is only telnet so there is nothing in between. Following are the setup
settings. Can anyone please highlight if a setting is missing or a wrong
setting is set? The setup/init code is below.
int processorCount = Runtime.getRuntime().availableProcessors();
if (processorCount <= 0) { processorCount = 8;}
NioSocketAcceptor acceptor = new NioSocketAcceptor(processorCount);
TextLineCodecFactory codec = new TextLineCodecFactory(Charset.forName("utf-8"));
codec.setDecoderMaxLineLength(1000 * 1024);
codec.setEncoderMaxLineLength(1000 * 1024);
acceptor.getFilterChain().addLast("codec", new ProtocolCodecFilter(codec));
acceptor.getFilterChain().addLast("threadPool", new ExecutorFilter(new
OrderedThreadPoolExecutor(1000, 1000)));
acceptor.getFilterChain().addLast("executor1", new ExecutorFilter(1000, 1000));
acceptor.getSessionConfig().setReadBufferSize(2048);
acceptor.getSessionConfig().setIdleTime(IdleStatus.BOTH_IDLE, 10);
acceptor.getSessionConfig().setTcpNoDelay(true);
acceptor.setBacklog(5000);
acceptor.bind(new InetSocketAddress(port));
Regards
nak
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
Re: Please help code review
Hi Jonathan, what is the pb you are having with GH ? Can't connect? Can't access to the mina-sshd repo? On 2022/09/07 12:32, Jonathan Valliere wrote: Emmanuel do you have a link somewhere how to fix my connection to Apache on GitHub? On Wed, Sep 7, 2022 at 4:29 AM Edward Zheng wrote: Hi guys, I create a pull request several days ago. https://github.com/apache/mina-sshd/pull/242. I’m not sure if it’s a bugfix or my usage is wrong, could someone help review and give me some suggestions? Thanks. - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Apache Mina SSHD 2.9.1
Hi Guillaume, sorry, I should have tested it again, it now passes green (I was in vacation last week...). I guess it was a hicup... My +1 for teh release. On 2022/09/05 09:43, Guillaume Nodet wrote: I've run the test alone without any issue on osx, windows 10 and fedora, so I'm quite confident the underlying code is working correctly. Le mar. 30 août 2022 à 06:41, Emmanuel Lécharny a écrit : Hi, got one error on sshd-core: [INFO] Running org.apache.sshd.common.auth.PublicKeyAuthenticationTest [ERROR] Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.847 s <<< FAILURE! - in org.apache.sshd.common.auth.PublicKeyAuthenticationTest [ERROR] org.apache.sshd.common.auth.PublicKeyAuthenticationTest.testUserAuthPkOkWrongKey Time elapsed: 0.131 s <<< FAILURE! java.lang.AssertionError: Unexpected failure cause - actual object type (org.apache.sshd.common.SshException) incompatible with expected (java.security.spec.InvalidKeySpecException) at org.junit.Assert.fail(Assert.java:89) at org.apache.sshd.util.test.JUnitTestSupport.assertObjectInstanceOf(JUnitTestSupport.java:415) at org.apache.sshd.common.auth.PublicKeyAuthenticationTest.testUserAuthPkOkWrongKey(PublicKeyAuthenticationTest.java:180) ... [WARNING] Flakes: [WARNING] org.apache.sshd.common.auth.PublicKeyAuthenticationTest.testUserAuthPkOkWrongKey [ERROR] Run 1: PublicKeyAuthenticationTest.testUserAuthPkOkWrongKey:180->JUnitTestSupport.assertObjectInstanceOf:415->Assert.fail:89 Unexpected failure cause - actual object type (org.apache.sshd.common.SshException) incompatible with expected (java.security.spec.InvalidKeySpecException) Env: MacOS 12.5.1 Maven: 3.8.1 Java: 1.8 Otherwise, the build was successful... On 2022/08/22 14:46, Guillaume Nodet wrote: I've staged a candidate release for 2.9.1 at: https://repository.apache.org/content/repositories/orgapachemina-1079 Git tag: https://github.com/apache/mina-sshd/tree/sshd-2.9.1 Issues solved: https://github.com/apache/mina-sshd/blob/sshd-2.9.1/docs/changes/2.9.1.md Please review and vote ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Apache Mina SSHD 2.9.1
Hi, got one error on sshd-core: [INFO] Running org.apache.sshd.common.auth.PublicKeyAuthenticationTest [ERROR] Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.847 s <<< FAILURE! - in org.apache.sshd.common.auth.PublicKeyAuthenticationTest [ERROR] org.apache.sshd.common.auth.PublicKeyAuthenticationTest.testUserAuthPkOkWrongKey Time elapsed: 0.131 s <<< FAILURE! java.lang.AssertionError: Unexpected failure cause - actual object type (org.apache.sshd.common.SshException) incompatible with expected (java.security.spec.InvalidKeySpecException) at org.junit.Assert.fail(Assert.java:89) at org.apache.sshd.util.test.JUnitTestSupport.assertObjectInstanceOf(JUnitTestSupport.java:415) at org.apache.sshd.common.auth.PublicKeyAuthenticationTest.testUserAuthPkOkWrongKey(PublicKeyAuthenticationTest.java:180) ... [WARNING] Flakes: [WARNING] org.apache.sshd.common.auth.PublicKeyAuthenticationTest.testUserAuthPkOkWrongKey [ERROR] Run 1: PublicKeyAuthenticationTest.testUserAuthPkOkWrongKey:180->JUnitTestSupport.assertObjectInstanceOf:415->Assert.fail:89 Unexpected failure cause - actual object type (org.apache.sshd.common.SshException) incompatible with expected (java.security.spec.InvalidKeySpecException) Env: MacOS 12.5.1 Maven: 3.8.1 Java: 1.8 Otherwise, the build was successful... On 2022/08/22 14:46, Guillaume Nodet wrote: I've staged a candidate release for 2.9.1 at: https://repository.apache.org/content/repositories/orgapachemina-1079 Git tag: https://github.com/apache/mina-sshd/tree/sshd-2.9.1 Issues solved: https://github.com/apache/mina-sshd/blob/sshd-2.9.1/docs/changes/2.9.1.md Please review and vote ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Infinite loop in Apache Directory Server when using MINA 2.2.1
Directory. bascially, rebuilding Apache LDAP API with Java 8 did the trick. The pb was due to an exception caused by an API change in Java 9, related to ByteBuffer (see https://www.morling.dev/blog/bytebuffer-and-the-dreaded-nosuchmethoderror/) which was causing an exception to be thrown, and the LDAP API handler was then tryingh to send a NoticeOfDisconnect message to the remote peer, which obviously ended in another exception to be thrown (ByteBuffer missing method), and voilà, infinite loop. On 11/08/2022 03:29, Jonathan Valliere wrote: Was the fix in Mina or Directory? On Wed, Aug 10, 2022 at 5:34 AM Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote: I confirm. I built the LDAP API with Java 11 targetting Java 8, but it's not enough. Fixed in trunk. On 30/07/2022 10:23, Emmanuel Lécharny wrote: > Seems like it's an issue with a mixed Java version being used: the lib > built with Java 11 and running tests in Java 8, or something like that. > > Still investigating. > > On 30/07/2022 10:03, Emmanuel Lécharny wrote: >> Hi, >> >> >> I'm currently investiagting some infinite loop in Apache DS when >> setting up a LDAPS server. I have no idea what's going on atm - but I >> will keep you posted. >> >> >> Here is the trace I get when doing a kill -3: >> >> >> "NioProcesso-- > *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE > T. +33 (0)4 89 97 36 50 > P. +33 (0)6 08 33 32 61 > emmanuel.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com> https://www.busit.com/ <https://www.busit.com/> -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com> https://www.busit.com/ <https://www.busit.com/> - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org <mailto:dev-unsubscr...@mina.apache.org> For additional commands, e-mail: dev-h...@mina.apache.org <mailto:dev-h...@mina.apache.org> -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Infinite loop in Apache Directory Server when using MINA 2.2.1
I confirm. I built the LDAP API with Java 11 targetting Java 8, but it's not enough. Fixed in trunk. On 30/07/2022 10:23, Emmanuel Lécharny wrote: Seems like it's an issue with a mixed Java version being used: the lib built with Java 11 and running tests in Java 8, or something like that. Still investigating. On 30/07/2022 10:03, Emmanuel Lécharny wrote: Hi, I'm currently investiagting some infinite loop in Apache DS when setting up a LDAPS server. I have no idea what's going on atm - but I will keep you posted. Here is the trace I get when doing a kill -3: "NioProcesso-- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Infinite loop in Apache Directory Server when using MINA 2.2.1
Seems like it's an issue with a mixed Java version being used: the lib built with Java 11 and running tests in Java 8, or something like that. Still investigating. On 30/07/2022 10:03, Emmanuel Lécharny wrote: Hi, I'm currently investiagting some infinite loop in Apache DS when setting up a LDAPS server. I have no idea what's going on atm - but I will keep you posted. Here is the trace I get when doing a kill -3: "NioProcesso-- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
Hi Christoph, answers inline On 28/07/2022 14:48, Christoph John wrote: Hi Emmanuel, I took a look at this and it seems the two latches were a red herring. One is for the initiator (connector) and the other one for the acceptor that are used in the unit test. I must admit I haven't spent enough time to unerstand what was going on ;-) No problem, thank you for your time to narrow the problem down. I for one am no expert in MINA. :) When trying to use MINA 2.2.0 I made the following changes to QFJ to make it compile. Could you (or Jonathan) please tell me if the changes are safe? https://github.com/quickfix-j/quickfixj/pull/441/files Especially I have the following questions: 1. setUseClientMode() should be no longer necessary No. It's automatically deduced. 2. the "initiateHandshake" and "autoStart" stuff of the SSLFilter is no > longer necessary?? I think it' snow spurious. I have to check 3. to use SNI we formerly set the "PEER_ADDRESS". Is this still possible? Please see here: https://github.com/quickfix-j/quickfixj/blob/c4c963cdb2a6c4f1942f12bcfd890bff166788c2/quickfixj-core/src/main/java/quickfix/mina/ssl/SSLFilter.java#L66-L78 Good question. I don't know... Jonathan ? -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Result, was Re: [VOTE] Apache MINA 2.2.1 release
Hi! I'm closing this vote with 4 binding +1 and one ,on binding +1: Binding - Jonathan - Jeff Genender - Guillaume - and me Non Binding: - Chistoph. Thanks for the votes, I'll push the packages and announce the release ASAP ! On 20/07/2022 15:41, Emmanuel Lécharny wrote: hi! This is a vote for MINA 2.2.1. This version just fixes an issue in the export declaration for OSGi: a missing comma made MINA 2.2.0 impossible to use by application that leverage OSGi, due to a concatenation of package name. A temporary tag has been created (it can be removed if the vote is not approved) : https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=023fdeb33e2a783498ef23a5cdb57d051ffbe65d The final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-1077 The distributions are available for download on : https://dist.apache.org/repos/dist/dev/mina/mina/2.2.1 Let us vote : [ ] +1 | Release MINA 2.2.1 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.2.1 -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
On 21/07/2022 15:38, Christoph John wrote:
Hi Emmanuel,
I took a look at this and it seems the two latches were a red herring.
One is for the initiator (connector) and the other one for the acceptor
that are used in the unit test.
I must admit I haven't spent enough time to unerstand what was going on ;-)
However, I think I found the root cause for the failing unit tests. We
have an AbstractIoHandler which extends IoHandlerAdapter. In its
exceptionCaught() method we do some magic and in the end disconnect the
session. You can see that here:
https://github.com/quickfix-j/quickfixj/pull/441/files#diff-ecbb4c6b07934a11f46ceae43478dc258e7dfcaedad8c67881c7441848f8909d
Now when I exchange the closeNow() with closeOnFlush() the unit tests
succeed, meaning that the registered filter is notified of the Exception.
Is this expected?
The closeNow is pretty brutal. In case of a TLS failure, the SSLEngine
generates a message that *must* be sent to the remote peer. This message
is a TLS alert, and it cntains the rooot cause of the failure.
Closing the connection brutally will not allow this message to be sent,
so doing a close n flush will guarantee that *every* message stored in
the queue qill be sent.
So, yes, this is the way to go.
Did this behaviour change intentionally?
No.
Is it safe to
always use closeOnFlush()?
It should be.
(probably I should wait for the returned
CloseFuture to complete for a sensible amount of time)
Thanks in advance and best regards
Chris.
On 16.07.22 05:30, Emmanuel Lécharny wrote:
Hi Christoph,
after further analysis, it appears that we have 2 countdown latch
instances (exceptionThrownLatch) at play:
* one that is decremented in the exceptionCaught event,
[Count1]>:1]--->PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
[Count0]>:0<]---
* and the other one that is checked for the exfeption being received:
[Count:1 in
assert
As you can see, the instances ID are different: b9ed2fa and 8458f04.
Seems like the handler you have added in teh chain is not owning the
same latch that the one being checked in the assert, now to see why...
On 13/07/2022 17:43, Emmanuel Lécharny wrote:
Hi Christoph,
actually, there is a kind of race condition in your test.
I have added some logs:
@Override
public void exceptionCaught(NextFilter nextFilter,
IoSession session, Throwable cause)
throws Exception {
System.out.println("[Count:"+exceptionThrownLatch.getCount()+"]--->"
+ cause.getMessage());
//LOGGER.info("exceptionCaught", cause);
exceptionThrownLatch.countDown();
System.out.println("[Count:"+exceptionThrownLatch.getCount()+"<]---");
nextFilter.exceptionCaught(session, cause);
}
which generates:
[Count:1]--->PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
[Count:0<]---
after the initiator.start() call. So the latch is properly
decremented and the initiator.assertSslExceptionThrown() should be
valid:
public void assertSslExceptionThrown() throws Exception {
System.out.println("[Count:"+exceptionThrownLatch.getCount()+" in
assert");
boolean reachedZero =
exceptionThrownLatch.await(TIMEOUT_SECONDS, TimeUnit.SECONDS);
if (!reachedZero) {
throw new AssertionError("No SSL exception thrown");
}
and weird enough, the latch counter is 1 ! (ie, the counter is
*not* decremented)
Here are the complete logs (check the 'Count' string):
juil. 13, 2022 5:33:12 PM
quickfix.mina.ssl.SSLCertificateTest$TestAcceptor createConnector
INFOS: Creating acceptor: [DEFAULT]
SocketUseSSL=Y
EndTime=00:00:00
ReconnectInterval=2
SocketAcceptPort=50957
SocketTrustStore=single-session/server.truststore
NeedClientAuth=Y
EnabledProtocols=TLSv1.2
SocketAcceptHost=localhost
CipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
ConnectionType=acceptor
StartTime=00:00:00
SocketKeyStorePassword=password
SocketConnectProtocol=SOCKET
KeyStoreType=JKS
SocketKeyStore=single-session/server.keystore
SocketTrustStorePassword=password
TrustStoreType=JKS
HeartBtInt=30
[SESSION]
BeginString=FIX.4.4
SenderCompID=ALFA
TargetCompID=ZULU
DataDictionary=FIX44.xml
juil. 13, 2022 5:33:14 PM quickfix.DefaultSessionSchedule
INFOS: [FIX.4.4:ALFA->ZULU] daily, 00:00:00-UTC - 00:00:00-UTC
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Session
FIX.4.4:ALFA->ZULU schedule is daily, 00:00:00-UTC - 00:00:00-UTC)
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Created session:
FIX.4.4:ALFA->ZULU)
juil. 13, 2022 5:33:14 PM quickfix.mina.SessionConnector
star
[VOTE] Apache MINA 2.2.1 release
hi! This is a vote for MINA 2.2.1. This version just fixes an issue in the export declaration for OSGi: a missing comma made MINA 2.2.0 impossible to use by application that leverage OSGi, due to a concatenation of package name. A temporary tag has been created (it can be removed if the vote is not approved) : https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=023fdeb33e2a783498ef23a5cdb57d051ffbe65d The final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-1077 The distributions are available for download on : https://dist.apache.org/repos/dist/dev/mina/mina/2.2.1 Let us vote : [ ] +1 | Release MINA 2.2.1 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.2.1 -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
MINA 2.2.1 needed...
Hi !
sadly, we will need a MINA 2.2.1 release ASAP. There is a missing comma
(',') in the MANIFEST which makes it impossible to use mina-core in
Apache LDAP-API because it fails with some OSGi tests:
org.apache.mina.core,
...
org.apache.mina.transport.vmpipe,
org.apache.mina.util <--- here we should have a','
org.apache.mina.util.byteaccess
in the mina-core pom.xml.
I'll cut the release.
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Apache Mina SSHD 2.9.0 (2nd try)
+1 - checked the packages signatures (GPG and SHA) - built from source, tests all green (java 11) Thanks Guillaume ! PS: I'll update the site doco to point to the proper KEYS file On 19/07/2022 16:31, Guillaume Nodet wrote: It's a subkey of the my last key which I've uploaded to https://dist.apache.org/repos/dist/release/mina/KEYS. It's available at http://keyserver.ubuntu.com/pks/lookup?search=4A61C968D0023541DAE9B1A0BC7DF305D87BDFA7=on=index but the key fingerprint does not appear in the KEYS file (I think that's because it's a subkey). But that should not prevent you to import it and verify the signature I think. Let me know ! Le mar. 19 juil. 2022 à 15:59, Emmanuel Lécharny a écrit : Hi Guillaume, qstill have an issue with the KEYS file. Where did you pushed it ? (I have successfully checked the signature with the SHA256 sig you pushed, thanks !) On 19/07/2022 11:51, Guillaume Nodet wrote: I've uploaded the releases and SHA 256 / 512 signatures to https://dist.apache.org/repos/dist/dev/mina/sshd/ and added my new key to the mina KEYS file. Thx ! Le mar. 19 juil. 2022 à 06:49, Emmanuel Lécharny a écrit : Just mentionning it because we *MUST* provide SHA256 and SHA 512 signatures, and the standard maven release only generates MD5 and SHA1 signatures. On 19/07/2022 06:47, Emmanuel Lécharny wrote: Also the packages are missing from https://dist.apache.org/repos/dist/dev/mina/sshd/ On 18/07/2022 09:51, Guillaume Nodet wrote: I've staged another candidate release at: https://repository.apache.org/content/repositories/orgapachemina-1076 Git tag: https://github.com/apache/mina-sshd/tree/sshd-2.9.0 Issues solved: https://github.com/apache/mina-sshd/blob/sshd-2.9.0/docs/changes/2.9.0.md Please review and vote ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Apache Mina SSHD 2.9.0 (2nd try)
Hi Guillaume, qstill have an issue with the KEYS file. Where did you pushed it ? (I have successfully checked the signature with the SHA256 sig you pushed, thanks !) On 19/07/2022 11:51, Guillaume Nodet wrote: I've uploaded the releases and SHA 256 / 512 signatures to https://dist.apache.org/repos/dist/dev/mina/sshd/ and added my new key to the mina KEYS file. Thx ! Le mar. 19 juil. 2022 à 06:49, Emmanuel Lécharny a écrit : Just mentionning it because we *MUST* provide SHA256 and SHA 512 signatures, and the standard maven release only generates MD5 and SHA1 signatures. On 19/07/2022 06:47, Emmanuel Lécharny wrote: Also the packages are missing from https://dist.apache.org/repos/dist/dev/mina/sshd/ On 18/07/2022 09:51, Guillaume Nodet wrote: I've staged another candidate release at: https://repository.apache.org/content/repositories/orgapachemina-1076 Git tag: https://github.com/apache/mina-sshd/tree/sshd-2.9.0 Issues solved: https://github.com/apache/mina-sshd/blob/sshd-2.9.0/docs/changes/2.9.0.md Please review and vote ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Apache Mina SSHD 2.9.0 (2nd try)
Just mentionning it because we *MUST* provide SHA256 and SHA 512 signatures, and the standard maven release only generates MD5 and SHA1 signatures. On 19/07/2022 06:47, Emmanuel Lécharny wrote: Also the packages are missing from https://dist.apache.org/repos/dist/dev/mina/sshd/ On 18/07/2022 09:51, Guillaume Nodet wrote: I've staged another candidate release at: https://repository.apache.org/content/repositories/orgapachemina-1076 Git tag: https://github.com/apache/mina-sshd/tree/sshd-2.9.0 Issues solved: https://github.com/apache/mina-sshd/blob/sshd-2.9.0/docs/changes/2.9.0.md Please review and vote ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Apache Mina SSHD 2.9.0 (2nd try)
Also the packages are missing from https://dist.apache.org/repos/dist/dev/mina/sshd/ On 18/07/2022 09:51, Guillaume Nodet wrote: I've staged another candidate release at: https://repository.apache.org/content/repositories/orgapachemina-1076 Git tag: https://github.com/apache/mina-sshd/tree/sshd-2.9.0 Issues solved: https://github.com/apache/mina-sshd/blob/sshd-2.9.0/docs/changes/2.9.0.md Please review and vote ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE] Release Apache Mina SSHD 2.9.0
Hi, just to be sure, has someone dropped the https://repository.apache.org/content/repositories/orgapachemina-1051 repository by mistake? I'm afraid that it was intended to drop the SSHD repo (1071) but actually the one which get dropped was the MINA 2.2.0 that was under vote for a long time:/ Just to be sure. (not such a big deal, I can re-push the packages). On 17/07/2022 00:42, Guillaume Nodet wrote: Yes, I'll do that on monday. Le sam. 16 juil. 2022 à 10:38, Thomas Wolf a écrit : On 13.07.22 08:44 , Thomas Wolf wrote: On 13.07.22 00:20 , Emmanuel Lécharny wrote: I get some error while running tests: org.testcontainers.containers.ContainerLaunchException: Container startup failed The problem is that the entrypoint.sh files in the test resources don't have the executable bit set. This is fixed by PR 233 [1]. Guillaume, could you please review, merge, and then do a respin? Cheers, Thomas [1] https://github.com/apache/mina-sshd/pull/233 -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
result: was [Vote] MINA 2.2.0 release
Thanks for the votes! I therefore close this vote with 3 binding +1 and o,ne non binding +1: - Christoph John (non binding) - Jeff (Genender) - Jonathan - and me I will push the packages, update the site and announce the release in the coming hours ! On 04/07/2022 23:43, Emmanuel Lécharny wrote: Hi! it has been a couple of months now that I cut a version of MINA 2.2.0, but haven't started a vote, because I wanted to test that exception were properly handled when generated from the SslFilter. It took may way longer to check that, mainly due to external factors). Anyway, I'm done with the test, all is nominal, so here is a formal vote for MINA 2.2.0. This version comes with a complete rewrite of the SSL layer, thanks for Jonathan hard work ! A temporary tag has been created (it can be removed if the vote is not approved) : https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4 The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-1051 The distributions are available for download on : https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0 Let us vote : [ ] +1 | Release MINA 2.2.0 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.2.0 -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [Vote] MINA 2.2.0 release
On 16/07/2022 11:31, Christoph John wrote: +1 Thanks! But don't know if my vote counts. Every vote *do* count, even if not all the votes are binding. The idea is that if someone casts a -1, that means there is something that requires some investigation. Typically, when I started the vote last week, you correctly asked if the pb you had was fixed, and we had to spend some extra time verifying that it was indeed the case. So please, feel free to vote :-) Thanks for your investigation. I will take a closer look next week. Cheers Chris Jul 16, 2022 10:32:02 Emmanuel Lécharny : Hi, I need one more vote at least to get the release out. I'm confident the pb Christoph had was due to some bad test, not to a MINA issue. Thanks ! On 05/07/2022 09:38, Christoph John wrote: Hi Emmanuel Did you manage to fix the bug which we talked about in the mail thread from May regarding the M1 milestone? Thanks Chris 04.07.2022 23:43:37 Emmanuel Lécharny : Hi! it has been a couple of months now that I cut a version of MINA 2.2.0, but haven't started a vote, because I wanted to test that exception were properly handled when generated from the SslFilter. It took may way longer to check that, mainly due to external factors). Anyway, I'm done with the test, all is nominal, so here is a formal vote for MINA 2.2.0. This version comes with a complete rewrite of the SSL layer, thanks for Jonathan hard work ! A temporary tag has been created (it can be removed if the vote is not approved) : https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4 The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-1051 The distributions are available for download on : https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0 Let us vote : [ ] +1 | Release MINA 2.2.0 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.2.0 -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [Vote] MINA 2.2.0 release
Hi, I need one more vote at least to get the release out. I'm confident the pb Christoph had was due to some bad test, not to a MINA issue. Thanks ! On 05/07/2022 09:38, Christoph John wrote: Hi Emmanuel Did you manage to fix the bug which we talked about in the mail thread from May regarding the M1 milestone? Thanks Chris 04.07.2022 23:43:37 Emmanuel Lécharny : Hi! it has been a couple of months now that I cut a version of MINA 2.2.0, but haven't started a vote, because I wanted to test that exception were properly handled when generated from the SslFilter. It took may way longer to check that, mainly due to external factors). Anyway, I'm done with the test, all is nominal, so here is a formal vote for MINA 2.2.0. This version comes with a complete rewrite of the SSL layer, thanks for Jonathan hard work ! A temporary tag has been created (it can be removed if the vote is not approved) : https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4 The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-1051 The distributions are available for download on : https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0 Let us vote : [ ] +1 | Release MINA 2.2.0 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.2.0 -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
Hi Christoph,
after further analysis, it appears that we have 2 countdown latch
instances (exceptionThrownLatch) at play:
* one that is decremented in the exceptionCaught event,
[Count1]>:1]--->PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
[Count0]>:0<]---
* and the other one that is checked for the exfeption being received:
[Count:1 in assert
As you can see, the instances ID are different: b9ed2fa and 8458f04.
Seems like the handler you have added in teh chain is not owning the
same latch that the one being checked in the assert, now to see why...
On 13/07/2022 17:43, Emmanuel Lécharny wrote:
Hi Christoph,
actually, there is a kind of race condition in your test.
I have added some logs:
@Override
public void exceptionCaught(NextFilter nextFilter,
IoSession session, Throwable cause)
throws Exception {
System.out.println("[Count:"+exceptionThrownLatch.getCount()+"]--->"
+ cause.getMessage());
//LOGGER.info("exceptionCaught", cause);
exceptionThrownLatch.countDown();
System.out.println("[Count:"+exceptionThrownLatch.getCount()+"<]---");
nextFilter.exceptionCaught(session, cause);
}
which generates:
[Count:1]--->PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
[Count:0<]---
after the initiator.start() call. So the latch is properly decremented
and the initiator.assertSslExceptionThrown() should be valid:
public void assertSslExceptionThrown() throws Exception {
System.out.println("[Count:"+exceptionThrownLatch.getCount()+" in assert");
boolean reachedZero =
exceptionThrownLatch.await(TIMEOUT_SECONDS, TimeUnit.SECONDS);
if (!reachedZero) {
throw new AssertionError("No SSL exception thrown");
}
and weird enough, the latch counter is 1 ! (ie, the counter is
*not* decremented)
Here are the complete logs (check the 'Count' string):
juil. 13, 2022 5:33:12 PM
quickfix.mina.ssl.SSLCertificateTest$TestAcceptor createConnector
INFOS: Creating acceptor: [DEFAULT]
SocketUseSSL=Y
EndTime=00:00:00
ReconnectInterval=2
SocketAcceptPort=50957
SocketTrustStore=single-session/server.truststore
NeedClientAuth=Y
EnabledProtocols=TLSv1.2
SocketAcceptHost=localhost
CipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
ConnectionType=acceptor
StartTime=00:00:00
SocketKeyStorePassword=password
SocketConnectProtocol=SOCKET
KeyStoreType=JKS
SocketKeyStore=single-session/server.keystore
SocketTrustStorePassword=password
TrustStoreType=JKS
HeartBtInt=30
[SESSION]
BeginString=FIX.4.4
SenderCompID=ALFA
TargetCompID=ZULU
DataDictionary=FIX44.xml
juil. 13, 2022 5:33:14 PM quickfix.DefaultSessionSchedule
INFOS: [FIX.4.4:ALFA->ZULU] daily, 00:00:00-UTC - 00:00:00-UTC
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Session
FIX.4.4:ALFA->ZULU schedule is daily, 00:00:00-UTC - 00:00:00-UTC)
<20220713-15:33:14, FIX.4.4:ALFA->ZULU, event> (Created session:
FIX.4.4:ALFA->ZULU)
juil. 13, 2022 5:33:14 PM quickfix.mina.SessionConnector startSessionTimer
INFOS: SessionTimer started
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketTcpNoDelay=true
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketSynchronousWrites=false
juil. 13, 2022 5:33:14 PM quickfix.mina.NetworkingOptions logOption
INFOS: Socket option: SocketSynchronousWriteTimeout=3
juil. 13, 2022 5:33:14 PM quickfix.mina.acceptor.AbstractSocketAcceptor
installSSL
INFOS: Installing SSL filter for 0.0.0.0/0.0.0.0:50957
juil. 13, 2022 5:33:14 PM quickfix.mina.acceptor.AbstractSocketAcceptor
startAcceptingConnections
INFOS: Listening for connections at 0.0.0.0/0.0.0.0:50957 for session(s)
[FIX.4.4:ALFA->ZULU]
juil. 13, 2022 5:33:14 PM
quickfix.mina.ssl.SSLCertificateTest$TestInitiator createConnector
INFOS: Creating initiator: [DEFAULT]
SocketConnectPort=50957
SocketUseSSL=Y
EndTime=00:00:00
ReconnectInterval=2
SocketTrustStore=single-session/client.truststore
EnabledProtocols=TLSv1.2
CipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
ConnectionType=initiator
StartTime=00:00:00
SocketConnectHost=localhost
SocketKeyStorePassword=password
SocketConnectProtocol=SOCKET
KeyStoreType=JKS
SocketKeyStore=single-session/server.keystore
SocketTrustStorePassword=password
TrustStoreType=JKS
HeartBtInt=30
[SESSION]
BeginString=FIX.4.4
SenderCompID=ZULU
TargetCompID=ALFA
DataDictionary=FIX44.xml
juil. 13, 2022 5:33:14 PM quickfix.DefaultSessionSchedule
INFOS: [FIX.4.4:ZULU->ALFA] daily, 00:00:00-UTC - 00:00:00-UTC
<20220713-15:33:14, FI
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
kfix.mina.SessionConnector startSessionTimer
INFOS: SessionTimer started
[Count:1 in assert
juil. 13, 2022 5:33:14 PM quickfix.mina.acceptor.AcceptorIoHandler
sessionCreated
INFOS: MINA session created: local=/127.0.0.1:50957, class
org.apache.mina.transport.socket.nio.NioSocketSession,
remote=/127.0.0.1:50958
<20220713-15:33:14, FIX.4.4:ZULU->ALFA, event> (MINA session created:
local=/127.0.0.1:50958, class
org.apache.mina.transport.socket.nio.NioSocketSession,
remote=localhost/127.0.0.1:50957)
juil. 13, 2022 5:33:15 PM org.apache.mina.filter.ssl.SSLHandlerG0
execute_task
GRAVE: SSLHandlerG0@52097369[mode=server, connected=false] task() -
storing error {}
javax.net.ssl.SSLHandshakeException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
at
[Count:1]--->PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
[Count:0<]---
juil. 13, 2022 5:33:15 PM quickfix.mina.AbstractIoHandler exceptionCaught
GRAVE: Socket (/127.0.0.1:50958): javax.net.ssl.SSLHandshakeException:
PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
javax.net.ssl.SSLHandshakeException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
at ...
<20220713-15:33:15, FIX.4.4:ZULU->ALFA, event> (Disconnecting:
Encountered END_OF_STREAM)
juil. 13, 2022 5:33:15 PM quickfix.mina.AbstractIoHandler exceptionCaught
GRAVE: Socket (null):
org.apache.mina.core.write.WriteToClosedSessionException
org.apache.mina.core.write.WriteToClosedSessionException
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.clearWriteRequestQueue(AbstractPollingIoProcessor.java:1192)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.removeNow(AbstractPollingIoProcessor.java:1153)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.removeSessions(AbstractPollingIoProcessor.java:864)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:694)
at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
juil. 13, 2022 5:33:16 PM quickfix.mina.acceptor.AcceptorIoHandler
sessionCreated
INFOS: MINA session created: local=/127.0.0.1:50957, class
org.apache.mina.transport.socket.nio.NioSocketSession,
remote=/127.0.0.1:50959
<20220713-15:33:16, FIX.4.4:ZULU->ALFA, event> (MINA session created:
local=/127.0.0.1:50959, class
org.apache.mina.transport.socket.nio.NioSocketSession,
remote=localhost/127.0.0.1:50957)
juil. 13, 2022 5:33:17 PM org.apache.mina.filter.ssl.SSLHandlerG0
execute_task
GRAVE: SSLHandlerG0@4dd2b12c[mode=server, connected=false] task() -
storing error {}
javax.net.ssl.SSLHandshakeException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
at ...
[Count:0]--->PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
[Count:0<]---
juil. 13, 2022 5:33:17 PM quickfix.mina.AbstractIoHandler exceptionCaught
GRAVE: Socket (/127.0.0.1:50959): javax.net.ssl.SSLHandshakeException:
PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
javax.net.ssl.SSLHandshakeException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
at ...
Basically, it goes:
- assert (counter is 1)
- receive exception (counter is decremented and is now 0)
- close the connection : "Disconnecting: Encountered END_OF_STREAM"
and you are doomed, the assert has already failed.
At this point, I believe the pb is in your test, as the root cause is
properly propagated to the client :
[Count:1]--->PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
[Count:0<]---
On 13/07/2022 13:58, Emmanuel Lécharny wrote:
On 13/07/2022 09:37, Christoph John wrote:
Hi Emmanuel,
thanks for your analysis. The filter that should catch the exception
is added as last part in the chain. Could it be that the chain is not
fully iterated somehow? Just guessing, I don't have enough MINA
experience to make an educated guess. :)
This is what I'm going to check :-)
Stay tuned !
Cheers
Chris
Jul 13, 2022 06:38:00 Emmanuel Lécharny :
Here are some of my current findings.
For the (failing) test shouldFailWhenUsingBadClientCertificate, here
are the traces we get:
juil. 13, 2022 6
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
On 13/07/2022 09:37, Christoph John wrote:
Hi Emmanuel,
thanks for your analysis. The filter that should catch the exception is added
as last part in the chain. Could it be that the chain is not fully iterated
somehow? Just guessing, I don't have enough MINA experience to make an educated
guess. :)
This is what I'm going to check :-)
Stay tuned !
Cheers
Chris
Jul 13, 2022 06:38:00 Emmanuel Lécharny :
Here are some of my current findings.
For the (failing) test shouldFailWhenUsingBadClientCertificate, here are the
traces we get:
juil. 13, 2022 6:28:42 AM org.apache.mina.filter.ssl.SSLHandlerG0 execute_task
GRAVE: SSLHandlerG0@ae273e3[mode=server, connected=false] task() - storing
error {}
javax.net.ssl.SSLHandshakeException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: signature check failed
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:349)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:287)
at
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkClientCerts(CertificateMessage.java:700)
at
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:411)
at
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:375)
at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
at
org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
at org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
at org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1213)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: sun.security.validator.ValidatorException: PKIX path validation
failed: java.security.cert.CertPathValidatorException: signature check failed
at
java.base/sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:369)
at
java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:275)
at java.base/sun.security.validator.Validator.validate(Validator.java:264)
at
java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:313
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
/java.lang.Thread.run(Thread.java:829) Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed at java.base/sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:369) at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:275) at java.base/sun.security.validator.Validator.validate(Validator.java:264) at java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:313) at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:233) at java.base/sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:104) at quickfix.mina.ssl.X509TrustManagerWrapper.checkClientTrusted(X509TrustManagerWrapper.java:60) at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkClientTrusted(SSLContextImpl.java:1517) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkClientCerts(CertificateMessage.java:682) ... 31 more Caused by: java.security.cert.CertPathValidatorException: signature check failed at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135) at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:224) at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:144) at java.base/sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:83) at java.base/java.security.cert.CertPathValidator.validate(CertPathValidator.java:309) at java.base/sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:364) ... 39 more Caused by: java.security.SignatureException: Signature does not match. at java.base/sun.security.x509.X509CertImpl.verify(X509CertImpl.java:422) at java.base/sun.security.provider.certpath.BasicChecker.verifySignature(BasicChecker.java:166) at java.base/sun.security.provider.certpath.BasicChecker.check(BasicChecker.java:147) at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125) ... 44 more As we can see, there is a log: juil. 13, 2022 6:28:42 AM quickfix.mina.ssl.SSLCertificateTest$TestConnector$1 exceptionCaught INFOS: exceptionCaught javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed saying that the client has actually received a rooted exception (here, the PKIX path validation failed). OTOH, it seems that the connector does not properly handle this exception, ie the alert message is not propagated to the exceptionCaught handler on the client side. That is the part to be investigated, IMO. On 13/07/2022 05:29, Emmanuel Lécharny wrote: Never mind, I'm set up now, and in debug mode. All is good ! On 13/07/2022 00:47, Emmanuel Lécharny wrote: Hi Christoph, I'm trying to ran the failing tests on my machine (eclipse with Java 8 and Java 11), and I'll probably need some assistance. I'm using the chrjohn-mina-2.2.0 branch. It seems that the generated code is not stored at the proper place. Any clue? On 09/07/2022 11:49, Christoph John wrote: Thanks. Anything I can do to assist? Although I might only find time the week after next because am currently on vacation. Jul 9, 2022 09:00:21 Emmanuel Lécharny : I do think we need to have a look at it (and I may find some time to do it too, as I'm in vacation in the coming week) However, I think we should get this 2.0 out. Ther eis no problem in releasing a fix if needed. Thanks ! On 09/07/2022 07:17, Jonathan Valliere wrote: Sooo… do I need to look into this or was this resolved? On Fri, Jul 8, 2022 at 11:51 PM Emmanuel Lécharny mailto:elecha...@gmail.com>> wrote: The changes I did were to ensure that any ouutbound data are sent when a TLS erroroccurs, because the Alert must be sent no matter what. This is critical for a client to know what is the cause of the failure (typically when a bad certificate is provided - expired, revoked, etc -): https://datatracker.ietf.org/doc/html/rfc5246#section-7.2 <https://datatracker.ietf.org/doc/html/rfc5246#section-7.2> I also checked that in this case an exception is propagated up to the IoHandler for teh server to be informed about the situuation. On 06/07/2022 12:42, Jonathan Valliere wrote: > What test are you trying? Emmanuel made changes from the original design > to cause it to throw on the filter. My original design threw on the filter > but only during a subsequent read or write action thereby enforcing strong > concurrency within the pipeline. > > On Jul 6, 2022
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
Never mind, I'm set up now, and in debug mode. All is good !
On 13/07/2022 00:47, Emmanuel Lécharny wrote:
Hi Christoph,
I'm trying to ran the failing tests on my machine (eclipse with Java 8
and Java 11), and I'll probably need some assistance.
I'm using the chrjohn-mina-2.2.0 branch. It seems that the generated
code is not stored at the proper place.
Any clue?
On 09/07/2022 11:49, Christoph John wrote:
Thanks. Anything I can do to assist? Although I might only find time
the week after next because am currently on vacation.
Jul 9, 2022 09:00:21 Emmanuel Lécharny :
I do think we need to have a look at it (and I may find some time to
do it too, as I'm in vacation in the coming week)
However, I think we should get this 2.0 out. Ther eis no problem in
releasing a fix if needed.
Thanks !
On 09/07/2022 07:17, Jonathan Valliere wrote:
Sooo… do I need to look into this or was this resolved?
On Fri, Jul 8, 2022 at 11:51 PM Emmanuel Lécharny
mailto:elecha...@gmail.com>> wrote:
The changes I did were to ensure that any ouutbound data are sent
when a
TLS erroroccurs, because the Alert must be sent no matter what.
This is
critical for a client to know what is the cause of the failure
(typically when a bad certificate is provided - expired, revoked,
etc -):
https://datatracker.ietf.org/doc/html/rfc5246#section-7.2
<https://datatracker.ietf.org/doc/html/rfc5246#section-7.2>
I also checked that in this case an exception is propagated up
to the
IoHandler for teh server to be informed about the situuation.
On 06/07/2022 12:42, Jonathan Valliere wrote:
> What test are you trying? Emmanuel made changes from the
original design
> to cause it to throw on the filter. My original design
threw on
the filter
> but only during a subsequent read or write action thereby
enforcing strong
> concurrency within the pipeline.
>
> On Jul 6, 2022 at 3:53:57 AM, Christoph John
> mailto:christoph.j...@macd.com>.invalid> wrote:
>
>> Ok, the tests in QuickFIX/J which expect the exception to be
caught in a
>> filter still don't work.
>> I recall that you also did some changes in other Apache
projects
to make
>> it work with MINA 2.2.0. Could it be that I also need to adapt
something in
>> this regard?
>>
>> Thanks
>> Chris
>>
>> Jul 5, 2022 18:47:09 Emmanuel Lécharny mailto:elecha...@gmail.com>>:
>>
>> I have tested that the exception gets propagated before
launching the vote
>> to be clear :-)
>>
>>
>> On 05/07/2022 18:17, Christoph John wrote:
>>
>>> Sorry, no. The last message regarding this was:
>>
>>>
>>
>>> --snip-
>>
>>>
>>
>>> 11.04.2022 09:37:30 Emmanuel Lécharny mailto:elecha...@gmail.com>>:
>>
>>> Hi Christophe,
>>
>>> sorry, my late mail was off base.
>>
>>> The pb here is that the SSLEngine excpeiton is not propagated
to the
>> handler, when it should.
>>
>>> My guess is that we have some missing call somewhere in the
stack. I'm
>> going to check that out.
>>
>>> On 11/04/2022 00:15, Christoph John wrote:
>>
>>>> Hi,
>>
>>>> thanks Jonathan and Emmanuel for working on this!
>>
>>>> I tried to integrate this into QuickFIX/J and it compiles
successfully.
>> However there are some tests failing that expect an Exception.
For example
>> we have
>>
>>>>
>>
https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
<https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54>
>>
>>>> Up to now it was tried to get the Exception via a filter in
the chain.
>> This no longer seems to work but I think I can see the error
getting thrown
>> in the log:
>>
>>>> SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false]
task() -
>> storing error {}
>>
>>>> javax.net.ssl.SSLHandshakeException: No available
authentication scheme
>>
>>>
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
Hi Christoph,
I'm trying to ran the failing tests on my machine (eclipse with Java 8
and Java 11), and I'll probably need some assistance.
I'm using the chrjohn-mina-2.2.0 branch. It seems that the generated
code is not stored at the proper place.
Any clue?
On 09/07/2022 11:49, Christoph John wrote:
Thanks. Anything I can do to assist? Although I might only find time the week
after next because am currently on vacation.
Jul 9, 2022 09:00:21 Emmanuel Lécharny :
I do think we need to have a look at it (and I may find some time to do it too,
as I'm in vacation in the coming week)
However, I think we should get this 2.0 out. Ther eis no problem in releasing a
fix if needed.
Thanks !
On 09/07/2022 07:17, Jonathan Valliere wrote:
Sooo… do I need to look into this or was this resolved?
On Fri, Jul 8, 2022 at 11:51 PM Emmanuel Lécharny mailto:elecha...@gmail.com>> wrote:
The changes I did were to ensure that any ouutbound data are sent
when a
TLS erroroccurs, because the Alert must be sent no matter what. This is
critical for a client to know what is the cause of the failure
(typically when a bad certificate is provided - expired, revoked,
etc -):
https://datatracker.ietf.org/doc/html/rfc5246#section-7.2
<https://datatracker.ietf.org/doc/html/rfc5246#section-7.2>
I also checked that in this case an exception is propagated up to the
IoHandler for teh server to be informed about the situuation.
On 06/07/2022 12:42, Jonathan Valliere wrote:
> What test are you trying? Emmanuel made changes from the
original design
> to cause it to throw on the filter. My original design threw on
the filter
> but only during a subsequent read or write action thereby
enforcing strong
> concurrency within the pipeline.
>
> On Jul 6, 2022 at 3:53:57 AM, Christoph John
> mailto:christoph.j...@macd.com>.invalid> wrote:
>
>> Ok, the tests in QuickFIX/J which expect the exception to be
caught in a
>> filter still don't work.
>> I recall that you also did some changes in other Apache projects
to make
>> it work with MINA 2.2.0. Could it be that I also need to adapt
something in
>> this regard?
>>
>> Thanks
>> Chris
>>
>> Jul 5, 2022 18:47:09 Emmanuel Lécharny mailto:elecha...@gmail.com>>:
>>
>> I have tested that the exception gets propagated before
launching the vote
>> to be clear :-)
>>
>>
>> On 05/07/2022 18:17, Christoph John wrote:
>>
>>> Sorry, no. The last message regarding this was:
>>
>>>
>>
>>> --snip-
>>
>>>
>>
>>> 11.04.2022 09:37:30 Emmanuel Lécharny mailto:elecha...@gmail.com>>:
>>
>>> Hi Christophe,
>>
>>> sorry, my late mail was off base.
>>
>>> The pb here is that the SSLEngine excpeiton is not propagated
to the
>> handler, when it should.
>>
>>> My guess is that we have some missing call somewhere in the
stack. I'm
>> going to check that out.
>>
>>> On 11/04/2022 00:15, Christoph John wrote:
>>
>>>> Hi,
>>
>>>> thanks Jonathan and Emmanuel for working on this!
>>
>>>> I tried to integrate this into QuickFIX/J and it compiles
successfully.
>> However there are some tests failing that expect an Exception.
For example
>> we have
>>
>>>>
>>
https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
<https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54>
>>
>>>> Up to now it was tried to get the Exception via a filter in
the chain.
>> This no longer seems to work but I think I can see the error
getting thrown
>> in the log:
>>
>>>> SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false]
task() -
>> storing error {}
>>
>>>> javax.net.ssl.SSLHandshakeException: No available
authentication scheme
>>
>>>> at
>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
>>
>>>> at
Re: [VOTE] Release Apache Mina SSHD 2.9.0
Hi Guillaume, I get some error while running tests: [ERROR] Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 33.642 s <<< FAILURE! - in org.apache.sshd.client.auth.pubkey.HostBoundPubKeyAuthTest [ERROR] org.apache.sshd.client.auth.pubkey.HostBoundPubKeyAuthTest.testPubkeyAuth[user01_rsa_sha2_512_2048] Time elapsed: 5.598 s <<< ERROR! org.testcontainers.containers.ContainerLaunchException: Container startup failed I have Docker started on my Mac, and it should work (I have another project using test container), but maybe this is an issue with the mac OS upgrade I did 2 weeks ago. On 11/07/2022 15:34, Guillaume Nodet wrote: I've staged a candidate release at: https://repository.apache.org/content/repositories/orgapachemina-1071 Git tag: https://github.com/apache/mina-sshd/tree/sshd-2.9.0 Issues solved: https://github.com/apache/mina-sshd/blob/sshd-2.9.0/docs/changes/2.9.0.md Please review and vote ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
Hi Christoph,
I think we should have the exact same tests in MINA. Poerting them
should not take too long.
On 06/07/2022 22:51, Christoph John wrote:
Hi
You could see the failing tests here:
https://github.com/quickfix-j/quickfixj/runs/7201285514?check_suite_focus=true
Basically these are tests that should fail when using a bad certificate.
As an example here is one test that registers a filter that should get an
exception but it doesn't:
https://github.com/quickfix-j/quickfixj/blob/da21d92c32c37265ee1d4e20519832fb13a26d05/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L67
Thanks in advance and cheers
Chris
Jul 6, 2022 12:42:15 Jonathan Valliere :
What test are you trying? Emmanuel made changes from the original design
to cause it to throw on the filter. My original design threw on the filter
but only during a subsequent read or write action thereby enforcing strong
concurrency within the pipeline.
On Jul 6, 2022 at 3:53:57 AM, Christoph John
wrote:
Ok, the tests in QuickFIX/J which expect the exception to be caught in a
filter still don't work.
I recall that you also did some changes in other Apache projects to make
it work with MINA 2.2.0. Could it be that I also need to adapt something in
this regard?
Thanks
Chris
Jul 5, 2022 18:47:09 Emmanuel Lécharny :
I have tested that the exception gets propagated before launching the vote
to be clear :-)
On 05/07/2022 18:17, Christoph John wrote:
Sorry, no. The last message regarding this was:
--snip-
11.04.2022 09:37:30 Emmanuel Lécharny :
Hi Christophe,
sorry, my late mail was off base.
The pb here is that the SSLEngine excpeiton is not propagated to the
handler, when it should.
My guess is that we have some missing call somewhere in the stack. I'm
going to check that out.
On 11/04/2022 00:15, Christoph John wrote:
Hi,
thanks Jonathan and Emmanuel for working on this!
I tried to integrate this into QuickFIX/J and it compiles successfully.
However there are some tests failing that expect an Exception. For example
we have
https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
Up to now it was tried to get the Exception via a filter in the chain.
This no longer seems to work but I think I can see the error getting thrown
in the log:
SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() -
storing error {}
javax.net.ssl.SSLHandshakeException: No available authentication scheme
at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
at
java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
at
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
at
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
at
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
at
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
at
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
at
org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
I do think we need to have a look at it (and I may find some time to do
it too, as I'm in vacation in the coming week)
However, I think we should get this 2.0 out. Ther eis no problem in
releasing a fix if needed.
Thanks !
On 09/07/2022 07:17, Jonathan Valliere wrote:
Sooo… do I need to look into this or was this resolved?
On Fri, Jul 8, 2022 at 11:51 PM Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:
The changes I did were to ensure that any ouutbound data are sent
when a
TLS erroroccurs, because the Alert must be sent no matter what. This is
critical for a client to know what is the cause of the failure
(typically when a bad certificate is provided - expired, revoked,
etc -):
https://datatracker.ietf.org/doc/html/rfc5246#section-7.2
<https://datatracker.ietf.org/doc/html/rfc5246#section-7.2>
I also checked that in this case an exception is propagated up to the
IoHandler for teh server to be informed about the situuation.
On 06/07/2022 12:42, Jonathan Valliere wrote:
> What test are you trying? Emmanuel made changes from the
original design
> to cause it to throw on the filter. My original design threw on
the filter
> but only during a subsequent read or write action thereby
enforcing strong
> concurrency within the pipeline.
>
> On Jul 6, 2022 at 3:53:57 AM, Christoph John
> mailto:christoph.j...@macd.com>.invalid> wrote:
>
>> Ok, the tests in QuickFIX/J which expect the exception to be
caught in a
>> filter still don't work.
>> I recall that you also did some changes in other Apache projects
to make
>> it work with MINA 2.2.0. Could it be that I also need to adapt
something in
>> this regard?
>>
>> Thanks
>> Chris
>>
>> Jul 5, 2022 18:47:09 Emmanuel Lécharny mailto:elecha...@gmail.com>>:
>>
>> I have tested that the exception gets propagated before
launching the vote
>> to be clear :-)
>>
>>
>> On 05/07/2022 18:17, Christoph John wrote:
>>
>>> Sorry, no. The last message regarding this was:
>>
>>>
>>
>>> --snip-
>>
>>>
>>
>>> 11.04.2022 09:37:30 Emmanuel Lécharny mailto:elecha...@gmail.com>>:
>>
>>> Hi Christophe,
>>
>>> sorry, my late mail was off base.
>>
>>> The pb here is that the SSLEngine excpeiton is not propagated
to the
>> handler, when it should.
>>
>>> My guess is that we have some missing call somewhere in the
stack. I'm
>> going to check that out.
>>
>>> On 11/04/2022 00:15, Christoph John wrote:
>>
>>>> Hi,
>>
>>>> thanks Jonathan and Emmanuel for working on this!
>>
>>>> I tried to integrate this into QuickFIX/J and it compiles
successfully.
>> However there are some tests failing that expect an Exception.
For example
>> we have
>>
>>>>
>>
https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
<https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54>
>>
>>>> Up to now it was tried to get the Exception via a filter in
the chain.
>> This no longer seems to work but I think I can see the error
getting thrown
>> in the log:
>>
>>>> SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false]
task() -
>> storing error {}
>>
>>>> javax.net.ssl.SSLHandshakeException: No available
authentication scheme
>>
>>>> at
>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
>>
>>>> at
>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>>
>>>> at
>>
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
>>
>>>> at
>>
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>>
>>>> at
>>
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
>>
>>>> at
>>
java.base/sun.
Re: Exception in filter (was: Re: [Vote] MINA 2.2.0 release)
The changes I did were to ensure that any ouutbound data are sent when a
TLS erroroccurs, because the Alert must be sent no matter what. This is
critical for a client to know what is the cause of the failure
(typically when a bad certificate is provided - expired, revoked, etc -):
https://datatracker.ietf.org/doc/html/rfc5246#section-7.2
I also checked that in this case an exception is propagated up to the
IoHandler for teh server to be informed about the situuation.
On 06/07/2022 12:42, Jonathan Valliere wrote:
What test are you trying? Emmanuel made changes from the original design
to cause it to throw on the filter. My original design threw on the filter
but only during a subsequent read or write action thereby enforcing strong
concurrency within the pipeline.
On Jul 6, 2022 at 3:53:57 AM, Christoph John
wrote:
Ok, the tests in QuickFIX/J which expect the exception to be caught in a
filter still don't work.
I recall that you also did some changes in other Apache projects to make
it work with MINA 2.2.0. Could it be that I also need to adapt something in
this regard?
Thanks
Chris
Jul 5, 2022 18:47:09 Emmanuel Lécharny :
I have tested that the exception gets propagated before launching the vote
to be clear :-)
On 05/07/2022 18:17, Christoph John wrote:
Sorry, no. The last message regarding this was:
--snip-
11.04.2022 09:37:30 Emmanuel Lécharny :
Hi Christophe,
sorry, my late mail was off base.
The pb here is that the SSLEngine excpeiton is not propagated to the
handler, when it should.
My guess is that we have some missing call somewhere in the stack. I'm
going to check that out.
On 11/04/2022 00:15, Christoph John wrote:
Hi,
thanks Jonathan and Emmanuel for working on this!
I tried to integrate this into QuickFIX/J and it compiles successfully.
However there are some tests failing that expect an Exception. For example
we have
https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
Up to now it was tried to get the Exception via a filter in the chain.
This no longer seems to work but I think I can see the error getting thrown
in the log:
SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() -
storing error {}
javax.net.ssl.SSLHandshakeException: No available authentication scheme
at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
at
java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
at
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
at
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
at
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
at
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
at
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
at
org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122
Re: [Vote] MINA 2.2.0 release
I have tested that the exception gets propagated before launching the
vote to be clear :-)
On 05/07/2022 18:17, Christoph John wrote:
Sorry, no. The last message regarding this was:
--snip-
11.04.2022 09:37:30 Emmanuel Lécharny :
Hi Christophe,
sorry, my late mail was off base.
The pb here is that the SSLEngine excpeiton is not propagated to the handler,
when it should.
My guess is that we have some missing call somewhere in the stack. I'm going to
check that out.
On 11/04/2022 00:15, Christoph John wrote:
Hi,
thanks Jonathan and Emmanuel for working on this!
I tried to integrate this into QuickFIX/J and it compiles successfully. However
there are some tests failing that expect an Exception. For example we have
https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
Up to now it was tried to get the Exception via a filter in the chain. This no
longer seems to work but I think I can see the error getting thrown in the log:
SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() - storing
error {}
javax.net.ssl.SSLHandshakeException: No available authentication scheme
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
at
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
at
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
at
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
at
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
at
org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
at org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
at org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1213)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
What is the new way to get this Exception?
NB: I recall discussing this with Jonathan some months ago but seem to have
lost
Re: [Vote] MINA 2.2.0 release
Hi Christoph, yes. I guess you tested it already. On 05/07/2022 09:38, Christoph John wrote: Hi Emmanuel Did you manage to fix the bug which we talked about in the mail thread from May regarding the M1 milestone? Thanks Chris 04.07.2022 23:43:37 Emmanuel Lécharny : Hi! it has been a couple of months now that I cut a version of MINA 2.2.0, but haven't started a vote, because I wanted to test that exception were properly handled when generated from the SslFilter. It took may way longer to check that, mainly due to external factors). Anyway, I'm done with the test, all is nominal, so here is a formal vote for MINA 2.2.0. This version comes with a complete rewrite of the SSL layer, thanks for Jonathan hard work ! A temporary tag has been created (it can be removed if the vote is not approved) : https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4 The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-1051 The distributions are available for download on : https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0 Let us vote : [ ] +1 | Release MINA 2.2.0 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.2.0 -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [Vote] MINA 2.2.0 release
Ah, sorry, copy/paste error:
https://repository.apache.org/content/repositories/orgapachemina-1070/
On 05/07/2022 08:02, Jeff MAURY wrote:
Staging repo is not available
On Mon, Jul 4, 2022 at 11:43 PM Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:
Hi!
it has been a couple of months now that I cut a version of MINA 2.2.0,
but haven't started a vote, because I wanted to test that exception
were
properly handled when generated from the SslFilter. It took may way
longer to check that, mainly due to external factors).
Anyway, I'm done with the test, all is nominal, so here is a formal
vote
for MINA 2.2.0.
This version comes with a complete rewrite of the SSL layer, thanks for
Jonathan hard work !
A temporary tag has been created (it can be removed if the vote is not
approved) :
https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4
<https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4>
The newly approved Nexus has been used for the preparation of this
release and all final artifacts are stored in a staging repository:
https://repository.apache.org/content/repositories/orgapachemina-1051
<https://repository.apache.org/content/repositories/orgapachemina-1051>
The distributions are available for download on :
https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0
<https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0>
Let us vote :
[ ] +1 | Release MINA 2.2.0
[ ] ± | Abstain
[ ] -1 | Do *NOT* release MINA 2.2.0
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com>
https://www.busit.com/ <https://www.busit.com/>
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
<mailto:dev-unsubscr...@mina.apache.org>
For additional commands, e-mail: dev-h...@mina.apache.org
<mailto:dev-h...@mina.apache.org>
--
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
- Bjarne Stroustrup
http://www.jeffmaury.com <http://www.jeffmaury.com>
http://riadiscuss.jeffmaury.com <http://riadiscuss.jeffmaury.com>
http://www.twitter.com/jeffmaury <http://www.twitter.com/jeffmaury>
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[Vote] MINA 2.2.0 release
Hi! it has been a couple of months now that I cut a version of MINA 2.2.0, but haven't started a vote, because I wanted to test that exception were properly handled when generated from the SslFilter. It took may way longer to check that, mainly due to external factors). Anyway, I'm done with the test, all is nominal, so here is a formal vote for MINA 2.2.0. This version comes with a complete rewrite of the SSL layer, thanks for Jonathan hard work ! A temporary tag has been created (it can be removed if the vote is not approved) : https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=7d8930d7f47dc94c4f155b77e074d4384b34c5e4 The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-1051 The distributions are available for download on : https://dist.apache.org/repos/dist/dev/mina/mina/2.2.0 Let us vote : [ ] +1 | Release MINA 2.2.0 [ ] ± | Abstain [ ] -1 | Do *NOT* release MINA 2.2.0 -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Where is the HTTP WRAPPED method coming from?
Hi Jonathan, I see that you added the LINK, UNLINK methods in the HttpMehod class on March, 25, 2018, and that's fine. But where is teh WRAPPED method coming from ? I can't find out the root for this method. Thanks ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Has anyone ever used the HTTP Module?
Hi ! Just wondering if anyone has ever used this module. To me, it seems *really* like a proof of concept. Thanks ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: MINA and TLS 1.3 (1ms sleep hack?)
Hi Guus,
On 05/05/2022 17:35, Guus der Kinderen wrote:
Hi everyone,
Apologies for taking a long time to get this tested, but things got
complicated.
Long story short: the issue with TLS v1.3 that I described (needing a
1ms wait around the TLS handshake) does no longer seem to exist with
commit 7d8930d7f47dc94c4f155b77e074d4384b34c5e4 / tag 2.2.0 of Apache MINA.
... unless I have repeatedly messed up testing, which happens with many
moving parts. I'd love a second pair of eyes confirming this.
I have fixed a nasty issue that was causing some issue
(https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=f64544006e9714541e1b472cef5be58148a3fd01)
As a couple of asides:
I'm not particularly fond of the StartTlsFilter approach, because its
implementation is tied to whatever protocol that you're using.
Hmmm, not sure to understand what you mean. The SslFilter will always be
first in the chain, so the protocol you are using is pretty irrelevant.
As we're
using XMPP, not LDAP, the StartTlsResponse class comparison didn't fly.
Ok, you mean StartTLS specific for your protocol. True that it is an
issue because the first response you will send *must* be in clear text,
in order to inform the client that the startTLS message has been
received. That collides with the fact that the SSL filter has already
been added to the chain, so you must bypass this filter when sending
this response.
Jonathan has added a specific class for that purpose, which can be used
to send the clear text message without being handled by the SslFilter.
For LDAP and FTP, I have added a specific filter that bypass the SSL
filter when the StartTLS response is sent, but it's kind of a protocol
trick, I agree.
In MINA 2.0/2.1, it was handled differently, with an Attribute flag that
said 'please SSLFilter, do *not* handled the *next* message and only the
*next* message'. This is also a kind of hack.
Jonathan solution is probably better, but it has to be used at the
Adapter level.
The thing here is that we might have decided to do that:
- send back the clear text message
- install the SSLFilter
but that does not fly because we may receive the ClientHello message
*before* the SslFilter is installed.
Instead, I resorted to this:
if (writeRequest.getOriginalMessage()instanceof IoBuffer &&
((IoBuffer) writeRequest.getOriginalMessage()).hasArray() &&
new String(((IoBuffer) writeRequest.getOriginalMessage()).array()).trim().equals("") )
(Which probably can be made smarter). Another downside of this is that
it will add a considerable amount of processing to each request if you
neglect to remove the filter after usage.
I'm not sure if Jonathan's suggestion is better, in that respect. I'm
not familiar enough with MINA to understand what is suggested.
Unrelated, since e2e0f2561fe51374091f6a943b462198c62d2b14 the build
requires Maven version 3.8 or later. Why is this? The build seems to run
fine with 3.6.3 - which is the version that is made available through
Ubuntu's 20.04 package manager.
If there is a reason to require a specific version, then maybe it could
be considered to add a Maven Wrapper (mvnw) to the project. If there's
no such requirement, then maybe drop the requirement, as to not throw up
unexpected and unneeded hurdles?
That is my fault. I may move back to an older version of maven for the
official release, if needed. I'm currently tracking another issue that
made me freeze the 2.2.0 release.
`
Kind regards,
Guus
On Fri, Apr 1, 2022 at 1:29 PM Jonathan Valliere
mailto:jon.valli...@emoten.com>> wrote:
Another way to do that is to have the SslFilter -> Your Clear Text
Control Plane Filter
The Control Plane Filter can conditionally wrap a WriteRequest in a
DisableEncryptWriteRequest. This guarantees that ONLY that message
bypasses the SslFilter
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally
protected from disclosure.
On Mar 31, 2022 at 4:34:18 PM, Emmanuel Lécharny
mailto:elecha...@gmail.com>> wrote:
Hi Guus,
On 31/03/2022 19:43, Guus der Kinderen wrote:
Thanks for the fast response Emmanuel,
Although I was able to build 2.2.0-SNAPSHOT, it doesn't seem to
be API
compatible with 2.1.3.
Things that I ran into:
* SslFilter.DISABLE_ENCRYPTION_ONCE no longer exists (which we
use to
implement StartTLS).
Yes, it was a source of problem. The way we deal with the
requirement to
send the StartTLS response in clear text *before* setting the
SslFilter
now is to use a dedicated filter. here is what we do in Apache
Diectory
Server:
public class StartTlsFilter extends IoFilterAdapter
{
/**
* {@inheritDoc}
Re: GitHub Action builds
Super, thanks Gregory ! On 11/04/2022 15:57, Gary Gregory wrote: Hi All: I enabled GitHub Actions builds which will give us quick feedback on PRs as well as sanity checks for building and testing on Java LTS versions. See https://github.com/apache/mina-ftpserver/actions Gary -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: MINA 2.2.0-M1
Hi! I've made a slight mistake yesterday evening (or should I say this early this morning): I name the release 2.2.0. I haven't yet launch the vote, so I may revert and delete the release to name it 2.2.0-M1, and also check the pb Cristoph is mentionning (the non propagation of an exception to the IoAdapter when the SSLEngine throw it). I'll keep you inform... On 09/04/2022 00:26, Emmanuel Lécharny wrote: Hi ! I will start to cut a first milestone for the MINA 2.2.X branch. It has been tested on Apache Ftpserver, Ldap API and Directory Server with success. There will probably be more milestone, but that would be a first step. The main changes are: - a complete redesign of the TLS handling - the removal of the SslFilter.DISABLE_ENCRYPTION_ONCE attribute, which is either replaced by a dedicated filter, or the encapsulation of the message in a DisableEncryptWriteRequest interface I'll do that this week-end. Thanks ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: MINA 2.2.0-M1
Hi Christophe,
sorry, my late mail was off base.
The pb here is that the SSLEngine excpeiton is not propagated to the
handler, when it should.
My guess is that we have some missing call somewhere in the stack. I'm
going to check that out.
On 11/04/2022 00:15, Christoph John wrote:
Hi,
thanks Jonathan and Emmanuel for working on this!
I tried to integrate this into QuickFIX/J and it compiles successfully.
However there are some tests failing that expect an Exception. For
example we have
https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
Up to now it was tried to get the Exception via a filter in the chain.
This no longer seems to work but I think I can see the error getting
thrown in the log:
SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() -
storing error {}
javax.net.ssl.SSLHandshakeException: No available authentication scheme
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
at
java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
at
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
at
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
at
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
at
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
at
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
at
org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1213)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
What is the new way to get this Exception?
NB: I recall discussing this with Jonathan some months ago but seem to
have lost track of the mail thread.
Thanks in advance,
Chris.
On 09.04.22 00:26, Emmanuel Lécharny wrote:
Hi !
I will start to cut a first milestone for the MINA 2.2.X branch. It
has
Re: MINA 2.2.0-M1
Hi Christoph,
I faced the issue too. The way it now works is that MINA will send a TLS
Alert message which should contain the root cause.
It's a little bit late here for me to dig in the Apache FTPServer code
where we were facing the issue, I'll do that tomorrow.
On 11/04/2022 00:15, Christoph John wrote:
Hi,
thanks Jonathan and Emmanuel for working on this!
I tried to integrate this into QuickFIX/J and it compiles successfully.
However there are some tests failing that expect an Exception. For
example we have
https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
Up to now it was tried to get the Exception via a filter in the chain.
This no longer seems to work but I think I can see the error getting
thrown in the log:
SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false] task() -
storing error {}
javax.net.ssl.SSLHandshakeException: No available authentication scheme
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
at
java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
at
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
at
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
at
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
at
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
at
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
at
org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1213)
at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
What is the new way to get this Exception?
NB: I recall discussing this with Jonathan some months ago but seem to
have lost track of the mail thread.
Thanks in advance,
Chris.
On 09.04.22 00:26, Emmanuel Lécharny wrote:
Hi !
I will start to cut a first milestone
MINA 2.2.0-M1
Hi ! I will start to cut a first milestone for the MINA 2.2.X branch. It has been tested on Apache Ftpserver, Ldap API and Directory Server with success. There will probably be more milestone, but that would be a first step. The main changes are: - a complete redesign of the TLS handling - the removal of the SslFilter.DISABLE_ENCRYPTION_ONCE attribute, which is either replaced by a dedicated filter, or the encapsulation of the message in a DisableEncryptWriteRequest interface I'll do that this week-end. Thanks ! -- *Emmanuel Lécharny* - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Releasing a MINA 2.2.0-alpha soon ?
Ok, tested MINA 2.2.0-SNAPSHOT with FtpServer, Apache LDAP API and
Apache Directoryserver, all is good.
May we cut a milestone ?
On 01/04/2022 18:56, Emmanuel Lécharny wrote:
Yu didn't cause any problem. This is just a bug, anybody could have been
caught by this one. I didn't expect that the state would be squashed if
you apply both NEED and WANT flag, and IMHO, it's a very bad API design
from Sun.
It was painful to find because I had to go deep into the Java SSL code
to understand what was going on, narrowing the issue little by little
comparing Mina 2.1 with 2.2 behaviors. Once I get to the point where I
knew it was an issue with the ClientAuthType propagation, it's was quite
easy to fix. Plus it was hidden by some side issues with the FtpServer
migration to MINA 2.2 (typically the clear text response to be sent
before the SSLFilter activation)
Anyway, I'm glad to have fixed it.
If you can find the bug request you are referring, that would be good
and if the correction also fixes this bug, this will just be extra bonus !
On 01/04/2022 18:42, Jonathan Valliere wrote:
Did I cause that problem because I remember there being a bug requestOk, tested
because we weren’t applying the Need and Want from the Impl config.
On Fri, Apr 1, 2022 at 10:55 AM Emmanuel Lécharny
wrote:
Got it !!!
What a nasty bug it was...
The new SslFilter.createEngine() method was doing:
protected SSLEngine createEngine(IoSession session, InetSocketAddress
addr) {
SSLEngine sslEngine = (addr != null) ?
sslContext.createSSLEngine(addr.getHostString(), addr.getPort())
: sslContext.createSSLEngine();
sslEngine.setNeedClientAuth(needClientAuth);
sslEngine.setWantClientAuth(wantClientAuth);
...
And in SslEngineImpl :
public synchronized void setNeedClientAuth(boolean need) {
conContext.sslConfig.clientAuthType =
(need ? ClientAuthType.CLIENT_AUTH_REQUIRED :
ClientAuthType.CLIENT_AUTH_NONE);
}
plus
public synchronized void setWantClientAuth(boolean want) {
conContext.sslConfig.clientAuthType =
(want ? ClientAuthType.CLIENT_AUTH_REQUESTED :
ClientAuthType.CLIENT_AUTH_NONE);
}
when you set Need & Want, the later wins. Here, I had Need but not Want,
so it ends with ClientAuthType.CLIENT_AUTH_NONE :/
You can't have both, you need to pick the one that has to be set and
ignore the other. In MINA 2.1.5, we have :
// Those parameters are only valid when in server mode
if (sslFilter.isWantClientAuth()) {
sslEngine.setWantClientAuth(true);
}
if (sslFilter.isNeedClientAuth()) {
sslEngine.setNeedClientAuth(true);
}
which only call the proper setting. Of course, if you set both to true,
you'll end with NEED, which is just fine.
On 01/04/2022 16:18, Emmanuel Lécharny wrote:
Some progress:
With MINA 2.1.5, the SSLEngine.SSLConfiguration instance has the
clientAuthType set to CLIENT_AUTH_REQUIRED, while in MINA 2.2.0, it's
set to CLIENT_AUTH_NONE. That explain why the CertificateRequest is not
sent to the client.
Now to understand why this flag is improperly set...
On 01/04/2022 11:06, Emmanuel Lécharny wrote:
Still fighting...
When using MINA 2.1.6, I see that the client (FTPSCLient, a java class
that is not using MINA) sends a client Certificate to the server after
having received a CertificateRequest:
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.544
CEST|CertificateRequest.java:692|Consuming CertificateRequest
handshake message (
"CertificateRequest": {
"certificate types": [ecdsa_sign, rsa_sign, dss_sign]
"supported signature algorithms": [ecdsa_secp256r1_sha256,
ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256,
rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256,
rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224,
rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
"certificate authorities": [CN=ftpserver, CN=ftpclient]
}
)
...
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.546
CEST|ServerHelloDone.java:151|Consuming ServerHelloDone handshake
message (
)
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.547
CEST|CertificateMessage.java:330|Produced client Certificate handshake
message (
"Certificates": [
"certificate" : {
"version" : "v3",
"serial number" : "60 38 4B B4",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=ftpclient",
"not before" : "2021-02-26 02:15:32.000 CET",
"not after" : "2031-02-26 02:15:32.000 CET",
"subje
Re: Releasing a MINA 2.2.0-alpha soon ?
Hi! whener ‹e do a mvn deploy, the snapshots are deployed to https://repository.apache.org/content/repositories/snapshots/org/apache/mina/mina-core/2.2.0-SNAPSHOT/ It's enough to specify this repository in your parent pom to get it found: ... apache.snapshots Apache Snapshot Repository https://repository.apache.org/content/repositories/snapshots false true On 01/04/2022 19:44, Christoph John wrote: Just a quick question: are the 2.2.0-SNAPSHOT builds continously being uploaded or do you need to trigger this manually? Thanks Am 1. April 2022 18:56:35 MESZ schrieb "Emmanuel Lécharny" : Yu didn't cause any problem. This is just a bug, anybody could have been caught by this one. I didn't expect that the state would be squashed if you apply both NEED and WANT flag, and IMHO, it's a very bad API design from Sun. It was painful to find because I had to go deep into the Java SSL code to understand what was going on, narrowing the issue little by little comparing Mina 2.1 with 2.2 behaviors. Once I get to the point where I knew it was an issue with the ClientAuthType propagation, it's was quite easy to fix. Plus it was hidden by some side issues with the FtpServer migration to MINA 2.2 (typically the clear text response to be sent before the SSLFilter activation) Anyway, I'm glad to have fixed it. If you can find the bug request you are referring, that would be good and if the correction also fixes this bug, this will just be extra bonus ! On 01/04/2022 18:42, Jonathan Valliere wrote: Did I cause that problem because I remember there being a bug request becaus - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Releasing a MINA 2.2.0-alpha soon ?
Yu didn't cause any problem. This is just a bug, anybody could have been
caught by this one. I didn't expect that the state would be squashed if
you apply both NEED and WANT flag, and IMHO, it's a very bad API design
from Sun.
It was painful to find because I had to go deep into the Java SSL code
to understand what was going on, narrowing the issue little by little
comparing Mina 2.1 with 2.2 behaviors. Once I get to the point where I
knew it was an issue with the ClientAuthType propagation, it's was quite
easy to fix. Plus it was hidden by some side issues with the FtpServer
migration to MINA 2.2 (typically the clear text response to be sent
before the SSLFilter activation)
Anyway, I'm glad to have fixed it.
If you can find the bug request you are referring, that would be good
and if the correction also fixes this bug, this will just be extra bonus !
On 01/04/2022 18:42, Jonathan Valliere wrote:
Did I cause that problem because I remember there being a bug request
because we weren’t applying the Need and Want from the Impl config.
On Fri, Apr 1, 2022 at 10:55 AM Emmanuel Lécharny
wrote:
Got it !!!
What a nasty bug it was...
The new SslFilter.createEngine() method was doing:
protected SSLEngine createEngine(IoSession session, InetSocketAddress
addr) {
SSLEngine sslEngine = (addr != null) ?
sslContext.createSSLEngine(addr.getHostString(), addr.getPort())
: sslContext.createSSLEngine();
sslEngine.setNeedClientAuth(needClientAuth);
sslEngine.setWantClientAuth(wantClientAuth);
...
And in SslEngineImpl :
public synchronized void setNeedClientAuth(boolean need) {
conContext.sslConfig.clientAuthType =
(need ? ClientAuthType.CLIENT_AUTH_REQUIRED :
ClientAuthType.CLIENT_AUTH_NONE);
}
plus
public synchronized void setWantClientAuth(boolean want) {
conContext.sslConfig.clientAuthType =
(want ? ClientAuthType.CLIENT_AUTH_REQUESTED :
ClientAuthType.CLIENT_AUTH_NONE);
}
when you set Need & Want, the later wins. Here, I had Need but not Want,
so it ends with ClientAuthType.CLIENT_AUTH_NONE :/
You can't have both, you need to pick the one that has to be set and
ignore the other. In MINA 2.1.5, we have :
// Those parameters are only valid when in server mode
if (sslFilter.isWantClientAuth()) {
sslEngine.setWantClientAuth(true);
}
if (sslFilter.isNeedClientAuth()) {
sslEngine.setNeedClientAuth(true);
}
which only call the proper setting. Of course, if you set both to true,
you'll end with NEED, which is just fine.
On 01/04/2022 16:18, Emmanuel Lécharny wrote:
Some progress:
With MINA 2.1.5, the SSLEngine.SSLConfiguration instance has the
clientAuthType set to CLIENT_AUTH_REQUIRED, while in MINA 2.2.0, it's
set to CLIENT_AUTH_NONE. That explain why the CertificateRequest is not
sent to the client.
Now to understand why this flag is improperly set...
On 01/04/2022 11:06, Emmanuel Lécharny wrote:
Still fighting...
When using MINA 2.1.6, I see that the client (FTPSCLient, a java class
that is not using MINA) sends a client Certificate to the server after
having received a CertificateRequest:
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.544
CEST|CertificateRequest.java:692|Consuming CertificateRequest
handshake message (
"CertificateRequest": {
"certificate types": [ecdsa_sign, rsa_sign, dss_sign]
"supported signature algorithms": [ecdsa_secp256r1_sha256,
ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256,
rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256,
rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224,
rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
"certificate authorities": [CN=ftpserver, CN=ftpclient]
}
)
...
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.546
CEST|ServerHelloDone.java:151|Consuming ServerHelloDone handshake
message (
)
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.547
CEST|CertificateMessage.java:330|Produced client Certificate handshake
message (
"Certificates": [
"certificate" : {
"version": "v3",
"serial number" : "60 38 4B B4",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=ftpclient",
"not before" : "2021-02-26 02:15:32.000 CET",
"not after" : "2031-02-26 02:15:32.000 CET",
"subject": "CN=ftpclient",
"subject public key" : "RSA"}
]
)
...
With MINA 2.2.0, I don't see any CertificateRequest being sent by the
s
Re: Releasing a MINA 2.2.0-alpha soon ?
Got it !!!
What a nasty bug it was...
The new SslFilter.createEngine() method was doing:
protected SSLEngine createEngine(IoSession session, InetSocketAddress
addr) {
SSLEngine sslEngine = (addr != null) ?
sslContext.createSSLEngine(addr.getHostString(), addr.getPort())
: sslContext.createSSLEngine();
sslEngine.setNeedClientAuth(needClientAuth);
sslEngine.setWantClientAuth(wantClientAuth);
...
And in SslEngineImpl :
public synchronized void setNeedClientAuth(boolean need) {
conContext.sslConfig.clientAuthType =
(need ? ClientAuthType.CLIENT_AUTH_REQUIRED :
ClientAuthType.CLIENT_AUTH_NONE);
}
plus
public synchronized void setWantClientAuth(boolean want) {
conContext.sslConfig.clientAuthType =
(want ? ClientAuthType.CLIENT_AUTH_REQUESTED :
ClientAuthType.CLIENT_AUTH_NONE);
}
when you set Need & Want, the later wins. Here, I had Need but not Want,
so it ends with ClientAuthType.CLIENT_AUTH_NONE :/
You can't have both, you need to pick the one that has to be set and
ignore the other. In MINA 2.1.5, we have :
// Those parameters are only valid when in server mode
if (sslFilter.isWantClientAuth()) {
sslEngine.setWantClientAuth(true);
}
if (sslFilter.isNeedClientAuth()) {
sslEngine.setNeedClientAuth(true);
}
which only call the proper setting. Of course, if you set both to true,
you'll end with NEED, which is just fine.
On 01/04/2022 16:18, Emmanuel Lécharny wrote:
Some progress:
With MINA 2.1.5, the SSLEngine.SSLConfiguration instance has the
clientAuthType set to CLIENT_AUTH_REQUIRED, while in MINA 2.2.0, it's
set to CLIENT_AUTH_NONE. That explain why the CertificateRequest is not
sent to the client.
Now to understand why this flag is improperly set...
On 01/04/2022 11:06, Emmanuel Lécharny wrote:
Still fighting...
When using MINA 2.1.6, I see that the client (FTPSCLient, a java class
that is not using MINA) sends a client Certificate to the server after
having received a CertificateRequest:
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.544
CEST|CertificateRequest.java:692|Consuming CertificateRequest
handshake message (
"CertificateRequest": {
"certificate types": [ecdsa_sign, rsa_sign, dss_sign]
"supported signature algorithms": [ecdsa_secp256r1_sha256,
ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256,
rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256,
rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224,
rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
"certificate authorities": [CN=ftpserver, CN=ftpclient]
}
)
...
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.546
CEST|ServerHelloDone.java:151|Consuming ServerHelloDone handshake
message (
)
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.547
CEST|CertificateMessage.java:330|Produced client Certificate handshake
message (
"Certificates": [
"certificate" : {
"version" : "v3",
"serial number" : "60 38 4B B4",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=ftpclient",
"not before" : "2021-02-26 02:15:32.000 CET",
"not after" : "2031-02-26 02:15:32.000 CET",
"subject" : "CN=ftpclient",
"subject public key" : "RSA"}
]
)
...
With MINA 2.2.0, I don't see any CertificateRequest being sent by the
server. Which I don't understand, because the NeedClientAuth flag is
set to true...
Still investigating
On 31/03/2022 14:38, Emmanuel Lécharny wrote:
Ok, pb fixed with an added filter.
Now, I still get a NPE while trying to access the peerCertificate
from the session, even after the Handshake has been completed...
On 30/03/2022 18:02, Emmanuel Lécharny wrote:
Hi Jonathan,
no, it's just that we try to send a clear text message after having
set the SSLFilter, pretty much as what we had to workaround in
Directory. I'm going to fix that.
On 25/03/2022 19:48, Jonathan Valliere wrote:
Are you trying to get the peer cert after the filter emits the
connected
after the handshake completes? If you do it too early it won’t
populate.
On Fri, Mar 25, 2022 at 2:33 PM Emmanuel Lécharny
wrote:
Hi!
following the effort put in rewriting the Sslfilter (and all the
inner
code) by Jonathan lately, I would like to know if we could mive
forward
with an alpha version of this work.
I have tested it with Apache LDAP API and Apache Directory Server,
with
success. I still have some work to do on FtpServer to have it working
with 2.
Re: Releasing a MINA 2.2.0-alpha soon ?
Some progress:
With MINA 2.1.5, the SSLEngine.SSLConfiguration instance has the
clientAuthType set to CLIENT_AUTH_REQUIRED, while in MINA 2.2.0, it's
set to CLIENT_AUTH_NONE. That explain why the CertificateRequest is not
sent to the client.
Now to understand why this flag is improperly set...
On 01/04/2022 11:06, Emmanuel Lécharny wrote:
Still fighting...
When using MINA 2.1.6, I see that the client (FTPSCLient, a java class
that is not using MINA) sends a client Certificate to the server after
having received a CertificateRequest:
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.544
CEST|CertificateRequest.java:692|Consuming CertificateRequest handshake
message (
"CertificateRequest": {
"certificate types": [ecdsa_sign, rsa_sign, dss_sign]
"supported signature algorithms": [ecdsa_secp256r1_sha256,
ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256,
rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256,
rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224,
rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
"certificate authorities": [CN=ftpserver, CN=ftpclient]
}
)
...
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.546
CEST|ServerHelloDone.java:151|Consuming ServerHelloDone handshake message (
)
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.547
CEST|CertificateMessage.java:330|Produced client Certificate handshake
message (
"Certificates": [
"certificate" : {
"version" : "v3",
"serial number" : "60 38 4B B4",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=ftpclient",
"not before" : "2021-02-26 02:15:32.000 CET",
"not after" : "2031-02-26 02:15:32.000 CET",
"subject" : "CN=ftpclient",
"subject public key" : "RSA"}
]
)
...
With MINA 2.2.0, I don't see any CertificateRequest being sent by the
server. Which I don't understand, because the NeedClientAuth flag is set
to true...
Still investigating
On 31/03/2022 14:38, Emmanuel Lécharny wrote:
Ok, pb fixed with an added filter.
Now, I still get a NPE while trying to access the peerCertificate from
the session, even after the Handshake has been completed...
On 30/03/2022 18:02, Emmanuel Lécharny wrote:
Hi Jonathan,
no, it's just that we try to send a clear text message after having
set the SSLFilter, pretty much as what we had to workaround in
Directory. I'm going to fix that.
On 25/03/2022 19:48, Jonathan Valliere wrote:
Are you trying to get the peer cert after the filter emits the
connected
after the handshake completes? If you do it too early it won’t
populate.
On Fri, Mar 25, 2022 at 2:33 PM Emmanuel Lécharny
wrote:
Hi!
following the effort put in rewriting the Sslfilter (and all the inner
code) by Jonathan lately, I would like to know if we could mive
forward
with an alpha version of this work.
I have tested it with Apache LDAP API and Apache Directory Server,
with
success. I still have some work to do on FtpServer to have it working
with 2.2.X, we get some NPE when trying to fetch the peer certificate
from the SSLSession (for some unkown reason, when I call
sslSession.getPeerCertiticate() it returns null).
Wdyt ?
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
<https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g>
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
Re: Releasing a MINA 2.2.0-alpha soon ?
Still fighting...
When using MINA 2.1.6, I see that the client (FTPSCLient, a java class
that is not using MINA) sends a client Certificate to the server after
having received a CertificateRequest:
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.544
CEST|CertificateRequest.java:692|Consuming CertificateRequest handshake
message (
"CertificateRequest": {
"certificate types": [ecdsa_sign, rsa_sign, dss_sign]
"supported signature algorithms": [ecdsa_secp256r1_sha256,
ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256,
rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256,
rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224,
rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
"certificate authorities": [CN=ftpserver, CN=ftpclient]
}
)
...
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.546
CEST|ServerHelloDone.java:151|Consuming ServerHelloDone handshake message (
)
javax.net.ssl|FINE|01|main|2022-04-01 09:58:48.547
CEST|CertificateMessage.java:330|Produced client Certificate handshake
message (
"Certificates": [
"certificate" : {
"version": "v3",
"serial number" : "60 38 4B B4",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=ftpclient",
"not before" : "2021-02-26 02:15:32.000 CET",
"not after" : "2031-02-26 02:15:32.000 CET",
"subject": "CN=ftpclient",
"subject public key" : "RSA"}
]
)
...
With MINA 2.2.0, I don't see any CertificateRequest being sent by the
server. Which I don't understand, because the NeedClientAuth flag is set
to true...
Still investigating
On 31/03/2022 14:38, Emmanuel Lécharny wrote:
Ok, pb fixed with an added filter.
Now, I still get a NPE while trying to access the peerCertificate from
the session, even after the Handshake has been completed...
On 30/03/2022 18:02, Emmanuel Lécharny wrote:
Hi Jonathan,
no, it's just that we try to send a clear text message after having
set the SSLFilter, pretty much as what we had to workaround in
Directory. I'm going to fix that.
On 25/03/2022 19:48, Jonathan Valliere wrote:
Are you trying to get the peer cert after the filter emits the connected
after the handshake completes? If you do it too early it won’t populate.
On Fri, Mar 25, 2022 at 2:33 PM Emmanuel Lécharny
wrote:
Hi!
following the effort put in rewriting the Sslfilter (and all the inner
code) by Jonathan lately, I would like to know if we could mive forward
with an alpha version of this work.
I have tested it with Apache LDAP API and Apache Directory Server, with
success. I still have some work to do on FtpServer to have it working
with 2.2.X, we get some NPE when trying to fetch the peer certificate
from the SSLSession (for some unkown reason, when I call
sslSession.getPeerCertiticate() it returns null).
Wdyt ?
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
<https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g>
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
Re: MINA and TLS 1.3 (1ms sleep hack?)
Hi Guus,
On 31/03/2022 19:43, Guus der Kinderen wrote:
Thanks for the fast response Emmanuel,
Although I was able to build 2.2.0-SNAPSHOT, it doesn't seem to be API
compatible with 2.1.3.
Things that I ran into:
* SslFilter.DISABLE_ENCRYPTION_ONCE no longer exists (which we use to
implement StartTLS).
Yes, it was a source of problem. The way we deal with the requirement to
send the StartTLS response in clear text *before* setting the SslFilter
now is to use a dedicated filter. here is what we do in Apache Diectory
Server:
public class StartTlsFilter extends IoFilterAdapter
{
/**
* {@inheritDoc}
*/
@Override
public void filterWrite( NextFilter nextFilter, IoSession session,
WriteRequest writeRequest ) throws Exception
{
if ( writeRequest.getOriginalMessage() instanceof
StartTlsResponse )
{
// We need to bypass the SslFilter
IoFilterChain chain = session.getFilterChain();
for ( IoFilterChain.Entry entry : chain.getAll() )
{
IoFilter filter = entry.getFilter();
if ( filter instanceof SslFilter )
{
entry.getNextFilter().filterWrite( session,
writeRequest );
}
}
}
else
{
nextFilter.filterWrite( session, writeRequest );
}
}
}
This is pretty straight forward: when we go through this filter with a
StartTLS response message, we bypass the SslFilter, otherwise we call it.
* SslFilter.SSL_SESSION no longer exists. Is SslFilter.SSL_SECURED a
drop-in replacement?
Yes. For instance, in FtpServer:
if (getFilterChain().contains(SslFilter.class)) {
SSLSession sslSession =
(SSLSession)getAttribute(SslFilter.SSL_SECURED);
* SslFilter.setUseClientMode(boolean) no longer exists.
It's computed automatically:
sslEngine.setUseClientMode(!session.isServer());
You may want to add the isServer() method in your IoSession
implementation, but by default it's defined in the AbstractIoSession to be :
@Override
public boolean isServer() {
return (getService() instanceof IoAcceptor);
}
WIth all that commented out, I'm still getting errors, but I'm not sure
if that's the same error, or if I'm now seeing a new error because I
broke StartTLS (which our test depends on)
Most certainly it's broken because of teh lack of clear text response
before the filter is set. See the added filter upper.
On Thu, Mar 31, 2022 at 3:37 PM Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:
Hi Guus,
I have successfully ran Apache Directory LDAP API and Server with MINA
2.2.0-SNAPSHOT, which has a fully rewritten SSL handling code.
It seems there are some kind of race condition in MINA 2.0.X/2.1.X
and I
expect MINA 2.2.X solve this issue.
Could you give it a try ? You'll have to build the 2.2.X branch:
$ git clone -b 2.2.X https://gitbox.apache.org/repos/asf/mina.git
<https://gitbox.apache.org/repos/asf/mina.git> mina-2.2.X
$ cd mina-2.2.X
$ mvn clean install
Just let me know if it's any better...
On 31/03/2022 14:53, Guus der Kinderen wrote:
> Hi Emanuel,
>
> I remember that you wrote that you were engaged in an epic battle
with
> an elusive TLS 1.3 bug in MINA. I'm now running into an issue
that is
> specific to TLS 1.3, which occurs in MINA 2.1.3 as well as 2.1.6
(I did
> not try other versions), and does /not/ occur with a connection
manager
> that is not powered by MINA.
>
> The work-around that a third party developer found is surprising.
They
> add a 1ms delay before starting to send data over a socket that
has just
> finished the TLS handshake. With that delay, the problem is
consistently
> gone. Without that delay, it consistently is reproducible.
>
> Their evaluation of the problem is documented here:
> https://github.com/xmppjs/xmpp.js/issues/889
<https://github.com/xmppjs/xmpp.js/issues/889>
> <https://github.com/xmppjs/xmpp.js/issues/889
<https://github.com/xmppjs/xmpp.js/issues/889>>
>
> My questions:
>
> * Does this relate to the issue that you were trying to solve?
> * Why do we _consistently_ suffer from this, assuming that
others are
> able to use MINA with TLS 1.3 at least some of the time?
> * How do we prevent this issue without depending on the client
> applying the 1ms sleep workaroud?
>
> Kind regards,
>
> Guus
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com>
Re: Releasing a MINA 2.2.0-alpha soon ?
Ok, pb fixed with an added filter. Now, I still get a NPE while trying to access the peerCertificate from the session, even after the Handshake has been completed... On 30/03/2022 18:02, Emmanuel Lécharny wrote: Hi Jonathan, no, it's just that we try to send a clear text message after having set the SSLFilter, pretty much as what we had to workaround in Directory. I'm going to fix that. On 25/03/2022 19:48, Jonathan Valliere wrote: Are you trying to get the peer cert after the filter emits the connected after the handshake completes? If you do it too early it won’t populate. On Fri, Mar 25, 2022 at 2:33 PM Emmanuel Lécharny wrote: Hi! following the effort put in rewriting the Sslfilter (and all the inner code) by Jonathan lately, I would like to know if we could mive forward with an alpha version of this work. I have tested it with Apache LDAP API and Apache Directory Server, with success. I still have some work to do on FtpServer to have it working with 2.2.X, we get some NPE when trying to fetch the peer certificate from the SSLSession (for some unkown reason, when I call sslSession.getPeerCertiticate() it returns null). Wdyt ? -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE <https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g> T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Releasing a MINA 2.2.0-alpha soon ?
Yep. But slightly more complicated for me, as I don't exactly know FtpServer code inside out :-) Regardless, that should not forbid us to cut a release. On 30/03/2022 19:30, Jonathan Valliere wrote: Ah so same thing as LDAP where you have to move that clear text message into a part of the filter chain and not some message generator. -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Releasing a MINA 2.2.0-alpha soon ?
... which is not that easy :/ I guess I have to use a dedicated filter once again for that purpose. On 30/03/2022 18:02, Emmanuel Lécharny wrote: Hi Jonathan, no, it's just that we try to send a clear text message after having set the SSLFilter, pretty much as what we had to workaround in Directory. I'm going to fix that. On 25/03/2022 19:48, Jonathan Valliere wrote: Are you trying to get the peer cert after the filter emits the connected after the handshake completes? If you do it too early it won’t populate. On Fri, Mar 25, 2022 at 2:33 PM Emmanuel Lécharny wrote: Hi! following the effort put in rewriting the Sslfilter (and all the inner code) by Jonathan lately, I would like to know if we could mive forward with an alpha version of this work. I have tested it with Apache LDAP API and Apache Directory Server, with success. I still have some work to do on FtpServer to have it working with 2.2.X, we get some NPE when trying to fetch the peer certificate from the SSLSession (for some unkown reason, when I call sslSession.getPeerCertiticate() it returns null). Wdyt ? -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE <https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g> T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Releasing a MINA 2.2.0-alpha soon ?
Hi Jonathan, no, it's just that we try to send a clear text message after having set the SSLFilter, pretty much as what we had to workaround in Directory. I'm going to fix that. On 25/03/2022 19:48, Jonathan Valliere wrote: Are you trying to get the peer cert after the filter emits the connected after the handshake completes? If you do it too early it won’t populate. On Fri, Mar 25, 2022 at 2:33 PM Emmanuel Lécharny wrote: Hi! following the effort put in rewriting the Sslfilter (and all the inner code) by Jonathan lately, I would like to know if we could mive forward with an alpha version of this work. I have tested it with Apache LDAP API and Apache Directory Server, with success. I still have some work to do on FtpServer to have it working with 2.2.X, we get some NPE when trying to fetch the peer certificate from the SSLSession (for some unkown reason, when I call sslSession.getPeerCertiticate() it returns null). Wdyt ? -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE <https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g> T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Releasing a MINA 2.2.0-alpha soon ?
Hi! following the effort put in rewriting the Sslfilter (and all the inner code) by Jonathan lately, I would like to know if we could mive forward with an alpha version of this work. I have tested it with Apache LDAP API and Apache Directory Server, with success. I still have some work to do on FtpServer to have it working with 2.2.X, we get some NPE when trying to fetch the peer certificate from the SSLSession (for some unkown reason, when I call sslSession.getPeerCertiticate() it returns null). Wdyt ? -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Welcome Gary Gregory as a new MINA committer !
Hi Gary, we are pleased to inform you that you have been granted commit access to the MINA project. FTR, Gary is a long time Apache member (back to 2008 AFAIR), and is active on commons, loogins and xalan Apache project. Many thanks ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [mina] 02/02: o Renamed SSLxxx classes to Sslxxx to keep an ascendant compatibility o Used meaningful variable nales o Removed useless 'this' o Removed useless 'final' o Transmitted the nexwt filt
Hi Gary,
this is a working branch in which some classes have been renamed from
SslXXX to SSLXXX, and this commit is moving back to the previous names,
exactly for the reason you mention...
So I guess you will approve this comit :-)
On 15/03/2022 14:41, Gary Gregory wrote:
You can't rename public or protected classes/types/methods without breaking
existing applications!
Gary
Gary
On Tue, Mar 15, 2022, 09:31 wrote:
This is an automated email from the ASF dual-hosted git repository.
elecharny pushed a commit to branch 2.2.X
in repository https://gitbox.apache.org/repos/asf/mina.git
commit f64544006e9714541e1b472cef5be58148a3fd01
Author: emmanuel lecharny
AuthorDate: Tue Mar 15 14:31:41 2022 +0100
o Renamed SSLxxx classes to Sslxxx to keep an ascendant compatibility
o Used meaningful variable nales
o Removed useless 'this'
o Removed useless 'final'
o Transmitted the nexwt filter to the throw_pending_error() method in
order to be able to write back the Alert to the remote peer
o Write the Alter back to the remote peer in the receive_loop() method
when the inbound has been closed following an error while processing a task
o Quick exit the receive_loop() method if the read message is empty
o Minor formatting (added nl, etc)
o Added missing javadoc
---
.../org/apache/mina/filter/ssl/SSLHandlerG0.java | 381
++---
...LContextFactory.java => SslContextFactory.java} | 2 +-
.../filter/ssl/{SSLEvent.java => SslEvent.java}| 2 +-
.../filter/ssl/{SSLFilter.java => SslFilter.java} | 30 +-
.../ssl/{SSLHandler.java => SslHandler.java} | 6 +-
.../transport/socket/nio/NioSocketSession.java | 4 +-
.../SSLTestHandshakeExceptionDIRMINA1077Test.java | 6 +-
.../ssl/{SSLFilterMain.java => SslFilterMain.java} | 8 +-
.../java/org/apache/mina/example/chat/Main.java| 4 +-
.../example/chat/client/ChatClientSupport.java | 4 +-
.../org/apache/mina/example/echoserver/Main.java | 4 +-
.../apache/mina/example/tcp/perf/TcpSslClient.java | 4 +-
.../apache/mina/example/tcp/perf/TcpSslServer.java | 4 +-
.../org/apache/mina/example/chat/serverContext.xml | 4 +-
.../mina/example/echoserver/AbstractTest.java | 4 +-
.../mina/example/echoserver/ConnectorTest.java | 10 +-
.../ssl/{SSLFilterTest.java => SslFilterTest.java} | 8 +-
17 files changed, 304 insertions(+), 181 deletions(-)
diff --git
a/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java
b/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java
index 76f2d53..31c35f5 100644
--- a/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java
+++ b/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java
@@ -42,7 +42,7 @@ import org.apache.mina.core.write.WriteRequest;
* @author Jonathan Valliere
* @author http://mina.apache.org;>Apache MINA Project
*/
-public class SSLHandlerG0 extends SSLHandler {
+public class SSLHandlerG0 extends SslHandler {
/**
* Maximum number of queued messages waiting for encoding
@@ -102,12 +102,12 @@ public class SSLHandlerG0 extends SSLHandler {
/**
* Instantiates a new handler
*
- * @param p engine
- * @param e executor
- * @param s session
+ * @param sslEngine The SSLEngine instance
+ * @param executor The executor instance to use to process tasks
+ * @param session The session to handle
*/
-public SSLHandlerG0(SSLEngine p, Executor e, IoSession s) {
-super(p, e, s);
+public SSLHandlerG0(SSLEngine sslEngine, Executor executor, IoSession
session) {
+super(sslEngine, executor, session);
}
/**
@@ -115,7 +115,7 @@ public class SSLHandlerG0 extends SSLHandler {
*/
@Override
public boolean isOpen() {
-return this.mEngine.isOutboundDone() == false;
+return mEngine.isOutboundDone() == false;
}
/**
@@ -123,21 +123,24 @@ public class SSLHandlerG0 extends SSLHandler {
*/
@Override
public boolean isConnected() {
-return this.mHandshakeComplete && isOpen();
+return mHandshakeComplete && isOpen();
}
/**
* {@inheritDoc}
*/
-synchronized public void open(final NextFilter next) throws
SSLException {
-if (this.mHandshakeStarted == false) {
-this.mHandshakeStarted = true;
-if (this.mEngine.getUseClientMode()) {
+@Override
+synchronized public void open(NextFilter next) throws SSLException {
+if (mHandshakeStarted == false) {
+mHandshakeStarted = true;
+
+if (mEngine.getUseClientMode()) {
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} open() - begin handshaking",
toString());
}
-this.mEngine.beginHandshake();
-this.write_handshake(next);
+
+
Result, was : [VOTE] Apache FtpServer 1.1.4/1.2.0 releases
Hi;, I'm closing this vote, with 3 binding +1 (Jonathan, Guillaume and me). I'll push the packages and announe the release. Thanks ! On 08/03/2022 07:23, Emmanuel Lecharny wrote: Hi, A mistake was made while releasing Apache MINA FtpServer 1.1.3: the API was broken. Those two releases are fixing this mistake: - 1.1.4 will revert back ion the changes that broke the API ascendant compatibility - 1.2.0 will contain the changes in the API that makes it possible to specify more than one enabled TLS version The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: 1.1.4: https://repository.apache.org/content/repositories/orgapachemina-1069/ 1.2.0: https://repository.apache.org/content/repositories/orgapachemina-1068/ The distributions are available for download on : 1.1.4: https://repository.apache.org/content/repositories/orgapachemina-&069/org/apache/ftpserver/ftpserver/1.1.4/ 1.2.0: https://repository.apache.org/content/repositories/orgapachemina-1068/org/apache/ftpserver/ftpserver/1.2.0/ Packages can also be downloaded from: 1.1.4: https://dist.apache.org/repos/dist/dev/mina/ftpserver/1.1.4/ 1.2.0: https://dist.apache.org/repos/dist/dev/mina/ftpserver/1.2.0/ Let us vote : [ ] +1 | Release Apache FtpServer 1.1.4 and 1.2.0 [ ] +/- | Abstain [ ] -1 | Do *NOT* release Apache FtpServer 1.1.4 and 1.2.0 Thanks ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
FTPServer 1.1.3 blunder...
Hi! The latest 1.1.3 FtPServer release is problematic: thre is an API change that makes it incompatible with revision 1.1.2. That is my bad, I overdid. Bottom line, I will cut a 1.1.4 that revert back to 1.1.2 compatibility, and also cut a 1.2.0 with the API change. This change was about the way we handle TLS enabled protocol. In 1.1 branch, this was a single element (now defaulting to TLSv1.2), and I changed that to make it possible to pass an array of enabled protocols (like ["TLSv1.2", "TLSv1.3"]). One change I will add in 1.1.4 and 1.2.0 will be the dependenc on the latest Log4j2.17.2. I'll start the release soon today. Thanks ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: SSL handler and SSLEngine tasks
And IMO this is a good idea. It decouples the task execution from the
IoProcessor.
Now, I don't think it will help against a SSL attack: the tasks will be
queued once the max threads limit is reached, which means it may take
forever to unqueue them once the attack is over, sucking all your CPU,
eventually ending with a OOM if the queue grew too large. Such attacks
should be mitigated at another level (You'll need some FW or dedicated
software to do that)
Otherwise I specifically referred to my proposal to use another executor
to spawn the tasks to be processed across threads: it won't work because
of the synchronized(engine). So my understanding of the "Multiple
delegated tasks can be run in parallel." sentence was incorrect: it
means you can run multiple delegated tasks as soon as they are for
different SSL sessions...
Bottom line, it's now clear for me and this thread can die :-)
On 03/03/2022 02:31, Jonathan Valliere wrote:
I was using an Executor to limit the number of threads that consume this
action to prevent the server from an SSL attack spinning on all the codes.
On Wed, Mar 2, 2022 at 6:43 PM Emmanuel Lécharny
wrote:
FTR, there is no point in using an executor to try to spread the load of
tasks across many threads:
private static class DelegatedTask implements Runnable {
private final SSLEngineImpl engine;
DelegatedTask(SSLEngineImpl engineInstance) {
this.engine = engineInstance;
}
@Override
public void run() {
synchronized (engine) { <<-- This...
Whatever we do, when a task is executed, it will block any other
DelegatedTask.
On 02/03/2022 15:33, Emmanuel Lécharny wrote:
On 02/03/2022 13:57, Jonathan Valliere wrote:
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally
protected from disclosure.
On Wed, Mar 2, 2022 at 7:33 AM Emmanuel Lécharny mailto:elecha...@gmail.com>> wrote:
On 02/03/2022 12:36, Jonathan Valliere wrote:
> It’s already running in an Executor
Can you clarify ? What is running in an executor?
The SSLEngine delegated task is run in a thread pool executor outside
of the filterchain.
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L617
<
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L617>
which is why it’s a runnable
Well, it's not related. You can create Runnable instances and
execute
them outside of an executor.
. The
> Runnable defers the actual execution logic to the execute task
function
> which should be the one that is looping to perform all queued
tasks from
> the SSL Engine.
Yes, but my point is that we could spawn threads inside the execute
task
(one thread per task) instead of creating an executor inside the
schedule_task.
It uses a configured Executor instance which is generally the same one
for every SSL session.
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L84
<
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L84>
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L72
<
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L72>
Ok, so we are on the same page here.
So the goal here is to spawn a thread that will process the
delegatedTask and let the IoProcessor deal with another session.
That's pretty much needed considering the potentially costly task done
in the delegated task.
My fear is that bu creating a new thread for each schedule_task
call is
that we may have many pending threads waiting for the thread
executing
execute_task to be completed, because of the synchronized nature
of the
execute_task method. All in all, it seems to create a bottleneck
that is
going to be problematic, when the tasks are supposed to be ran
concurrently.
Am I missing something ?
If more than one scheduled task could happen (which I doubt it
honestly) yes they would block on each other because the execute_task
function is synchronized. But we want to block here because the
delegated tasks MUST be executed in order,
No, this is not required:
"Multiple delegated tasks can be run in parallel."
(
https://docs
Re: SSL handler and SSLEngine tasks
FTR, there is no point in using an executor to try to spread the load of
tasks across many threads:
private static class DelegatedTask implements Runnable {
private final SSLEngineImpl engine;
DelegatedTask(SSLEngineImpl engineInstance) {
this.engine = engineInstance;
}
@Override
public void run() {
synchronized (engine) { <<-- This...
Whatever we do, when a task is executed, it will block any other
DelegatedTask.
On 02/03/2022 15:33, Emmanuel Lécharny wrote:
On 02/03/2022 13:57, Jonathan Valliere wrote:
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally
protected from disclosure.
On Wed, Mar 2, 2022 at 7:33 AM Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:
On 02/03/2022 12:36, Jonathan Valliere wrote:
> It’s already running in an Executor
Can you clarify ? What is running in an executor?
The SSLEngine delegated task is run in a thread pool executor outside
of the filterchain.
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L617
<https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L617>
which is why it’s a runnable
Well, it's not related. You can create Runnable instances and execute
them outside of an executor.
. The
> Runnable defers the actual execution logic to the execute task
function
> which should be the one that is looping to perform all queued
tasks from
> the SSL Engine.
Yes, but my point is that we could spawn threads inside the execute
task
(one thread per task) instead of creating an executor inside the
schedule_task.
It uses a configured Executor instance which is generally the same one
for every SSL session.
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L84
<https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L84>
https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L72
<https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L72>
Ok, so we are on the same page here.
So the goal here is to spawn a thread that will process the
delegatedTask and let the IoProcessor deal with another session.
That's pretty much needed considering the potentially costly task done
in the delegated task.
My fear is that bu creating a new thread for each schedule_task
call is
that we may have many pending threads waiting for the thread
executing
execute_task to be completed, because of the synchronized nature
of the
execute_task method. All in all, it seems to create a bottleneck
that is
going to be problematic, when the tasks are supposed to be ran
concurrently.
Am I missing something ?
If more than one scheduled task could happen (which I doubt it
honestly) yes they would block on each other because the execute_task
function is synchronized. But we want to block here because the
delegated tasks MUST be executed in order,
No, this is not required:
"Multiple delegated tasks can be run in parallel."
(https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLEngine.html#getDelegatedTask())
Although it's not clear if they meant "multiple delegated tasks for
different sessions" or "multiple delegated tasks for one session", I
think the former is correct.
The SSLEngine will manage the context, and any wrap/unwrap call will be
blocked until all the tasks are executed.
So my guess is that it makes sense to use another executor to process
the tasks, such as in my proposal.
Now, going back to the initial question - ie why do we need an executor
when we execute a synchronized method - do you agree that my
understanding is correct: this allow the IoProcessor thread to be freed
for another session ?
if a second scheduled task is created, it's a
guaranteed that any subsequent delegated tasks are actually executed
and not lost in the time between a previous execution of a delegated
task and the exit of the synchronized block in execute_task. We don't
want any weird race conditions here.
I'm not sure we could face race condition when executing tasks. They are
supposed to be safe from a concurrency PoV.
I wanted to ensure that the async captured excep
Re: SSL handler and SSLEngine tasks
On 02/03/2022 13:57, Jonathan Valliere wrote: CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. On Wed, Mar 2, 2022 at 7:33 AM Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote: On 02/03/2022 12:36, Jonathan Valliere wrote: > It’s already running in an Executor Can you clarify ? What is running in an executor? The SSLEngine delegated task is run in a thread pool executor outside of the filterchain. https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L617 <https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L617> which is why it’s a runnable Well, it's not related. You can create Runnable instances and execute them outside of an executor. . The > Runnable defers the actual execution logic to the execute task function > which should be the one that is looping to perform all queued tasks from > the SSL Engine. Yes, but my point is that we could spawn threads inside the execute task (one thread per task) instead of creating an executor inside the schedule_task. It uses a configured Executor instance which is generally the same one for every SSL session. https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L84 <https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L84> https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L72 <https://github.com/apache/mina/blob/4fb5d0ee65c079efab08d66bd4c6897f76f39c4f/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLFilter.java#L72> Ok, so we are on the same page here. So the goal here is to spawn a thread that will process the delegatedTask and let the IoProcessor deal with another session. That's pretty much needed considering the potentially costly task done in the delegated task. My fear is that bu creating a new thread for each schedule_task call is that we may have many pending threads waiting for the thread executing execute_task to be completed, because of the synchronized nature of the execute_task method. All in all, it seems to create a bottleneck that is going to be problematic, when the tasks are supposed to be ran concurrently. Am I missing something ? If more than one scheduled task could happen (which I doubt it honestly) yes they would block on each other because the execute_task function is synchronized. But we want to block here because the delegated tasks MUST be executed in order, No, this is not required: "Multiple delegated tasks can be run in parallel." (https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLEngine.html#getDelegatedTask()) Although it's not clear if they meant "multiple delegated tasks for different sessions" or "multiple delegated tasks for one session", I think the former is correct. The SSLEngine will manage the context, and any wrap/unwrap call will be blocked until all the tasks are executed. So my guess is that it makes sense to use another executor to process the tasks, such as in my proposal. Now, going back to the initial question - ie why do we need an executor when we execute a synchronized method - do you agree that my understanding is correct: this allow the IoProcessor thread to be freed for another session ? if a second scheduled task is created, it's a guaranteed that any subsequent delegated tasks are actually executed and not lost in the time between a previous execution of a delegated task and the exit of the synchronized block in execute_task. We don't want any weird race conditions here. I'm not sure we could face race condition when executing tasks. They are supposed to be safe from a concurrency PoV. I wanted to ensure that the async captured exception elevates to the Filter exception handler in a very standard and known way. Now this is interesting. OTOH as soon as we catch an exception for any task being executed, we will process it. It *may* happen we have more than one, if we have more than one task being executed concurrently. But in this case, the session would just be shut down by the first exception being handled, no matter which one it is. A simple way to force the handling of the exception on the filter-chain is to cause a throwing of a special WriteRequest which will flow down
Re: SSL handler and SSLEngine tasks
On 02/03/2022 12:36, Jonathan Valliere wrote:
It’s already running in an Executor
Can you clarify ? What is running in an executor?
which is why it’s a runnable
Well, it's not related. You can create Runnable instances and execute
them outside of an executor.
. The
Runnable defers the actual execution logic to the execute task function
which should be the one that is looping to perform all queued tasks from
the SSL Engine.
Yes, but my point is that we could spawn threads inside the execute task
(one thread per task) instead of creating an executor inside the
schedule_task.
My fear is that bu creating a new thread for each schedule_task call is
that we may have many pending threads waiting for the thread executing
execute_task to be completed, because of the synchronized nature of the
execute_task method. All in all, it seems to create a bottleneck that is
going to be problematic, when the tasks are supposed to be ran concurrently.
Am I missing something ?
On Wed, Mar 2, 2022 at 3:51 AM Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:
Hi,
an alternative would be to modify the execute_task method to become:
synchronized protected void execute_task(NextFilter next) {
Runnable task = null;
while ((task = mEngine.getDelegatedTask()) != null) {
try {
if (ENABLE_ASYNC_TASKS && (mExecutor != null)) {
mExecutor.execute(task);
} else {
task.run();
}
write_handshake(next);
} catch (SSLException e) {
So here, we push the tasks into an executor to be processed
concurrently.
On 02/03/2022 07:05, Emmanuel Lécharny wrote:
> Hi Jonathan,
>
> I wonder if using an executor to process SSLEngine tasks is
useful at
> all, considering that the execute_task method is synchronized:
>
> protected void schedule_task(NextFilter next) {
> if (ENABLE_ASYNC_TASKS) {
> if (mExecutor == null) {
> execute_task(next);
> } else {
> mExecutor.execute(new Runnable() {
> @Override
> public void run() {
> SSLHandlerG0.this.execute_task(next);
> }
> });
>
> and
>
> synchronized protected void execute_task(NextFilter next) {
> ...
>
>
> Also the execute_task will pull tasks from the SSLEngine - we may
have
> more than one, so it will loop on the tasks - and it's unlikely
that we
> will have more tasks to execute when exiting the execute_tasks
method.
>
> The only benefit I can see is that the main thread will be freed for
> other tasks - like processing another IoSession - while tasks are
being
> processed by another thread. And may be this is what was
intended, but I
> wonder iff we should not simply spawn a dedicated thread for that
purpose.
>
> IMO, if we want to introduce an executor in the equation, it
should be
> done in the execute_task method, not in the schedule_task, it would
> speed up the TLS processing, while also freeing the main thread fast
> enough - even a bit slower than having the task loop being
processed by
> a dedicated thread.
>
> wdyt?
>
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com>
https://www.busit.com/ <https://www.busit.com/>
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
<mailto:dev-unsubscr...@mina.apache.org>
For additional commands, e-mail: dev-h...@mina.apache.org
<mailto:dev-h...@mina.apache.org>
--
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
Re: SSL handler and SSLEngine tasks
Hi,
an alternative would be to modify the execute_task method to become:
synchronized protected void execute_task(NextFilter next) {
Runnable task = null;
while ((task = mEngine.getDelegatedTask()) != null) {
try {
if (ENABLE_ASYNC_TASKS && (mExecutor != null)) {
mExecutor.execute(task);
} else {
task.run();
}
write_handshake(next);
} catch (SSLException e) {
So here, we push the tasks into an executor to be processed concurrently.
On 02/03/2022 07:05, Emmanuel Lécharny wrote:
Hi Jonathan,
I wonder if using an executor to process SSLEngine tasks is useful at
all, considering that the execute_task method is synchronized:
protected void schedule_task(NextFilter next) {
if (ENABLE_ASYNC_TASKS) {
if (mExecutor == null) {
execute_task(next);
} else {
mExecutor.execute(new Runnable() {
@Override
public void run() {
SSLHandlerG0.this.execute_task(next);
}
});
and
synchronized protected void execute_task(NextFilter next) {
...
Also the execute_task will pull tasks from the SSLEngine - we may have
more than one, so it will loop on the tasks - and it's unlikely that we
will have more tasks to execute when exiting the execute_tasks method.
The only benefit I can see is that the main thread will be freed for
other tasks - like processing another IoSession - while tasks are being
processed by another thread. And may be this is what was intended, but I
wonder iff we should not simply spawn a dedicated thread for that purpose.
IMO, if we want to introduce an executor in the equation, it should be
done in the execute_task method, not in the schedule_task, it would
speed up the TLS processing, while also freeing the main thread fast
enough - even a bit slower than having the task loop being processed by
a dedicated thread.
wdyt?
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
SSL handler and SSLEngine tasks
Hi Jonathan,
I wonder if using an executor to process SSLEngine tasks is useful at
all, considering that the execute_task method is synchronized:
protected void schedule_task(NextFilter next) {
if (ENABLE_ASYNC_TASKS) {
if (mExecutor == null) {
execute_task(next);
} else {
mExecutor.execute(new Runnable() {
@Override
public void run() {
SSLHandlerG0.this.execute_task(next);
}
});
and
synchronized protected void execute_task(NextFilter next) {
...
Also the execute_task will pull tasks from the SSLEngine - we may have
more than one, so it will loop on the tasks - and it's unlikely that we
will have more tasks to execute when exiting the execute_tasks method.
The only benefit I can see is that the main thread will be freed for
other tasks - like processing another IoSession - while tasks are being
processed by another thread. And may be this is what was intended, but I
wonder iff we should not simply spawn a dedicated thread for that purpose.
IMO, if we want to introduce an executor in the equation, it should be
done in the execute_task method, not in the schedule_task, it would
speed up the TLS processing, while also freeing the main thread fast
enough - even a bit slower than having the task loop being processed by
a dedicated thread.
wdyt?
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
SSL Code format
Hi Jonathan
do you mind if I do a bit of formatting in the SSL classes, like :
- using meaningful variables instead of single letter ones (sslHandler
instead of x, for instance)
- get rid of useless 'final' keyword
- add some missing {} around LOGs
- rename the mXyx member variables to xyz
The idea is to have a code base which is globally using the same scheme...
Thanks !
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler
Some more insight:
When a exception is thrown while processing a task, the SslEngine do
close the InputBound (normal). The probelm now that we can't really call
the receive_loop() again to send back the Alert, because tghis method
first check the InputBoud status:
protected void receive_loop(final NextFilter next, final IoBuffer
message) throws SSLException {
System.out.println(toString() + " receive_loop() - source " +
message);
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - source {}", toString(),
message);
}
if (mEngine.isInboundDone()) {
System.out.println(toString() + " receive_loop() - closed");
throw new IllegalStateException("closed");
}
so we never send back the alert.
If I do something like :
synchronized protected void throw_pending_error(NextFilter next)
throws SSLException {
final SSLException e = this.mPendingError;
if (e != null) {
this.mPendingError = null;
this.receive_loop(next, null); // Call the loop
throw e;
}
}
and:
protected void receive_loop(final NextFilter next, final IoBuffer
message) throws SSLException {
System.out.println(toString() + " receive_loop() - source " +
message);
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - source {}", toString(),
message);
}
if (mEngine.isInboundDone()) {
System.out.println(toString() + " receive_loop() - closed");
switch (mEngine.getHandshakeStatus()) {
case NEED_WRAP:
System.out.println(toString() + " receive_loop() -
handshake needs wrap, invoking write");
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - handshake
needs wrap, invoking write", toString());
}
this.write_handshake(next);
break;
}
throw new IllegalStateException("closed");
}
then all come back on its feet. But it's kind of ugly...
On 25/02/2022 14:55, Emmanuel Lécharny wrote:
Hi Jonathan,
we need to close the connection, but the error alert should be sent
before that. Actually, that should inform the remote peer that there was
some problem.
What I don't k now ATM is what happens when the SSLEngine fail at some
task. We should check the HS status, and I guess it will return a
NEED_WRAP, which will produce the Error Alert, that we should send to
the remote peer and the close the session.
The receive_loop currently do that:
protected void receive_loop(final NextFilter next, final IoBuffer
message) throws SSLException {
...
final SSLEngineResult result = mEngine.unwrap(source.buf(),
dest.buf());
...
switch (result.getHandshakeStatus()) {
...
case NEED_TASK:
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - handshake needs
task, scheduling", toString());
}
this.schedule_task(next);
break;
...
}
}
and we get out immediately while the tasks are being executed, which
leave the HS pending. If one task fails, we need to enter into the loop
again in order to send the Alert.
On 25/02/2022 13:47, Jonathan Valliere wrote:
If we close the ssl instantly then that’s a point of DDOS. Relying on
the idleness timers is important for handling connections in a bad
state like this example. What’s the exception that unit test is
supposed to cause?
On Thu, Feb 24, 2022 at 4:56 PM Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:
So the idea is first to loop on a NEED_TASK because we may need to
send
the alert before closing the connection (but I need to triple check
that, it's a bit late here, and the day was a bit tough on my brain
with
all the bad news...)
On 24/02/2022 19:18, Emmanuel Lécharny wrote:
>
>
> On 24/02/2022 17:21, Jonathan Valliere wrote:
>> If we were to elevate this error in another way like an error
handler
>> then what would you do? Close the session?
>
> Actually, yes, we should send a Error alert (see
> https://datatracker.ietf.org/doc/html/rfc8446#section-6
<https://datatracker.ietf.org/doc/html/rfc8446#section-6>, par. 6.2)
and
> close the session.
>
>
>>
>> On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny
>> mailto:elecha...@gmail.com>
<mailto:elecha...@gmail.com <mailto:elecha...@gmail.com>>> wrote:
>>
>> Understood, but here if a task fail
Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler
Hi Jonathan,
we need to close the connection, but the error alert should be sent
before that. Actually, that should inform the remote peer that there was
some problem.
What I don't k now ATM is what happens when the SSLEngine fail at some
task. We should check the HS status, and I guess it will return a
NEED_WRAP, which will produce the Error Alert, that we should send to
the remote peer and the close the session.
The receive_loop currently do that:
protected void receive_loop(final NextFilter next, final IoBuffer
message) throws SSLException {
...
final SSLEngineResult result = mEngine.unwrap(source.buf(),
dest.buf());
...
switch (result.getHandshakeStatus()) {
...
case NEED_TASK:
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - handshake needs
task, scheduling", toString());
}
this.schedule_task(next);
break;
...
}
}
and we get out immediately while the tasks are being executed, which
leave the HS pending. If one task fails, we need to enter into the loop
again in order to send the Alert.
On 25/02/2022 13:47, Jonathan Valliere wrote:
If we close the ssl instantly then that’s a point of DDOS. Relying on
the idleness timers is important for handling connections in a bad state
like this example. What’s the exception that unit test is supposed to cause?
On Thu, Feb 24, 2022 at 4:56 PM Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:
So the idea is first to loop on a NEED_TASK because we may need to send
the alert before closing the connection (but I need to triple check
that, it's a bit late here, and the day was a bit tough on my brain
with
all the bad news...)
On 24/02/2022 19:18, Emmanuel Lécharny wrote:
>
>
> On 24/02/2022 17:21, Jonathan Valliere wrote:
>> If we were to elevate this error in another way like an error
handler
>> then what would you do? Close the session?
>
> Actually, yes, we should send a Error alert (see
> https://datatracker.ietf.org/doc/html/rfc8446#section-6
<https://datatracker.ietf.org/doc/html/rfc8446#section-6>, par. 6.2)
and
> close the session.
>
>
>>
>> On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny
>> mailto:elecha...@gmail.com>
<mailto:elecha...@gmail.com <mailto:elecha...@gmail.com>>> wrote:
>>
>> Understood, but here if a task fails, I'm not sure the exception
>> will be
>> handled at all. In the case of a handshake, nothing will be
written
>> back
>> to the remote client, AFAICT, so the connection will remain
pending
>> forever.
>>
>> On 24/02/2022 14:23, Jonathan Valliere wrote:
>> > The reason I did this was an ensure the concurrency model
of the
>> > filterchain.
>> >
>> > On Thu, Feb 24, 2022 at 8:22 AM Jonathan Valliere
>> > mailto:jon.valli...@emoten.com>
<mailto:jon.valli...@emoten.com <mailto:jon.valli...@emoten.com>>
>> <mailto:jon.valli...@emoten.com
<mailto:jon.valli...@emoten.com> <mailto:jon.valli...@emoten.com
<mailto:jon.valli...@emoten.com>>>>
>> wrote:
>> >
>> > The pending error is elevated back on either read or
>> write. That
>> > way the async error will be thrown on a filter chain
call
>> stack.
>> >
>> > On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny
>> > mailto:elecha...@gmail.com>
<mailto:elecha...@gmail.com <mailto:elecha...@gmail.com>>
>> <mailto:elecha...@gmail.com <mailto:elecha...@gmail.com>
<mailto:elecha...@gmail.com <mailto:elecha...@gmail.com>>>> wrote:
>> >
>> > Hi Jonathan,
>> >
>> > I have a test that isn't happy with the way we
deal with
>> > delegatedTasks
>> > in MINA 2.2 new SSLFilter implementation.
>> >
>> > The context:
>> > We do a TLS connection with a wrong certificate, the
>> test is
>> > expected to
>> > fail, because of this error:
>> >
>> > javax.net.ssl.SSLHandshakeException: PKIX path
building
>> failed:
Result,was: [VOTE] Apache FtpServer 1.1.3 release
I'm closing this vote. We've got 4 binding +1: Jeff Genender, Guillaume Nodet, Jonathan Valiere and myself. I will push the packages and make the announcement. May thanks for the votes ! This has been a busy year with 2 MINA releases and 2 FTPServer release so far in 2022 ! Let's keep going the good work... On 20/02/2022 09:48, Emmanuel Lecharny wrote: Hi, This is a bug fix release. This version uses the latest MINA release (2.1.6), the latest Log4j version (2.17.1) and an issue with TLS 1.3 that wasn't enabled properly. A temporary tag has been created (it can be removed if the vote is not approved) The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-1067/ The distributions are available for download on : https://repository.apache.org/content/repositories/orgapachemina-004/org/apache/mina/ftpserver/1.1.3/ Let us vote : [ ] +1 | Release Apache FtpServer 1.1.3 [ ] +/- | Abstain [ ] -1 | Do *NOT* release Apache FtpServer 1.1.3 Thanks ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
