Re: SSL Code format

[Jonathan Valliere]

It’s fine. I only use nondescript names when there just isn’t something
great.

On Fri, Feb 25, 2022 at 12:43 PM Emmanuel Lécharny 
wrote:

> Hi Jonathan
>
> do you mind if I do a bit of formatting in the SSL classes, like :
> - using meaningful variables instead of single letter ones (sslHandler
> instead of x, for instance)
> - get rid of useless 'final' keyword
> - add some missing {} around LOGs
> - rename the mXyx member variables to xyz
>
> The idea is to have a code base which is globally using the same scheme...
>
> Thanks !
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> 
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
>

[jira] [Commented] (SSHD-1250) Document how to set up an encrypted tunnel

[Thomas Wolf (Jira)]

[ 
https://issues.apache.org/jira/browse/SSHD-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498303#comment-17498303
 ] 

Thomas Wolf commented on SSHD-1250:
---

There is no built-in implementation of a client-side proxy connector in Apache 
MINA sshd. You'd have to write your own. If you want a "secure" proxy you'd 
have to have a TLS connection to the proxy and run the proxy protocol over 
that, the run the SSH protocol over that TLS connection. This effectively 
encrypts twice (outer TLS, inner SSH).

Typically such proxies run locally or in a trusted network, so using a normal 
non-TLS connection should be fine. The proxy connect would be unsecured, which 
is fine in a trusted network, but the SSH connection over that proxy connection 
is encrypted, like all SSH connections, which should be good enough. But Apache 
MINA sshd also has no built-in implementation for this. There is one in 
[JGit|https://git.eclipse.org/r/plugins/gitiles/jgit/jgit/+/refs/heads/master], 
but it's not self-contained and fairly involved. See SSHD-1008.

> Document how to set up an encrypted tunnel
> --
>
> Key: SSHD-1250
> URL: https://issues.apache.org/jira/browse/SSHD-1250
> Project: MINA SSHD
>  Issue Type: Documentation
>Affects Versions: 2.8.0
>Reporter: Gili
>Priority: Major
>
> Please explain how to set up an encrypted connection in 
> [https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md] 
> I'd like to be able to run a "secure" SOCKS proxy as defined by 
> https://github.com/eclipse/jetty.project/issues/7647



--
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

SSL Code format

[Emmanuel Lécharny]

Hi Jonathan

do you mind if I do a bit of formatting in the SSL classes, like :
- using meaningful variables instead of single letter ones (sslHandler 
instead of x, for instance)

- get rid of useless 'final' keyword
- add some missing {} around LOGs
- rename the mXyx member variables to xyz

The idea is to have a code base which is globally using the same scheme...

Thanks !
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Created] (SSHD-1250) Document how to set up an encrypted tunnel

[Gili (Jira)]

Gili created SSHD-1250:
--

 Summary: Document how to set up an encrypted tunnel
 Key: SSHD-1250
 URL: https://issues.apache.org/jira/browse/SSHD-1250
 Project: MINA SSHD
  Issue Type: Documentation
Affects Versions: 2.8.0
Reporter: Gili


Please explain how to set up an encrypted connection in 
[https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md] 

I'd like to be able to run a "secure" SOCKS proxy as defined by 
https://github.com/eclipse/jetty.project/issues/7647



--
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: Trouble with deleghated tasks in MINA 2.2 SSLHandler

[Emmanuel Lécharny]

Some more insight:

When a exception is thrown while processing a task, the SslEngine do 
close the InputBound (normal). The probelm now that we can't really call 
the receive_loop() again to send back the Alert, because tghis method 
first check the InputBoud status:


protected void receive_loop(final NextFilter next, final IoBuffer 
message) throws SSLException {
System.out.println(toString() + " receive_loop() - source " + 
message);


if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - source {}", toString(), 
message);

}

if (mEngine.isInboundDone()) {
System.out.println(toString() + " receive_loop() - closed");
throw new IllegalStateException("closed");
}

so we never send back the alert.

If I do something like :


synchronized protected void throw_pending_error(NextFilter next) 
throws SSLException {

final SSLException e = this.mPendingError;
if (e != null) {
this.mPendingError = null;
this.receive_loop(next, null);  // Call the loop
throw e;
}
}


and:

