MIA for a few days
Hi! My computer just died this morning, it does not see the disk anymore :-/ it will be a matter of days to either get it repaired or worse, to buy a new one. I hope to be able to get back the data, as I have some substantial pending modifications to push - and yeah, next time I’ll push them to a git branch...- In the mean time, I’m pretty incapable to Participate, beside mails. I hope it win’t last too long. Thanks, Emmanuel -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
[jira] [Commented] (SSHD-860) org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client identities (private key files)
[
https://issues.apache.org/jira/browse/SSHD-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677170#comment-16677170
]
Goldstein Lyor commented on SSHD-860:
-
I do not necessarily agree with the severity but I can see why some may think
it is not minor (so upgraded it to major). Unfortunately, loading key pairs
lazily is a major overhaul of the code which we can afford at the moment given
the extremely limited R resources at our disposal. We have considered it in
the past but I am not sure when we might find the time for such an overhaul.
The good news is that we do accept code contributions (;)). If this is indeed
critical for you I recommend not to wait for us to get around to it, clone the
code and publish a PR. (Again, not because we don't want to, but because in the
foreseeable future we might not be able to invest the time it requires). If you
do go ahead with it, please note that not only this class needs an overhaul,
but perhaps all the other identity loaders and all their code
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client
> identities (private key files)
>
>
> Key: SSHD-860
> URL: https://issues.apache.org/jira/browse/SSHD-860
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0, 2.1.0, 2.1.1
>Reporter: Thomas Wolf
>Priority: Major
>
> {{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} loads and
> caches in memory private keys prematurely. Keys are loaded even if they are
> not used at all in the end. In other words, incremental loading of keys
> doesn't work.
> This is bad for two reasons:
> # Private keys should be kept in memory only if and when needed. Loading
> completely unused private keys must be avoided.
> # With encrypted private keys, the user may end up being asked for
> passphrases for keys that are not used at all in the end, which is highly
> disruptive.
> {{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} does in its
> constructor:
> {code:java}
> Iterator current;
> Collection> identities = new
> LinkedList<>();
> ...
> identities.add(Stream.of(ClientSession.providerOf(session))
> .map(KeyIdentityProvider::loadKeys)
> .flatMap(GenericUtils::stream)
> .map(kp -> new KeyPairIdentity(signatureFactories, session, kp)));
> current = identities.stream().flatMap(r -> r).iterator();
> {code}
> The final {{current}} iterator uses some internal buffer (size unknown;
> didn't try to determine it) and will pre-fill this buffer completely. So with
> buffer size _N_ it'll pre-load the first _N_ keys from the combined identity
> stream. If the first key authenticates successfully, loading all the others
> must not be done.
> See my [test
> case|https://github.com/tomaswolf/mina-sshd/blob/SSHD-860/sshd-core/src/test/java/org/apache/sshd/client/ClientKeyLoadTest.java]
> showing this faulty behavior. It does exactly the same as the
> {{UserAuthPublicKeyIterator}} constructor, using two iterators with two
> identity files each, and then tests the resulting iterator. The first
> {{hasNext()/next()}} call on the {{current}} iterator _loads all four keys!_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SSHD-860) org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client identities (private key files)
[
https://issues.apache.org/jira/browse/SSHD-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor updated SSHD-860:
Priority: Major (was: Minor)
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client
> identities (private key files)
>
>
> Key: SSHD-860
> URL: https://issues.apache.org/jira/browse/SSHD-860
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0, 2.1.0, 2.1.1
>Reporter: Thomas Wolf
>Priority: Major
>
> {{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} loads and
> caches in memory private keys prematurely. Keys are loaded even if they are
> not used at all in the end. In other words, incremental loading of keys
> doesn't work.
> This is bad for two reasons:
> # Private keys should be kept in memory only if and when needed. Loading
> completely unused private keys must be avoided.
> # With encrypted private keys, the user may end up being asked for
> passphrases for keys that are not used at all in the end, which is highly
> disruptive.
> {{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} does in its
> constructor:
> {code:java}
> Iterator current;
> Collection> identities = new
> LinkedList<>();
> ...
> identities.add(Stream.of(ClientSession.providerOf(session))
> .map(KeyIdentityProvider::loadKeys)
> .flatMap(GenericUtils::stream)
> .map(kp -> new KeyPairIdentity(signatureFactories, session, kp)));
> current = identities.stream().flatMap(r -> r).iterator();
> {code}
> The final {{current}} iterator uses some internal buffer (size unknown;
> didn't try to determine it) and will pre-fill this buffer completely. So with
> buffer size _N_ it'll pre-load the first _N_ keys from the combined identity
> stream. If the first key authenticates successfully, loading all the others
> must not be done.
> See my [test
> case|https://github.com/tomaswolf/mina-sshd/blob/SSHD-860/sshd-core/src/test/java/org/apache/sshd/client/ClientKeyLoadTest.java]
> showing this faulty behavior. It does exactly the same as the
> {{UserAuthPublicKeyIterator}} constructor, using two iterators with two
> identity files each, and then tests the resulting iterator. The first
> {{hasNext()/next()}} call on the {{current}} iterator _loads all four keys!_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SSHD-860) org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client identities (private key files)
[
https://issues.apache.org/jira/browse/SSHD-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-860:
-
Description:
{{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} loads and
caches in memory private keys prematurely. Keys are loaded even if they are not
used at all in the end. In other words, incremental loading of keys doesn't
work.
This is bad for two reasons:
# Private keys should be kept in memory only if and when needed. Loading
completely unused private keys must be avoided.
# With encrypted private keys, the user may end up being asked for passphrases
for keys that are not used at all in the end, which is highly disruptive.
{{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} does in its
constructor:
{code:java}
Iterator current;
Collection> identities = new LinkedList<>();
...
identities.add(Stream.of(ClientSession.providerOf(session))
.map(KeyIdentityProvider::loadKeys)
.flatMap(GenericUtils::stream)
.map(kp -> new KeyPairIdentity(signatureFactories, session, kp)));
current = identities.stream().flatMap(r -> r).iterator();
{code}
The final {{current}} iterator uses some internal buffer (size unknown; didn't
try to determine it) and will pre-fill this buffer completely. So with buffer
size _N_ it'll pre-load the first _N_ keys from the combined identity stream.
If the first key authenticates successfully, loading all the others must not be
done.
See my [test
case|https://github.com/tomaswolf/mina-sshd/blob/SSHD-860/sshd-core/src/test/java/org/apache/sshd/client/ClientKeyLoadTest.java]
showing this faulty behavior. It does exactly the same as the
{{UserAuthPublicKeyIterator}} constructor, using two iterators with two
identity files each, and then tests the resulting iterator. The first
{{hasNext()/next()}} call on the {{current}} iterator _loads all four keys!_
was:
{{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} loads and
caches in memory private keys prematurely. Keys are loaded even if they are not
used at all in the end. In other words, incremental loading of keys doesn't
work.
This is bad for two reasons:
# Private keys should be kept in memory only if and when needed. Loading
completely unused private keys must be avoided.
# With encrypted private keys, the user may end up being asked for passphrases
for keys that are not used at all in the end, which is highly disruptive.
{{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} does in its
constructor:
{code:java}
Iterator current;
Collection> identities = new LinkedList<>();
...
identities.add(Stream.of(ClientSession.providerOf(session))
.map(KeyIdentityProvider::loadKeys)
.flatMap(GenericUtils::stream)
.map(kp -> new KeyPairIdentity(signatureFactories, session, kp)));
current = identities.stream().flatMap(r -> r).iterator();
{code}
The final {{current}} iterator uses some internal buffer (size unknown; didn't
try to determine it) and will pre-fill this buffer completely. So with buffer
size _N_ it'll pre-load the first _N_ keys from the combined identity stream.
If the first key authenticates successfully, loading all the others must not be
done.
See my [test case|https://github.com/tomaswolf/mina-sshd/commit/a71c62e66]
showing this faulty behavior. It does exactly the same as the
{{UserAuthPublicKeyIterator}} constructor, using two iterators with two
identity files each, and then tests the resulting iterator. The first
{{hasNext()/next()}} call on the {{current}} iterator _loads all four keys!_
Link to test case updated.
I'm a bit surprised you consider this "minor"... note that this also means that
a serious sshd client cannot use {{UserAuthPublicKeyIterator}} but needs to
provide its own implementation, which is not possible without some minor
hacking. See for instance what we do in JGit to get around this problem:
*
[JGitPublicKeyIterator.java|https://git.eclipse.org/r/#/c/131884/6/org.eclipse.jgit.ssh.apache/src/org/eclipse/jgit/internal/transport/sshd/JGitPublicKeyIterator.java]
*
[JGitPublicKeyAuthentication.java|https://git.eclipse.org/r/#/c/131884/6/org.eclipse.jgit.ssh.apache/src/org/eclipse/jgit/internal/transport/sshd/JGitPublicKeyAuthentication.java]
– not calling {{super.init()}} is the "minor hack" I referred to above
*
[JGitPublicKeyAuthFactory.java|https://git.eclipse.org/r/#/c/131884/6/org.eclipse.jgit.ssh.apache/src/org/eclipse/jgit/internal/transport/sshd/JGitPublicKeyAuthFactory.java]
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client
> identities (private key files)
>
>
> Key: SSHD-860
> URL: https://issues.apache.org/jira/browse/SSHD-860
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0,
[jira] [Updated] (SSHD-860) org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client identities (private key files)
[
https://issues.apache.org/jira/browse/SSHD-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor updated SSHD-860:
Priority: Minor (was: Critical)
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client
> identities (private key files)
>
>
> Key: SSHD-860
> URL: https://issues.apache.org/jira/browse/SSHD-860
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0, 2.1.0, 2.1.1
>Reporter: Thomas Wolf
>Priority: Minor
>
> {{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} loads and
> caches in memory private keys prematurely. Keys are loaded even if they are
> not used at all in the end. In other words, incremental loading of keys
> doesn't work.
> This is bad for two reasons:
> # Private keys should be kept in memory only if and when needed. Loading
> completely unused private keys must be avoided.
> # With encrypted private keys, the user may end up being asked for
> passphrases for keys that are not used at all in the end, which is highly
> disruptive.
> {{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} does in its
> constructor:
> {code:java}
> Iterator current;
> Collection> identities = new
> LinkedList<>();
> ...
> identities.add(Stream.of(ClientSession.providerOf(session))
> .map(KeyIdentityProvider::loadKeys)
> .flatMap(GenericUtils::stream)
> .map(kp -> new KeyPairIdentity(signatureFactories, session, kp)));
> current = identities.stream().flatMap(r -> r).iterator();
> {code}
> The final {{current}} iterator uses some internal buffer (size unknown;
> didn't try to determine it) and will pre-fill this buffer completely. So with
> buffer size _N_ it'll pre-load the first _N_ keys from the combined identity
> stream. If the first key authenticates successfully, loading all the others
> must not be done.
> See my [test case|https://github.com/tomaswolf/mina-sshd/commit/a71c62e66]
> showing this faulty behavior. It does exactly the same as the
> {{UserAuthPublicKeyIterator}} constructor, using two iterators with two
> identity files each, and then tests the resulting iterator. The first
> {{hasNext()/next()}} call on the {{current}} iterator _loads all four keys!_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677002#comment-16677002 ] Goldstein Lyor commented on SSHD-849: - Not a problem - time spent trying to improve the code is never wasted - even if it turns out that there was nothing to do. At least we have a double confirmation that the original code works. Closing the issue... > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Assignee: Goldstein Lyor >Priority: Major > Fix For: 2.1.1 > > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Our definitive working code is at > https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6 > Cheers. > Roberto > Cheers > Roberto > The code changes against master code are : > https://github.com/robertodeandrea/myclone/commit/0602840140ce82f51446b0d5a05fb409e730adad > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roberto Deandrea closed SSHD-849. - Resolution: Fixed Hi Lyor, You can consider good your master code. We made a mistake during our test phase so our latest code is NOT needed to make things work for us. Very sorry for wasting your precious time!! Regards Roberto > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Assignee: Goldstein Lyor >Priority: Major > Fix For: 2.1.1 > > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Our definitive working code is at > https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6 > Cheers. > Roberto > Cheers > Roberto > The code changes against master code are : > https://github.com/robertodeandrea/myclone/commit/0602840140ce82f51446b0d5a05fb409e730adad > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SSHD-860) org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client identities (private key files)
Thomas Wolf created SSHD-860:
Summary:
org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client
identities (private key files)
Key: SSHD-860
URL: https://issues.apache.org/jira/browse/SSHD-860
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.0.0, 2.1.0, 2.1.1
Reporter: Thomas Wolf
{{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} loads and
caches in memory private keys prematurely. Keys are loaded even if they are not
used at all in the end. In other words, incremental loading of keys doesn't
work.
This is bad for two reasons:
# Private keys should be kept in memory only if and when needed. Loading
completely unused private keys must be avoided.
# With encrypted private keys, the user may end up being asked for passphrases
for keys that are not used at all in the end, which is highly disruptive.
{{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} does in its
constructor:
{code:java}
Iterator current;
Collection> identities = new LinkedList<>();
...
identities.add(Stream.of(ClientSession.providerOf(session))
.map(KeyIdentityProvider::loadKeys)
.flatMap(GenericUtils::stream)
.map(kp -> new KeyPairIdentity(signatureFactories, session, kp)));
current = identities.stream().flatMap(r -> r).iterator();
{code}
The final {{current}} iterator uses some internal buffer (size unknown; didn't
try to determine it) and will pre-fill this buffer completely. So with buffer
size _N_ it'll pre-load the first _N_ keys from the combined identity stream.
If the first key authenticates successfully, loading all the others must not be
done.
See my [test case|https://github.com/tomaswolf/mina-sshd/commit/a71c62e66]
showing this faulty behavior. It does exactly the same as the
{{UserAuthPublicKeyIterator}} constructor, using two iterators with two
identity files each, and then tests the resulting iterator. The first
{{hasNext()/next()}} call on the {{current}} iterator _loads all four keys!_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[
https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676595#comment-16676595
]
Goldstein Lyor commented on SSHD-849:
-
Here is how to make sure you are correctly rebased (assuming you have followed
my previous instructions)
* Edit your {{~/.gitconfig}} file and add
{noformat}
[pull]
rebase = true
{noformat}
** or {code:bash}git config --global pull.rebase true{code}
** or {code:bash}git config pull.rebase true{code} - if you don't want it in
all your projects
* {{git co master}} - assuming {{origin/master}} is the MINA SSHD github project
* {{git pull -tp}}
* {{git co master -b SSHD-849}}
* ...make only your changes...
* {{git push -u (if 1st time yous push this branch) -f (if you already have
pushed this branch) fork SSHD-849}}
* Go to your github fork and create a PR
I would like to emphasize again - please do not reformat the code and make sure
only your changes are in the commit.
> Possible race condition for local port forwarding channels
> --
>
> Key: SSHD-849
> URL: https://issues.apache.org/jira/browse/SSHD-849
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.1.1
>
>
> Hi Lyor,
> We found another critical race condition sending data through local port
> forwarding channels that causes loosing data bytes sent by client to target
> server.
> As soon as possible I will open a pull request with our potential changes to
> fix this issue.
> I let you know when done because I would like to know your feedback.
> Hi Lyor,
> We made some code changes to your proposed solution based on
> ClientChannelPendingMessageQueue.
> You can find our commit at
> https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d
> Can you review our code and give us feedback ?
> If it satisfies you can you merge it in Apache SSHD master repository ?
> Our definitive working code is at
> https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6
> Cheers.
> Roberto
> Cheers
> Roberto
> The code changes against master code are :
> https://github.com/robertodeandrea/myclone/commit/0602840140ce82f51446b0d5a05fb409e730adad
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676486#comment-16676486 ] Goldstein Lyor commented on SSHD-849: - Hi Roberto, Sorry, but the PR is still not "clean" - it is (still) not rebased on latest _master_ version + contains re-formatting (which I asked not to do...). Lyor > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Assignee: Goldstein Lyor >Priority: Major > Fix For: 2.1.1 > > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Our definitive working code is at > https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6 > Cheers. > Roberto > Cheers > Roberto > The code changes against master code are : > https://github.com/robertodeandrea/myclone/commit/0602840140ce82f51446b0d5a05fb409e730adad > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676316#comment-16676316 ] Roberto Deandrea commented on SSHD-849: --- Hi Lyor, My pull request with 2 files changed is the following : https://github.com/apache/mina-sshd/pull/80 Thanks for your instructions. Regards Roberto > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Assignee: Goldstein Lyor >Priority: Major > Fix For: 2.1.1 > > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Our definitive working code is at > https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6 > Cheers. > Roberto > Cheers > Roberto > The code changes against master code are : > https://github.com/robertodeandrea/myclone/commit/0602840140ce82f51446b0d5a05fb409e730adad > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676315#comment-16676315 ] ASF GitHub Bot commented on SSHD-849: - GitHub user robertodeandrea opened a pull request: https://github.com/apache/mina-sshd/pull/80 SSHD-849 working code for pull request Lyor, this is my pull request according to your instructions for review. You can merge this pull request into a Git repository by running: $ git pull https://github.com/robertodeandrea/mina-sshd SSHD-849 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mina-sshd/pull/80.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #80 commit c9cf7ce16367926da56f1444e8479dee63de7241 Author: roberto.deandrea Date: 2018-11-06T07:58:36Z SSHD-849 working code for pull request > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Assignee: Goldstein Lyor >Priority: Major > Fix For: 2.1.1 > > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Our definitive working code is at > https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6 > Cheers. > Roberto > Cheers > Roberto > The code changes against master code are : > https://github.com/robertodeandrea/myclone/commit/0602840140ce82f51446b0d5a05fb409e730adad > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] mina-sshd pull request #80: SSHD-849 working code for pull request
GitHub user robertodeandrea opened a pull request: https://github.com/apache/mina-sshd/pull/80 SSHD-849 working code for pull request Lyor, this is my pull request according to your instructions for review. You can merge this pull request into a Git repository by running: $ git pull https://github.com/robertodeandrea/mina-sshd SSHD-849 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mina-sshd/pull/80.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #80 commit c9cf7ce16367926da56f1444e8479dee63de7241 Author: roberto.deandrea Date: 2018-11-06T07:58:36Z SSHD-849 working code for pull request ---
