Re: FYI: epoll issue fixed in b54
Hello Jean Francois, seems JDK 6 update 16 is there, is epoll bug fixed in it? Victor N Jeanfrancois Arcand wrote: Salut, Emmanuel Lecharny wrote: Jeanfrancois Arcand wrote: Salut, The fix for epoll File exists and spinning Selector issue this community has experienced will be available with jdk7 build 54. I recommend you test it and report any failure as this fix will be backported to JDK 6 eventually (no idea which version...will report as soon as I know). Great ! Nothing expected for Java 5 ? No, unfortunately. The fix will be available in 6u16 and no more lower version. A+ -- Jeanfrancois
Re: FYI: epoll issue fixed in b54
Victor wrote: Hello Jean Francois, seems JDK 6 update 16 is there, is epoll bug fixed in it? i'm afraid not, looking at the change log : *Bug Fixes* This feature release does not contain any new fixes for security vulnerabilities to its previous release, Java SE 6 Update 15. Users who have Java SE 6 Update 15 have the latest security fixes and do not need to upgrade to this release to be current on security fixes. I'm wondering why they released this version ... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Question about Mina - IoService.getManagedSessions
Dear mina dev team I have a question about the name of method getManagedSessions. Why it is named managed, does it mean that there is still some sessions out of control? If that's true, would you kind to tell me what is managed and what is out of control. Thanks in advance.
Re: Question about Mina - IoService.getManagedSessions
任政委 wrote:
Dear mina dev team
I have a question about the name of method getManagedSessions. Why it
is named managed, does it mean that there is still some sessions out
of control? If that's true, would you kind to tell me what is managed
and what is out of control.
The Javadoc is quite clear about what are those 'managed' sessions :
/**
* Returns the map of all sessions which are currently managed by this
* service. The key of map is the {...@link IoSession#getId() ID} of the
* session.
*
* @return the sessions. An empty collection if there's no session.
*/
'Managed' may not be the best term, but I don't see any other which fits
better.
This method will return the session which have been created for the
associated service. The internal list is updated when a new session is
created, or closed.
Hope it clarifies a bit.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
[jira] Created: (FTPSERVER-323) Passive Data connections should check the remote IP address before starting the data transfer
Passive Data connections should check the remote IP address before starting the data transfer - Key: FTPSERVER-323 URL: https://issues.apache.org/jira/browse/FTPSERVER-323 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.2 Reporter: Sai Pullabhotla Fix For: 1.1.0 In the current version it is possible for a hacker to connect to any passive port that is currently waiting for a connection and read/write data off that connection. We should implement a check in place to make sure the IP address of the remote host is same as the one we are expecting, if not, close the data connection right way. After closing the data connection we can do one of the following: 1. Wait for incoming connection again so the original client can connect 2. just quit and send a reply back to the client that the data connection is closed. We need to figure out what reply we want to send in this case. What do you guys think we should do? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-323) Passive Data connections should check the remote IP address before starting the data transfer
[ https://issues.apache.org/jira/browse/FTPSERVER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742544#action_12742544 ] Niklas Gustavsson commented on FTPSERVER-323: - If this happens, and it should be a very uncommon event, I think we should close the data connection. It is after all known by the hacker, so better safe than sorry. Passive Data connections should check the remote IP address before starting the data transfer - Key: FTPSERVER-323 URL: https://issues.apache.org/jira/browse/FTPSERVER-323 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.2 Reporter: Sai Pullabhotla Fix For: 1.1.0 In the current version it is possible for a hacker to connect to any passive port that is currently waiting for a connection and read/write data off that connection. We should implement a check in place to make sure the IP address of the remote host is same as the one we are expecting, if not, close the data connection right way. After closing the data connection we can do one of the following: 1. Wait for incoming connection again so the original client can connect 2. just quit and send a reply back to the client that the data connection is closed. We need to figure out what reply we want to send in this case. What do you guys think we should do? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