protected void receive_loop(final NextFilter next, final IoBuffer 
message) throws SSLException {
System.out.println(toString() + " receive_loop() - source " + 
message);


if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - source {}", toString(), 
message);

}

if (mEngine.isInboundDone()) {
System.out.println(toString() + " receive_loop() - closed");

switch (mEngine.getHandshakeStatus()) {
case NEED_WRAP:
System.out.println(toString() + " receive_loop() - 
handshake needs wrap, invoking write");

if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - handshake 
needs wrap, invoking write", toString());

}
this.write_handshake(next);
break;
}
throw new IllegalStateException("closed");
}


then all come back on its feet. But it's kind of ugly...

On 25/02/2022 14:55, Emmanuel Lécharny wrote:

Hi Jonathan,

we need to close the connection, but the error alert should be sent 
before that. Actually, that should inform the remote peer that there was 
some problem.


What I don't k now ATM is what happens when the SSLEngine fail at some 
task. We should check the HS status, and I guess it will return a 
NEED_WRAP, which will produce the Error Alert, that we should send to 
the remote peer and the close the session.


The receive_loop currently do that:

     protected void receive_loop(final NextFilter next, final IoBuffer 
message) throws SSLException {

     ...
     final SSLEngineResult result = mEngine.unwrap(source.buf(), 
dest.buf());

 ...
     switch (result.getHandshakeStatus()) {
     ...
     case NEED_TASK:
     if (LOGGER.isDebugEnabled()) {
     LOGGER.debug("{} receive_loop() - handshake needs 
task, scheduling", toString());

     }
     this.schedule_task(next);
     break;
     ...
     }
     }

and we get out immediately while the tasks are being executed, which 
leave the HS pending. If one task fails, we need to enter into the loop 
again in order to send the Alert.


On 25/02/2022 13:47, Jonathan Valliere wrote:
If we close the ssl instantly then that’s a point of DDOS.  Relying on 
the idleness timers is important for handling connections in a bad 
state like this example. What’s the exception that unit test is 
supposed to cause?


On Thu, Feb 24, 2022 at 4:56 PM Emmanuel Lécharny > wrote:


    So the idea is first to loop on a NEED_TASK because we may need to 
send

    the alert before closing the connection (but I need to triple check
    that, it's a bit late here, and the day was a bit tough on my brain
    with
    all the bad news...)

    On 24/02/2022 19:18, Emmanuel Lécharny wrote:
 >
 >
 > On 24/02/2022 17:21, Jonathan Valliere wrote:
 >> If we were to elevate this error in another way like an error
    handler
 >> then what would you do? Close the session?
 >
 > Actually, yes, we should send a Error alert (see
 > https://datatracker.ietf.org/doc/html/rfc8446#section-6
    , par. 6.2)
    and
 > close the session.
 >
 >
 >>
 >> On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny
 >> mailto:elecha...@gmail.com>
    >> wrote:
 >>
 >>     Understood, but here if a task fails, I'm not sure the 
exception

 >>     will be
 >>     handled at all. In the case of a handshake, nothing will be
    written
 >>     back
 >>     to the remote client, AFAICT, so the connection 

[jira] [Commented] (FTPSERVER-503) Cannot limit the server to listen for client connections using TLS 1.2(/1.3) only

[Jira]

[ 
https://issues.apache.org/jira/browse/FTPSERVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498163#comment-17498163
 ] 

Emmanuel Lécharny commented on FTPSERVER-503:
-

Fixed in 1.1.2

> Cannot limit the server to listen for client connections using TLS 1.2(/1.3) 
> only
> -
>
> Key: FTPSERVER-503
> URL: https://issues.apache.org/jira/browse/FTPSERVER-503
> Project: FtpServer
>  Issue Type: Bug
>  Components: Core, Server
>Reporter: AvnerW
>Priority: Major
> Fix For: 1.1.2
>
>
> Hi,
> I would like to know if there is a way to limit the server to listen for TLS 
> 1.2(/1.3) only and block older versions of SSL/TLS (TLS1.1, TLS1.0 or SSLv3).
> I'm using:
>  *ftpserver-core 1.1.1*
>  *mina-core 2.0.21*
> I tried to *setSslProtocol*("TLSv1.2") in the *SslConfigurationFactory*.
>  As I understand this is should affect the *SSLContext* initialization.
> However, I am able to connect to the server with both:
>  - WinSCP client after setting the min & max TLS version to *TLSv1.0-TLSv1.0*
>  - openssl s_client -connect : *-tls1* -starttls ftp
> I am expecting both to fail (as the server should only accept TLS 1.2)
> Any idea if this is a bug or not yet supported in Apache FTP?



--
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] (FTPSERVER-503) Cannot limit the server to listen for client connections using TLS 1.2(/1.3) only

