Q: why is the KeepAliveHandler always return ReplyFailure ?

Shouldn't it return ReplySuccess ? After all, if its code has been reached then the server is alive...

Q: is there support for -etm MAC(s)

The current default supported MAC(s) are not of the encrypt-then-mac type (see http://www.freebsd.org/cgi/man.cgi?query=sshd_configsektion=5 - the MACs section). Is it possible to implement them using their existing counterparts or is there some extra functionality required ?

RE: [VOTE] Release Apache Mina SSHD 0.13.0

+1 -Original Message- From: Guillaume Nodet [mailto:gno...@apache.org] Sent: Tuesday, October 21, 2014 12:28 To: dev@mina.apache.org Subject: [VOTE] Release Apache Mina SSHD 0.13.0 I'd like to call a vote on releasing Apache SSHD 0.13.0 Staging repo at

RE: [jira] [Resolved] (SSHD-406) Stop parsing pty-req modes for undefined opcodes

Hi Guillaume, I was wondering about SSHD-394 (Use ExecutorService for SftpSubsystem), SSHD-395 (Use an ExecutorService to run ScpCommand(s)) patches that I submitted. Is there a reason why you haven't applied them yet ? If so, please let me know (you can communicate with me directly to my

RE: [VOTE] Release Apache Mina SSHD 0.14.0

+1 -Original Message- From: Guillaume Nodet [mailto:gno...@apache.org] Sent: Tuesday, March 03, 2015 18:39 To: dev@mina.apache.org Subject: [VOTE] Release Apache Mina SSHD 0.14.0 I'd like to call a vote on releasing Apache SSHD 0.14.0 Staging repo at

Does anyone object to me applying patch for SSHD-448 ?

https://issues.apache.org/jira/browse/SSHD-448

RE: Does anyone object to me applying patch for SSHD-448 ?

at some point, which will call handler.sessionClosed() which will close the AbstractSession. 2015-05-06 15:45 GMT+02:00 Lyor Goldstein lgoldst...@vmware.com: I don’t think that's the case - the code is a bit convoluted, but IMO what happens is that when one closes the server only the listen

RE: Does anyone object to me applying patch for SSHD-448 ?

, closing all ssh sessions. 2015-05-06 14:27 GMT+02:00 Lyor Goldstein lgoldst...@vmware.com: https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org _jira_browse_SSHD-2D448d=AwIBaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVM NtXt-uEsr=HMhsGLKXv55xAmksY4SsQcYP_oPrfu1Vne__JKwWQvom=gWo5SxQId8HTF

RE: Question regarding intermediate commits of collateral changes

Then should we use the [SSHD-xxx:related] prefix (otherwise someone might think that the issue is what the text says - and it isn't)... -Original Message- From: Guillaume Nodet [mailto:gno...@apache.org] Sent: Thursday, May 7, 2015 09:30 To: Lyor Goldstein; dev@mina.apache.org Subject

RE: Does anyone object to me applying patch for SSHD-448 ?

Seems you are right - stopping the server does close the connections - my mistake, I will close the issue... -Original Message- From: Lyor Goldstein [mailto:lgoldst...@vmware.com] Sent: Wednesday, May 6, 2015 17:04 To: dev@mina.apache.org Subject: RE: Does anyone object to me applying

RE: Any progress on the voting on SSHD 1.0 ?

for PublickeyAuthenticatorTest Do you also see that test failure ? 2015-08-16 6:37 GMT+02:00 Lyor Goldstein lgoldst...@vmware.com: No hurry, just wanted to make sure it has not been forgotten... -Original Message- From: Guillaume Nodet [mailto:gno...@apache.org] Sent: Sunday, August 16, 2015 00:06 To: dev

RE: Any progress on the voting on SSHD 1.0 ?

on the voting on SSHD 1.0 ? I see the use of randomised values in testStaticPublickeyAuthenticator. In my failing case, all values, including the key, are null, hence the NPE... 2015-08-18 11:05 GMT+02:00 Lyor Goldstein lgoldst...@vmware.com: Looking into it right now - strange, it did not use

RE: Any progress on the voting on SSHD 1.0 ?

. I'll start the release process next week when I come back... 2015-08-13 10:04 GMT+02:00 Lyor Goldstein lgoldst...@vmware.com: I have made a few bug fixes since the 1st time I asked for the vote, but since then (~2 weeks) I have not made (nor do intend to) any changes – unless some bug fixes

RE: [VOTE] Release SSHD 1.0.0

+1 (obviously... :-) ) -Original Message- From: Guillaume Nodet [mailto:gno...@apache.org] Sent: Tuesday, August 18, 2015 16:06 To: dev@mina.apache.org Subject: [VOTE] Release SSHD 1.0.0 Please review and vote. Cheers, Guillaume Nodet

RE: Any progress on the voting on SSHD 1.0 ?

) at org.apache.sshd.server.PublickeyAuthenticatorTest.testStaticPublickeyAuthenticator(PublickeyAuthenticatorTest.java:78) at org.apache.sshd.server.PublickeyAuthenticatorTest.testAcceptAllPublickeyAuthenticator(PublickeyAuthenticatorTest.java:50) 2015-08-18 11:00 GMT+02:00 Lyor Goldstein lgoldst...@vmware.com: No - can you

