[jira] [Updated] (FTPSERVER-225) Missing entries in public API for embedded context
[ https://issues.apache.org/jira/browse/FTPSERVER-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-225: Fix Version/s: 1.1.5 (was: 1.1.2) > Missing entries in public API for embedded context > -- > > Key: FTPSERVER-225 > URL: https://issues.apache.org/jira/browse/FTPSERVER-225 > Project: FtpServer > Issue Type: Wish > Components: Core >Affects Versions: 1.0.0-M4 >Reporter: Olivier Lourdais >Priority: Minor > Fix For: 1.1.5 > > > I use Apache FTP Server embedded in an application. From this application, I > have to: > - create and delete FTP users on the fly, > - be able to stop a FTP connection (and any associated data connection) from > the server side. > I can get Listener and UserManager objects from the FtpServerContext. But I > can't get the FtpServerContext object from the FtpServer object I created (It > was possible in 1.0.0-M3 version), I have to cast the FtpServer object to > DefaultFtpServer, and use a private API. > I think it would be in the public API. > Moreover, the easiest way to create a user is to instantiate the BaseUser > class, which is in the private API. > I would like to be able to create users from the public API (maybe through a > factory). > Also, classes implementing Authority (TransferRatePermission, > WritePermission, ConcurrentLoginPermission) don't seem to be instantiatable > through public API (I'm not sure it's really necessary, but I currently use > "new TransferRatePermission(0, 0)" as authorities for users I create). > NB: Isn't org.apache.ftpserver.listener.Listener class name is too generic? -- 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-291) Include 64 bit version of the Windows service wrapper
[ https://issues.apache.org/jira/browse/FTPSERVER-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-291: Fix Version/s: 1.1.5 (was: 1.1.2) > Include 64 bit version of the Windows service wrapper > - > > Key: FTPSERVER-291 > URL: https://issues.apache.org/jira/browse/FTPSERVER-291 > Project: FtpServer > Issue Type: Improvement > Components: Core >Reporter: Niklas Therning >Assignee: Niklas Therning >Priority: Major > Fix For: 1.1.5 > > Attachments: tomcat6.exe, tomcat6w.exe, untitled.GIF > > -- 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-126) Perform some basic benchmarking and profiling of FtpServer
[ https://issues.apache.org/jira/browse/FTPSERVER-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-126: Fix Version/s: 1.1.5 (was: 1.1.2) > Perform some basic benchmarking and profiling of FtpServer > -- > > Key: FTPSERVER-126 > URL: https://issues.apache.org/jira/browse/FTPSERVER-126 > Project: FtpServer > Issue Type: Task >Affects Versions: 1.0.0-M2 >Reporter: Niklas Therning >Assignee: Niklas Therning >Priority: Major > Fix For: 1.1.5 > > > Lots of code changes and an upgrade to MINA 2.0 has been done since we last > did any benchmarking on FtpServer. These tests should be repeated on the new > code base to find any obvious issues. -- 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-280) allow dynamic parts in translated strings
[ https://issues.apache.org/jira/browse/FTPSERVER-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-280: Fix Version/s: 1.1.5 (was: 1.1.2) > allow dynamic parts in translated strings > - > > Key: FTPSERVER-280 > URL: https://issues.apache.org/jira/browse/FTPSERVER-280 > Project: FtpServer > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: raphael bauduin >Priority: Minor > Fix For: 1.1.5 > > > Translated strings in > apache-ftpserver-1.0.0/src/core/src/main/resources/org/apache/ftpserver/message/FtpStatus.properties > are static. > I would have been interested to add a dynamic part in the string, coming from > the session. -- 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-240) Multiple Simultaneous Connections On Passive Data Ports
[ https://issues.apache.org/jira/browse/FTPSERVER-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-240: Fix Version/s: 1.1.5 (was: 1.1.2) > Multiple Simultaneous Connections On Passive Data Ports > > > Key: FTPSERVER-240 > URL: https://issues.apache.org/jira/browse/FTPSERVER-240 > Project: FtpServer > Issue Type: Improvement >Affects Versions: 1.0.0-M4 >Reporter: Jörg Schubert >Assignee: Niklas Therning >Priority: Major > Fix For: 1.1.5 > > Attachments: patch_ServerSocket.txt, patch_ServerSocket_3.txt > > Original Estimate: 5h > Remaining Estimate: 5h > > Hello, > the current Implementation limits the maximum number of simultaneous > connections to the number of activated data ports in passive mode. This is > not really enterprise grade! > I'm not sure if the ftp-spec allows this, but it works. > I have a working patch against 1.0.0-M4 (tested with filezilla), but > unfortunaltely I can't attach it here. > Should I send it to the mailing list? > With best Regards, > Jörg Schubert -- 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-133) Profile leaking file handles
[ https://issues.apache.org/jira/browse/FTPSERVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-133: Fix Version/s: 1.1.5 (was: 1.1.2) > Profile leaking file handles > > > Key: FTPSERVER-133 > URL: https://issues.apache.org/jira/browse/FTPSERVER-133 > Project: FtpServer > Issue Type: Task > Components: Core >Affects Versions: 1.0.0-M1, 1.0.0-M2 >Reporter: Niklas Therning >Assignee: Niklas Therning >Priority: Major > Fix For: 1.1.5 > > > There are indications of FtpServer not releasing file handles appropriately. > This needs to be profiled and fixed. -- 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-277) Ftplet which forces TLS/SSL for control and data channels when using explicit FTPS
[
https://issues.apache.org/jira/browse/FTPSERVER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny updated FTPSERVER-277:
Fix Version/s: 1.1.5
(was: 1.1.2)
> Ftplet which forces TLS/SSL for control and data channels when using explicit
> FTPS
> --
>
> Key: FTPSERVER-277
> URL: https://issues.apache.org/jira/browse/FTPSERVER-277
> Project: FtpServer
> Issue Type: New Feature
> Components: Ftplets
>Reporter: Niklas Therning
>Assignee: Niklas Therning
>Priority: Minor
> Fix For: 1.1.5
>
>
> I've developed a simple Ftplet which forces the client to use secure control
> and data channels when the server has been configured for explicit FTPS. The
> code has been pasted below. Let me know what you think about it. I've tried
> it with curl and it seems to work as expected both for passive and active
> data channels. Feel free to include it in Ftpserver if you find it useful.
> import java.io.IOException;
> import java.util.HashSet;
> import java.util.Set;
> import org.apache.ftpserver.ftplet.DefaultFtpReply;
> import org.apache.ftpserver.ftplet.FtpException;
> import org.apache.ftpserver.ftplet.FtpReply;
> import org.apache.ftpserver.ftplet.FtpRequest;
> import org.apache.ftpserver.ftplet.FtpSession;
> import org.apache.ftpserver.ftplet.Ftplet;
> import org.apache.ftpserver.ftplet.FtpletContext;
> import org.apache.ftpserver.ftplet.FtpletResult;
> /**
> * {@link Ftplet} which forces the client to use secure control and data
> * channels when connecting in explicit FTPS mode. In implicit FTPS the
> control
> * channel is always secure, however, the data channel can be plain text. This
> * {@link Ftplet} will not allow clients to open insecure data channels in
> * implicit FTPS mode.
> *
> * @version $Id$
> */
> public class ExplicitSslForcingFtplet implements Ftplet {
> private static final String SECURE =
> ExplicitSslForcingFtplet.class.getName() + ".secure";
> private static final Set DATA_CHANNEL_COMMANDS;
>
> static {
> DATA_CHANNEL_COMMANDS = new HashSet();
> DATA_CHANNEL_COMMANDS.add("APPE");
> DATA_CHANNEL_COMMANDS.add("LIST");
> DATA_CHANNEL_COMMANDS.add("MLSD");
> DATA_CHANNEL_COMMANDS.add("NLST");
> DATA_CHANNEL_COMMANDS.add("RETR");
> DATA_CHANNEL_COMMANDS.add("STOR");
> DATA_CHANNEL_COMMANDS.add("STOU");
> }
> public FtpletResult afterCommand(FtpSession session, FtpRequest request,
> FtpReply reply) throws FtpException, IOException {
> String cmd = request.getCommand().toUpperCase();
> int code = reply.getCode();
> if ("AUTH".equals(cmd) && code >= 200 && code < 300) {
> session.setAttribute(SECURE, true);
> }
>
> return FtpletResult.DEFAULT;
> }
> public FtpletResult beforeCommand(FtpSession session, FtpRequest request)
> throws FtpException, IOException {
> String cmd = request.getCommand().toUpperCase();
> boolean secure = (Boolean) session.getAttribute(SECURE);
> if ("USER".equals(cmd)) {
> if (!secure) {
> session.write(new DefaultFtpReply(500, "Control channel not
> secure. Issue AUTH command first."));
> return FtpletResult.SKIP;
> }
> } else if (DATA_CHANNEL_COMMANDS.contains(cmd)) {
> if (!session.getDataConnection().isSecure()) {
> session.write(new DefaultFtpReply(500, "Data channel not
> secure. Issue PROT command first."));
> return FtpletResult.SKIP;
> }
> }
> return FtpletResult.DEFAULT;
> }
> public void destroy() {
> }
> public void init(FtpletContext ftpletContext) throws FtpException {
> }
> public FtpletResult onConnect(FtpSession session) throws FtpException,
> IOException {
> session.setAttribute(SECURE, session.isSecure());
> return FtpletResult.DEFAULT;
> }
> public FtpletResult onDisconnect(FtpSession session) throws FtpException,
> IOException {
>
> return FtpletResult.DEFAULT;
> }
> }
--
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-292) Starting two servers on the same port should fail
[ https://issues.apache.org/jira/browse/FTPSERVER-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-292: Fix Version/s: 1.1.5 (was: 1.1.2) > Starting two servers on the same port should fail > - > > Key: FTPSERVER-292 > URL: https://issues.apache.org/jira/browse/FTPSERVER-292 > Project: FtpServer > Issue Type: Improvement > Environment: windows xp >Reporter: Francis De Brabandere >Priority: Major > Fix For: 1.1.5 > > > see this thread: > http://www.mail-archive.com/ftpserver-users@mina.apache.org/msg00749.html > I start up a ftp server in my unit tests. But I want to make sure > there is only one instance running on a port, starting a second server > on the same port should fail (throw an exception). > Right now the second server starts up without errors but making a > connection to the port used gives me the first server... > =quote= > Windows has a weird (or wrong) > treatment of SO_REUSEADDR. You can read more about it here: > http://msdn.microsoft.com/en-us/library/ms740621(VS.85).aspx > This has been discussed here before, but with no good resolution. One > possibility is that we could make our use of SO_REUSEADDR > configurable. -- 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-320) Passive Data connections are slow when using SSL
[ https://issues.apache.org/jira/browse/FTPSERVER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-320: Fix Version/s: 1.1.5 (was: 1.1.2) > Passive Data connections are slow when using SSL > > > Key: FTPSERVER-320 > URL: https://issues.apache.org/jira/browse/FTPSERVER-320 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla >Assignee: David Latorre >Priority: Major > Fix For: 1.1.5 > > Attachments: IODataConnectionFactory.java.patch > > > Creation of passive data sockets is slow when using SSL. The issue is that > the code calls InetAddress.getHostName() method which performs a reverse name > lookup. This is an expensive operation (at least on all the systems I've > tried). We really don't have a need to get the host name, so change the code > to get string version of the IP address and use it instead. More information > on this issue is available at > http://www.mail-archive.com/dev@mina.apache.org/msg13644.html. -- 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-378) [FindBugs] Method DefaultFtpStatistics::setLogin() call passes null for nonnull parameter of new DefaultFtpStatistics$UserLogins(InetAddress)
[ https://issues.apache.org/jira/browse/FTPSERVER-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-378: Fix Version/s: 1.1.5 (was: 1.1.2) > [FindBugs] Method DefaultFtpStatistics::setLogin() call passes null for > nonnull parameter of new DefaultFtpStatistics$UserLogins(InetAddress) > - > > Key: FTPSERVER-378 > URL: https://issues.apache.org/jira/browse/FTPSERVER-378 > Project: FtpServer > Issue Type: Bug > Components: Core >Reporter: Sergey Vladimirov >Priority: Minor > Labels: findbugs, npe > Fix For: 1.0.0-M1, 1.1.5 > > > If session.getRemoteAddress() is not instanceof InetSocketAddress, then > address is null. But UserLogins do not accept nulls as argument (null can't > be a key for ConcurrentHashMap) > I think 'fake' NULL address constant shall be introduced in > DefaultFtpStatistics for this case. -- 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-374) Make socket reuse configurable
[ https://issues.apache.org/jira/browse/FTPSERVER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-374: Fix Version/s: 1.1.5 (was: 1.1.2) > Make socket reuse configurable > -- > > Key: FTPSERVER-374 > URL: https://issues.apache.org/jira/browse/FTPSERVER-374 > Project: FtpServer > Issue Type: Improvement > Components: Core, Server >Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4 >Reporter: Niklas Therning >Priority: Major > Fix For: 1.1.5 > > > Add a configuration option to disable socket reuse by the NioListener. -- 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-364) Incorrect behavior when max logins limit is reached
[ https://issues.apache.org/jira/browse/FTPSERVER-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-364: Fix Version/s: 1.1.5 (was: 1.1.2) > Incorrect behavior when max logins limit is reached > --- > > Key: FTPSERVER-364 > URL: https://issues.apache.org/jira/browse/FTPSERVER-364 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.4 >Reporter: Sai Pullabhotla >Priority: Minor > Fix For: 1.0.0-M1, 1.1.5 > > > When max logins limit is reached, the server currently behaves as below: > Accepts connections from new clients and keeps them open > Let's the new clients issue some commands (like I can go ahead and issue as > many invalid commands as I want) > When the client sends a valid USER command with username argument, the server > then figures out that it has reached the max limit. > I think t would probably makes sense to change the behavior as follows: > When a new client comes in, check if we reached the cap, and if so, send 421 > message right away, instead of sending a 2xxx reply. -- 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-339) Commands Dropped After Successful File Upload
[ https://issues.apache.org/jira/browse/FTPSERVER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-339: Fix Version/s: 1.1.5 (was: 1.1.2) > Commands Dropped After Successful File Upload > - > > Key: FTPSERVER-339 > URL: https://issues.apache.org/jira/browse/FTPSERVER-339 > Project: FtpServer > Issue Type: Bug >Affects Versions: 1.0.3 >Reporter: Nick Padgett >Assignee: Niklas Therning >Priority: Critical > Fix For: 1.0.0-M1, 1.1.5 > > > After my ftp client successfully uploads a file, it sends a QUIT request. > This QUIT request doesn't always appear to be logged by the FtpServer which > results in the connection idling and the FtpServer subsequently closes the > connection. We experience this issue often when uploading large files (2+GB) > or multiple medium size files (~1 GB). When the QUIT is received before the > FtpServer issues a 226 transfer complete message, the server sends a 226 > transfer complete message , the a 221 goodbye message before closing the > connection. When the QUIT is received after the FtpServer issues a 226 > transfer complete message, sometimes the QUIT is processed on the existing > thread and sometimes it is processed on a new thread. In either case, the > server sends a 221 goodbye message and closed the connection. This leads me > to believe that a QUIT message could be sent to the server in the time > between when the first thread is being closed and the second thread is being > opened. Below are logs from my FtpServer that illustrate all of these > scenarios. > This issue occurs very frequently and is resulting in the user believing > their uploads failed. > QUIT received before 226 transfer complete sent: > 2009-11-04 14:32:31,936 [pool-4-thread-8] INFO > org.apache.ftpserver.command.impl.STOR - File uploaded > /1024/2009/11/02/7558_7W5oJqfN_event.wmv > 2009-11-04 14:32:31,937 [pool-4-thread-8] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 150 File status > okay; about to open data connection. > 2009-11-04 14:32:32,104 [pool-4-thread-8] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: QUIT > 2009-11-04 14:32:32,104 [pool-4-thread-8] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 226 Transfer > complete. > 2009-11-04 14:32:32,105 [pool-4-thread-8] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 221 Goodbye. > 2009-11-04 14:32:32,105 [pool-4-thread-8] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - CLOSED > QUIT received after 226 transfer complete sent on the same thread: > 2009-11-03 19:25:23,958 [pool-4-thread-697] INFO > org.apache.ftpserver.command.impl.STOR - File uploaded > /1017/2009/10/09/7235_xVJpQ8tT_event.wmv > 2009-11-03 19:25:23,958 [pool-4-thread-697] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 150 File status > okay; about to open data connection. > 2009-11-03 19:25:23,968 [pool-4-thread-697] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 226 Transfer > complete. > 2009-11-03 19:25:23,991 [pool-4-thread-697] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: QUIT > 2009-11-03 19:25:23,992 [pool-4-thread-697] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 221 Goodbye. > 2009-11-03 19:25:23,992 [pool-4-thread-697] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - CLOSED > QUIT received after the 226 transfer complete sent on a new thread: > 2009-11-03 04:43:16,551 [pool-4-thread-662] INFO > org.apache.ftpserver.command.impl.STOR - File uploaded > /1030/2009/11/02/7580_GxDwum7M_event.wmv > 2009-11-03 04:43:16,552 [pool-4-thread-662] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 150 File status > okay; about to open data connection. > 2009-11-03 04:43:16,552 [pool-4-thread-662] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 226 Transfer > complete. > 2009-11-03 04:43:16,595 [pool-4-thread-667] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: QUIT > 2009-11-03 04:43:16,598 [pool-4-thread-667] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 221 Goodbye. > 2009-11-03 04:43:16,598 [pool-4-thread-667] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - CLOSED > QUIT NOT received because the FtpServer is between threads: > 2009-11-04 02:05:18,328 [pool-4-thread-16] INFO > org.apache.ftpserver.command.impl.STOR - File uploaded > /1051/2008/11/15/7400_NHftLRzu_event.mp4 > 2009-11-04 02:05:18,329 [pool-4-thread-16] INFO > org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 150 File status > okay; about to open data connection. > 2009-11-04 02:05:18,397
[jira] [Updated] (FTPSERVER-335) Create a HomeDirectoryResolver interface to Resolve a User's Home Directory
[
https://issues.apache.org/jira/browse/FTPSERVER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny updated FTPSERVER-335:
Fix Version/s: 1.1.5
(was: 1.1.2)
> Create a HomeDirectoryResolver interface to Resolve a User's Home Directory
> ---
>
> Key: FTPSERVER-335
> URL: https://issues.apache.org/jira/browse/FTPSERVER-335
> Project: FtpServer
> Issue Type: Improvement
>Affects Versions: 1.0.0, 1.0.1, 1.0.2
>Reporter: Nick Padgett
>Priority: Major
> Fix For: 1.1.5
>
>
> It would be useful to have a HomeDirectoryResolver interface to resolve a
> user's home directory. I use such a class to do the following:
> 1) Prefix a base path to user home directories. I have FtpServer deployed
> with two different applications. In one applicationI need their home
> directory to begin with "d:/mnt" and in the other I need "/mnt".
> 2) Allow users to share a common home directory (i.e. "d:/mnt/users").
> 3) Allow users to have private home directories (i.e.
> "d:/mnt/users/npadgett").
> The interface I use looks something like:
>
> public interface HomeDirectoryResolver {
> String resolve(final User user);
> }
>
> The class I use looks something like:
>
> public class HomeDirectoryResolverImpl implements HomeDirectoryResolver {
> public static enum Strategy {
> SHARED, USERNAME, HOME_DIRECTORY
> }
> private final String basePath;
> private final Strategy strategy;
> public HomeDirectoryResolverImpl(final String basePath,
> final Strategy strategy) {
> this.basePath = basePath;
> this.strategy = strategy;
> }
> public String resolve(final User user) {
> String homeDirectory = this.basePath
> + (this.basePath.endsWith("/") ? "" : "/");
> switch (this.strategy) {
> case SHARED:
> // do nothing
> break;
> case USERNAME:
> homeDirectory += user.getName();
> break;
> case HOME_DIRECTORY:
> homeDirectory += user.getHomeDirectory();
> break;
> default:
> throw new IllegalStateException();
> }
> return homeDirectory;
> }
> }
>
--
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-272) follow symbolic links
[ https://issues.apache.org/jira/browse/FTPSERVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-272: Fix Version/s: 1.1.5 (was: 1.1.2) > follow symbolic links > - > > Key: FTPSERVER-272 > URL: https://issues.apache.org/jira/browse/FTPSERVER-272 > Project: FtpServer > Issue Type: New Feature > Environment: unix, linux, mac, ... >Reporter: Francis De Brabandere >Assignee: Niklas Therning >Priority: Major > Fix For: 1.1.5 > > > there should be a way to make the ftpserver follow symbolic links instead of > keeping the symbolic link as pwd: > Command:CWD link > Response: 250 CWD command successful. > Command:PWD > Response: 257 "/linkedToFolder" is current directory. > you might want to make this the default behavior as some other ftp server do > that (to investigate) > for links the file.getAbsolutePath() gives you the link path and > file.getCanonicalPath() gives you the real (linked to) path > (only tested on Linux with sun jvm, not sure this is defined in the spec) -- 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-337) XSD Does Not Support Property Placeholders for Attributes
[ https://issues.apache.org/jira/browse/FTPSERVER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-337: Fix Version/s: 1.1.5 (was: 1.1.2) > XSD Does Not Support Property Placeholders for Attributes > - > > Key: FTPSERVER-337 > URL: https://issues.apache.org/jira/browse/FTPSERVER-337 > Project: FtpServer > Issue Type: Improvement >Affects Versions: 1.0.3 >Reporter: Nick Padgett >Priority: Major > Fix For: 1.1.5 > > > For example: -- 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-344) Allow configuration of FileObserver and StatisticsObserver
[ https://issues.apache.org/jira/browse/FTPSERVER-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-344: Fix Version/s: 1.1.5 (was: 1.1.2) > Allow configuration of FileObserver and StatisticsObserver > -- > > Key: FTPSERVER-344 > URL: https://issues.apache.org/jira/browse/FTPSERVER-344 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3 >Reporter: Dave Roberts >Priority: Major > Fix For: 1.1.5 > > Attachments: ftpStatistics.patch, ftpStatistics2.patch > > > Setting this Observers currently involves a lot of casting and use of > "internal" classes and interfaces. > These need to be exposed to the public interfaces. > The simplest idea would seem to be to push the methods up to the > FtpStatistics interface. However, these are only exposed through the Ftplet > which are runtime objects, so a better mechanism is required. -- 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-365) Overload FtpIoSession.getDataConnection to indicate whether or not a new DataConnectionFactory be created
[ https://issues.apache.org/jira/browse/FTPSERVER-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-365: Fix Version/s: 1.1.5 (was: 1.1.2) > Overload FtpIoSession.getDataConnection to indicate whether or not a new > DataConnectionFactory be created > - > > Key: FTPSERVER-365 > URL: https://issues.apache.org/jira/browse/FTPSERVER-365 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.4 >Reporter: Sai Pullabhotla >Priority: Trivial > Fix For: 1.0.0-M1, 1.1.5 > > > It would be nice to overload the above mentioned method with a boolean > parameter which indicates if a new DataConnectionFactory is to be created. > Currently, we always create one if one does not exist already for the > session. We try to create one even when the session is closing (for example > when the control connection is refused by the blacklist filter), which does > not make much sense. Having this overloaded method would be useful when the > session is closing. -- 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-349) WhiteList
[ https://issues.apache.org/jira/browse/FTPSERVER-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-349: Fix Version/s: 1.1.5 (was: 1.1.2) > WhiteList > - > > Key: FTPSERVER-349 > URL: https://issues.apache.org/jira/browse/FTPSERVER-349 > Project: FtpServer > Issue Type: Improvement > Components: Server >Affects Versions: 1.0.3 >Reporter: DevNull43 >Priority: Trivial > Fix For: 1.1.5 > > Attachments: WhiteList.txt > > > WhiteList filer > Restricting access to FTP based on a WhiteList > BlackList -> Allow all, Deny some. > WhiteList -> Deny all, Allow some. -- 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-366) Fix interim problems with SiteTest.testSiteStat()
[ https://issues.apache.org/jira/browse/FTPSERVER-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-366: Fix Version/s: 1.1.5 (was: 1.1.2) > Fix interim problems with SiteTest.testSiteStat() > - > > Key: FTPSERVER-366 > URL: https://issues.apache.org/jira/browse/FTPSERVER-366 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.4 >Reporter: Niklas Therning >Assignee: Niklas Therning >Priority: Major > Fix For: 1.0.0-M1, 1.1.5 > > > SiteTest.testSiteStat() fails intermittently for us in Hudson and generates > pretty useless error message. We should investigate why it fails, or at least > add some reasonable assertion messages. > Example of a failed test: > http://hudson.zones.apache.org/hudson/view/FtpServer/job/ftpserver-trunk-jdk1.6-ibm-ubuntu/org.apache.ftpserver$ftpserver-core/57/testReport/junit/org.apache.ftpserver.clienttests/SiteTest/testSiteStat/ -- 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-350) Custom reply messages
[ https://issues.apache.org/jira/browse/FTPSERVER-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-350: Fix Version/s: 1.1.5 (was: 1.1.2) > Custom reply messages > - > > Key: FTPSERVER-350 > URL: https://issues.apache.org/jira/browse/FTPSERVER-350 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.3 >Reporter: DevNull43 >Priority: Minor > Fix For: 1.1.5 > > Attachments: customVariable.txt > > > Enhance reply commands to include custom messages. > Initial approach is to store this messages in session. -- 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-360) When no passive ports are available error out immediately rather than waiting for a port to become available
[ https://issues.apache.org/jira/browse/FTPSERVER-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-360: Fix Version/s: 1.1.5 (was: 1.1.2) > When no passive ports are available error out immediately rather than waiting > for a port to become available > > > Key: FTPSERVER-360 > URL: https://issues.apache.org/jira/browse/FTPSERVER-360 > Project: FtpServer > Issue Type: Bug >Affects Versions: 1.0.4 >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla >Priority: Major > Fix For: 1.0.0-M1, 1.1.5 > > Attachments: FTPSERVER-360.patch > > > Based on the filed issue, http://issues.apache.org/jira/browse/FTPSERVER-359, > we probably want to quick fix the code to error out right away when no > passive port is available. -- 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-397) DefaultFtplet does not return valid FtpResult values
[ https://issues.apache.org/jira/browse/FTPSERVER-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-397: Fix Version/s: 1.1.5 (was: 1.1.2) > DefaultFtplet does not return valid FtpResult values > > > Key: FTPSERVER-397 > URL: https://issues.apache.org/jira/browse/FTPSERVER-397 > Project: FtpServer > Issue Type: Bug >Reporter: Sebb >Priority: Major > Fix For: 1.1.5 > > > The DefaultFtplet returns null for all the methods which should return an > FtpResult. > This appears to be treated the same as FtpResult.DEFAULT - so why not use > that value? > Also, the Javadoc does not state what the return value is, so it's not clear > which methods need to be overridden. -- 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-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-357: Fix Version/s: 1.1.5 (was: 1.1.2) > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla >Priority: Major > Fix For: 1.1.5 > > Attachments: ftpserver-ipfilter.patch, ftpserver-ipfilter2.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- 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-409) Requesting number of active transfers in FtpStatistics
[ https://issues.apache.org/jira/browse/FTPSERVER-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-409: Fix Version/s: 1.1.5 (was: 1.1.2) > Requesting number of active transfers in FtpStatistics > -- > > Key: FTPSERVER-409 > URL: https://issues.apache.org/jira/browse/FTPSERVER-409 > Project: FtpServer > Issue Type: Improvement >Reporter: Stepan Koltsov >Priority: Major > Fix For: 1.1.5 > > > FtpStatistics has handy getCurrentConnectionNumber parameter. This value > includes connections, that has no transfers. > Requesting also getCurrentUploadsNumber, getCurrentDownloadsNumbers. Needed > for monitoring. -- 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-371) Create a specialized FtpReply to send to Ftplets after login finishes
[ https://issues.apache.org/jira/browse/FTPSERVER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-371: Fix Version/s: 1.1.5 (was: 1.1.2) > Create a specialized FtpReply to send to Ftplets after login finishes > - > > Key: FTPSERVER-371 > URL: https://issues.apache.org/jira/browse/FTPSERVER-371 > Project: FtpServer > Issue Type: New Feature > Components: Core, Ftplets >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla >Priority: Major > Fix For: 1.1.5 > > Attachments: FTPSERVER-371.patch > > > As an addition to https://issues.apache.org/jira/browse/FTPSERVER-253, I > think it would be nice to have a specialized reply that could be sent to the > Ftplets. The reply could include information such as the attempted user name, > password used by anonymous users, any exception that was thrown by the > UserManager during authentication. Perhaps the exception is the most > important piece that the Ftplets (like the one that does audit logging) would > like to know. -- 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-390) FTPServer disabling anonymous not compatible with Windows Explorer
[ https://issues.apache.org/jira/browse/FTPSERVER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-390: Fix Version/s: 1.1.5 (was: 1.1.2) > FTPServer disabling anonymous not compatible with Windows Explorer > -- > > Key: FTPSERVER-390 > URL: https://issues.apache.org/jira/browse/FTPSERVER-390 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.5 >Reporter: Matthew Schulze >Assignee: Niklas Therning >Priority: Major > Fix For: 1.0.0-M1, 1.1.5 > > Attachments: Windows_Explorer_anonymous_login.patch > > > When using Windows Explorer to attempt to connect to an FTP connection, it > first attempts an anonymous login and then prompts the user for credentials > after failure. Disabling anonymous login on the current version of Apache FTP > Server returns a 530 response and immediately closes the connection, > preventing the credentials dialog from appearing in Explorer and causing an > error dialog to be displayed. > If the USER command is successful and the anonymous user is rejected after > the PASS command is sent with a 421 response sent by the server, Windows > Explorer is able to handle the login process properly. To maintain maximum > compatibility, anonymous user checks should all be handled in the PASS > command. -- 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-367) RFC: FTP HASH command (similar to MD5, which is already supported)
[ https://issues.apache.org/jira/browse/FTPSERVER-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-367: Fix Version/s: 1.1.5 (was: 1.1.2) > RFC: FTP HASH command (similar to MD5, which is already supported) > -- > > Key: FTPSERVER-367 > URL: https://issues.apache.org/jira/browse/FTPSERVER-367 > Project: FtpServer > Issue Type: New Feature >Reporter: Ant Bryan >Priority: Trivial > Fix For: 1.1.5 > > > According to http://mina.apache.org/ftpserver/documentation.html , the > MD5/MMD5 FTP commands from draft-twine-ftpmd5-00 are supported. > Unfortunately, MD5 and other FTP hashing commands (XMD5, XSHA, XSHA1, > XSHA256, XSHA512, SITE SHOHASH, SITE CHECKSUM, etc) have not been formally > specified, leading to non-interoperability and confusion. > A new draft which intends to reach RFC status is underway: > http://tools.ietf.org/html/draft-bryan-ftp-hash > It would be very helpful, if this draft could be reviewed and your comments > provided to improve it. > Here is a quick overview. > Requesting hash: >HASH filename.ext >HASH server response with Positive Completion code and the requested >hash using the currently selected algorithm: >213 80bc95fd391772fa61c91ed68567f0980bb45fd9 > Changing HASH algorithms: > C> OPTS HASH SHA-512 > S> 200 SHA-512 -- 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-355) Use the maven release plugin for releases
[ https://issues.apache.org/jira/browse/FTPSERVER-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-355: Fix Version/s: 1.1.5 (was: 1.1.2) > Use the maven release plugin for releases > - > > Key: FTPSERVER-355 > URL: https://issues.apache.org/jira/browse/FTPSERVER-355 > Project: FtpServer > Issue Type: Task >Reporter: Niklas Therning >Priority: Major > Fix For: 1.1.5 > > > We currently have a highly manual process for releasing FtpServer (updating > POMs, staging files for voting, tagging and so on). All of this can be > automated by the maven release plugin. -- 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-377) [FindBugs] Dereference of the result of readLine() without nullcheck in AddUser
[ https://issues.apache.org/jira/browse/FTPSERVER-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-377: Fix Version/s: 1.1.5 (was: 1.1.2) > [FindBugs] Dereference of the result of readLine() without nullcheck in > AddUser > --- > > Key: FTPSERVER-377 > URL: https://issues.apache.org/jira/browse/FTPSERVER-377 > Project: FtpServer > Issue Type: Bug > Components: Server >Reporter: Sergey Vladimirov >Priority: Trivial > Labels: console, findbugs, npe, ui > Fix For: 1.0.0-M1, 1.1.5 > > > Since it's for management only, we don't care if admin will have java > exceptions as a response... do we? Especially if stream is terminated already. > But may be explicit handling is better. -- 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-381) Disable Nagle algorithm by default for the control connection, and make this configurable
[ https://issues.apache.org/jira/browse/FTPSERVER-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-381: Fix Version/s: 1.1.5 (was: 1.1.2) > Disable Nagle algorithm by default for the control connection, and make this > configurable > - > > Key: FTPSERVER-381 > URL: https://issues.apache.org/jira/browse/FTPSERVER-381 > Project: FtpServer > Issue Type: Improvement > Components: Core >Reporter: Niklas Therning >Priority: Major > Fix For: 1.1.5 > > > See http://www.mail-archive.com/ftpserver-users@mina.apache.org/msg01005.html > and http://markmail.org/message/mv5khhibs77b7res for details and discussions. -- 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-391) LDAP support
[ https://issues.apache.org/jira/browse/FTPSERVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-391: Fix Version/s: 1.1.5 (was: 1.1.2) > LDAP support > > > Key: FTPSERVER-391 > URL: https://issues.apache.org/jira/browse/FTPSERVER-391 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Andrey Domas >Assignee: Niklas Therning >Priority: Major > Fix For: 1.1.5 > > Attachments: mina-1.1.0-ldap.patch > > > Patch with cached LDAP support. > Features: > * Authentication and authorization from LDAP(JNDI client implementation). > * Cache for the search results in a directory for authentication (password > is cached in the successful bindu). > Cache options: > - ttl - time to live of the object in the cache (seconds) > - size - max. cache size(number of the objects) > - check-interval - interval of the periodic cleaning job(search and > remove expired objects, seconds) > * User preferences received from LDAP attributes: > username > home directory > enabled - if present then the user has the login permission) > write permission - if present then the user has the write permission > under home directory -- 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-486) Timing Side Channel StringUtils
[
https://issues.apache.org/jira/browse/FTPSERVER-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny updated FTPSERVER-486:
Fix Version/s: 1.1.5
(was: 1.1.2)
> Timing Side Channel StringUtils
> ---
>
> Key: FTPSERVER-486
> URL: https://issues.apache.org/jira/browse/FTPSERVER-486
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.1
> Environment: test on macOS High Sierra 10.13.4, but not relevant
>Reporter: Yannic Noller
>Assignee: Emmanuel Lécharny
>Priority: Major
> Labels: easyfix, pull-request-available
> Fix For: 1.1.5
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Dear Apache FTPServer developers,
> We have found a timing side-channel in class
> org.apache.ftpserver.util.StringUtils, method "public final static String
> pad(String src, char padChar, boolean rightPad, int totalLength)". This
> method leaks the necessary padding in a timing side channel, from which a
> potential attacker could obtain the length of the src String. In your project
> this method is used to add padding to a username, hence, a potential attacker
> could obtain the length of a given username, which might be used for further
> attacks.
> Do you agree with our findings?
> We found this class in the latest version of your git repo:
> https://git-wip-us.apache.org/repos/asf?p=mina-ftpserver.git;a=summary
> As a secure fix we would recommend to use a variant of the equals method,
> which does iterate the complete strings in the case of the same string
> lengths, independent from whether they do match or not:
>public final static String pad_safe(String src, char padChar, boolean
> rightPad, int totalLength) {
>int srcLength = src.length();
>if (srcLength >= totalLength) {
>return src;
>}
>int padLength = totalLength - srcLength;
>StringBuilder sb = new StringBuilder(padLength);
>for (int i = 0; i < totalLength; ++i) {
>if (i < padLength) {
>sb.append(padChar);
>} else {
>sb.append("");
>}
>}
>if (rightPad) {
>return src + sb.toString();
>} else {
>return sb.toString() + src;
>}
>}
> Do you agree with our patch proposal?
> Please feel free to contact us for further clarification! You can reach us by
> the following email address:
> yannic.nol...@informatik.hu-berlin.de
> Best regards,
> Yannic Noller
--
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-399) DefaultFtpHandler.sessionOpened does not check if the Ftplet returned a FtpletResult.SKIP
[ https://issues.apache.org/jira/browse/FTPSERVER-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated FTPSERVER-399: Fix Version/s: 1.1.5 (was: 1.1.2) > DefaultFtpHandler.sessionOpened does not check if the Ftplet returned a > FtpletResult.SKIP > - > > Key: FTPSERVER-399 > URL: https://issues.apache.org/jira/browse/FTPSERVER-399 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.5 >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla >Priority: Major > Fix For: 1.1.5 > > > I was trying to use an Ftplet to send a custom welcome message using the > Ftplet.onConnect. Within this method, I write a 220 reply to the client with > my custom message, and return FtpletResult.SKIP. I expect that the server > would not send the default welcome message, but it does it any how. When I > looked at the server code, the DefaultFtpHandler does not handle the > FtpletResult.SKIP case. I think it needs to be updated so a welcome message > is sent only if the Ftplet returned DEFAULT result. -- 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-499) FtpResponseEncoder is not thread safe
[
https://issues.apache.org/jira/browse/FTPSERVER-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved FTPSERVER-499.
-
Resolution: Fixed
Patch provided by Hai Zhang.
> FtpResponseEncoder is not thread safe
> -
>
> Key: FTPSERVER-499
> URL: https://issues.apache.org/jira/browse/FTPSERVER-499
> Project: FtpServer
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.0.6, 1.1.1
> Environment: redhat 7, java 8
>Reporter: Hisaki
>Priority: Critical
> Fix For: 1.1.5, 1.2.1
>
>
> {color:#1f497d}Dear Apache FTPServer developers{color}
> {color:#1f497d} {color}
> {color:#1f497d}java.nio.charset.CharsetEncoder is a mutable-class.{color}
> {color:#1f497d}It change the "state" of the instance-variable every time you
> encode.{color}
> {color:#1f497d}FtpResponseEncoder is not thread-safe because it defines
> CharsetEncoder as a class-variable.{color}
> {color:#1f497d} {color}
> {color:#1f497d}Could you patch the FtpResponseEncoder to make it
> thread-safe?{color}
> {color:#1f497d} {color}
> {color:#1f497d}For example{color}{color:#1f497d}…{color}
> {color:#1f497d}Change {color}{color:#1f497d}“ENCODER” of FtpResponseEncoder
> from a class-variable to an instance-variable.{color}
> {color:#1f497d}And, instantiate the ProtocolEncoder of
> FtpServerProtocolCodecFactory#getEncoder each time.{color}
> {color:#1f497d}Alternatively, change "ENCODER" of FtpResponseEncoder from a
> class-variable to a local-variable and generate an instance each time.{color}
> {color:#1f497d} {color}
> {color:#1f497d}Stack trace when a problem occurs{color}
>
> {color:#1f497d}org.apache.mina.filter.codec.ProtocolEncoderException:
> java.lang.IllegalStateException: Current state = RESET, new state = CODING_END
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:355)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:509)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1400(DefaultIoFilterChain.java:46)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:808)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:85)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.filter.logging.MdcInjectionFilter.filter(MdcInjectionFilter.java:136)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.filter.util.CommonEventFilter.filterWrite(CommonEventFilter.java:80)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:509)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1400(DefaultIoFilterChain.java:46)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:808)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:135)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:509)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1400(DefaultIoFilterChain.java:46)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:808)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.filterWrite(DefaultIoFilterChain.java:734)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:509)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:501)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:490)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:435)
> ~[mina-core-2.0.4.jar:na]
> at org.apache.ftpserver.impl.FtpIoSession.write(FtpIoSession.java:527)
> ~[ftpserver-core-1.0.6.jar:1.0.6]
> at org.apache.ftpserver.command.impl.USER.execute(USER.java:197)
> ~[ftpserver-core-1.0.6.jar:1.0.6]
> at
> org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(DefaultFtpHandler.java:210)
> ~[ftpserver-core-1.0.6.jar:1.0.6]
> at
> org.apache.ftpserver.listener.nio.FtpHandlerAdapter.messageReceived(FtpHandlerAdapter.java:61)
> ~[ftpserver
[jira] [Updated] (FTPSERVER-499) FtpResponseEncoder is not thread safe
[
https://issues.apache.org/jira/browse/FTPSERVER-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny updated FTPSERVER-499:
Fix Version/s: 1.1.5
1.2.1
> FtpResponseEncoder is not thread safe
> -
>
> Key: FTPSERVER-499
> URL: https://issues.apache.org/jira/browse/FTPSERVER-499
> Project: FtpServer
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.0.6, 1.1.1
> Environment: redhat 7, java 8
>Reporter: Hisaki
>Priority: Critical
> Fix For: 1.1.5, 1.2.1
>
>
> {color:#1f497d}Dear Apache FTPServer developers{color}
> {color:#1f497d} {color}
> {color:#1f497d}java.nio.charset.CharsetEncoder is a mutable-class.{color}
> {color:#1f497d}It change the "state" of the instance-variable every time you
> encode.{color}
> {color:#1f497d}FtpResponseEncoder is not thread-safe because it defines
> CharsetEncoder as a class-variable.{color}
> {color:#1f497d} {color}
> {color:#1f497d}Could you patch the FtpResponseEncoder to make it
> thread-safe?{color}
> {color:#1f497d} {color}
> {color:#1f497d}For example{color}{color:#1f497d}…{color}
> {color:#1f497d}Change {color}{color:#1f497d}“ENCODER” of FtpResponseEncoder
> from a class-variable to an instance-variable.{color}
> {color:#1f497d}And, instantiate the ProtocolEncoder of
> FtpServerProtocolCodecFactory#getEncoder each time.{color}
> {color:#1f497d}Alternatively, change "ENCODER" of FtpResponseEncoder from a
> class-variable to a local-variable and generate an instance each time.{color}
> {color:#1f497d} {color}
> {color:#1f497d}Stack trace when a problem occurs{color}
>
> {color:#1f497d}org.apache.mina.filter.codec.ProtocolEncoderException:
> java.lang.IllegalStateException: Current state = RESET, new state = CODING_END
> at
> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:355)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:509)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1400(DefaultIoFilterChain.java:46)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:808)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:85)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.filter.logging.MdcInjectionFilter.filter(MdcInjectionFilter.java:136)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.filter.util.CommonEventFilter.filterWrite(CommonEventFilter.java:80)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:509)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1400(DefaultIoFilterChain.java:46)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:808)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:135)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:509)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1400(DefaultIoFilterChain.java:46)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:808)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.filterWrite(DefaultIoFilterChain.java:734)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:509)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:501)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:490)
> ~[mina-core-2.0.4.jar:na]
> at
> org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:435)
> ~[mina-core-2.0.4.jar:na]
> at org.apache.ftpserver.impl.FtpIoSession.write(FtpIoSession.java:527)
> ~[ftpserver-core-1.0.6.jar:1.0.6]
> at org.apache.ftpserver.command.impl.USER.execute(USER.java:197)
> ~[ftpserver-core-1.0.6.jar:1.0.6]
> at
> org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(DefaultFtpHandler.java:210)
> ~[ftpserver-core-1.0.6.jar:1.0.6]
> at
> org.apache.ftpserver.listener.nio.FtpHandlerAdapter.messageReceived(FtpHandlerAdapter.java:61)
> ~[ftpserver-cor
[GitHub] [mina-ftpserver] elecharny commented on pull request #11: Use ThreadLocal for FtpResponseEncoder.ENCODER.
elecharny commented on pull request #11: URL: https://github.com/apache/mina-ftpserver/pull/11#issuecomment-1066210854 Well, I can close it myself :-) -- 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
[GitHub] [mina-ftpserver] elecharny closed pull request #11: Use ThreadLocal for FtpResponseEncoder.ENCODER.
elecharny closed pull request #11: URL: https://github.com/apache/mina-ftpserver/pull/11 -- 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
[GitHub] [mina-ftpserver] elecharny commented on pull request #11: Use ThreadLocal for FtpResponseEncoder.ENCODER.
elecharny commented on pull request #11: URL: https://github.com/apache/mina-ftpserver/pull/11#issuecomment-1066210798 Note that we now have 2 branches for the project: - 1.1.X for any 1.1. version patches - 1.2.X for any 1.2 version patches Can you close the PR? Thanks ! -- 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
[GitHub] [mina-ftpserver] elecharny commented on pull request #11: Use ThreadLocal for FtpResponseEncoder.ENCODER.
elecharny commented on pull request #11: URL: https://github.com/apache/mina-ftpserver/pull/11#issuecomment-1066210559 Patch applied in 1.1.X and 1.2.X branches. Many thanks ! -- 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
[jira] [Commented] (FTPSERVER-478) java.nio.charset.CoderMalfunctionError: java.nio.BufferUnderflowException
[ https://issues.apache.org/jira/browse/FTPSERVER-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505934#comment-17505934 ] Emmanuel Lécharny commented on FTPSERVER-478: - Hi ! Thanks for the report ! Sadly, 1.1.4 has just been released as of today. But we can start with a new release that fixes this issue. > java.nio.charset.CoderMalfunctionError: java.nio.BufferUnderflowException > - > > Key: FTPSERVER-478 > URL: https://issues.apache.org/jira/browse/FTPSERVER-478 > Project: FtpServer > Issue Type: Bug > Components: Core, Server >Affects Versions: 1.1.0 > Environment: Media Box with Android 4.4.2 >Reporter: Jerry Wu >Priority: Major > Fix For: 1.0.6 > > > java.nio.BufferUnderflowException is never happened in 1.0.6, it happened in > 1.1.0 frequently, I wonder whether this exception is from files name with > Chinese character -- 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-506) Binary compatibility is broken in ftpserver-core 1.1.3 vs 1.1.2
[
https://issues.apache.org/jira/browse/FTPSERVER-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505927#comment-17505927
]
Emmanuel Lécharny commented on FTPSERVER-506:
-
Hi Gary,
no, no hiccup, just the week-end with a 5yo to deal with...
I'm currently pushing everything.
> Binary compatibility is broken in ftpserver-core 1.1.3 vs 1.1.2
> ---
>
> Key: FTPSERVER-506
> URL: https://issues.apache.org/jira/browse/FTPSERVER-506
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Reporter: Gary D. Gregory
>Priority: Major
>
> Over at Apache Commons, when we update Commons Net from 1.1.2 to 1.1.3, we
> get compile errors:
> {noformat}
> [INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @
> commons-net ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 63 source files to
> /home/runner/work/commons-net/commons-net/target/test-classes
> [INFO] -
> Error: COMPILATION ERROR :
> [INFO] -
> Error:
> /home/runner/work/commons-net/commons-net/src/test/java/org/apache/commons/net/ftp/NoProtocolSslConfigurationProxy.java:[30,8]
> org.apache.commons.net.ftp.NoProtocolSslConfigurationProxy is not abstract
> and does not override abstract method getEnabledProtocols() in
> org.apache.ftpserver.ssl.SslConfiguration
> Error:
> /home/runner/work/commons-net/commons-net/src/test/java/org/apache/commons/net/ftp/NoProtocolSslConfigurationProxy.java:[32,5]
> method does not override or implement a method from a supertype
> [INFO] 2 errors
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 20.310 s
> [INFO] Finished at: 2022-03-04T02:17:14Z
> [INFO]
>
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile
> (default-testCompile) on project commons-net: Compilation failure:
> Compilation failure:
> Error:
> /home/runner/work/commons-net/commons-net/src/test/java/org/apache/commons/net/ftp/NoProtocolSslConfigurationProxy.java:[30,8]
> org.apache.commons.net.ftp.NoProtocolSslConfigurationProxy is not abstract
> and does not override abstract method getEnabledProtocols() in
> org.apache.ftpserver.ssl.SslConfiguration
> Error:
> /home/runner/work/commons-net/commons-net/src/test/java/org/apache/commons/net/ftp/NoProtocolSslConfigurationProxy.java:[32,5]
> method does not override or implement a method from a supertype
> Error: -> [Help 1]
> Error:
> Error: To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> Error: Re-run Maven using the -X switch to enable full debug logging.
> Error:
> Error: For more information about the errors and possible solutions, please
> read the following articles:
> Error: [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> Error: Process completed with exit code 1.
> {noformat}
> See PR Bump ftpserver-core from 1.1.2 to 1.1.3 Java CI #429:
> https://github.com/apache/commons-net/runs/5416642453?check_suite_focus=true
> Please don't break BC! That should be rule #1 IMO.
--
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
Result, was : [VOTE] Apache FtpServer 1.1.4/1.2.0 releases
Hi;, I'm closing this vote, with 3 binding +1 (Jonathan, Guillaume and me). I'll push the packages and announe the release. Thanks ! On 08/03/2022 07:23, Emmanuel Lecharny wrote: Hi, A mistake was made while releasing Apache MINA FtpServer 1.1.3: the API was broken. Those two releases are fixing this mistake: - 1.1.4 will revert back ion the changes that broke the API ascendant compatibility - 1.2.0 will contain the changes in the API that makes it possible to specify more than one enabled TLS version The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: 1.1.4: https://repository.apache.org/content/repositories/orgapachemina-1069/ 1.2.0: https://repository.apache.org/content/repositories/orgapachemina-1068/ The distributions are available for download on : 1.1.4: https://repository.apache.org/content/repositories/orgapachemina-&069/org/apache/ftpserver/ftpserver/1.1.4/ 1.2.0: https://repository.apache.org/content/repositories/orgapachemina-1068/org/apache/ftpserver/ftpserver/1.2.0/ Packages can also be downloaded from: 1.1.4: https://dist.apache.org/repos/dist/dev/mina/ftpserver/1.1.4/ 1.2.0: https://dist.apache.org/repos/dist/dev/mina/ftpserver/1.2.0/ Let us vote : [ ] +1 | Release Apache FtpServer 1.1.4 and 1.2.0 [ ] +/- | Abstain [ ] -1 | Do *NOT* release Apache FtpServer 1.1.4 and 1.2.0 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] (FTPSERVER-506) Binary compatibility is broken in ftpserver-core 1.1.3 vs 1.1.2
[
https://issues.apache.org/jira/browse/FTPSERVER-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505922#comment-17505922
]
Gary D. Gregory commented on FTPSERVER-506:
---
I don't see anything new on Maven Central. Was there a hiccup in the vote
thread?
> Binary compatibility is broken in ftpserver-core 1.1.3 vs 1.1.2
> ---
>
> Key: FTPSERVER-506
> URL: https://issues.apache.org/jira/browse/FTPSERVER-506
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Reporter: Gary D. Gregory
>Priority: Major
>
> Over at Apache Commons, when we update Commons Net from 1.1.2 to 1.1.3, we
> get compile errors:
> {noformat}
> [INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @
> commons-net ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 63 source files to
> /home/runner/work/commons-net/commons-net/target/test-classes
> [INFO] -
> Error: COMPILATION ERROR :
> [INFO] -
> Error:
> /home/runner/work/commons-net/commons-net/src/test/java/org/apache/commons/net/ftp/NoProtocolSslConfigurationProxy.java:[30,8]
> org.apache.commons.net.ftp.NoProtocolSslConfigurationProxy is not abstract
> and does not override abstract method getEnabledProtocols() in
> org.apache.ftpserver.ssl.SslConfiguration
> Error:
> /home/runner/work/commons-net/commons-net/src/test/java/org/apache/commons/net/ftp/NoProtocolSslConfigurationProxy.java:[32,5]
> method does not override or implement a method from a supertype
> [INFO] 2 errors
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 20.310 s
> [INFO] Finished at: 2022-03-04T02:17:14Z
> [INFO]
>
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile
> (default-testCompile) on project commons-net: Compilation failure:
> Compilation failure:
> Error:
> /home/runner/work/commons-net/commons-net/src/test/java/org/apache/commons/net/ftp/NoProtocolSslConfigurationProxy.java:[30,8]
> org.apache.commons.net.ftp.NoProtocolSslConfigurationProxy is not abstract
> and does not override abstract method getEnabledProtocols() in
> org.apache.ftpserver.ssl.SslConfiguration
> Error:
> /home/runner/work/commons-net/commons-net/src/test/java/org/apache/commons/net/ftp/NoProtocolSslConfigurationProxy.java:[32,5]
> method does not override or implement a method from a supertype
> Error: -> [Help 1]
> Error:
> Error: To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> Error: Re-run Maven using the -X switch to enable full debug logging.
> Error:
> Error: For more information about the errors and possible solutions, please
> read the following articles:
> Error: [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> Error: Process completed with exit code 1.
> {noformat}
> See PR Bump ftpserver-core from 1.1.2 to 1.1.3 Java CI #429:
> https://github.com/apache/commons-net/runs/5416642453?check_suite_focus=true
> Please don't break BC! That should be rule #1 IMO.
--
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
[GitHub] [mina-ftpserver] zhanghai opened a new pull request #11: Use ThreadLocal for FtpResponseEncoder.ENCODER.
zhanghai opened a new pull request #11: URL: https://github.com/apache/mina-ftpserver/pull/11 CharsetEncoder isn't thread safe so the original code often crashes when there are multiple responses being encoded concurrently. We can use a ThreadLocal for the CharsetEncoder to fix 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 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
[jira] [Commented] (FTPSERVER-478) java.nio.charset.CoderMalfunctionError: java.nio.BufferUnderflowException
[ https://issues.apache.org/jira/browse/FTPSERVER-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505416#comment-17505416 ] Hai Zhang commented on FTPSERVER-478: - Can we get a fix for this in 1.1.4? > java.nio.charset.CoderMalfunctionError: java.nio.BufferUnderflowException > - > > Key: FTPSERVER-478 > URL: https://issues.apache.org/jira/browse/FTPSERVER-478 > Project: FtpServer > Issue Type: Bug > Components: Core, Server >Affects Versions: 1.1.0 > Environment: Media Box with Android 4.4.2 >Reporter: Jerry Wu >Priority: Major > Fix For: 1.0.6 > > > java.nio.BufferUnderflowException is never happened in 1.0.6, it happened in > 1.1.0 frequently, I wonder whether this exception is from files name with > Chinese character -- 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-478) java.nio.charset.CoderMalfunctionError: java.nio.BufferUnderflowException
[ https://issues.apache.org/jira/browse/FTPSERVER-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505414#comment-17505414 ] Hai Zhang commented on FTPSERVER-478: - I've been hit by this when I send FTP commands rapidly to the server, and I think I've found the culprit: FtpResponseEncoder uses one static CharsetEncoder instance (FtpResponseEncoder.ENCODER) and it's used by multiple threads in an OrderedThreadPoolExecutor. However, CharsetEncoder isn't thread-safe: > Instances of this class are not safe for use by multiple concurrent threads. https://docs.oracle.com/javase/8/docs/api/java/nio/charset/CharsetEncoder.html So please make FtpResponseEncoder.ENCODER a ThreadLocal instead of a plain CharsetEncoder to fix this. > java.nio.charset.CoderMalfunctionError: java.nio.BufferUnderflowException > - > > Key: FTPSERVER-478 > URL: https://issues.apache.org/jira/browse/FTPSERVER-478 > Project: FtpServer > Issue Type: Bug > Components: Core, Server >Affects Versions: 1.1.0 > Environment: Media Box with Android 4.4.2 >Reporter: Jerry Wu >Priority: Major > Fix For: 1.0.6 > > > java.nio.BufferUnderflowException is never happened in 1.0.6, it happened in > 1.1.0 frequently, I wonder whether this exception is from files name with > Chinese character -- 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
