mimaya commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1698929146
> handleClose() handles reception of the peer's CLOSE message. As I
understood the problem is that the client sends its EOF after it has already
sent its CLOSE.
We always
mimaya commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1698964313
I also couldn't reproduce this issue with sample code. this comes only in
our application during PSR testing where more than 50k command are executed
over ssh.
--
This is an
tomaswolf merged PR #404:
URL: https://github.com/apache/mina-sshd/pull/404
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
tomaswolf merged PR #413:
URL: https://github.com/apache/mina-sshd/pull/413
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
tomaswolf closed issue #410: SSH_MSG_CHANNEL_EOF is sent after
SSH_MSG_CHANNEL_CLOSE
URL: https://github.com/apache/mina-sshd/issues/410
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the
elecharny commented on PR #27:
URL: https://github.com/apache/mina/pull/27#issuecomment-1707651468
AFAICT, this has been committed a long time ago;
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go
elecharny closed pull request #27: DIRMINA-1126 : filterWrite in
ProtocolCodecFilter can send corrupted writeRequest message to the next filter
URL: https://github.com/apache/mina/pull/27
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to
FerrariCalifornia opened a new issue, #414:
URL: https://github.com/apache/mina-sshd/issues/414
### Version
2.9.2
### Bug description
When using a custom thread to send netconf messages, the cpu is continuously
occupied, which affects the code of other modules. I
FerrariCalifornia commented on issue #414:
URL: https://github.com/apache/mina-sshd/issues/414#issuecomment-1709350807
we did not try 2.10.0
Here is the code I suspect is causing the problem
tomaswolf commented on issue #414:
URL: https://github.com/apache/mina-sshd/issues/414#issuecomment-1709555946
I do know the Apache MINA sshd code :smile:. Yes, that's where the loop is.
But the bug is in the flushing thread; it must handle exceptions that occur
when flushing a packet
thachlp closed pull request #347: Update docs
URL: https://github.com/apache/mina-sshd/pull/347
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
mimaya opened a new issue, #410:
URL: https://github.com/apache/mina-sshd/issues/410
### Version
2.10.0
### Bug description
when we close channelOutputStream and ClientChannel with in few milli
seconds delay. some time sending of SSH_MSG_CHANNEL_EOF message goes after
tomaswolf commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1696220020
Can you provide code for reproducing this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above
tomaswolf commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1699596455
I'm getting confused.
Who initiates the channel closing when that problem occurs? Client or
server? Or both?
Is client code closing the output stream explicitly, or
yuruhimesama commented on issue #412:
URL: https://github.com/apache/mina-sshd/issues/412#issuecomment-1699261864
Curious, thank you for the insight into why the stack trace is returning
what it does.
As for the algorithm, everything we do defaults to RSA but I can generate EC
tomaswolf merged PR #411:
URL: https://github.com/apache/mina-sshd/pull/411
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
tomaswolf opened a new pull request, #413:
URL: https://github.com/apache/mina-sshd/pull/413
When a channel using a ChannelAsyncOutputStream, do not only wait until all
pending data has been written but also wait for the EOF having been sent before
proceeding with closing the channel.
fherbreteau commented on code in PR #404:
URL: https://github.com/apache/mina-sshd/pull/404#discussion_r1313667435
##
sshd-common/src/main/java/org/apache/sshd/common/util/buffer/Buffer.java:
##
@@ -292,6 +292,10 @@ public short getShort() {
return v;
}
+
fherbreteau commented on code in PR #404:
URL: https://github.com/apache/mina-sshd/pull/404#discussion_r1313668685
##
sshd-contrib/pom.xml:
##
@@ -80,6 +80,16 @@
test-jar
test
+
+ org.mockito
+
fherbreteau commented on PR #404:
URL: https://github.com/apache/mina-sshd/pull/404#issuecomment-1703608365
Indentation fixed.
Commit squashed with new commit message.
btw I've reused your proposal as it fits the intent of the MR.
--
This is an automated message from the Apache Git
tomaswolf commented on code in PR #404:
URL: https://github.com/apache/mina-sshd/pull/404#discussion_r1313454310
##
sshd-contrib/pom.xml:
##
@@ -80,6 +80,16 @@
test-jar
test
+
+ org.mockito
+
dependabot[bot] commented on PR #400:
URL: https://github.com/apache/mina-sshd/pull/400#issuecomment-1703282548
OK, I won't notify you again about this release, but will get in touch when
a new version is available. If you'd rather skip all updates until the next
major or minor version,
tomaswolf commented on PR #400:
URL: https://github.com/apache/mina-sshd/pull/400#issuecomment-1703282502
Done as part of commit 9cc8be8, which also bumped the Apache parent POM and
thus a lot of other versions of build-time dependencies.
--
This is an automated message from the Apache
tomaswolf closed pull request #400: Bump org.codehaus.plexus:plexus-archiver
from 4.2.6 to 4.8.0
URL: https://github.com/apache/mina-sshd/pull/400
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to
tomaswolf merged PR #415:
URL: https://github.com/apache/mina-sshd/pull/415
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
tomaswolf closed issue #414: A broken link during key exchange may cause an
infinite loop.
URL: https://github.com/apache/mina-sshd/issues/414
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the
yuruhimesama commented on issue #412:
URL: https://github.com/apache/mina-sshd/issues/412#issuecomment-1699327825
Update -- altering to an EC256 key solved the whole problem. Thank you for
alerting me to it. I'm glad I do not have to attempt any interventions with the
`Registrar`
yuruhimesama closed issue #412: Azure JCA Provider Not Being Recognized --
URL: https://github.com/apache/mina-sshd/issues/412
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
yuruhimesama opened a new issue, #412:
URL: https://github.com/apache/mina-sshd/issues/412
### Version
2.10
### Bug description
I am trying to integrate the [Azure Keyvault JCA
mimaya commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1697915239
will the below changes fix the issue ?
AbstractChannel
line 101
`
protected IoWriteFuture sendEofFuture;
`
AbstractChannel.sendEof()
line: 961
`
mimaya commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1697908979
AbstractChannel
line 101
protected IoWriteFuture sendEofFuture;
AbstractChannel.sendEof()
line: 961
this.sendEofFuture = s.writePacket(buffer);
tomaswolf commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1697949684
> will the below changes fix the issue ?
I don't think so. First, storing that IoWriteFuture in a field is kind of
hacky, and second, `handleClose()` handles reception of
mimaya commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1697964493
we added it in handleClose as reception of peer CLOSE calls channel close
and send client CLOSE message
ClientSessionImpl.doHandleMessage
tomaswolf commented on code in PR #404:
URL: https://github.com/apache/mina-sshd/pull/404#discussion_r1311446710
##
sshd-contrib/src/main/java/org/apache/sshd/contrib/server/session/proxyprotocolv2/utils/ProxyUtils.java:
##
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache
tomaswolf commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1700652719
All right. I have now a test case that reproduces this. It's hyper-ugly test
code, and to reproduce the race I had to instrument the code in
`AbstractChannel`. But there is
tomaswolf commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1697999000
I think I need code that shows this problem all the same. So far I have not
been able to provoke this condition.
--
This is an automated message from the Apache Git Service.
To
fherbreteau commented on code in PR #404:
URL: https://github.com/apache/mina-sshd/pull/404#discussion_r1311683836
##
sshd-contrib/src/main/java/org/apache/sshd/contrib/server/session/proxyprotocolv2/utils/ProxyUtils.java:
##
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache
fherbreteau commented on code in PR #404:
URL: https://github.com/apache/mina-sshd/pull/404#discussion_r1311683836
##
sshd-contrib/src/main/java/org/apache/sshd/contrib/server/session/proxyprotocolv2/utils/ProxyUtils.java:
##
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache
fherbreteau commented on code in PR #404:
URL: https://github.com/apache/mina-sshd/pull/404#discussion_r1311564415
##
sshd-contrib/src/main/java/org/apache/sshd/contrib/server/session/proxyprotocolv2/utils/ProxyUtils.java:
##
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache
fherbreteau commented on code in PR #404:
URL: https://github.com/apache/mina-sshd/pull/404#discussion_r1311570124
##
sshd-contrib/src/main/java/org/apache/sshd/contrib/server/session/proxyprotocolv2/utils/ProxyUtils.java:
##
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache
tomaswolf commented on code in PR #404:
URL: https://github.com/apache/mina-sshd/pull/404#discussion_r1311600018
##
sshd-contrib/src/main/java/org/apache/sshd/contrib/server/session/proxyprotocolv2/utils/ProxyUtils.java:
##
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache
mimaya commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1708752868
Do you have any tentative date 2.10.1 release that has the fix?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and
tomaswolf commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1708796218
No, I don't. The 2.10.1-SNAPSHOT from the [Apache Snapshot
repository](https://repository.apache.org/content/repositories/snapshots) does
have the fix.
There is no fixed
tomaswolf commented on issue #414:
URL: https://github.com/apache/mina-sshd/issues/414#issuecomment-1708783985
That looks strange. I do have a nasty suspicion... please show the code of
your transferEpQueryReq thread.
--
This is an automated message from the Apache Git Service.
To
tomaswolf opened a new pull request, #415:
URL: https://github.com/apache/mina-sshd/pull/415
During KEX we may queue up higher-level packets. When KEX ends, we flush
this queue, writing all these queued packets. When writing a queued packet
fails, previous code handled the failure wrongly,
evgeny-pasynkov opened a new pull request, #424:
URL: https://github.com/apache/mina-sshd/pull/424
This allows client code to override and extend the Nio2Session class.
Current implementation creates createWriteCycleCompletionHandler which executes
OS callback and completes the future on
mimaya commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1765702087
If you are planning to release 2.9.3 before 2.11.0 . Would it be possible to
add the fix in 2.9.3 ?
--
This is an automated message from the Apache Git Service.
To respond to the
tomaswolf commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1765764491
Guillaume just included the CVE fix in 2.9.3. I don't have time to backport
this fix and ask for a respin.
--
This is an automated message from the Apache Git Service.
To
sanshengshui commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-1782544953
IPV4 connection
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific
elecharny commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-1782455788
@sanshengshui the diff I see is that curl uses ESPV while wget uses PASV. Is
that a IPV6 connection?
--
This is an automated message from the Apache Git Service.
To respond
elecharny commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-1782215984
Ok, so can you provide the code associated with
om.tuya.sftp.protocol.gateway.service.protocol.command.RetrCommand?
--
This is an automated message from the Apache Git
sanshengshui commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-1782228194
One way to cheat is: Through what configuration can the client only go to
PASV mode
--
This is an automated message from the Apache Git Service.
To respond to the
sanshengshui commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-178408
I made a preliminary determination that curl went to epsv mode by default.
The curl command is as follows:
```
➜ ~ curl --ftp-pasv -u 02982C3LaV:TjTv7Swb -O
sanshengshui commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-1782179965
I am an employee of tuya.com and am trying to set up an ftp service using
FTP-server
I'll keep trying to figure out what caused it
Whether wget enters epsv mode
kllbzz opened a new pull request, #41:
URL: https://github.com/apache/mina/pull/41
I'm getting exception when using SSL filter together with SOCKS proxy in
quickfix library 2.2.0 with mina 2.2.2
java.lang.IllegalStateException
at
chrjohn commented on PR #41:
URL: https://github.com/apache/mina/pull/41#issuecomment-1783732939
I'm surprised that it worked to simply swap out MINA in QFJ 2.2.0 at runtime
since here were some API incompatibilties.
There is a PR here https://github.com/quickfix-j/quickfixj/pull/661
elecharny commented on PR #41:
URL: https://github.com/apache/mina/pull/41#issuecomment-1783879546
To be clear: as soon as the connection has been created, we need to initiate
the handshake. This is the purpose of the **onPosAdd** method. If we don't do
that, then the handshake will never
elecharny commented on PR #41:
URL: https://github.com/apache/mina/pull/41#issuecomment-1786361873
@kllbzz I think the autostart feature is missing in 2.2.X, and I think we
should reintroduce it. Actually, this is the default behaviour, but there are
uses case - like yours - where we want
elecharny commented on PR #41:
URL: https://github.com/apache/mina/pull/41#issuecomment-1789366924
Patch applied!
Many thanks!
I'll try to get a release out in the coming days.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log
elecharny closed pull request #41: Remove ssl handshake initiation from postAdd
method in SslFilter.java
URL: https://github.com/apache/mina/pull/41
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to
RyanLivingston opened a new issue, #427:
URL: https://github.com/apache/mina-sshd/issues/427
### Version
2.11.0
### Bug description
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is
RyanLivingston opened a new issue, #428:
URL: https://github.com/apache/mina-sshd/issues/428
### Version
2.11.0
### Bug description
When calling `ScpClient(String, String)`, the method does not throw any
exception or indicate to the caller that the SCP failed when the
pflaska opened a new issue, #429:
URL: https://github.com/apache/mina-sshd/issues/429
### Description
To make the git protocol-v2 work, the env. variable GIT_PROTOCOL has to be
set to the 'version=2' value on the client side. The SSHD server reads the
variable and sets extra
pflaska opened a new pull request, #430:
URL: https://github.com/apache/mina-sshd/pull/430
Make the protocol-v2 default for client. GIT_PROTOCOL environment variable
is set to "version=2" in a session.
The UploadPack is modified to accept the variable.
lgoldstein commented on issue #428:
URL: https://github.com/apache/mina-sshd/issues/428#issuecomment-1792016802
The log is very long and convoluted - can you show what you mean by
> From the logging, we can see a WARNING exit status is received but it is
only logged.
--
This is an
rohit-100 commented on issue #25:
URL: https://github.com/apache/mina-ftpserver/issues/25#issuecomment-1791986638
@elecharny i am also facing compatablity issue of mina-core-2.2.1 with ftp
server. Can you pls do it soon , i am waiting for it.
--
This is an automated message from the
lgoldstein commented on code in PR #430:
URL: https://github.com/apache/mina-sshd/pull/430#discussion_r1381259350
##
sshd-git/src/main/java/org/apache/sshd/git/pack/GitPackCommand.java:
##
@@ -77,7 +79,11 @@ public void run() {
Repository db = key.open(true /* must
lgoldstein commented on code in PR #430:
URL: https://github.com/apache/mina-sshd/pull/430#discussion_r1381259350
##
sshd-git/src/main/java/org/apache/sshd/git/pack/GitPackCommand.java:
##
@@ -77,7 +79,11 @@ public void run() {
Repository db = key.open(true /* must
RyanLivingston commented on issue #428:
URL: https://github.com/apache/mina-sshd/issues/428#issuecomment-1792516539
> The log is very long and convoluted - can you show what you mean by
>
> > From the logging, we can see a WARNING exit status is received but it is
only logged.
lgoldstein commented on issue #428:
URL: https://github.com/apache/mina-sshd/issues/428#issuecomment-1792758336
Another question - I see that the command being executed is
```
scp -f -- /Users/ryanlivingston/tmp/null.txt
```
What does the "--" stand for ? I am not familiar with
RyanLivingston commented on issue #428:
URL: https://github.com/apache/mina-sshd/issues/428#issuecomment-1792808302
Thanks for the response!
This testing is being done on macOS (JDK 18) with what I believe is an
_OpenSSH_ server. The testing user has no explicit `~/.ssh/ssh_config`
RyanLivingston commented on issue #428:
URL: https://github.com/apache/mina-sshd/issues/428#issuecomment-1792827892
> Another question - I see that the command being executed is
>
> ```
> scp -f -- /Users/ryanlivingston/tmp/null.txt
> ```
>
> What does the "--" stand for
lgoldstein commented on issue #428:
URL: https://github.com/apache/mina-sshd/issues/428#issuecomment-1792752434
Thank you for the clarification - this sounds very strange - will need to
look into it, though there is one more question - what **server** are you using
? Is it *OpenSSH*, MINA
kllbzz commented on PR #41:
URL: https://github.com/apache/mina/pull/41#issuecomment-1786199195
@elecharny thanks for reply.
> The rational is that teh _SslFilter_ can be added on the fly on an opened
session, so removing the call to _onConnected_ in the _onPostAdd_ will defeat
this
kllbzz commented on PR #41:
URL: https://github.com/apache/mina/pull/41#issuecomment-1786206622
> Side note: in 2.1.X and 2.0.X, this is how it works: we initiate the
handshake in the _postAdd_ method, nowhere else.
yes, you are right, it was also public method to do handshake. So as
elecharny commented on PR #41:
URL: https://github.com/apache/mina/pull/41#issuecomment-1784467431
Side note: in 2.1.X and 2.0.X, this is how it works: we initiate the
handshake in the _postAdd_ method, nowhere else.
--
This is an automated message from the Apache Git Service.
To respond
elecharny commented on PR #41:
URL: https://github.com/apache/mina/pull/41#issuecomment-1784464949
@kllbzz reviewing the SslFilter code, I think I totally missed the part
where the SslHandler is also initialized in the _SessionOpened_ function.
Originally, it was done in the _onPostAdd_,
kllbzz commented on PR #41:
URL: https://github.com/apache/mina/pull/41#issuecomment-1784193949
@chrjohn you are right, I leid a bit, I introduced this exact PR into 2.2.0
version, I'm using a bit modified quickfix library. Actually inital problem was
to get rid of
kllbzz commented on PR #41:
URL: https://github.com/apache/mina/pull/41#issuecomment-1784200832
@elecharny
> To be clear: as soon as the connection has been created, we need to
initiate the handshake. This is the purpose of the **onPosAdd** method. If we
don't do that, then the
kllbzz commented on PR #41:
URL: https://github.com/apache/mina/pull/41#issuecomment-1787184366
@elecharny for my personal needs it seems I'm ok to not merge it at all. For
community, yes, I would revert this flag, next guy will spend less time getting
proxy + ssl working with this version
alexmherrmann opened a new issue, #426:
URL: https://github.com/apache/mina-sshd/issues/426
### Version
2.11.0
### Bug description
I have not found any examples of what I am trying to do in official
documentation.
I have two tests here (in kotlin):
elecharny commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-1778011235
1.1.2: https://issues.apache.org/jira/projects/FTPSERVER/versions/12340451
1.1.3 and 1.1.4 were mainly bumping up some dependencies.
I'd just like to know if you still
sanshengshui commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-1780678322
I just upgraded to 1.1.4
Here's what happens when you download with curl
```
➜ Downloads curl -u 0297XfYHmj:Cbr3QqJC -o ocpp.tar.gz
elecharny commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-1780732921
Can you check if you have any log on the FtpServer side?
More specifically, any log containing the string "Exception during data
transfer, closing data connection
mimaya commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1780665841
Thanks , I see 2.11.0 version is released now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above
sanshengshui commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-1780841012
The error message is as follows:
```
2023-10-26 16:41:01.018|TID:N/A|WARN
sanshengshui commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-1780671735
Just upgraded to version 1.1.4
Here's what happens when you download with curl:
```bash
➜ Downloads curl -u 0297XfYHmj:Cbr3QqJC -o ocpp.tar.gz
elecharny commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-1780884115
Ok, this is clearly not a problem in MINA FTP server code. At some point,
when the RETR command is received, the following method is called:
```
at
elecharny commented on issue #29:
URL: https://github.com/apache/mina-ftpserver/issues/29#issuecomment-1780926271
Some question:
* the fact the socket times out drives me to think it's more like a
configuration issue on your side than a problem in the code. Can you check that?
* Which
lgoldstein commented on issue #428:
URL: https://github.com/apache/mina-sshd/issues/428#issuecomment-1795490668
Thanks for the information - I will try and take a look at it when I have
some free time (not sure when it will be...)
--
This is an automated message from the Apache Git
mimaya commented on issue #410:
URL: https://github.com/apache/mina-sshd/issues/410#issuecomment-1766990540
We are using this in a large enterprise product. To fix an issue, we were
upgrading the SSH client to 2.9.2, but we found the following problem during
PSR testing:
tomaswolf commented on issue #418:
URL: https://github.com/apache/mina-sshd/issues/418#issuecomment-1730022907
This sounds like a duplicate of the recently fixed #410. Does this still
occur with 2.10.1-SNAPSHOT available from the [Apache Snapshot
lgoldstein commented on PR #416:
URL: https://github.com/apache/mina-sshd/pull/416#issuecomment-1724046203
@tomaswolf Please review and merge if you are satisfied - thx.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use
lgoldstein opened a new pull request, #416:
URL: https://github.com/apache/mina-sshd/pull/416
(no comment)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe,
lgoldstein commented on issue #328:
URL: https://github.com/apache/mina-sshd/issues/328#issuecomment-1724059388
Seems reasonable - I will look into it...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above
lgoldstein commented on issue #355:
URL: https://github.com/apache/mina-sshd/issues/355#issuecomment-1724071731
There is no built-in mechanism, but you could achieve this by registering a
non-default `SftpFileSystemAccessor` and override the `openFile` method to
return a file channel that
dependabot[bot] opened a new pull request, #417:
URL: https://github.com/apache/mina-sshd/pull/417
Bumps org.eclipse.jgit:org.eclipse.jgit from 5.13.0.202109080827-r to
6.6.1.202309021850-r.
[