RE: Any progress on the voting on SSHD 1.0 ?

: Any progress on the voting on SSHD 1.0 ? I see the use of randomised values in testStaticPublickeyAuthenticator. In my failing case, all values, including the key, are null, hence the NPE... 2015-08-18 11:05 GMT+02:00 Lyor Goldstein lgoldst...@vmware.com: Looking into it right now - strange

RE: SSHD Build

Emmanuel Lécharny elecha...@gmail.com: Le 20/08/15 14:45, Lyor Goldstein a écrit : Your help in setting up such a CI would be greatly appreciated... We already have a Jenkins server that could be used for that purpose. -- BEKK Open https://urldefense.proofpoint.com/v2/url?u=http-3A__open.bekk.nod

RE: SSHD Build

Your help in setting up such a CI would be greatly appreciated... -Original Message- From: Stefan Magnus Landrø [mailto:stefan.lan...@gmail.com] Sent: Thursday, August 20, 2015 15:26 To: dev@mina.apache.org Subject: SSHD Build Hi there, Wouldn't it make sense to add a few travis

RE: [VOTE] Release SSHD 1.0.0

argument lists differ in length) [ERROR] constructor java.lang.InternalError.InternalError() is not applicable [ERROR] (actual and formal argument lists differ in length) [ERROR] - [Help 1] On Tue, Aug 18, 2015 at 6:12 AM, Lyor Goldstein lgoldst...@vmware.com wrote: +1 (obviously

Vote on releasing SSHD 1.0

As you have probably noticed, SSHD 1.0 has undergone major development - including features, bug fixes and re-organization of the code in order to make it more robust, easier to debug, extend, etc... The version seems stable enough - no major new features planned (at least for 1.0). Personally,

RE: apache-sshd-1.0 kex regression?

* "maybe algos were dropped in 1.0?" - no algos were dropped * Your message says "Attached debug log" - where is it ... -Original Message- From: Alon Bar-Lev [mailto:alon.bar...@gmail.com] Sent: Saturday, November 14, 2015 00:43 To: dev@mina.apache.org Subject: apache-sshd-1.0 kex

RE: SSHD Server

1. The server code is incomplete - after "server.start()" you must have an infinite loop otherwise the "main" program will exit and stop: server.start(); while(...still ok to run...) { Thread.sleep(...); } 2. Are you sure "/bin/ksh" can be run by you ? Remember that your server

RE: Timeout on Large file transfers

I agree that it should not happen. 1. Have you tried the recently released version 1.0.0 ? 2. If the problem persists, try setting the FactoryManager.IDLE_TIMEOUT value to zero (FactoryManagerUtils.updateProperty(client or server, FactoryManager.IDLE_TIMEOUT, 0L) - this disables the idle

RE: [VOTE] Release SSHD 1.0.0 (2nd try)

+1 -Original Message- From: Guillaume Nodet [mailto:gno...@apache.org] Sent: Wednesday, August 19, 2015 17:13 To: dev@mina.apache.org Subject: [VOTE] Release SSHD 1.0.0 (2nd try) I uploaded another 1.0.0 release of SSHD to fix the JDK7 compatibility problems. The artefacts are

RE: [VOTE] Release SSHD 1.0.0 (2nd try)

07/09/15 06:01, Lyor Goldstein a écrit : > They are excluded (or the build would have failed...) just run mvn apache-rat:check

RE: [VOTE] Release SSHD 1.0.0 (2nd try)

ubject: Re: [VOTE] Release SSHD 1.0.0 (2nd try) Le 07/09/15 09:08, Lyor Goldstein a écrit : > This is not I know. The thing is that there is no way to check that the license headers are correct *before* running the release, when we would like to check that beforehand. That means there is proba

RE: [VOTE] Release SSHD 1.0.0 (2nd try)

. Unapproved: 0 unknown: 0 generated: 0 approved: 624 licence. [INFO] -Original Message- From: Emmanuel Lécharny [mailto:elecha...@gmail.com] Sent: Monday, September 7, 2015 10:03 To: dev@mina.apache.org Subject: Re: [VOTE] Release SSHD 1.0.0 (2nd try) Le 07/09/15 06:01, Lyor Goldstein a écrit

RE: [VOTE] Release SSHD 1.0.0 (2nd try)

Found another way (committed in latest 'master' version) - simply run 'mvn apache-rat:check' wherever you like in the project and the correct defaults will be applied - regardless of whether the sources are compiled or not... -Original Message- From: Lyor Goldstein [mailto:lgoldst

RE: [VOTE] Release SSHD 1.0.0 (2nd try)

They are excluded (or the build would have failed...) -Original Message- From: Emmanuel Lécharny [mailto:elecha...@gmail.com] Sent: Sunday, September 6, 2015 13:29 To: dev@mina.apache.org Subject: Re: [VOTE] Release SSHD 1.0.0 (2nd try) Le 06/09/15 12:06, Lyor Goldstein a écrit

RE: [VOTE] Release SSHD 1.0.0 (2nd try)

eptember 3, 2015 02:17 To: dev@mina.apache.org Subject: Re: [VOTE] Release SSHD 1.0.0 (2nd try) Le 02/09/15 14:51, Lyor Goldstein a écrit : > +1 (if developers can vote for the very code they wrote... :-)) I tested the code (from git and from the published package, and I get an error : ...

RE: [VOTE] Release SSHD 1.0.0 (2nd try)

Good idea, We'll do that for 1.1... From: Emmanuel Lécharny [elecha...@gmail.com] Sent: Thursday, September 3, 2015 4:53 PM To: dev@mina.apache.org Subject: Re: [VOTE] Release SSHD 1.0.0 (2nd try) Ok, the failing test is due to the resolution of

RE: [VOTE] Release SSHD 1.0.0 (2nd try)

+1 (if developers can vote for the very code they wrote... :-)) -Original Message- From: Guillaume Nodet [mailto:gno...@apache.org] Sent: Wednesday, September 2, 2015 15:19 To: dev@mina.apache.org Subject: Re: [VOTE] Release SSHD 1.0.0 (2nd try) I think we're still missing some binding

RE: [VOTE] MINA 2.0.10 release

+1 -Original Message- From: Guillaume Nodet [mailto:gno...@apache.org] Sent: Friday, December 11, 2015 09:20 To: dev@mina.apache.org; Lecharny, Emmanuel (EMC) Subject: Re: [VOTE] MINA 2.0.10 release +1 2015-12-07 11:08 GMT+01:00 Emmanuel Lecharny

RE: MINA build with Java 8

Of Jeff MAURY Sent: Thursday, December 17, 2015 15:32 To: dev <dev@mina.apache.org> Subject: Re: MINA build with Java 8 On Thu, Dec 17, 2015 at 2:20 PM, Lyor Goldstein <lgoldst...@vmware.com> wrote: > I think there is @SuppressWarning("javadoc") available... > We don't

RE: MINA build with Java 8

I think there is @SuppressWarning("javadoc") available... -Original Message- From: jeffma...@gmail.com [mailto:jeffma...@gmail.com] On Behalf Of Jeff MAURY Sent: Thursday, December 17, 2015 15:17 To: dev Subject: Re: MINA build with Java 8 Given the Java5 minimum

RE: Selecting a specific KEX signature at client for server key

From: Alon Bar-Lev [alon.bar...@gmail.com] Sent: Thursday, December 17, 2015 9:22 PM To: dev@mina.apache.org; Lyor Goldstein Subject: Re: Selecting a specific KEX signature at client for server key On 17 December 2015 at 18:19, Alon Bar-Lev <alon.

RE: Selecting a specific KEX signature at client for server key

global request handler _ From: Alon Bar-Lev [alon.bar...@gmail.com] Sent: Thursday, December 17, 2015 6:19 PM To: dev@mina.apache.org; Lyor Goldstein Subject: Selecting a specific KEX signature at client for server key Hello, I have a challenge... Let's assume I need to securely

RE: [jira] [Created] (SSHD-618) Support restricting server host key algorithms

There several confusions and misconceptions in the description. It may be possible to do what you describe - not sure though it would be standard or work with all servers. Unfortunately, I am out-of-office for the next two weeks, so we'll have to take this up then...

RE: [GitHub] mina-sshd pull request: [SSHD-618] Support restricting server host...

This the wrong way to do this. You will have to wait until I return, however if you want to get started here is the way to go: - Define SignatureFactoriesManager interface that has get/setSignatureFactories factories methods - Remove the definitions of these methods from their current interface

RE: KeyReExchangeTest::nio2 occasionally fails

Don't know what to say - all these tests pass without a problem. There may be a timing issue, but I can't tell for sure... -Original Message- From: Alon Bar-Lev [mailto:alon.bar...@gmail.com] Sent: Tuesday, November 24, 2015 20:14 To: dev@mina.apache.org Cc: Lyor Goldstein <lgol

RE: Vote on Apache SSHD version 1.1 release

want to actually do the release ? Else I can do it if you want. The mina release process is explained at http://mina.apache.org/mina-project/developer-guide.html#releasing-a-point-release-committers-only Cheers, Guillaume 2016-01-12 8:25 GMT+01:00 Lyor Goldstein <lgoldst...@vmware.com>:

RE: [VOTE] Release SSHD 1.1.0

+1 I am the one worked on it and suggested it. I am voting +1 to show my confidence in the code I wrote... -Original Message- From: Ashish [mailto:paliwalash...@gmail.com] Sent: Saturday, January 16, 2016 18:20 To: dev@mina.apache.org Subject: Re: [VOTE] Release SSHD 1.1.0 +1 Build

RE: Apache SSHD file stores

You make some excellent points about the difficulty that the transition from the old files view to Java 7 NIO model poses to older code. However, the idea behind this transition was to align the code with existing Java mechanisms thus making it standard (see SftpFileSystem implementation). I

Applying SSHD-639 into version 1.1 and releasing 1.1.1

Hi Guilluame, I have successfully completed SSHD-639 that took care of an issue reported in SSHD-634 - namely the possibility of session decode buffer corruption due to re-using it in order to write the response. Just out of curiosity I applied it to 1.1 (with a few adjustments) and all tests

RE: [VOTE] Release SSHD 1.1.0

<dev@mina.apache.org> Subject: Re: [VOTE] Release SSHD 1.1.0 Lyor, ok, I created a "normal" user on my Win7 workstation and build is now ok. It would be nice if the build checks that condition for non expert users. So here's my +1. Jeff On Mon, Jan 25, 2016 at 7:12 AM, Lyor

RE: [VOTE] Release SSHD 1.1.0

We are not using the SslHandler (AFAIK) so it is highly unlikely we are affected by this bug, but it may be a good idea to hold off until a patched version of MINA is released ... -Original Message- From: Emmanuel Lécharny [mailto:elecha...@gmail.com] Sent: Friday, January 22, 2016

RE: [VOTE] Release SSHD 1.1.0

Fixed on latest checked in version in 'master' - thanks for the heads-up... -Original Message- From: jeffma...@gmail.com [mailto:jeffma...@gmail.com] On Behalf Of Jeff MAURY Sent: Friday, January 22, 2016 11:11 To: dev Subject: Re: [VOTE] Release SSHD 1.1.0 Working

RE: [VOTE] Release SSHD 1.1.0

Hi Jeff, I don’t see any attached log to the message…. Lyor From: jeffma...@gmail.com [mailto:jeffma...@gmail.com] On Behalf Of Jeff MAURY Sent: Friday, January 22, 2016 12:20 To: dev Subject: Re: [VOTE] Release SSHD 1.1.0 Hello, I tried to build on a Windows workstation

RE: [VOTE] Release SSHD 1.1.0

Hi Jeff, Indeed there is an issue with running the tests under Windows as administrator - we chose not to address it by design as there are some complex issues associated with identifying such a user/group in Java without resorting to native Win32 API and we did not want to get into it. Please

Re: [VOTE] Release Apache Mina SSHD 1.4.0

+1 Proper disclosure: I am the one who made most of the changes and initiated the vote (through Guillaume).

Re: [VOTE] Release SSHD 1.3.0

+1 (if my vote as a developer counts)

Release SSHD 2.0 ?

Hi everybody, I believe we have accumulated a respectable amount of changes - both bug fixes and new features - not to mention some non-trivial re-structuring of the code. I therefore feel it is time to release version 2.0 - I am not aware of major features or bug fixes currently pending so it

Re: [VOTE] Apache Mina 2.0.19

>> This is a fix for the previous release (2.0.18) which broke the API by mistake. +1

Any progress on the re-release of SSHD 2.0 ?

Hi guys, I was wondering where we are after resuming the vote on whether to release SSHD 2.0 ... Thanks,

Re: [DISCUSS] Some SSHD refactoring before 2.0.0

I have read the proposed changes and I agree in principle, although the suggested re-factoring feels a bit too extensive. >> remove a few interfaces which are not actually used, i.e. they've been introduced because various classes have methods with similar signatures, but there's no real concept

Re: [DISCUSS] Some SSHD refactoring before 2.0.0

>>> > I disagree with the characterization that they do not have a "real concept > behind them" they represent contracts of entities that have similar > attributes. IMO, all the various *XxxHolder*(s) represent an entity that > provides whatever these "attribute" interfaces hold. >>> Well, I

Re: [DISCUSS] Some SSHD refactoring before 2.0.0

> >> remove a few interfaces which are not actually used, i.e. they've been > introduced because various classes have methods with similar signatures, > but there's no real concept behind > > I disagree with the characterization that they do not have a "real concept > behind them" they represent

Re: [DISCUSS] Some SSHD refactoring before 2.0.0

>>> But if the community want to pursue the 2.0.0 release as it is, that's fine with me, I can restart a vote quickly, as I haven't deleted the staging repository or tag yet I'm with Jonathan on this - let's release 2.0 as planned, and then discuss and implement whatever re-factoring is deemed

Re: [DISCUSS] Some SSHD refactoring before 2.0.0

>>> In our case, I don't see any real purpose for all those interfaces beyond linking together unrelated objects just because they hold the same kind object. I think this is a worthy purpose nevertheless and feel very strongly that we should keep them - I don't see the harm BTW, I could

Re: [DISCUSS] Some SSHD refactoring before 2.0.0

>>> > I think this is a worthy purpose nevertheless and feel very strongly that > we should keep them - I don't see the harm > > BTW, I could argue the same case against *InitializingBean* and > *DisposableBean* in view of *@PostConstruct* and *@PreDispose*, but I still > think they are very

Re: [VOTE] Release Mina SSHD 2.0.0

+1 >> I've staged a release of Mina SSHD 2.0.0 https://repository.apache.org/content/repositories/orgapachemina-1035/

Re: [CANCEL] [VOTE] Release Mina SSHD 2.0.0

>> Following up the discussions, I'm resuming the vote... (Again) +1

SSHD 2.0 released on Maven central ?

Hi, I just noticed that SSHD 2.0 is listed on Maven central. I am all for it, but I do not remember seeing the official announcement - did I miss it ? Lyor

[ANNOUNCE] Apache SSHD 2.0.0 released

The Apache SSHD project is pleased to announce the release of SSHD 2.0.0 Apache SSHD is a 100% pure java library to support the SSH protocols on both the client and server side. This library can leverage Apache MINA and also Netty - scalable and high performance asynchronous IO libraries. SSHD

Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests

I believe CAMEL can simply choose to use mina-core 2.0.18 (since they have the same API) by simply overriding its version in the CAMEL POM. Furthermore, since SSHD does not really need MINA, it can be configured to use NIO2 and thus avoid dragging in the MINA dependency.

Re: [VOTE] Release Apache Mina SSHD 1.7.0

Hi guys, I was wondering where we are on this since I don't see anyone else voting... I vote +1 ... Lyor G. (a.k.a. lgoldstein...) From: Guillaume Nodet Sent: Thursday, January 11, 2018 8:59 PM To: dev@mina.apache.org Subject: [VOTE] Release Apache Mina SSHD 1.7.0 I've

Re: Pease welcome Jonathan Vallliere, who has been voted as a new MINA committer

Welcome aboard. >> Hi ! >> >> I'm pleased to announce that Jonathan Valliere has been voted in this weekend as a new committer of the MINA project !

Q: SSHD - Should we add dependencies to Apache Commons or not ?

While going over the MINA SSHD code in order to try and break it down further to smaller modules, I encountered quite a few utility classes that duplicate (exactly or closely) code that already exists in other very popular "3rd party" library - specifically Apache Commons (...so not quite "3rd

Re: Q: SSHD - Should we add dependencies to Apache Commons or not ?

>>> Of course, it's all about the size of what is copied. At some point, it would be better to go witha third party dependency instead of copying its code. Valid observation - we will need to "weigh" the amount of copied code and see how "heavy" it is. >>> On important aspect of adding external

Re: Q: SSHD - Should we add dependencies to Apache Commons or not ?

>>> We should be careful when trying to replace existing code with external libraries because there is rarely a guarantee that it will work exactly as the old code does. I agree in principle, but am not sure about "rarely a guarantee" - especially in this case where the code is a 100% duplicate

Re: Q: SSHD - Should we add dependencies to Apache Commons or not ?

Thanks for all the great inputs - at this stage we will not add these dependencies in view of their relative small "weight" in our code. If this should change in the future we will revisit this decision.

Q: Break down sshd-core into sshd-utils + sshd-core ?

As part of an ongoing agenda to make SSHD less "monolithic" we have re-factored the code and extracted MINA, Netty, SCP, SFTP and CLI to their own modules. As part of this agenda I have been considering splitting the *sshd-core* further into *sshd-utils* that will contain common support code -

Re: Q: Release SSHD 2.1 ?

>> I'll try to find some time to do it. Great, thanks Guillaume...

Re: FTPServer future...

I find the FTPserver still useful. I personally use it in some other project I am involved with in order to provide a test environment for (also Apache) FTP(S) client. While it might not be actively maintained, there are still issues being opened on it (I myself opened such an issue), so perhaps

Re: [DISCUSS] Switch SSHD version to 2.0

>> Given we've introduced incompatible changes, especially on the client side >> SSHD api, I think we should switch the version to 2.0 to follow semantic versioning. Agreed - +1 - especially since we are likely to add more (e.g., SSHD-818 - split SCP code to own module)

Re: MINA SonarQube analysis

Looks interesting is there a guide as to how to register a project (I was thinking about SSHD...) >> Hi guys, >> I have registred MINA on the SonarQube server we have at Apache. The result can be seen here : >> https://builds.apache.org/analysis/component_measures/?id=MINA >> It gets generated

Re: MINA SonarQube analysis

simuilar) - is there a way to see which files these are ? Then I can fix them (e.g., exclude them from the plugin's configuration) again - thanks a lot... Lyor >> Hi Lyor, >> Le 18/03/2018 à 19:26, Lyor Goldstein a écrit : >>>> Looks interesting is there a guide as to how

Re: [Vote] was : [New chairman]

+1 I fully agree that " Guillaume is a very nice and talended person " and thank him for volunteering... >> Vote Guillaume Nodet as the new MINA chairman : >> [ ] +1 Great, I'm all in for Guillaume to be the new chairman >> [ ] +/-0 No opinion >> [ ] -1 I think somebody else should be chairman

Re: [VOTE] Release Mina SSHD 2.1.0

Hi Emmanuel, >> I just used the link Guillaume provided https://repository.apache.org/content/repositories/orgapachemina-1038/ The link contains only binaries - do you mean that you somehow unzipped the sources that are posted there and tried to build from them ? How is it even possible - after

Re: [VOTE] Release Mina SSHD 2.1.0

>>> I just used the link Guillaume provided > https://repository.apache.org/content/repositories/orgapachemina-1038/ > build fails I was able to reproduce the build failure and also figure out the reason for it + fix it. Turns out the the source ZIP contains several extra files (in this case 2

Please help review and test solution for SSHD-849

Here is the issue in a nutshell - a client might open an SSH tunnel, send some data and close (normally) its side of the tunnel before the channel to the other side has been successfully established and all data transmitted. Currently a race condition may occur in such a scenario where the code

Re: Please help review and test solution for SSHD-849

>> You should not have to deal with the delayed closing: MINA is already >> allowing you to do that, if you call closeOnFlush() instead of closeNow() -or close(), which maps to closeNow()-. It will then flushall the pending messages before closing the session. No message written in the session

Re: More documentation with clear examples of SFTP

>> I just hope you guys can provide some short examples with full code to do tasks such as file upload, download, fire commands on remote server. All I could find was abstract examples. I appreciate the vote of confidence in our library (we are rather proud of it and it seems to be used in quite

Re: [VOTE] Release Mina SSHD 2.1.0

>> Lyor, would you mind writing the release annoucement ? I'll publish the artifacts this morning, so we can send it later today. >> Sure - I'll send it to your private mail for proof-reading and any last-minute modifications you see fit so you can release it whenever you feel is right. Done -

Re: [VOTE] Release Mina SSHD 2.1.0

>> Lyor, would you mind writing the release annoucement ? I'll publish the >> artifacts this morning, so we can send it later today. Sure - I'll send it to your private mail for proof-reading and any last-minute modifications you see fit so you can release it whenever you feel is right.

Re: [VOTE] Release Mina SSHD 2.1.0

>> #2 is not an option imho. Given the amount of work that would be needed to manually re-package and re-sign the distributions artifacts, i'd go for #1 if this is considered a blocker. Reasonable - I was only bringing it up so that when we decide how to proceed we have all the relevant options

Re: [VOTE] Release Mina SSHD 2.1.0

>> Also Github is own by a private company, we should not depend on them, they can easily shutdown their service, or stopping offering it for free. Very good point - however, why shouldn't Apache run its own GIT repository (which it actually does, since github is just a mirror of it...) >> Or

Re: [VOTE] Release Mina SSHD 2.1.0

> sources that are posted there and tried to build from them ? How is it even > possible - after all (AFAIK) they do not form a valid Maven project ? >> They should. What's the pount in distributing a source package if you can't build it ? >> Also keep in mind that Apache does *only* distribute

Re: [VOTE] Release Mina SSHD 2.1.0

> >>> Or simply have an issue and lose the data. > > Then they would lose the community's support as well... >> Which is the least of our concern ;-) Since they have been bought by M$, many projects already migrated to gitlab (wait for gitlab to be bought by some big co...) Excellent point (BTW,

Re: [VOTE] Release Mina SSHD 2.1.0

Le 01/10/2018 à 09:10, Lyor Goldstein a écrit : >>> Lyor, would you mind writing the release annoucement ? I'll publish the artifacts > this morning, so we can send it later today. > > Sure - I'll send it to your private mail for proof-reading and any > last-minute modific

Re: [VOTE] Release Mina SSHD 2.1.0

>> Compiled the package, compiled from source, check the N files. >> Weird enough, everything works fine with source grabbed from the git repo, but the package consistently fails with those errors Indeed strange. We are aware of *intermittent* errors when building MINA or NETTY code - but never

Re: Q: your take on SSHD-868 - a.k.a. the dangers of RLE...

>> In ApacheDS, we decided to limit the size of a PDU to avoid crazy big (and crafted) messages to be processed. This is of course configurable. I guess you could do the same. Note that I don't think it makes sense to send a big chunk of data in SSH, IMO. Please note though that the limiting the

Q: your take on SSHD-868 - a.k.a. the dangers of RLE...

The issue recognizes the fact that since SSH packets are RLE (read-length encoded) it is possible to craft malicious packets that can cause memory allocation errors due to reporting extremely large lengths of data (up to 32-bit). We can easily implement some mechanism that executes some sanity

Re: [VOTE] MINA SSHD relocation of Apache git repositories on git-wip-us.apache.org

>> Do we have to do this for MINA also? I believe so - see the original mail I posted. Anyway, seems it is not up to us - anyone not initiating such a migration will be migrated anyway. I have sent this mail since they require a documented discussion/vote if one initiates the transition before

Re: SSHD - java.nio.file usage - possible issue

Hi Adam, I have not been able to figure out is the exact issue you are encountering, but if you can diagnose it and perhaps provide some test code that reproduces it, we will certainly try and see how to make it work. That being said, a few remarks on this issue: >> have been implementing

[VOTE] MINA SSHD relocation of Apache git repositories on git-wip-us.apache.org

I have opened https://issues.apache.org/jira/browse/INFRA-17374 to track it, but as per the original email (see below), we need to provide the link to the discussion on this issue so I am asking you to vote on it so we can go ahead and do it. Thanks. Lyor Daniel Gruno Fri 12/7/2018, 6:53 PM

[VOTE] MINA SSHD relocation of Apache git repositories on git-wip-us.apache.org

I have opened https://issues.apache.org/jira/browse/INFRA-17374 to track it, but as per the original email (see below), we need to provide the link to the discussion on this issue so I am asking you to vote on it so we can go ahead and do it. Thanks. Lyor Daniel Gruno Fri 12/7/2018, 6:53 PM

Re: I have question regarding SSH server timeout

>> I have question regarding SSH server timeout. Can you please help me with timeout configuration for sshd apache server. There are many timeouts or other configuration values that affect timeouts in SSHD. The code assumes some reasonable widely used defaults. If these are not good enough for

Re: SSH with PEM file

>> SSH user@host -i key.pem There are many ways to do this - here is the simplest // Do it ONCE in your main method SshClient client = SshClient.setupDefaultClient(); client.start(); // to connect and authenticate in the code try (ClientSession session = client.connect(user, host)

Re: [NOTICE] Mandatory migration of git repositories to gitbox.apache.org

>> Unless someone has any problem with the migration, I'm going to create the JIRA early next week to comply. No problem from my end - but I already opened https://issues.apache.org/jira/browse/INFRA-17374 - all that is required is a recorded vote (which I also sent an e-mail on this list).

  1   2   3   4   5   6   7   8   9   10   >