[RESULT] [VOTE] Release Apache MINA SSHD 2.13.2
Closing this vote with 5 +1s and no other votes. Thx everyone ! Guillaume Le mar. 23 juil. 2024 à 18:24, Guillaume Nodet a écrit : > > Hey, > > I've staged a candidate release for an SSHD 2.13.2 release. > This release contains a single bug fix: > * Fix sntrup761x25519-sha512 (https://github.com/apache/mina-sshd/issues/525) > > Official staging repo: > https://dist.apache.org/repos/dist/dev/mina/sshd/2.13.2/ > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachemina-1099 > Git tag: > https://github.com/apache/mina-sshd/commits/sshd-2.13.2 > > Please review and vote ! > > -- > ---- > Guillaume Nodet -- Guillaume Nodet - 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.13.2
+1 Le mar. 23 juil. 2024 à 18:24, Guillaume Nodet a écrit : > > Hey, > > I've staged a candidate release for an SSHD 2.13.2 release. > This release contains a single bug fix: > * Fix sntrup761x25519-sha512 (https://github.com/apache/mina-sshd/issues/525) > > Official staging repo: > https://dist.apache.org/repos/dist/dev/mina/sshd/2.13.2/ > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachemina-1099 > Git tag: > https://github.com/apache/mina-sshd/commits/sshd-2.13.2 > > Please review and vote ! > > -- > ---- > Guillaume Nodet -- Guillaume Nodet - 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.13.2
I've staged a new build which seems to have the problem fixed. However, I haven't changed anything, so I'm not really sure what happened... https://repository.apache.org/content/repositories/orgapachemina-1101 Guillaume Le mar. 23 juil. 2024 à 19:15, Thomas Wolf a écrit : > > On 23.07.24 18:24 , Guillaume Nodet wrote: > > Hey, > > > > I've staged a candidate release for an SSHD 2.13.2 release. > > This release contains a single bug fix: > > * Fix sntrup761x25519-sha512 > > (https://github.com/apache/mina-sshd/issues/525) > > > > Official staging repo: > >https://dist.apache.org/repos/dist/dev/mina/sshd/2.13.2/ > > Maven staging repo: > >https://repository.apache.org/content/repositories/orgapachemina-1099 > > Git tag: > >https://github.com/apache/mina-sshd/commits/sshd-2.13.2 > > > > Please review and vote ! > > > > -2. > > The MANIFEST.MF of sshd-osgi (sshd-osgi-2.13.2.jar) is broken. > > Cheers, > >Thomas > > > > - > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org > For additional commands, e-mail: dev-h...@mina.apache.org > -- Guillaume Nodet - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[VOTE] Release Apache MINA SSHD 2.13.2
Hey, I've staged a candidate release for an SSHD 2.13.2 release. This release contains a single bug fix: * Fix sntrup761x25519-sha512 (https://github.com/apache/mina-sshd/issues/525) Official staging repo: https://dist.apache.org/repos/dist/dev/mina/sshd/2.13.2/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemina-1099 Git tag: https://github.com/apache/mina-sshd/commits/sshd-2.13.2 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
[ANNOUNCE] Apache MINA SSHD 2.13.1 released
The Apache Mina PMC is proud to announce the release of Mina SSHD 2.13.1.
This 2.13.1 micro release is a quick fix for the 2.13.0 (published, but not
announced), solely to rectify the issue that the 2.13.0 release encountered
during the release process, where the source jars were not created.
Release notes at:
https://github.com/apache/mina-sshd/releases/tag/sshd-2.13.1
https://github.com/apache/mina-sshd/releases/tag/sshd-2.13.0
The release is available for download at
https://mina.apache.org/sshd-project/download_2.13.1.html
Here's a brief list of changes since 2.12.1 release.
New features:
* GH-498: Implement the "sntrup761x25519-sha...@openssh.com" KEX method by
@tomaswolf
Improvements:
* GH-318: Handle cascaded proxy jumps by @tomaswolf in #512
* GH-461: Fix heartbeats with `wantReply=true` by @tomaswolf in #507
* GH-468: Handle excess data in SFTP read requests by @tomaswolf in #495
Bug fixes and minor changes
* GH-427: Read initial ACK on channel open prior to direct stream upload &
close streams prior to exit code handling by @TerraNibble in #464
* GH-455: ensure BaseCipher.update() fulfills the contract by @tomaswolf in
#463
* GH-470: Synchronize not thread safe
java.security.KeyPairGenerator.generateKe… by @zakharovsergey1000 in #467
* GH-476: Fix Android detection false negative by @wh0
* GH-475: Switch uses of JSch library to the com.github.mwiede:jsch fork by
@Alex-Vol-Amz
* GH-472: change client start condition in sshd-spring-sftp by @alwaystom
* GH-489: sftp readdir: determine file type from longname by @tomaswolf in
#491
* GH-486: Add missing U2F {ed25519,ecdsa}-sk public key equality methods by
@lf-
* SSHD-1237 Handle keep-alive channel requests by @tomaswolf in #492
* GH-494: Nio2Session improvements by @evgeny-pasynkov
* GH-500: SftpFileSystemProvider: close SftpClient on exception by
@tomaswolf in #501
* GH-504: Pass reason to sessionNegotiationEnd by @duco-lw in #505
* GH-493: Fix arcfour128 and arcfour256 ciphers (regression in 2.2.0)
* GH-509: SFTP v[456] client: validate attribute flags
* GH-510: Fix class name in BuiltinIoServiceFactoryFactories (regression in
2.6.0)
A big thanks to everyone that helped in this release.
On behalf of the Maven Mina PMC team,
Guillaume Nodet
Re: [VOTE] Release Apache MINA SSHD 2.13.1
Closing this vote with 4 +1s. I'll publish the release asap. Guillaume Le jeu. 20 juin 2024 à 22:58, Guillaume Nodet a écrit : > 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 > > -- Guillaume Nodet
Re: [VOTE] Release Apache MINA SSHD 2.13.1
+1 Le jeu. 20 juin 2024 à 22:58, Guillaume Nodet a écrit : > 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 > > -- Guillaume Nodet
[VOTE] Release Apache MINA SSHD 2.13.1
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
Re: Missing source files for SSHD 2.13.0 release
Le jeu. 20 juin 2024 à 17:54, Emmanuel Lécharny a écrit : > Can't you just cancel the 2.13.1 and redo the exact same release? > 2.13.0 has been published to maven central. That's how someone saw the problem, after being synced to central. So I need to do a 2.13.1. > 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). > Yeah, good idea. I'll try to do that asap. Guillaume > > > 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 > > -- Guillaume Nodet
Missing source files for SSHD 2.13.0 release
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
[RESULT][VOTE] Release Mina SSHD 2.13.0
The vote succeeds with 5 +1s and no other votes. I'll publish the binaries asap. Cheers, Guillaume
Re: [VOTE] Release Mina SSHD 2.13.0
+1 I'll close the vote and upload the release now. Guillaume Le mer. 19 juin 2024 à 03:08, Gary Gregory a écrit : > What this vote wrapped up? > > Gary > > On Thu, Jun 13, 2024 at 6:14 PM wrote: > > > > +1 > > > > Jeff > > > > > > > On Jun 13, 2024, at 8:54 AM, Emmanuel Lécharny > wrote: > > > > > > 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 > > > > > > > > > - > > 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 > > -- Guillaume Nodet
[VOTE] Release Mina SSHD 2.13.0
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 ! -- Guillaume Nodet
Re: Release Apache MINA SSHD 2.13.0?
Yes, I'll do that tomorrow ! Le lun. 10 juin 2024 à 18:00, Thomas Wolf a écrit : > Guillaume, could you please prepare and stage a release? > > Cheers, > >Thomas > > On 08.06.24 21:35 , Gary Gregory wrote: > > Sounds good to me. > > > > Gary > > > > On Sat, Jun 8, 2024, 2:56 PM Thomas Wolf > <mailto:tw...@apache.org>> wrote: > > > > On 2024-06-08 20:48 , Thomas Wolf wrote: > > > I suggest we start with a release for Apache MINA 2.13.0. > > > > Apache MINA SSHD, of course. > > > > Cheers, > > > > Thomas > > > > > > - > > 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> > > > > -- Guillaume Nodet
[RESULT] [VOTE] Release Mina SSHD 2.12.1
Closing this vote with 3 +1s and no other votes. I'll publish the binaries asap. Thx ! Guillaume Le mar. 6 févr. 2024 à 16:34, Guillaume Nodet a écrit : > > 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 -- Guillaume Nodet - 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
+1 I'll close the vote and publish the release asap. Guillaume Le mar. 6 févr. 2024 à 16:34, Guillaume Nodet a écrit : > > 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 -- Guillaume Nodet - 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
Le jeu. 8 févr. 2024 à 03:08, Emmanuel Lécharny a écrit : > > Hi, > > built from the distribution: > - once docker is launched, Yes, i've been hit by that one more than once. There's a no-containers-for-windows profile (which is automatically activated on windows) and which disables tests that use docker. I think we should fail fast if this profile is not enabled and no docker env is available (and maybe rename it as it would not be windows specific). > - and Java 11 used > got it to work. > > The README stipulate that Java 8+ is required, the tests are faiking > with Java 8. The build time and run time requirements may differ. The target JDK is still 1.8. Fwiw, I've just run a full build of the source release archive with JDK 8 (docker enabled of course). > There are a lot of files in sshd-sources and docs that have no AL.2.0 > headers, so rat is failing when ran. The rat plugin is part of the build, but those files are excluded from the check. See https://github.com/apache/mina-sshd/blob/master/pom.xml#L718-L757 I don't think the files in sshd-sources are used in the build, so maybe we should get rid of those. They were added as part of https://issues.apache.org/jira/browse/SSHD-914 4 or 5 years ago but never touched since... Guillaume > > 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 > -- Guillaume Nodet - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[VOTE] Release Mina SSHD 2.12.1
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
[jira] [Closed] (SSHD-1338) SSHD 2.12 not binary compatible with JGIT 5.13
[
https://issues.apache.org/jira/browse/SSHD-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed SSHD-1338.
-
Resolution: Fixed
> SSHD 2.12 not binary compatible with JGIT 5.13
> --
>
> Key: SSHD-1338
> URL: https://issues.apache.org/jira/browse/SSHD-1338
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Tomas Hofman
> Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.12.1
>
>
> Current version of SSHD still contains a dependency on JGIT 5.13. This is to
> keep SSHD compatible with Java 1.8, as JGIT 6.x requires Java 11.
> However SSHD 2.12 is not binary compatible with 2.9.x versions, which is the
> version that JGIT 5.13.x were build against. The result is that when SSHD
> 2.12 and JGIT 5.13 are used together, one can get NoSuchMethodErrors like
> here:
> {code}
> Caused by: java.lang.NoSuchMethodError: 'java.lang.Object
> org.apache.sshd.client.future.ConnectFuture.verify()'
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:189)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:142)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:99)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:235)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1338) SSHD 2.12 not binary compatible with JGIT 5.13
[
https://issues.apache.org/jira/browse/SSHD-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated SSHD-1338:
--
Fix Version/s: 2.12.1
> SSHD 2.12 not binary compatible with JGIT 5.13
> --
>
> Key: SSHD-1338
> URL: https://issues.apache.org/jira/browse/SSHD-1338
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Tomas Hofman
> Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.12.1
>
>
> Current version of SSHD still contains a dependency on JGIT 5.13. This is to
> keep SSHD compatible with Java 1.8, as JGIT 6.x requires Java 11.
> However SSHD 2.12 is not binary compatible with 2.9.x versions, which is the
> version that JGIT 5.13.x were build against. The result is that when SSHD
> 2.12 and JGIT 5.13 are used together, one can get NoSuchMethodErrors like
> here:
> {code}
> Caused by: java.lang.NoSuchMethodError: 'java.lang.Object
> org.apache.sshd.client.future.ConnectFuture.verify()'
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:189)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:142)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:99)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:235)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1338) SSHD 2.12 not binary compatible with JGIT 5.13
[
https://issues.apache.org/jira/browse/SSHD-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned SSHD-1338:
-
Assignee: Guillaume Nodet
> SSHD 2.12 not binary compatible with JGIT 5.13
> --
>
> Key: SSHD-1338
> URL: https://issues.apache.org/jira/browse/SSHD-1338
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Tomas Hofman
> Assignee: Guillaume Nodet
>Priority: Major
>
> Current version of SSHD still contains a dependency on JGIT 5.13. This is to
> keep SSHD compatible with Java 1.8, as JGIT 6.x requires Java 11.
> However SSHD 2.12 is not binary compatible with 2.9.x versions, which is the
> version that JGIT 5.13.x were build against. The result is that when SSHD
> 2.12 and JGIT 5.13 are used together, one can get NoSuchMethodErrors like
> here:
> {code}
> Caused by: java.lang.NoSuchMethodError: 'java.lang.Object
> org.apache.sshd.client.future.ConnectFuture.verify()'
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:189)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:142)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:99)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:235)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[ANNOUNCE] Apache MINA SSHD 2.12.0 released
The Apache Mina PMC is proud to announce the release of Mina SSHD 2.12.0. 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.12.0 The release is available for download at https://mina.apache.org/sshd-project/download_2.12.0.html # Introduced in 2.12.0 ## Bug Fixes * GH-428/GH-392 SCP client fails silently when error signalled due to missing file or lacking permissions * GH-434 Ignore unknown key types from agent or in OpenSSH host keys extension ## New Features * GH-429 Support GIT protocol-v2 * GH-445 OpenSSH "strict key exchange" protocol extension (CVE-2023-48795 mitigation) # Behavioral changes and enhancements ## New ScpTransferEventListener callback method Following GH-428/GH-392 a new handleReceiveCommandAckInfo method has been added to enable users to inspect acknowledgements of a receive related command. The user is free to inspect the command that was attempted as well as the response code and decide how to handle it - including even throwing an exception if OK status (if this makes sense for whatever reason). The default implementation checks for ERROR code and throws an exception if so. ## OpenSSH protocol extension: strict key exchange GH-445 implements an extension to the SSH protocol introduced in OpenSSH 9.6. This "strict key exchange" extension hardens the SSH key exchange against the "Terrapin attack" (CVE-2023-48795). The extension is active if both parties announce their support for it at the start of the initial key exchange. If only one party announces support, it is not activated to ensure compatibility with SSH implementations that do not implement it. Apache MINA sshd clients and servers always announce their support for strict key exchange. On behalf of the Maven Mina PMC team, Guillaume Nodet - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[RESULT] [VOTE] Release Mina SSHD 2.12.0
Closing the vote with 4 +1s and no other votes. I'll publish the release. Cheers ! Guillaume Le ven. 12 janv. 2024 à 14:14, Guillaume Nodet a écrit : > 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 ! > > -- > > Guillaume Nodet > > -- Guillaume Nodet
Re: [VOTE] Release Mina SSHD 2.12.0
+1 Le ven. 12 janv. 2024 à 14:14, Guillaume Nodet a écrit : > 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 ! > > -- > > Guillaume Nodet > > -- Guillaume Nodet
[VOTE] Release Mina SSHD 2.12.0
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 ! -- Guillaume Nodet
Re: New release of Apache MINA SSHD needed
I'll start the release process tomorrow. Guillaume Le mar. 9 janv. 2024 à 20:43, Thomas Wolf a écrit : > Could we have a new Apache MINA SSHD 2.12.0 release, please? > > There've been a few minor improvements, but the main reason > for a new release is that we've implemented the "strict key > exchange" mitigation against the Terrapin attack > (CVE-2023-48795, which is a CVE against the SSH protocol > itself.) > > Downstream users need a new release to get this strict key > exchange protocol extension. > > Cheers, > > Thomas > -- Guillaume Nodet
[ANNOUNCE] Apache MINA SSHD 2.11.0 released
evicted from the pool. Properties to configure these pool parameters have been added to `SftpModuleProperties`. On behalf of the Apache MINA project, Guillaume Nodet
[ANNOUNCE] Apache MINA SSHD 2.9.3 released
The Apache Mina PMC is proud to announce the release of Mina SSHD 2.9.3. This is a bug fix release, see the details at: https://github.com/apache/mina-sshd/releases/tag/sshd-2.9.3 The release is available for download at https://mina.apache.org/sshd-project/download_2.9.3.html Changelog: * CVE-2023-35887 / SSHD-1324 Rooted file system can leak informations * Fix reproducible builds issue * Support building with Maven 3.9.x On behalf of the Apache MINA project, Guillaume Nodet
[jira] [Updated] (SSHD-1324) Rooted file system can leak informations
[ https://issues.apache.org/jira/browse/SSHD-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-1324: -- Fix Version/s: 2.9.3 > Rooted file system can leak informations > > > Key: SSHD-1324 > URL: https://issues.apache.org/jira/browse/SSHD-1324 > Project: MINA SSHD > Issue Type: Bug > Reporter: Guillaume Nodet > Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.10.0, 2.9.3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[RESULT] [VOTE] Release Apache Mina SSHD 2.11.0
The vote passes with 4 +1s and no other votes. I'll publish the release and update the website asap. Cheers, Guillaume Le jeu. 12 oct. 2023 à 16:33, Guillaume Nodet a écrit : > I've staged a candidate release for 2.11.0 at: > Official staging repo: > https://dist.apache.org/repos/dist/dev/mina/sshd/2.11.0/ > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachemina-1089 > Git tag: > https://github.com/apache/mina-sshd/commits/sshd-2.11.0 > Changelog: > > https://github.com/apache/mina-sshd/blob/sshd-2.11.0/docs/changes/2.11.0.md > > Please review and vote ! > > > -- > > Guillaume Nodet > > -- Guillaume Nodet
Re: [VOTE] Release Apache Mina SSHD 2.11.0
+1 Le jeu. 12 oct. 2023 à 16:33, Guillaume Nodet a écrit : > I've staged a candidate release for 2.11.0 at: > Official staging repo: > https://dist.apache.org/repos/dist/dev/mina/sshd/2.11.0/ > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachemina-1089 > Git tag: > https://github.com/apache/mina-sshd/commits/sshd-2.11.0 > Changelog: > > https://github.com/apache/mina-sshd/blob/sshd-2.11.0/docs/changes/2.11.0.md > > Please review and vote ! > > > -- > > Guillaume Nodet > > -- Guillaume Nodet
[RESULT] [VOTE] Release Apache Mina SSHD 2.9.3
The vote passes with 4 +1s. I'll publish the release and update the web site asap. Guillaume Le jeu. 12 oct. 2023 à 16:33, Guillaume Nodet a écrit : > 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 > > -- Guillaume Nodet
Re: [VOTE] Release Apache Mina SSHD 2.9.3
+1 Le jeu. 12 oct. 2023 à 16:33, Guillaume Nodet a écrit : > 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 > > -- Guillaume Nodet
Re: [VOTE] Release Apache Mina SSHD 2.9.3
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 > > -- Guillaume Nodet
Re: [VOTE] Release Apache Mina SSHD 2.11.0
Not sure what you're referring to. The web site doc for the sha generation is correct (I just messed up the command) https://mina.apache.org/mina-project/developer-guide.html#step-12-deploy-web-reports-javadoc-and-jxr and the web site itself is usually updated after the release: https://mina.apache.org/mina-project/developer-guide.html#step-12-deploy-web-reports-javadoc-and-jxr Am I missing something ? Guillaume Le sam. 14 oct. 2023 à 20:02, Gary Gregory a écrit : > Hi Guillaume, > > Did you update the site generation as well? > > Gary > > > On Sat, Oct 14, 2023, 12:48 PM Guillaume Nodet wrote: > >> Thx for pointing out the weird sha files. I've fixed them and removed the >> sha256 ones. >> >> Guillaume >> >> >> Le sam. 14 oct. 2023 à 17:13, Gary D. Gregory a >> écrit : >> >> > Hi All: >> > >> > +1 >> > >> > I am reviewing the src zip file: >> > >> > - ASC OK >> > >> > - Can't validate SHA file with: >> > shasum --check apache-sshd-2.11.0-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? >> > >> > - 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 >> ...) >> > >> > - mvn apache-rat:check OK >> > >> > - mvn clean install OK >> > >> > - 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:37 Guillaume Nodet wrote: >> > > I've staged a candidate release for 2.11.0 at: >> > > Official staging repo: >> > > https://dist.apache.org/repos/dist/dev/mina/sshd/2.11.0/ >> > > Maven staging repo: >> > > >> https://repository.apache.org/content/repositories/orgapachemina-1089 >> > > Git tag: >> > > https://github.com/apache/mina-sshd/commits/sshd-2.11.0 >> > > Changelog: >> > > >> > > >> > >> https://github.com/apache/mina-sshd/blob/sshd-2.11.0/docs/changes/2.11.0.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 >> > >> > >> >> -- >> >> Guillaume Nodet >> > -- Guillaume Nodet
Re: [VOTE] Release Apache Mina SSHD 2.11.0
Thx for pointing out the weird sha files. I've fixed them and removed the sha256 ones. Guillaume Le sam. 14 oct. 2023 à 17:13, Gary D. Gregory a écrit : > Hi All: > > +1 > > I am reviewing the src zip file: > > - ASC OK > > - Can't validate SHA file with: > shasum --check apache-sshd-2.11.0-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? > > - 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 ...) > > - mvn apache-rat:check OK > > - mvn clean install OK > > - 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:37 Guillaume Nodet wrote: > > I've staged a candidate release for 2.11.0 at: > > Official staging repo: > > https://dist.apache.org/repos/dist/dev/mina/sshd/2.11.0/ > > Maven staging repo: > > https://repository.apache.org/content/repositories/orgapachemina-1089 > > Git tag: > > https://github.com/apache/mina-sshd/commits/sshd-2.11.0 > > Changelog: > > > > > https://github.com/apache/mina-sshd/blob/sshd-2.11.0/docs/changes/2.11.0.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 > > -- Guillaume Nodet
[VOTE] Release Apache Mina SSHD 2.11.0
I've staged a candidate release for 2.11.0 at: Official staging repo: https://dist.apache.org/repos/dist/dev/mina/sshd/2.11.0/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemina-1089 Git tag: https://github.com/apache/mina-sshd/commits/sshd-2.11.0 Changelog: https://github.com/apache/mina-sshd/blob/sshd-2.11.0/docs/changes/2.11.0.md Please review and vote ! -- Guillaume Nodet
[VOTE] Release Apache Mina SSHD 2.9.3
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
Re: Time for a new Apache MINA SSHD release?
Sounds good, I'll do that asap. I'll also release a 2.9.3 bugfix release with the CVE fix for users that can't easily upgrade to the newer 2.10 or 2.11. Guillaume Le lun. 9 oct. 2023 à 23:27, Thomas Wolf a écrit : > I think it would be about time for a new Apache MINA SSHD 2.11.0 > release. > > The last 2.10.0 release was in May 2023; since then we have a couple > of bug fixes and improvements ([1], [2]). Two regressions from 2.10.0 > were fixed (GH-407 and SSHD-1332), from the rest the fixes for GH-410 > and GH-414 are fairly important. > > The channel pool in SftpFileSystem has been completely rewritten > (GH-371), and SFTP file handles have been changed to ensure > interoperability with (broken) WS_FTP (GH-403). > > What do you think? > > Cheers, > >Thomas > > [1] > > https://issues.apache.org/jira/browse/SSHD-1332?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.11.0 > [2] https://github.com/apache/mina-sshd/milestone/3?closed=1 > -- Guillaume Nodet
Re: [VOTE] Apache MINA 2.2.3, 2.1.8 and 2.0.25 releases
+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
[jira] [Assigned] (SSHD-981) Implement no-flow-control SFTP extension
[ https://issues.apache.org/jira/browse/SSHD-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SSHD-981: Assignee: (was: Guillaume Nodet) > Implement no-flow-control SFTP extension > > > Key: SSHD-981 > URL: https://issues.apache.org/jira/browse/SSHD-981 > Project: MINA SSHD > Issue Type: Improvement > Reporter: Guillaume Nodet >Priority: Major > > This extension has been specified by [RFC 8308 - section > 3.3|https://tools.ietf.org/html/rfc8308#section-3.3] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1328) Hanging while executing rsync commands.
[ https://issues.apache.org/jira/browse/SSHD-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728233#comment-17728233 ] Guillaume Nodet commented on SSHD-1328: --- Could you reformat the code so that it's readable and provide the debug output log of the execution ? > Hanging while executing rsync commands. > > > Key: SSHD-1328 > URL: https://issues.apache.org/jira/browse/SSHD-1328 > Project: MINA SSHD > Issue Type: Bug > Environment: Linux and Solaris >Reporter: sivaprasad >Priority: Blocker > > Hi Team, > I hope all are doing great, I'm using Mina to execute remote commands > execution and file uploads/downloads. everything is working fine, but while > executing rsync commands( this command will take more than 1hr to complete) > Mina is hanging forever and not returning anything. > I have added HEARTBEAT in my code, but Mina is printing command output after > command execution is completed but I need to print command output parallel > with command execution. > I have attached my code, can someone look into this and help me to resolve > this issue’s. > > Thanks, > Siva. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[RESULT] [VOTE] Release Apache Mina SSHD 2.10.0
Closing this vote with 3 +1s and no other votes. I'll publish the release asap. Cheers Guillaume Le mer. 10 mai 2023 à 09:35, Guillaume Nodet a écrit : > I've staged a candidate release for 2.10.0 at: > Official staging repo: > https://dist.apache.org/repos/dist/dev/mina/sshd/2.10.0/ > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachemina-1081 > Git tag: > https://github.com/apache/mina-sshd/tree/sshd-2.10.0 > Change log: > > https://github.com/apache/mina-sshd/blob/sshd-2.10.0/docs/changes/2.10.0.md > > Please review and vote ! > > -- > > Guillaume Nodet > > -- Guillaume Nodet
Re: [VOTE] Release Apache Mina SSHD 2.10.0
+1 Le mer. 10 mai 2023, 09:35, Guillaume Nodet a écrit : > I've staged a candidate release for 2.10.0 at: > Official staging repo: > https://dist.apache.org/repos/dist/dev/mina/sshd/2.10.0/ > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachemina-1081 > Git tag: > https://github.com/apache/mina-sshd/tree/sshd-2.10.0 > Change log: > > https://github.com/apache/mina-sshd/blob/sshd-2.10.0/docs/changes/2.10.0.md > > Please review and vote ! > > -- > > Guillaume Nodet > >
Re: [VOTE] Release Apache Mina SSHD 2.10.0
It's on public keyservers: https://keyserver.ubuntu.com/pks/lookup?search=073F7A9345756F3B40CDB99E6C70A3B7599C5736=on=index I've updated the KEYS file at https://dist.apache.org/repos/dist/release/mina/KEYS with the updated key. Thx ! Le mer. 10 mai 2023 à 21:10, Thomas Wolf a écrit : > On 10.05.23 09:35 , Guillaume Nodet wrote: > > I've staged a candidate release for 2.10.0 at: > [...] > > Please review and vote ! > > +1 > > * JGit SSH tests pass > * CI builds in Github are all green > * Class versions are 52 (Java 8) > * Src tar unpacks and builds fine; all tests pass locally (OS X) > > Thanks, Guillaume! (Also for finishing PR 392.) > > Where can one find the public key of the signing key you used > (EDDSA key 073F7A9345756F3B40CDB99E6C70A3B7599C5736)? > > Cheers, > >Thomas > > > - > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org > For additional commands, e-mail: dev-h...@mina.apache.org > > -- Guillaume Nodet
[VOTE] Release Apache Mina SSHD 2.10.0
I've staged a candidate release for 2.10.0 at: Official staging repo: https://dist.apache.org/repos/dist/dev/mina/sshd/2.10.0/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemina-1081 Git tag: https://github.com/apache/mina-sshd/tree/sshd-2.10.0 Change log: https://github.com/apache/mina-sshd/blob/sshd-2.10.0/docs/changes/2.10.0.md Please review and vote ! -- Guillaume Nodet
[jira] [Updated] (SSHD-1324) Rooted file system can leak informations
[ https://issues.apache.org/jira/browse/SSHD-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-1324: -- Fix Version/s: 2.10.0 > Rooted file system can leak informations > > > Key: SSHD-1324 > URL: https://issues.apache.org/jira/browse/SSHD-1324 > Project: MINA SSHD > Issue Type: Bug > Reporter: Guillaume Nodet > Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1324) Rooted file system can leak informations
[ https://issues.apache.org/jira/browse/SSHD-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SSHD-1324: - Assignee: Guillaume Nodet > Rooted file system can leak informations > > > Key: SSHD-1324 > URL: https://issues.apache.org/jira/browse/SSHD-1324 > Project: MINA SSHD > Issue Type: Bug > Reporter: Guillaume Nodet > Assignee: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1324) Rooted file system can leak informations
[ https://issues.apache.org/jira/browse/SSHD-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SSHD-1324. --- Resolution: Fixed > Rooted file system can leak informations > > > Key: SSHD-1324 > URL: https://issues.apache.org/jira/browse/SSHD-1324 > Project: MINA SSHD > Issue Type: Bug > Reporter: Guillaume Nodet > Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-1324) Rooted file system can leak informations
Guillaume Nodet created SSHD-1324: - Summary: Rooted file system can leak informations Key: SSHD-1324 URL: https://issues.apache.org/jira/browse/SSHD-1324 Project: MINA SSHD Issue Type: Bug Reporter: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[RESULT] [VOTE] Release Apache Mina SSHD 2.9.1
The vote passes with 4 +1s. Thx everyone ! Guillaume Le lun. 22 août 2022 à 14:46, Guillaume Nodet a écrit : > 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 ! > > -- > ---- > Guillaume Nodet > > -- Guillaume Nodet
Re: [VOTE] Release Apache Mina SSHD 2.9.1
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 > > -- Guillaume Nodet
Re: [VOTE] Release Apache Mina SSHD 2.9.1
+1 Le lun. 22 août 2022 à 14:46, Guillaume Nodet a écrit : > 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 ! > > -- > ---- > Guillaume Nodet > > -- Guillaume Nodet
[VOTE] Release Apache Mina SSHD 2.9.1
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 ! -- Guillaume Nodet
Re: Apache MINA SSHD 2.9.1 bug-fix release needed (Was: Apache MINA 2.9.1 bug-fix release needed)
I'm mostly offline these days, but i'll try to push a release candidate for a vote this week or next. Le mer. 3 août 2022 à 22:03, Thomas Wolf a écrit : > On 02.08.22 23:47 , Thomas Wolf wrote: > > The 2.9.0 release appears to have been built incorrectly. > > To clarify: of course I meant "The Apache MINA SSHD 2.9.0 release..." > > > Guillaume, could you please prepare a 2.9.1 bug fix release? > > of Apache MINA SSHD? > > Cheers, > > Thomas > -- Guillaume Nodet
[RESULT] [VOTE] Release Apache Mina SSHD 2.9.0 (2nd try)
The vote passes with 4 +1s. I'll publish the binaries asap. Cheers, Guillaume Le lun. 18 juil. 2022 à 09:51, Guillaume Nodet a écrit : > > 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 ! > > -- > ---- > Guillaume Nodet > > -- Guillaume Nodet
Re: [VOTE] Release Apache Mina SSHD 2.9.0 (2nd try)
+1 Le lun. 18 juil. 2022 à 09:51, Guillaume Nodet a écrit : > > 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 ! > > -- > ---- > Guillaume Nodet > > -- Guillaume Nodet
Re: [VOTE] Apache MINA 2.2.1 release
+1 Le mer. 20 juil. 2022 à 15:42, Emmanuel Lécharny a écrit : > 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 > > -- Guillaume Nodet
Re: [VOTE] Release Apache Mina SSHD 2.9.0 (2nd try)
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 > > -- Guillaume Nodet
Re: [VOTE] Release Apache Mina SSHD 2.9.0 (2nd try)
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 > > -- Guillaume Nodet
[VOTE] Release Apache Mina SSHD 2.9.0 (2nd try)
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 ! -- Guillaume Nodet
[CANCEL] [VOTE] Release Apache Mina SSHD 2.9.0
I'm cancelling this vote to respin a release with the PR provided by twolf included. Le lun. 11 juil. 2022 à 15:34, Guillaume Nodet a écrit : > 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 ! > > -- > ---- > Guillaume Nodet > > -- Guillaume Nodet
Re: [Vote] MINA 2.2.0 release
+1 Le lun. 4 juil. 2022 à 23:43, Emmanuel Lécharny a écrit : > 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 > > -- Guillaume Nodet
Re: [VOTE] Release Apache Mina SSHD 2.9.0
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 > > -- Guillaume Nodet
[VOTE] Release Apache Mina SSHD 2.9.0
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 ! -- Guillaume Nodet
Re: [VOTE] Apache FtpServer 1.1.4/1.2.0 releases
+1 Le mar. 8 mars 2022 à 07:23, Emmanuel Lecharny a écrit : > 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 ! > > -- > 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
Re: [VOTE] Apache FtpServer 1.1.3 release
+1 Le dim. 20 févr. 2022 à 09:48, Emmanuel Lecharny a écrit : > 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 ! > > > -- > 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
[jira] [Commented] (SSHD-1243) is GitSshdSessionProcess class Git specific?
[
https://issues.apache.org/jira/browse/SSHD-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484284#comment-17484284
]
Guillaume Nodet commented on SSHD-1243:
---
The {{GitSshdSessionProcess}} won't help you as you'd have to create the ssh
session and channel, it's just a thin wrapper. You just need the
{{ChannelExec}} which will allow you to run a remote command, so just call the
correct method on the {{{}ClientSession{}}}:
[https://github.com/apache/mina-sshd/blob/da2958172281ef20e51681afe036bd42c9cf843a/sshd-core/src/main/java/org/apache/sshd/client/session/ClientSession.java#L182]
The reason why there's no abstraction is that you need to configure the SSH
layer: host, port, user, password, ssh private key, host entries, ciphers,
macs, etc... So we probably won't provide such a thing.
And if you think you really need the {{GitSshdSessionProcess}} class, just copy
it, rename it, and hack it to suit your needs.
Btw, you're saying you're migrating from {{Jsch}} but afaik, it does not
provide this kind of abstraction (for the same reason I suppose). However, it
provides a {{ChannelExec}} in the same way as SSHD ...
> is GitSshdSessionProcess class Git specific?
> -
>
> Key: SSHD-1243
> URL: https://issues.apache.org/jira/browse/SSHD-1243
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.8.0
>Reporter: dgü
> Assignee: Guillaume Nodet
>Priority: Major
>
> Hello!
> {{is org.apache.sshd.git.transport.GitSshdSessionProcess}} class Git specific
> ?
> Is there a generic SSHD class extending java.lang.Process ?
> Thanks in advance!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Closed] (SSHD-1243) is GitSshdSessionProcess class Git specific?
[
https://issues.apache.org/jira/browse/SSHD-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed SSHD-1243.
-
Assignee: Guillaume Nodet
Resolution: Not A Problem
> is GitSshdSessionProcess class Git specific?
> -
>
> Key: SSHD-1243
> URL: https://issues.apache.org/jira/browse/SSHD-1243
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.8.0
>Reporter: dgü
> Assignee: Guillaume Nodet
>Priority: Major
>
> Hello!
> {{is org.apache.sshd.git.transport.GitSshdSessionProcess}} class Git specific
> ?
> Is there a generic SSHD class extending java.lang.Process ?
> Thanks in advance!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1243) is GitSshdSessionProcess class Git specific?
[
https://issues.apache.org/jira/browse/SSHD-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484225#comment-17484225
]
Guillaume Nodet commented on SSHD-1243:
---
It's not really git specific but definitely SSHD specific.
You can try to reuse it if you want, but there's nothing in the SSHD code that
will provide the magic you're looking for executing remote command.
I suggest you read the doc at
[https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#running-a-command-or-opening-a-shell]
and try building a small test with the plain SSHD api using the
{{{}Session.createExecChannel{}}}, you'll also find some examples at
https://github.com/apache/mina-sshd/blob/da2958172281ef20e51681afe036bd42c9cf843a/sshd-core/src/test/java/org/apache/sshd/client/ClientTest.java.
> is GitSshdSessionProcess class Git specific?
> -
>
> Key: SSHD-1243
> URL: https://issues.apache.org/jira/browse/SSHD-1243
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.8.0
>Reporter: dgü
>Priority: Major
>
> Hello!
> {{is org.apache.sshd.git.transport.GitSshdSessionProcess}} class Git specific
> ?
> Is there a generic SSHD class extending java.lang.Process ?
> Thanks in advance!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1239) PtyChannelConfiguration only support PtyType("xterm")?
[
https://issues.apache.org/jira/browse/SSHD-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483597#comment-17483597
]
Guillaume Nodet commented on SSHD-1239:
---
The Pty support is full working in SSHD on both client and server side, but it
has to be used with a Pty capable library.
I recommend having a look at JLine 3 which is working perfectly well with SSHD
(signals, terminal resize, etc...), and works with any kind of terminal which
fully advertise its capabilities.
The integration bits are available at
https://github.com/jline/jline3/tree/master/remote-ssh/src/main/java/org/jline/builtins/ssh
> PtyChannelConfiguration only support PtyType("xterm")?
> --
>
> Key: SSHD-1239
> URL: https://issues.apache.org/jira/browse/SSHD-1239
> Project: MINA SSHD
> Issue Type: Question
>Reporter: g3g4x5x6
>Assignee: Lyor Goldstein
>Priority: Major
>
> PtyChannelConfiguration only support PtyType
> "{color:#FF}_*xterm*_{color}"?
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1240) Wrong password in URI works
[
https://issues.apache.org/jira/browse/SSHD-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481195#comment-17481195
]
Guillaume Nodet commented on SSHD-1240:
---
The expectation is that the password are ignored when matching file systems,
only the user is actually checked. This sounds reasonable because a given user
should not be able to log with two different passwords.
I would suggest not putting the password in the URIs at all.
> Wrong password in URI works
> ---
>
> Key: SSHD-1240
> URL: https://issues.apache.org/jira/browse/SSHD-1240
> Project: MINA SSHD
> Issue Type: Request
>Affects Versions: 2.8.0
> Environment: Java SE 8, Apache NetBeans IDE 12.5
>Reporter: dgü
>Priority: Major
>
> Hello!
> This is another question encountered in SSHD-1238.
> I created URI instances with wrong passwords. But, It worked. The code:
> {noformat}
> */
> public static void main(String[] args) throws IOException,
> URISyntaxException {
> // Correct user info
> URI uri = new URI("sftp://deneme:deneme123@127.0.0.1:22;);
> try (FileSystem fs = FileSystems.newFileSystem(uri,
> Collections.emptyMap())) {
> // Wrong password
> Path sourceFile = Paths.get(new
> URI("sftp://deneme:random1@127.0.0.1:22/C:/Users/XXX/Desktop/sil/sftp/sil1.txt;));
> // Wrong password
> Path targetFile = Paths.get(new
> URI("sftp://deneme:random2@127.0.0.1:22/C:/Users/XXX/Desktop/sil/sftp/sil2.txt;));
> Files.copy(sourceFile, targetFile,
> StandardCopyOption.REPLACE_EXISTING);
> }
> }
> {noformat}
>
> is this expected behaviour? I guess URI in _Paths.get_ matches only
> host:port:user with URI in _FileSystems.newFileSystem_
> Thanks in advance!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1207) Large file get using WinSCP with Apache SFTP Server is not working
[
https://issues.apache.org/jira/browse/SSHD-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated SSHD-1207:
--
Description:
We have been using Apache SSHD version 2.5.1 for SFTP Server functionaity and
it was working very well with all the sftp clients. Recently we have upgraded
2.7.0 and facing issues with largefile downloads using WinSCP. Entire file is
not getting downloaded. Some time with out downloading the entire file WinSCP
is showing the transfer as complete. In the Apache SSHD logs, I see many EOF
status messages to the client. Not sure why so many EOF messages are exchanged
between the client and Server.
{code:java}
04 Aug 2021 21:38:10,841 [sshd-SftpSubsystem-46473-thread-1] DEBUG Nio2Session
- writeBuffer(Nio2Session[local=/10.15.102.66:59119,
remote=10.84.42.167/10.84.42.167:59334]) writing 16448 bytes
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
process(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[length=53,
type=SSH_FXP_READ, id=4884997] processing
04 Aug 2021 21:38:10,842 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG ServerSessionImpl -
encode(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334]) packet
#149 sending command=94[SSH_MSG_CHANNEL_DATA] len=10734
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
doSendStatus(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[id=4884997]
SSH_FXP_STATUS (substatus=SSH_FX_EOF, lang=, msg=End of file)
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
process(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[length=53,
type=SSH_FXP_READ, id=4885253] processing
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
doSendStatus(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[id=4885253]
SSH_FXP_STATUS (substatus=SSH_FX_EOF, lang=, msg=End of file)
04 Aug 2021 21:38:10,843 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG Nio2Session - writeBuffer(Nio2Session[local=/10.15.102.66:59119,
remote=10.84.42.167/10.84.42.167:59334]) writing 10800 bytes
04 Aug 2021 21:38:10,843 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG ServerSessionImpl -
encode(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334]) packet
#150 sending command=94[SSH_MSG_CHANNEL_DATA] len=41
04 Aug 2021 21:38:10,843 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG Nio2Session - writeBuffer(Nio2Session[local=/10.15.102.66:59119,
remote=10.84.42.167/10.84.42.167:59334]) writing 96 bytes
04 Aug 2021 21:38:10,843 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG ServerSessionImpl -
encode(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334]) packet
#151 sending command=94[SSH_MSG_CHANNEL_DATA] len=41
04 Aug 2021 21:38:10,843 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG Nio2Session - writeBuffer(Nio2Session[local=/10.15.102.66:59119,
remote=10.84.42.167/10.84.42.167:59334]) writing 96 bytes
04 Aug 2021 21:38:11,038 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-8]
DEBUG ChannelSession - handleData(ChannelSession[id=0,
recipient=256]-ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])
SSH_MSG_CHANNEL_DATA len=57{code}
was:
We have been using Apache SSHD version 2.5.1 for SFTP Server functionaity and
it was working very well with all the sftp clients. Recently we have upgraded
2.7.0 and facing issues with largefile downloads using WinSCP. Entire file
is not getting downloaded. Some time with out downloading the entire file
WinSCP is showing the transfer as complete. In the Apache SSHD logs, I see
many EOF status messages to the client. Not sure why so many EOF messages are
exchanged between the client and Server.
04 Aug 2021 21:38:10,841 [sshd-SftpSubsystem-46473-thread-1] DEBUG Nio2Session
- writeBuffer(Nio2Session[local=/10.15.102.66:59119,
remote=10.84.42.167/10.84.42.167:59334]) writing 16448 bytes
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
process(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[length=53,
type=SSH_FXP_READ, id=4884997] processing
04 Aug 2021 21:38:10,842 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG ServerSessionImpl -
encode(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334]) packet
#149 sending command=94[SSH_MSG_CHANNEL_DATA] len=10734
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
doSendStatus(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[id=4884997]
SSH_FXP_STATUS (substatus=SSH_FX_EOF, lang=, msg=End of file)
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
process(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[length=53,
type=SSH_FXP_READ
[jira] [Closed] (SSHD-1236) java.lang.NoClassDefFoundError: Failed resolution of: Ljavax/management/ReflectionException;
[ https://issues.apache.org/jira/browse/SSHD-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed SSHD-1236. - Resolution: Not A Problem > java.lang.NoClassDefFoundError: Failed resolution of: > Ljavax/management/ReflectionException; > > > Key: SSHD-1236 > URL: https://issues.apache.org/jira/browse/SSHD-1236 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 > Environment: sshd-sftp:2.8.0 jdk 1.8.0 android :26 >Reporter: qiang,wei >Priority: Blocker > > with android target:26 > gradle:7.0 > agp:4.1.3, > sshd-sftp:2.8.0 > When setup a sftpServer, I got these problems. The reason is in andrid.jar > ,it lost many javax.*.class. > java.lang.NoClassDefFoundError: Failed resolution of: > Ljavax/management/ReflectionException; > How can i fix this issue? -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1238) java.nio.file.FileSystemNotFoundException by SftpFileSystemProvider.getFileSystem
[
https://issues.apache.org/jira/browse/SSHD-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved SSHD-1238.
---
Assignee: Guillaume Nodet
Resolution: Not A Problem
> java.nio.file.FileSystemNotFoundException by
> SftpFileSystemProvider.getFileSystem
> -
>
> Key: SSHD-1238
> URL: https://issues.apache.org/jira/browse/SSHD-1238
> Project: MINA SSHD
> Issue Type: Request
>Affects Versions: 2.8.0
> Environment: Java SE 8, Apache NetBeans IDE 12.5
>Reporter: dgü
> Assignee: Guillaume Nodet
>Priority: Major
>
> Hello!
> The following code runs successfully:
> {noformat}
> public static void main(String[] args) throws IOException {
> URI uri = SftpFileSystemProvider.createFileSystemURI("127.0.0.1", 22,
> "deneme", "deneme123");
> try (FileSystem fs = FileSystems.newFileSystem(uri,
> Collections.emptyMap())) {
> Path localPath =
> fs.getPath("C:/Users/XXX/Desktop/sil/sftp/sil1.txt");
> Path targetPath =
> fs.getPath("C:/Users/XXX/Desktop/sil/sftp/sil2.txt");
> Files.copy(localPath, targetPath,
> StandardCopyOption.REPLACE_EXISTING);
> }
> }
> {noformat}
> The following code fails:
> {noformat}
> public static void main(String[] args) throws URISyntaxException {
> Path sourceFile = Paths.get(new
> URI("sftp://deneme:deneme123@127.0.0.1/C:/Users/XXX/Desktop/sil/sftp/sil.txt;));
> }
> {noformat}
> The exeption is:
> {noformat}
> Exception in thread "main" java.nio.file.FileSystemNotFoundException:
> 127.0.0.1:22:deneme
> at
> org.apache.sshd.sftp.client.fs.SftpFileSystemProvider.getFileSystem(SftpFileSystemProvider.java:451)
> at
> org.apache.sshd.sftp.client.fs.SftpFileSystemProvider.getPath(SftpFileSystemProvider.java:492)
> at java.nio.file.Paths.get(Paths.java:143)
> at com.ubtools.ubutils.UBTest.main(UBTest.java:30)
> {noformat}
>
> How can I solve this problem ?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1238) java.nio.file.FileSystemNotFoundException by SftpFileSystemProvider.getFileSystem
[
https://issues.apache.org/jira/browse/SSHD-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480860#comment-17480860
]
Guillaume Nodet commented on SSHD-1238:
---
The exception thrown indicates that the FileSystem was not found. Indeed, the
call to \{{java.nio.file.Paths.get}} will not automatically create the {{SFTP}}
filesystem, and you need to explicitely create it using a call to
{{FileSystems.newFileSystem}}.
The following will work:
{code:java}
URI uri = SftpFileSystemProvider.createFileSystemURI("127.0.0.1", port,
"deneme", "deneme");
try (FileSystem fs = FileSystems.newFileSystem(uri, Collections.emptyMap())) {
Path sourceFile = Paths.get(new URI("sftp://deneme:deneme@127.0.0.1:; +
port + "/C:/Users/XXX/Desktop/sil/sftp/sil.txt"));
}
{code}
> java.nio.file.FileSystemNotFoundException by
> SftpFileSystemProvider.getFileSystem
> -
>
> Key: SSHD-1238
> URL: https://issues.apache.org/jira/browse/SSHD-1238
> Project: MINA SSHD
> Issue Type: Request
>Affects Versions: 2.8.0
> Environment: Java SE 8, Apache NetBeans IDE 12.5
>Reporter: dgü
>Priority: Major
>
> Hello!
> The following code runs successfully:
> {noformat}
> public static void main(String[] args) throws IOException {
> URI uri = SftpFileSystemProvider.createFileSystemURI("127.0.0.1", 22,
> "deneme", "deneme123");
> try (FileSystem fs = FileSystems.newFileSystem(uri,
> Collections.emptyMap())) {
> Path localPath =
> fs.getPath("C:/Users/XXX/Desktop/sil/sftp/sil1.txt");
> Path targetPath =
> fs.getPath("C:/Users/XXX/Desktop/sil/sftp/sil2.txt");
> Files.copy(localPath, targetPath,
> StandardCopyOption.REPLACE_EXISTING);
> }
> }
> {noformat}
> The following code fails:
> {noformat}
> public static void main(String[] args) throws URISyntaxException {
> Path sourceFile = Paths.get(new
> URI("sftp://deneme:deneme123@127.0.0.1/C:/Users/XXX/Desktop/sil/sftp/sil.txt;));
> }
> {noformat}
> The exeption is:
> {noformat}
> Exception in thread "main" java.nio.file.FileSystemNotFoundException:
> 127.0.0.1:22:deneme
> at
> org.apache.sshd.sftp.client.fs.SftpFileSystemProvider.getFileSystem(SftpFileSystemProvider.java:451)
> at
> org.apache.sshd.sftp.client.fs.SftpFileSystemProvider.getPath(SftpFileSystemProvider.java:492)
> at java.nio.file.Paths.get(Paths.java:143)
> at com.ubtools.ubutils.UBTest.main(UBTest.java:30)
> {noformat}
>
> How can I solve this problem ?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-1235) Terminal resizing: with jediterm, when quit from vim, terminal don't resizing any more
[
https://issues.apache.org/jira/browse/SSHD-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467817#comment-17467817
]
Guillaume Nodet edited comment on SSHD-1235 at 1/3/22, 7:28 AM:
The setPtyLines and setPtyColumns methods can only be used to configure the
initial terminal size and have no effect after the terminal being open.
To propagate terminal changes once it has been opened, you need to use
{code}
channel.sendWindowChange(columns, lines);
{code}
or
{code}
channel.sendWindowChange(columns, lines, height, width);
{code}
was (Author: gnt):
The setPtyLines and setPtyColumns methods can only be used to configure the
initial terminal size and have no effect after the terminal being open.
To propagate terminal changes once it has been opened, you need to use
{code}
channel.sendWindowChange(columns, lines);
{code}
> Terminal resizing: with jediterm, when quit from vim, terminal don't
> resizing any more
> ---
>
> Key: SSHD-1235
> URL: https://issues.apache.org/jira/browse/SSHD-1235
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
> Environment: IDEA
>Reporter: g3g4x5x6
>Priority: Major
> Attachments: image-2022-01-03-02-41-16-780.png,
> image-2022-01-03-02-41-32-678.png
>
>
> h1. Create widget
>
> {code:java}
> ..
> private ClientSession getSession(SshClient client){
> ClientSession session;
> try {
> session = client.connect(this.user, this.host,
> this.port).verify(5000, TimeUnit.MILLISECONDS).getSession();
> session.addPasswordIdentity(this.pass);
> session.auth().verify(15, TimeUnit.SECONDS);
>
> session.setSessionHeartbeat(SessionHeartbeatController.HeartbeatType.IGNORE,
> Duration.ofMinutes(3));
> return session;
> } catch (IOException e) {
> e.printStackTrace();
> DialogUtil.error(e.getMessage());
> return null;
> }
> }
> ..
> private @NotNull JediTermWidget createTerminalWidget() {
> SshSettingsProvider sshSettingsProvider = new SshSettingsProvider();
> JediTermWidget widget = new JediTermWidget(sshSettingsProvider);
> widget.setTtyConnector(new DefaultTtyConnector(session));
> widget.start();
> return widget;
> } {code}
>
>
> h1. DefaultTtyConnector
> {code:java}
> package com.g3g4x5x6.ui.panels.ssh;
> import com.jediterm.terminal.Questioner;
> import com.jediterm.terminal.TtyConnector;
> import lombok.SneakyThrows;
> import lombok.extern.slf4j.Slf4j;
> import org.apache.sshd.client.channel.ChannelShell;
> import org.apache.sshd.client.session.ClientSession;
> import org.jetbrains.annotations.NotNull;
> import java.awt.*;
> import java.io.*;
> import java.nio.charset.StandardCharsets;
> import java.util.concurrent.TimeUnit;
> @Slf4j
> public class DefaultTtyConnector implements TtyConnector {
> private ClientSession session;
> private ChannelShell channel;
> private Dimension myPendingTermSize;
> private PipedOutputStream channelOut;
> private InputStream channelIn;
> private OutputStream outputStream;
> private BufferedReader reader;
> private BufferedWriter writer;
> public DefaultTtyConnector(ClientSession clientSession) {
> this.session = clientSession;
> }
> @Override
> public boolean init(Questioner questioner) {
> try {
> PipedOutputStream out = new PipedOutputStream();
> channelIn = new PipedInputStream(out);
> channelOut = new PipedOutputStream();
> PipedInputStream in = new PipedInputStream(channelOut);
> reader = new BufferedReader(new InputStreamReader(in,
> StandardCharsets.UTF_8));
> writer = new BufferedWriter(new OutputStreamWriter(out));
> channel = initClientChannel(session, channelIn, channelOut);
> outputStream = channel.getInvertedIn();
> } catch (IOException e) {
> e.printStackTrace();
> }
> return true;
> }
> private ChannelShell initClientChannel(ClientSession session, InputStream
> input, OutputStream output) throws IOException {
> ChannelShell channel = session.createShellChannel();
> String lang = (String) System.getenv().get("LANG");
> channel.setEnv("LANG", lang != null ? lang : "zh_CN.UTF-8");
> channel.setPtyType("xterm");
> channel.setUsePty(tru
[jira] [Commented] (SSHD-1235) Terminal resizing: with jediterm, when quit from vim, terminal don't resizing any more
[
https://issues.apache.org/jira/browse/SSHD-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467817#comment-17467817
]
Guillaume Nodet commented on SSHD-1235:
---
The setPtyLines and setPtyColumns methods can only be used to configure the
initial terminal size and have no effect after the terminal being open.
To propagate terminal changes once it has been opened, you need to use
{code}
channel.sendWindowChange(columns, lines);
{code}
> Terminal resizing: with jediterm, when quit from vim, terminal don't
> resizing any more
> ---
>
> Key: SSHD-1235
> URL: https://issues.apache.org/jira/browse/SSHD-1235
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
> Environment: IDEA
>Reporter: g3g4x5x6
>Priority: Major
> Attachments: image-2022-01-03-02-41-16-780.png,
> image-2022-01-03-02-41-32-678.png
>
>
> h1. Create widget
>
> {code:java}
> ..
> private ClientSession getSession(SshClient client){
> ClientSession session;
> try {
> session = client.connect(this.user, this.host,
> this.port).verify(5000, TimeUnit.MILLISECONDS).getSession();
> session.addPasswordIdentity(this.pass);
> session.auth().verify(15, TimeUnit.SECONDS);
>
> session.setSessionHeartbeat(SessionHeartbeatController.HeartbeatType.IGNORE,
> Duration.ofMinutes(3));
> return session;
> } catch (IOException e) {
> e.printStackTrace();
> DialogUtil.error(e.getMessage());
> return null;
> }
> }
> ..
> private @NotNull JediTermWidget createTerminalWidget() {
> SshSettingsProvider sshSettingsProvider = new SshSettingsProvider();
> JediTermWidget widget = new JediTermWidget(sshSettingsProvider);
> widget.setTtyConnector(new DefaultTtyConnector(session));
> widget.start();
> return widget;
> } {code}
>
>
> h1. DefaultTtyConnector
> {code:java}
> package com.g3g4x5x6.ui.panels.ssh;
> import com.jediterm.terminal.Questioner;
> import com.jediterm.terminal.TtyConnector;
> import lombok.SneakyThrows;
> import lombok.extern.slf4j.Slf4j;
> import org.apache.sshd.client.channel.ChannelShell;
> import org.apache.sshd.client.session.ClientSession;
> import org.jetbrains.annotations.NotNull;
> import java.awt.*;
> import java.io.*;
> import java.nio.charset.StandardCharsets;
> import java.util.concurrent.TimeUnit;
> @Slf4j
> public class DefaultTtyConnector implements TtyConnector {
> private ClientSession session;
> private ChannelShell channel;
> private Dimension myPendingTermSize;
> private PipedOutputStream channelOut;
> private InputStream channelIn;
> private OutputStream outputStream;
> private BufferedReader reader;
> private BufferedWriter writer;
> public DefaultTtyConnector(ClientSession clientSession) {
> this.session = clientSession;
> }
> @Override
> public boolean init(Questioner questioner) {
> try {
> PipedOutputStream out = new PipedOutputStream();
> channelIn = new PipedInputStream(out);
> channelOut = new PipedOutputStream();
> PipedInputStream in = new PipedInputStream(channelOut);
> reader = new BufferedReader(new InputStreamReader(in,
> StandardCharsets.UTF_8));
> writer = new BufferedWriter(new OutputStreamWriter(out));
> channel = initClientChannel(session, channelIn, channelOut);
> outputStream = channel.getInvertedIn();
> } catch (IOException e) {
> e.printStackTrace();
> }
> return true;
> }
> private ChannelShell initClientChannel(ClientSession session, InputStream
> input, OutputStream output) throws IOException {
> ChannelShell channel = session.createShellChannel();
> String lang = (String) System.getenv().get("LANG");
> channel.setEnv("LANG", lang != null ? lang : "zh_CN.UTF-8");
> channel.setPtyType("xterm");
> channel.setUsePty(true);
> channel.setIn(input);
> channel.setOut(output);
> channel.setErr(output);
> channel.open().verify(3000, TimeUnit.MILLISECONDS);
> return channel;
> }
> @SneakyThrows
> @Override
> public void close() {
> channel.close();
> }
> @Override
> public String getName() {
> return "SSH"
[jira] [Commented] (SSHD-1169) Sftp Server throughput is lagging for concurrent threads
[ https://issues.apache.org/jira/browse/SSHD-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458250#comment-17458250 ] Guillaume Nodet commented on SSHD-1169: --- At first glance, the file size seems to have an effect. But the test data does not really seem consistent enough to find out what the problem is. Could you try maybe with an additional smaller file size ? And could you publish the project to GitHub to reproduce the data ? > Sftp Server throughput is lagging for concurrent threads > > > Key: SSHD-1169 > URL: https://issues.apache.org/jira/browse/SSHD-1169 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.5.1 >Reporter: Susmit Sarkar >Priority: Blocker > Attachments: image-2021-05-19-10-27-20-261.png > > > Hello Team, > We are seeing a considerably low throughput for large-sized file (100Mb sized > file during concurrent execution) > We did some load testing and the throughputs sometimes increase (when we do a > VM reboot for 1st run) and sometimes its pretty low compare to commercial > servers > > *2000 cycle runs | 20 concurrent threads | 100mb files == Throughput is 0.94 > documents per seconds* > For a commercial server, it's around 1.17 documents per second. > Now if we do a server reboot and re-execute the test then the throughput > increases by leaps and bounds > *2000 cycle runs | 20 concurrent threads | 100 MB files == Throughput is 1.90 > documents per seconds (More than 100 percent)* > *cycle means 100 MB file upload times, 2000 means 2000times*100 MB which got > distributed by 20 concurrent sftp sessions* > I am using IO Factory as NIO2, and below are the combinations for different > NIO worker threads > !image-2021-05-19-10-27-20-261.png! > We are pretty confused and need help. For small files, Apache performed very > well the throughput was 30 percent better than commercial server, but for > large files, we are seeing these issues sometimes (mostly with reboot it > performs good, but after that run its starts lagging) > nio-workers ===> *varies from the chart above* > max-auth-requests ===> 3 > Compression ===> NONE > max-concurrent-sessions ===> 2147483647 > packet-size ===> 65536 > idle-timeout ===> 30 > server-identification ===> SFTP Server > window-size ===> 4194304 > we are setting currently all this properties to *SshServer*, is there any > performance tuning parameter can be used? > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: Question if it is possible to hand off server side initiated TCP connection to a SSH client
You should be able to achieve that using a custom org.apache.sshd.common.io.IoConnector / IoServiceFactory. These are the interfaces used by sshd to connect and process all low-level I/O. There are 3 implementations using sock nio2, mina or netty. You'll have to override one to return an already existing TCP connection wrapped into a dummy IoConnector which will return an IoSession implementation. Whichever implementation you choose to derive from should work, and you should be able to reuse the provided IoSession implementation as is hopefully. So this should just be a matter of implementing the 2 interfaces IoConnector and IoServiceFactory. Le mer. 8 déc. 2021 à 15:31, Bergquist, Brett a écrit : > For background the Netconf Protocol (rfc6241 > <https://tools.ietf.org/html/rfc6241>) supports a Call Home feature where > the Netconf server (SSH server) initiates a connection. In this case, the > Netconf server initiates a TCP connection to TCP port 4334. What needs to > happen is that the TCP connection request is accepted by code in the SSH > client application and then this TCP connection needs to be used to > establish the SSH client to SSH server connection. > > So we need to initiate a client SSH connection using Apache MINA SSHD > using an already established TCP connection. The TCP connection could be > established using Apache MINA CORE if required. This is to support a SSH > server application (Netconf with Call Home) so that it can work behind a > NAT firewall. In this case the TCP connection will originate from within > a device behind the NAT firewall by establishing an outbound TCP > connection. We wish to use that TCP connection and pass it to the Apache > MINA SSHD client for its SSH use. > > We are having trouble figuring out what we need to provide or implement or > inject to allow the SshClient to connect using the already established TCP > connection. We cannot use the normal "SshClient.connect" methods as those > will try to establish a separate TCP connection. > > Right now we are trying to use a NioSocketAcceptor with our own > IoHandlerAdpater and in the "sessionOpened" method, hand off the session > somehow to the the SshClient. > > Any guidance on how to move forward will be greatly appreciated. > > > -- > > *Brett Bergquist – *Chief Software Architect > > 100 Bank Street, Seymour CT 06483 > > *Main*: 203.888.7914 Ext 204 - *Fax*: 203.888.7932 > > <http://www.canoga.com> > > -- > > Canoga Perkins > 20600 Prairie Street > Chatsworth, CA 91311 > (818) 718-6300 > > This e-mail and any attached document(s) is confidential and is intended > only for the review of the party to whom it is addressed. If you have > received this transmission in error, please notify the sender immediately > and discard the original message and any attachment(s). > -- Guillaume Nodet
[RESULT] [VOTE] Mina SSHD 2.8.0
Closing this vote with 4 +1s and no other votes. I'll perform the required steps to upload the release. Guillaume Le mar. 30 nov. 2021 à 08:12, Guillaume Nodet a écrit : > I've staged a release candidate at >https://repository.apache.org/content/repositories/orgapachemina-1061 > GIt Tag: > https://github.com/apache/mina-sshd/releases/tag/sshd-2.8.0 > Issues solved: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.8.0 > > Please review and vote ! > > Cheers > Guillaume Nodet > > -- Guillaume Nodet
Re: [VOTE] Mina SSHD 2.8.0
+1 I'll let the release go with SSHD-1231 and I propose to release 2.8.1 in a few days. Le mar. 30 nov. 2021 à 08:12, Guillaume Nodet a écrit : > I've staged a release candidate at >https://repository.apache.org/content/repositories/orgapachemina-1061 > GIt Tag: > https://github.com/apache/mina-sshd/releases/tag/sshd-2.8.0 > Issues solved: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.8.0 > > Please review and vote ! > > Cheers > Guillaume Nodet > > -- Guillaume Nodet
[VOTE] Mina SSHD 2.8.0
I've staged a release candidate at https://repository.apache.org/content/repositories/orgapachemina-1061 GIt Tag: https://github.com/apache/mina-sshd/releases/tag/sshd-2.8.0 Issues solved: https://issues.apache.org/jira/issues/?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.8.0 Please review and vote ! Cheers Guillaume Nodet
[jira] [Updated] (SSHD-1162) Make sure the project is built using a 1.8
[ https://issues.apache.org/jira/browse/SSHD-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-1162: -- Fix Version/s: (was: 2.8.0) > Make sure the project is built using a 1.8 > - > > Key: SSHD-1162 > URL: https://issues.apache.org/jira/browse/SSHD-1162 > Project: MINA SSHD > Issue Type: Task > Reporter: Guillaume Nodet > Assignee: Guillaume Nodet >Priority: Blocker > Fix For: 2.7.1 > > > If not, the Buffer.flip() methods can be built using JDK 11 methods and cause > linking errors when run at JDK 8. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1225) NOTICE: wrong copyright year range
[
https://issues.apache.org/jira/browse/SSHD-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved SSHD-1225.
---
Fix Version/s: 2.7.1
Assignee: Guillaume Nodet
Resolution: Fixed
Fixed with
https://github.com/apache/mina-sshd/commit/80e57cfaa7bc0d36deecf19b2fc7c12e18427593
> NOTICE: wrong copyright year range
> --
>
> Key: SSHD-1225
> URL: https://issues.apache.org/jira/browse/SSHD-1225
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.7.0
>Reporter: Thomas Wolf
> Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.7.1
>
>
> The NOTICE files included in the JAR artifacts published to maven central say
> for instance for 2.7.0:
> {code:java}
> Apache MINA SSHD
> Copyright 2008-2020 The Apache Software Foundation
> {code}
> This is wrong. 2.7.0 was released in 2021, so it must say 2008-2021.
> It's not clear to me where this comes from, but I find [this property
> setting|https://github.com/apache/mina-sshd/blob/8e6e907e3/pom.xml#L86] in
> our root pom suspicious.
> For the sshd-osgi artifact we get a range of 2018-2020, which I find strange
> given that this is just a shading of sshd-common and sshd-core. Lower end of
> the range should also be 2008.
> These NOTICE files appear to be generated by the Apache root pom; there's a
> template in org.apache:apache-jar-resource-bundle:1.4 which uses a
> ${projectTimespan} variable, but I don't see where _that_ is set.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
Planning SSHD release
Hey, I've seen some mentions of an SSHD release. I'd be happy to cut one in the coming days. What's left to do for this release ? Cheers Guillaume Nodet
[jira] [Resolved] (SSHD-1213) Update tarLongFileMode to use POSIX
[ https://issues.apache.org/jira/browse/SSHD-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SSHD-1213. --- Fix Version/s: 2.7.1 Resolution: Fixed > Update tarLongFileMode to use POSIX > --- > > Key: SSHD-1213 > URL: https://issues.apache.org/jira/browse/SSHD-1213 > Project: MINA SSHD > Issue Type: Bug >Reporter: Roberto Oliveira > Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.7.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Mina sshd fails to build when the UID and/or GID of the user who executed the > build is bigger than 2097151. This is happening when building this project in > an OpenShift environment. > A fix for this is to use the TarArchiver behavior POSIX instead of GNU. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1213) Update tarLongFileMode to use POSIX
[ https://issues.apache.org/jira/browse/SSHD-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SSHD-1213: - Assignee: Guillaume Nodet > Update tarLongFileMode to use POSIX > --- > > Key: SSHD-1213 > URL: https://issues.apache.org/jira/browse/SSHD-1213 > Project: MINA SSHD > Issue Type: Bug >Reporter: Roberto Oliveira > Assignee: Guillaume Nodet >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Mina sshd fails to build when the UID and/or GID of the user who executed the > build is bigger than 2097151. This is happening when building this project in > an OpenShift environment. > A fix for this is to use the TarArchiver behavior POSIX instead of GNU. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1201) Sever Keys name changed post 2.7.0
[ https://issues.apache.org/jira/browse/SSHD-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387990#comment-17387990 ] Guillaume Nodet commented on SSHD-1201: --- [~Susmit07] This looks related https://issues.apache.org/jira/browse/SSHD-1163 > Sever Keys name changed post 2.7.0 > -- > > Key: SSHD-1201 > URL: https://issues.apache.org/jira/browse/SSHD-1201 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.7.0 >Reporter: Susmit Sarkar >Priority: Blocker > Fix For: 2.7.0 > > > Hello Team, > We upgrade to 2.7.0 from 2.5.1 > we are seeing an issue > > String hostkey = > sftpClient.getSession().getNegotiatedKexParameter(KexProposalOption.SERVERKEYS); > > > Host Key in 2.5.1 was *ssh-rsa* and now with the upgrade to 2.7.0 all our > test cases are failing as the API is returning *rsa-sha2-512* > Please note the keys were actually created using ssh-rsa using 2.5.1 library > > Thanks, > Susmit > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1182) skip() doesn't work properly in SftpInputStreamAsync
[ https://issues.apache.org/jira/browse/SSHD-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363423#comment-17363423 ] Guillaume Nodet commented on SSHD-1182: --- Could you write an additional unit test in SftpTest please ? > skip() doesn't work properly in SftpInputStreamAsync > > > Key: SSHD-1182 > URL: https://issues.apache.org/jira/browse/SSHD-1182 > Project: MINA SSHD > Issue Type: Bug >Reporter: Pavel Stetsuk >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > skip() doesn't work properly in SftpInputStreamAsync if executed before read > a data. > In this case data read from the beginning and skip() is ignored -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1178) SOCKS5 proxy stand-alone code
[ https://issues.apache.org/jira/browse/SSHD-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SSHD-1178. --- Resolution: Not A Problem Maybe you could start by reading the doc: https://github.com/apache/mina-sshd/blob/master/docs/port-forwarding.md > SOCKS5 proxy stand-alone code > - > > Key: SSHD-1178 > URL: https://issues.apache.org/jira/browse/SSHD-1178 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar >Priority: Blocker > > Hello Team, > I want to create a SOCKS5 server using MINA sshd. I am not getting sure from > where to start. Shall be really grateful if someone can help with an example > code for standalone proxy server using mina sshd > Are SOCKS5 proxy and SSH Jumps both same? > > Thanks, > Susmit -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1181) SFTP Get downloads empty file from servers which supports EOF indication after data
[
https://issues.apache.org/jira/browse/SSHD-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved SSHD-1181.
---
Fix Version/s: 2.7.1
Resolution: Fixed
https://github.com/apache/mina-sshd/commit/3db721d9a109d9aa80b3a662c43b57458acd99e4
> SFTP Get downloads empty file from servers which supports EOF indication
> after data
> ---
>
> Key: SSHD-1181
> URL: https://issues.apache.org/jira/browse/SSHD-1181
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: SFTP, mina, sshd
> Fix For: 2.7.1
>
>
> So, apparently there's a bug in Mina implementation when downloading the
> file, which is smaller than Mina's buffer (meaning it gets read in one
> iteration), from servers, which send EOF indicator at the end of data
> (https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#[section-9.3|https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-9.3]).
> The bug seems to be in setting up EOF indicator in
> {noformat}
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#pollBuffer{noformat}
> prematurely (one iteration sooner), trace with me this example situation -
> download of the small file (14 B):
> At some point we arrive to mentioned function _pollBuffer()_, note that
> _this.pendingReads_ is set to 2. In first call of _pollBuffer()_ we go
> through this code on receiving SSH_FXP_DATA
> {code:java}
> if (type == SftpConstants.SSH_FXP_DATA) {
> int dlen = buf.getInt();
> int rpos = buf.rpos();
> buf.rpos(rpos + dlen);
> Boolean b = SftpHelper.getEndOfFileIndicatorValue(buf,
> client.getVersion());
> if ((b != null) && b.booleanValue()) {
> eofIndicator = true;
> }{code}
> Here, consider this situation, we're downloading file with 14B, remote server
> adds EOF indicator to the end of the data, so it makes 15B, let's add some
> necessary overhead (size etc.) which is, according to my experience, 13B, so
> we receive 15 + 13 = 28B into initial buffer.
> Now, if we populate these variables, _dlen_ = 14B (file size), _rpos_ = 13
> (overhead), and we set _buf.rpos_ to 27 (14 + 13), but _wpos_ is at the
> moment equal to 28B, as that's what we received. (We're not taking EOF into
> account here)
> Then the _SftpHelper.getEndOfFileIndicatorValue_ is called, which in it's
> implementation looks like this:
> {code:java}
> public static Boolean getEndOfFileIndicatorValue(Buffer buffer, int version) {
> return (version < SftpConstants.SFTP_V6) || (buffer.available() < 1) ?
> null : buffer.getBoolean();
> }
> {code}
> Pay attention to the _buffer.available()_ function as it's implemented like
> this:
> {code:java}
> public int available() {
> return wpos - rpos;
> }
> {code}
> therefore returning 1 (28 - 27), condition is then resolved in
> _SftpHelper.getEndOfFileIndicatorValue_ as a true and true is also returned
> to the _pollBuffer_ and _eofIndicator_ is set to true.
> If you'd keep tracing further, you'd find out that the buffer is then never
> read and returned from _SftpInputStreamAsync_ class, just because
> _eofIndicator_ was set sooner than it should have been.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1181) SFTP Get downloads empty file from servers which supports EOF indication after data
[
https://issues.apache.org/jira/browse/SSHD-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17360319#comment-17360319
]
Guillaume Nodet commented on SSHD-1181:
---
I've been able to reproduce the problem. The first thing was to change the
server side sftp code to send this EOF indicator when it makes sense. I should
be able to commit a fix with a test tomorrow.
> SFTP Get downloads empty file from servers which supports EOF indication
> after data
> ---
>
> Key: SSHD-1181
> URL: https://issues.apache.org/jira/browse/SSHD-1181
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Priority: Major
> Labels: SFTP, mina, sshd
>
> So, apparently there's a bug in Mina implementation when downloading the
> file, which is smaller than Mina's buffer (meaning it gets read in one
> iteration), from servers, which send EOF indicator at the end of data
> (https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#[section-9.3|https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-9.3]).
> The bug seems to be in setting up EOF indicator in
> {noformat}
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#pollBuffer{noformat}
> prematurely (one iteration sooner), trace with me this example situation -
> download of the small file (14 B):
> At some point we arrive to mentioned function _pollBuffer()_, note that
> _this.pendingReads_ is set to 2. In first call of _pollBuffer()_ we go
> through this code on receiving SSH_FXP_DATA
> {code:java}
> if (type == SftpConstants.SSH_FXP_DATA) {
> int dlen = buf.getInt();
> int rpos = buf.rpos();
> buf.rpos(rpos + dlen);
> Boolean b = SftpHelper.getEndOfFileIndicatorValue(buf,
> client.getVersion());
> if ((b != null) && b.booleanValue()) {
> eofIndicator = true;
> }{code}
> Here, consider this situation, we're downloading file with 14B, remote server
> adds EOF indicator to the end of the data, so it makes 15B, let's add some
> necessary overhead (size etc.) which is, according to my experience, 13B, so
> we receive 15 + 13 = 28B into initial buffer.
> Now, if we populate these variables, _dlen_ = 14B (file size), _rpos_ = 13
> (overhead), and we set _buf.rpos_ to 27 (14 + 13), but _wpos_ is at the
> moment equal to 28B, as that's what we received. (We're not taking EOF into
> account here)
> Then the _SftpHelper.getEndOfFileIndicatorValue_ is called, which in it's
> implementation looks like this:
> {code:java}
> public static Boolean getEndOfFileIndicatorValue(Buffer buffer, int version) {
> return (version < SftpConstants.SFTP_V6) || (buffer.available() < 1) ?
> null : buffer.getBoolean();
> }
> {code}
> Pay attention to the _buffer.available()_ function as it's implemented like
> this:
> {code:java}
> public int available() {
> return wpos - rpos;
> }
> {code}
> therefore returning 1 (28 - 27), condition is then resolved in
> _SftpHelper.getEndOfFileIndicatorValue_ as a true and true is also returned
> to the _pollBuffer_ and _eofIndicator_ is set to true.
> If you'd keep tracing further, you'd find out that the buffer is then never
> read and returned from _SftpInputStreamAsync_ class, just because
> _eofIndicator_ was set sooner than it should have been.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1181) SFTP Get downloads empty file from servers which supports EOF indication after data
[
https://issues.apache.org/jira/browse/SSHD-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned SSHD-1181:
-
Assignee: Guillaume Nodet
> SFTP Get downloads empty file from servers which supports EOF indication
> after data
> ---
>
> Key: SSHD-1181
> URL: https://issues.apache.org/jira/browse/SSHD-1181
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: SFTP, mina, sshd
>
> So, apparently there's a bug in Mina implementation when downloading the
> file, which is smaller than Mina's buffer (meaning it gets read in one
> iteration), from servers, which send EOF indicator at the end of data
> (https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#[section-9.3|https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-9.3]).
> The bug seems to be in setting up EOF indicator in
> {noformat}
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#pollBuffer{noformat}
> prematurely (one iteration sooner), trace with me this example situation -
> download of the small file (14 B):
> At some point we arrive to mentioned function _pollBuffer()_, note that
> _this.pendingReads_ is set to 2. In first call of _pollBuffer()_ we go
> through this code on receiving SSH_FXP_DATA
> {code:java}
> if (type == SftpConstants.SSH_FXP_DATA) {
> int dlen = buf.getInt();
> int rpos = buf.rpos();
> buf.rpos(rpos + dlen);
> Boolean b = SftpHelper.getEndOfFileIndicatorValue(buf,
> client.getVersion());
> if ((b != null) && b.booleanValue()) {
> eofIndicator = true;
> }{code}
> Here, consider this situation, we're downloading file with 14B, remote server
> adds EOF indicator to the end of the data, so it makes 15B, let's add some
> necessary overhead (size etc.) which is, according to my experience, 13B, so
> we receive 15 + 13 = 28B into initial buffer.
> Now, if we populate these variables, _dlen_ = 14B (file size), _rpos_ = 13
> (overhead), and we set _buf.rpos_ to 27 (14 + 13), but _wpos_ is at the
> moment equal to 28B, as that's what we received. (We're not taking EOF into
> account here)
> Then the _SftpHelper.getEndOfFileIndicatorValue_ is called, which in it's
> implementation looks like this:
> {code:java}
> public static Boolean getEndOfFileIndicatorValue(Buffer buffer, int version) {
> return (version < SftpConstants.SFTP_V6) || (buffer.available() < 1) ?
> null : buffer.getBoolean();
> }
> {code}
> Pay attention to the _buffer.available()_ function as it's implemented like
> this:
> {code:java}
> public int available() {
> return wpos - rpos;
> }
> {code}
> therefore returning 1 (28 - 27), condition is then resolved in
> _SftpHelper.getEndOfFileIndicatorValue_ as a true and true is also returned
> to the _pollBuffer_ and _eofIndicator_ is set to true.
> If you'd keep tracing further, you'd find out that the buffer is then never
> read and returned from _SftpInputStreamAsync_ class, just because
> _eofIndicator_ was set sooner than it should have been.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-1179) Getting OOM after upgrading to 2.6.0
[
https://issues.apache.org/jira/browse/SSHD-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17359905#comment-17359905
]
Guillaume Nodet edited comment on SSHD-1179 at 6/9/21, 11:28 AM:
-
The most probable reason is that the {{SftpSubsystem}} are not closed
correctly. Those are closed automatically when the server channel is closed,
which happens when the client closes the channel or the connection.
was (Author: gnt):
The most probable reason is that the {{SftpSubsystem}} are not closed correctly.
> Getting OOM after upgrading to 2.6.0
>
>
> Key: SSHD-1179
> URL: https://issues.apache.org/jira/browse/SSHD-1179
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Subramaniajeeva
>Priority: Critical
>
> I upgraded mina version from 2.3.0 to 2.6.0 2 months back. Since then I could
> see the number of JVM threads keep on increasing(till ~12500), leading to OOM
> in production systems.
> Here is the stack trace with 2100+ similar threads:
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park({color:#80}Native Method{color})
> - parking to wait for *<0x00079f7630c8>* (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.park({color:#80}LockSupport.java:175{color})
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await({color:#80}AbstractQueuedSynchronizer.java:2039{color})
> at
> java.util.concurrent.LinkedBlockingQueue.take({color:#80}LinkedBlockingQueue.java:442{color})
> at
> org.apache.sshd.sftp.server.SftpSubsystem.run({color:#80}SftpSubsystem.java:267{color})
> at
> java.util.concurrent.Executors$RunnableAdapter.call({color:#80}Executors.java:511{color})
> at
> java.util.concurrent.FutureTask.run({color:#80}FutureTask.java:266{color})
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker({color:#80}ThreadPoolExecutor.java:1149{color})
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run({color:#80}ThreadPoolExecutor.java:624{color})
> at java.lang.Thread.run({color:#80}Thread.java:748{color})
>
> I tried to debug and I'm not able to isolate the root cause. Is it identified
> and fixed already in 2.7.0?
> [~lgoldstein] Any help would be appreciated.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1179) Getting OOM after upgrading to 2.6.0
[
https://issues.apache.org/jira/browse/SSHD-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17359905#comment-17359905
]
Guillaume Nodet commented on SSHD-1179:
---
The most probable reason is that the {{SftpSubsystem}} are not closed correctly.
> Getting OOM after upgrading to 2.6.0
>
>
> Key: SSHD-1179
> URL: https://issues.apache.org/jira/browse/SSHD-1179
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Subramaniajeeva
>Priority: Critical
>
> I upgraded mina version from 2.3.0 to 2.6.0 2 months back. Since then I could
> see the number of JVM threads keep on increasing(till ~12500), leading to OOM
> in production systems.
> Here is the stack trace with 2100+ similar threads:
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park({color:#80}Native Method{color})
> - parking to wait for *<0x00079f7630c8>* (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.park({color:#80}LockSupport.java:175{color})
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await({color:#80}AbstractQueuedSynchronizer.java:2039{color})
> at
> java.util.concurrent.LinkedBlockingQueue.take({color:#80}LinkedBlockingQueue.java:442{color})
> at
> org.apache.sshd.sftp.server.SftpSubsystem.run({color:#80}SftpSubsystem.java:267{color})
> at
> java.util.concurrent.Executors$RunnableAdapter.call({color:#80}Executors.java:511{color})
> at
> java.util.concurrent.FutureTask.run({color:#80}FutureTask.java:266{color})
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker({color:#80}ThreadPoolExecutor.java:1149{color})
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run({color:#80}ThreadPoolExecutor.java:624{color})
> at java.lang.Thread.run({color:#80}Thread.java:748{color})
>
> I tried to debug and I'm not able to isolate the root cause. Is it identified
> and fixed already in 2.7.0?
> [~lgoldstein] Any help would be appreciated.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1176) Upgrade from 2.5.1 to 2.7.0
[ https://issues.apache.org/jira/browse/SSHD-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354497#comment-17354497 ] Guillaume Nodet commented on SSHD-1176: --- The changelog has been updated. SSH jumps ([http://issues.apache.org/jira/browse/SSHD-1047)] are not related to SOCKS proxies and those were implemented in 2.6.0. > Upgrade from 2.5.1 to 2.7.0 > --- > > Key: SSHD-1176 > URL: https://issues.apache.org/jira/browse/SSHD-1176 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar >Priority: Critical > > Hello Team, > We are currently in 2.5.1 and it's pretty stable, but we are planning to > upgrade to 2.7.0. > Is it justified to update to 2.7.0 or 2.6.0 w.r.t stability? > Do we expect any new features with respect to SOCKS5 proxy support that will > help us. I checked the changes.md but couldn't find any, although there were > few features related to forwarding port and filter. > I didn't found 2.7.0 listed in maven repository, when can we expect the same > Thank you, > Best Regards, > Susmit > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1176) Upgrade from 2.5.1 to 2.7.0
[ https://issues.apache.org/jira/browse/SSHD-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354484#comment-17354484 ] Guillaume Nodet commented on SSHD-1176: --- The only issue I know about SOCKS5 is https://issues.apache.org/jira/browse/SSHD-1008 which is not resolved, so it's definitely not part of any release atm. > Upgrade from 2.5.1 to 2.7.0 > --- > > Key: SSHD-1176 > URL: https://issues.apache.org/jira/browse/SSHD-1176 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar >Priority: Critical > > Hello Team, > We are currently in 2.5.1 and it's pretty stable, but we are planning to > upgrade to 2.7.0. > Is it justified to update to 2.7.0 or 2.6.0 w.r.t stability? > Do we expect any new features with respect to SOCKS5 proxy support that will > help us. I checked the changes.md but couldn't find any, although there were > few features related to forwarding port and filter. > I didn't found 2.7.0 listed in maven repository, when can we expect the same > Thank you, > Best Regards, > Susmit > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1176) Upgrade from 2.5.1 to 2.7.0
[ https://issues.apache.org/jira/browse/SSHD-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1735#comment-1735 ] Guillaume Nodet commented on SSHD-1176: --- 2.7.0 is now available in central. > Upgrade from 2.5.1 to 2.7.0 > --- > > Key: SSHD-1176 > URL: https://issues.apache.org/jira/browse/SSHD-1176 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar >Priority: Critical > > Hello Team, > We are currently in 2.5.1 and it's pretty stable, but we are planning to > upgrade to 2.7.0. > Is it justified to update to 2.7.0 or 2.6.0 w.r.t stability? > Do we expect any new features with respect to SOCKS5 proxy support that will > help us. I checked the changes.md but couldn't find any, although there were > few features related to forwarding port and filter. > I didn't found 2.7.0 listed in maven repository, when can we expect the same > Thank you, > Best Regards, > Susmit > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354432#comment-17354432
]
Guillaume Nodet commented on SSHD-1173:
---
Yes, using a configurable timeout would be better indeed.
The {{send}} method is calling {{verify}} to make sure that the message has
actually been written. If the thread is never released, it should indicate
that the packet has not been written yet. The most probable cause is that the
server does not handle the SSH window correctly and never sends
{{SSH_MSG_CHANNEL_WINDOW_ADJUST}} to tell the client it can send more data. If
you know the target server, maybe you can perform a test transfer (bit enough)
and see if the server ever sends those messages ?
> SFTP worker threads got stuck while processing PUT methods against one
> specific SFTP server
> ---
>
> Key: SSHD-1173
> URL: https://issues.apache.org/jira/browse/SSHD-1173
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Priority: Critical
> Labels: SFTP, mina, sshd
>
> Hey guys,
> Recently I've encountered one remote SFTP server, that causes SFTP worker
> threads to enter TIMED_WAITING state, from which they do not recover. Please,
> take a look into this thread dump:
> {code:java}
> SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
> tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
> elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
> monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting
> on at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
> - waiting to re-lock in wait() <0x0006e3bbc420> (a
> org.apache.sshd.common.channel.IoWriteFutureImpl) at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
> com.mina.command.Put.replyInto(Put.java:55) at
> com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
> at
> com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
> at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
> Source) at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
> {code}
> Seems like the thread is waiting for lock in
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
> I'm currently not sure what thread holds the lock and why it's not ever
> released.
> Also, I'm not able to reproduce this, but it constantly happens to all the
> PUT methods targeting one specific remote server (which I don't own), so I
> suppose there would be something odd with the remote server, but it doesn't
> mean, that we shouldn't be able to deal with that.
> Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
> verify() in
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> is called without any timeout, which then defaults to LONG.MAX here: at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
> shouldn't we have configurable timeout here? or what's the point of default
> timeout? what are we really waiting for in at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