[Jira]

 [ 
https://issues.apache.org/jira/browse/FTPSERVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lécharny resolved FTPSERVER-503.
-
Resolution: Fixed

Fixed in 1.1.2

> Cannot limit the server to listen for client connections using TLS 1.2(/1.3) 
> only
> -
>
> Key: FTPSERVER-503
> URL: https://issues.apache.org/jira/browse/FTPSERVER-503
> Project: FtpServer
>  Issue Type: Bug
>  Components: Core, Server
>Reporter: AvnerW
>Priority: Major
> Fix For: 1.1.2
>
>
> Hi,
> I would like to know if there is a way to limit the server to listen for TLS 
> 1.2(/1.3) only and block older versions of SSL/TLS (TLS1.1, TLS1.0 or SSLv3).
> I'm using:
>  *ftpserver-core 1.1.1*
>  *mina-core 2.0.21*
> I tried to *setSslProtocol*("TLSv1.2") in the *SslConfigurationFactory*.
>  As I understand this is should affect the *SSLContext* initialization.
> However, I am able to connect to the server with both:
>  - WinSCP client after setting the min & max TLS version to *TLSv1.0-TLSv1.0*
>  - openssl s_client -connect : *-tls1* -starttls ftp
> I am expecting both to fail (as the server should only accept TLS 1.2)
> Any idea if this is a bug or not yet supported in Apache FTP?



--
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] (FTPSERVER-503) Cannot limit the server to listen for client connections using TLS 1.2(/1.3) only

[Jira]

 [ 
https://issues.apache.org/jira/browse/FTPSERVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Lécharny updated FTPSERVER-503:

Fix Version/s: 1.1.2

> Cannot limit the server to listen for client connections using TLS 1.2(/1.3) 
> only
> -
>
> Key: FTPSERVER-503
> URL: https://issues.apache.org/jira/browse/FTPSERVER-503
> Project: FtpServer
>  Issue Type: Bug
>  Components: Core, Server
>Reporter: AvnerW
>Priority: Major
> Fix For: 1.1.2
>
>
> Hi,
> I would like to know if there is a way to limit the server to listen for TLS 
> 1.2(/1.3) only and block older versions of SSL/TLS (TLS1.1, TLS1.0 or SSLv3).
> I'm using:
>  *ftpserver-core 1.1.1*
>  *mina-core 2.0.21*
> I tried to *setSslProtocol*("TLSv1.2") in the *SslConfigurationFactory*.
>  As I understand this is should affect the *SSLContext* initialization.
> However, I am able to connect to the server with both:
>  - WinSCP client after setting the min & max TLS version to *TLSv1.0-TLSv1.0*
>  - openssl s_client -connect : *-tls1* -starttls ftp
> I am expecting both to fail (as the server should only accept TLS 1.2)
> Any idea if this is a bug or not yet supported in Apache FTP?



--
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] (FTPSERVER-503) Cannot limit the server to listen for client connections using TLS 1.2(/1.3) only

[Jira]

[ https://issues.apache.org/jira/browse/FTPSERVER-503 ]


Emmanuel Lécharny deleted comment on FTPSERVER-503:
-

was (Author: elecharny):
Hi,

I think you should tell the server you want to set TLS when started, which the 
following code:

{code:java}
ListenerFactory factory = new 
ListenerFactory(server.getListener("default"));

factory.setImplicitSsl(true); // That will add the SslFilter with your 
configuration 
{code}

Now, if you do that, your server will only accept TLS communication.

> Cannot limit the server to listen for client connections using TLS 1.2(/1.3) 
> only
> -
>
> Key: FTPSERVER-503
> URL: https://issues.apache.org/jira/browse/FTPSERVER-503
> Project: FtpServer
>  Issue Type: Bug
>  Components: Core, Server
>Reporter: AvnerW
>Priority: Major
>
> Hi,
> I would like to know if there is a way to limit the server to listen for TLS 
> 1.2(/1.3) only and block older versions of SSL/TLS (TLS1.1, TLS1.0 or SSLv3).
> I'm using:
>  *ftpserver-core 1.1.1*
>  *mina-core 2.0.21*
> I tried to *setSslProtocol*("TLSv1.2") in the *SslConfigurationFactory*.
>  As I understand this is should affect the *SSLContext* initialization.
> However, I am able to connect to the server with both:
>  - WinSCP client after setting the min & max TLS version to *TLSv1.0-TLSv1.0*
>  - openssl s_client -connect : *-tls1* -starttls ftp
> I am expecting both to fail (as the server should only accept TLS 1.2)
> Any idea if this is a bug or not yet supported in Apache FTP?



--
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] (FTPSERVER-503) Cannot limit the server to listen for client connections using TLS 1.2(/1.3) only

[Jira]

[ 
https://issues.apache.org/jira/browse/FTPSERVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498150#comment-17498150
 ] 

Emmanuel Lécharny commented on FTPSERVER-503:
-

Hi,

I think you should tell the server you want to set TLS when started, which the 
following code:

{code:java}
ListenerFactory factory = new 
ListenerFactory(server.getListener("default"));

factory.setImplicitSsl(true); // That will add the SslFilter with your 
configuration 
{code}

Now, if you do that, your server will only accept TLS communication.

> Cannot limit the server to listen for client connections using TLS 1.2(/1.3) 
> only
> -
>
> Key: FTPSERVER-503
> URL: https://issues.apache.org/jira/browse/FTPSERVER-503
> Project: FtpServer
>  Issue Type: Bug
>  Components: Core, Server
>Reporter: AvnerW
>Priority: Major
>
> Hi,
> I would like to know if there is a way to limit the server to listen for TLS 
> 1.2(/1.3) only and block older versions of SSL/TLS (TLS1.1, TLS1.0 or SSLv3).
> I'm using:
>  *ftpserver-core 1.1.1*
>  *mina-core 2.0.21*
> I tried to *setSslProtocol*("TLSv1.2") in the *SslConfigurationFactory*.
>  As I understand this is should affect the *SSLContext* initialization.
> However, I am able to connect to the server with both:
>  - WinSCP client after setting the min & max TLS version to *TLSv1.0-TLSv1.0*
>  - openssl s_client -connect : *-tls1* -starttls ftp
> I am expecting both to fail (as the server should only accept TLS 1.2)
> Any idea if this is a bug or not yet supported in Apache FTP?



--
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: Trouble with deleghated tasks in MINA 2.2 SSLHandler

[Emmanuel Lécharny]

Hi Jonathan,

we need to close the connection, but the error alert should be sent 
before that. Actually, that should inform the remote peer that there was 
some problem.


What I don't k now ATM is what happens when the SSLEngine fail at some 
task. We should check the HS status, and I guess it will return a 
NEED_WRAP, which will produce the Error Alert, that we should send to 
the remote peer and the close the session.


The receive_loop currently do that:

protected void receive_loop(final NextFilter next, final IoBuffer 
message) throws SSLException {

...
final SSLEngineResult result = mEngine.unwrap(source.buf(), 
dest.buf());

...
switch (result.getHandshakeStatus()) {
...
case NEED_TASK:
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{} receive_loop() - handshake needs 
task, scheduling", toString());

}
this.schedule_task(next);
break;
...
}
}

and we get out immediately while the tasks are being executed, which 
leave the HS pending. If one task fails, we need to enter into the loop 
again in order to send the Alert.


On 25/02/2022 13:47, Jonathan Valliere wrote:
If we close the ssl instantly then that’s a point of DDOS.  Relying on 
the idleness timers is important for handling connections in a bad state 
like this example. What’s the exception that unit test is supposed to cause?


On Thu, Feb 24, 2022 at 4:56 PM Emmanuel Lécharny > wrote:


So the idea is first to loop on a NEED_TASK because we may need to send
the alert before closing the connection (but I need to triple check
that, it's a bit late here, and the day was a bit tough on my brain
with
all the bad news...)

On 24/02/2022 19:18, Emmanuel Lécharny wrote:
 >
 >
 > On 24/02/2022 17:21, Jonathan Valliere wrote:
 >> If we were to elevate this error in another way like an error
handler
 >> then what would you do? Close the session?
 >
 > Actually, yes, we should send a Error alert (see
 > https://datatracker.ietf.org/doc/html/rfc8446#section-6
, par. 6.2)
and
 > close the session.
 >
 >
 >>
 >> On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny
 >> mailto:elecha...@gmail.com>
>> wrote:
 >>
 >>     Understood, but here if a task fails, I'm not sure the exception
 >>     will be
 >>     handled at all. In the case of a handshake, nothing will be
written
 >>     back
 >>     to the remote client, AFAICT, so the connection will remain
pending
 >>     forever.
 >>
 >>     On 24/02/2022 14:23, Jonathan Valliere wrote:
 >>  > The reason I did this was an ensure the concurrency model
of the
 >>  > filterchain.
 >>  >
 >>  > On Thu, Feb 24, 2022 at 8:22 AM Jonathan Valliere
 >>  > mailto:jon.valli...@emoten.com>
>
 >>      >     wrote:
 >>  >
 >>  >     The pending error is elevated back on either read or
 >> write.  That
 >>  >     way the async error will be thrown on a filter chain
call
 >> stack.
 >>  >
 >>  >     On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny
 >>  >     mailto:elecha...@gmail.com>
>
 >>     
>  >
 >>  >         Hi Jonathan,
 >>  >
 >>  >         I have a test that isn't happy with the way we
deal with
 >>  >         delegatedTasks
 >>  >         in MINA 2.2 new SSLFilter implementation.
 >>  >
 >>  >         The context:
 >>  >         We do a TLS connection with a wrong certificate, the
 >> test is
 >>  >         expected to
 >>  >         fail, because of this error:
 >>  >
 >>  >         javax.net.ssl.SSLHandshakeException: PKIX path
building
 >>     failed:
 >>  >
 >>  sun.security.provider.certpath.SunCertPathBuilderException:
 >>  >         unable to
 >>  >         find valid certification path to requested target
 >>  >
 >>  >         The problem is that this exception is never
caught, for
 >> some
 >>  >         reason I'm
 >>  >         trying to understand.The SSLHandlerG0.execute_task do
 >>     catch an
 >>  >         exception
 >>  >         and stores it 

Re: Trouble with deleghated tasks in MINA 2.2 SSLHandler

[Jonathan Valliere]

If we close the ssl instantly then that’s a point of DDOS.  Relying on the
idleness timers is important for handling connections in a bad state like
this example. What’s the exception that unit test is supposed to cause?

On Thu, Feb 24, 2022 at 4:56 PM Emmanuel Lécharny 
wrote:

> So the idea is first to loop on a NEED_TASK because we may need to send
> the alert before closing the connection (but I need to triple check
> that, it's a bit late here, and the day was a bit tough on my brain with
> all the bad news...)
>
> On 24/02/2022 19:18, Emmanuel Lécharny wrote:
> >
> >
> > On 24/02/2022 17:21, Jonathan Valliere wrote:
> >> If we were to elevate this error in another way like an error handler
> >> then what would you do? Close the session?
> >
> > Actually, yes, we should send a Error alert (see
> > https://datatracker.ietf.org/doc/html/rfc8446#section-6, par. 6.2) and
> > close the session.
> >
> >
> >>
> >> On Thu, Feb 24, 2022 at 10:35 AM Emmanuel Lécharny
> >> mailto:elecha...@gmail.com>> wrote:
> >>
> >> Understood, but here if a task fails, I'm not sure the exception
> >> will be
> >> handled at all. In the case of a handshake, nothing will be written
> >> back
> >> to the remote client, AFAICT, so the connection will remain pending
> >> forever.
> >>
> >> On 24/02/2022 14:23, Jonathan Valliere wrote:
> >>  > The reason I did this was an ensure the concurrency model of the
> >>  > filterchain.
> >>  >
> >>  > On Thu, Feb 24, 2022 at 8:22 AM Jonathan Valliere
> >>  > mailto:jon.valli...@emoten.com>
> >> >>
> >> wrote:
> >>  >
> >>  > The pending error is elevated back on either read or
> >> write.  That
> >>  > way the async error will be thrown on a filter chain call
> >> stack.
> >>  >
> >>  > On Wed, Feb 23, 2022 at 11:13 PM Emmanuel Lécharny
> >>  > mailto:elecha...@gmail.com>
> >> >> wrote:
> >>  >
> >>  > Hi Jonathan,
> >>  >
> >>  > I have a test that isn't happy with the way we deal with
> >>  > delegatedTasks
> >>  > in MINA 2.2 new SSLFilter implementation.
> >>  >
> >>  > The context:
> >>  > We do a TLS connection with a wrong certificate, the
> >> test is
> >>  > expected to
> >>  > fail, because of this error:
> >>  >
> >>  > javax.net.ssl.SSLHandshakeException: PKIX path building
> >> failed:
> >>  >
> >>  sun.security.provider.certpath.SunCertPathBuilderException:
> >>  > unable to
> >>  > find valid certification path to requested target
> >>  >
> >>  > The problem is that this exception is never caught, for
> >> some
> >>  > reason I'm
> >>  > trying to understand.The SSLHandlerG0.execute_task do
> >> catch an
> >>  > exception
> >>  > and stores it into the mPendingError variable, but this
> >> is never
> >>  > used.
> >>  >
> >>  > --
> >>  > *Emmanuel Lécharny - CTO* 205 Promenade des Anglais –
> >> 06200 NICE
> >>  >
> >>  <
> https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g
> >> <
> https://www.google.com/maps/search/205+Promenade+des+Anglais+%E2%80%93+06200+NICE?entry=gmail=g>>
>
> >>
> >>  > T. +33 (0)4 89 97 36 50
> >>  > P. +33 (0)6 08 33 32 61
> >>  > emmanuel.lecha...@busit.com 
> >>  >> >
> >>  > https://www.busit.com/ 
> >> >
> >>  >
> >>  >
> >>  -
> >>  > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> >> 
> >>  >  >> >
> >>  > For additional commands, e-mail:
> dev-h...@mina.apache.org
> >> 
> >>  >  >> >
> >>  >
> >>  > --
> >>  > CONFIDENTIALITY NOTICE: The contents of this email message
> >> and any
> >>  > attachments are intended solely for the addressee(s) and may
> >> contain
> >>  > confidential and/or privileged information and may be legally
> >>  > protected from disclosure.
> >>  >
> >>  > --
> >>  > CONFIDENTIALITY NOTICE: The contents of this email message and
> any
> >>  > attachments are intended solely for the addressee(s) and may
> >> contain
> >>  > 

Result,was: [VOTE] Apache FtpServer 1.1.3 release

[Emmanuel Lécharny]

I'm closing this vote.

We've got 4 binding +1:
Jeff Genender, Guillaume Nodet, Jonathan Valiere and myself.

I will push the packages and make the announcement.

May thanks for the votes !

This has been a busy year with 2 MINA releases and 2 FTPServer release 
so far in 2022 ! Let's keep going the good work...


On 20/02/2022 09:48, Emmanuel Lecharny wrote:

Hi,

This is a bug fix release. This version uses the latest MINA release
(2.1.6), the latest Log4j version (2.17.1) and an issue with TLS 1.3
that wasn't enabled properly.

A temporary tag has been created (it can be removed if the vote is not approved)

The newly approved Nexus has been used for the preparation of this
release and all final artifacts are stored in a staging repository:
https://repository.apache.org/content/repositories/orgapachemina-1067/


The distributions are available for download on :
https://repository.apache.org/content/repositories/orgapachemina-004/org/apache/mina/ftpserver/1.1.3/

Let us vote :
[ ] +1 | Release Apache FtpServer 1.1.3
[ ] +/- | Abstain
[ ] -1 | Do *NOT* release Apache FtpServer 1.1.3

Thanks !




--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[GitHub] [mina-ftpserver] elecharny commented on issue #8: TLS protocol is not enabled correctly, also only one can be set

[GitBox]

elecharny commented on issue #8:
URL: https://github.com/apache/mina-ftpserver/issues/8#issuecomment-1050717287


   @Marcel, FYI, I'm closing the vote today and will push the official packages 
ad announce the release in teh coming hours.


-- 
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: dev-unsubscr...@mina.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org