investtools-ftpd 1.0.1

data/features/ftp_server/delay_after_failed_login.feature

@@ -0,0 +1,23 @@
+Feature: Delay After Failed Login
+
+  As an administrator
+  I want to make brute force attacks less efficient
+  So that an attacker doesn't gain access
+
+  Scenario: Failed login attempts
+    Given the test server has a failed login delay of 0.2 seconds
+    And the test server is started
+    Given the client connects
+    And the client logs in with bad user
+    And the client logs in with bad user
+    And the client logs in
+    Then it should take at least 0.4 seconds
+
+  Scenario: Failed login attempts
+    Given the test server has a failed login delay of 0.0 seconds
+    And the test server is started
+    Given the client connects
+    And the client logs in with bad user
+    And the client logs in with bad user
+    And the client logs in
+    Then it should take less than 0.4 seconds

data/features/ftp_server/delete.feature

@@ -0,0 +1,60 @@
+Feature: Delete
+
+  As a client
+  I want to delete files
+  So that nobody can fetch them from the server
+
+  Background:
+    Given the test server is started
+
+  Scenario: Delete a file
+    Given a successful login
+    And the server has file "foo"
+    When the client successfully deletes "foo"
+    Then the server should not have file "foo"
+
+  Scenario: Delete a file in a subdirectory
+    Given a successful login
+    And the server has file "foo/bar"
+    When the client successfully deletes "foo/bar"
+    Then the server should not have file "foo/bar"
+
+  Scenario: Change current directory
+    Given a successful login
+    And the server has file "foo/bar"
+    And the client successfully cd's to "foo"
+    When the client successfully deletes "bar"
+    Then the server should not have file "foo/bar"
+
+  Scenario: Missing path
+    Given a successful login
+    And the server has file "foo"
+    When the client deletes with no path
+    Then the server returns a path required error
+
+  Scenario: not found
+    Given a successful login
+    When the client deletes "foo"
+    Then the server returns a not found error
+
+  Scenario: Access denied
+    Given a successful login
+    When the client deletes "forbidden"
+    Then the server returns an access denied error
+
+  Scenario: File system error
+    Given a successful login
+    When the client deletes "unable"
+    Then the server returns an action not taken error
+
+  Scenario: Not logged in
+    Given a successful connection
+    When the client deletes "foo"
+    Then the server returns a not logged in error
+
+  Scenario: Delete not enabled
+    Given the test server lacks delete
+    And a successful login
+    And the server has file "foo"
+    When the client deletes "foo"
+    Then the server returns an unimplemented command error

data/features/ftp_server/directory_navigation.feature

@@ -0,0 +1,59 @@
+Feature: Change Directory
+
+  As a client
+  I want to change the current directory
+  So that I can use shorter paths
+
+  Background:
+    Given the test server is started
+
+  Scenario: Down to subdir
+    Given a successful login
+    And the server has file "subdir/bar"
+    When the client successfully cd's to "subdir"
+    Then the current directory should be "/subdir"
+
+  Scenario: Up from subdir
+    Given a successful login
+    And the server has file "subdir/bar"
+    And the client successfully cd's to "subdir"
+    When the client successfully cd's to ".."
+    Then the current directory should be "/"
+
+  Scenario: Up from root
+    Given a successful login
+    When the client successfully cd's to ".."
+    Then the current directory should be "/"
+
+  Scenario: XPWD
+    Given a successful login
+    And the server has directory "subdir"
+    When the client successfully cd's to "subdir"
+    Then the XPWD directory should be "/subdir"
+
+  Scenario: XCWD
+    Given a successful login
+    And the server has directory "subdir"
+    When the client successfully sends "XCWD subdir"
+    Then the current directory should be "/subdir"
+
+  Scenario: Change to file
+    Given a successful login
+    And the server has file "baz"
+    When the client cd's to "baz"
+    Then the server returns a not a directory error
+
+  Scenario: No such directory
+    Given a successful login
+    When the client cd's to "subdir"
+    Then the server returns a not found error
+
+  Scenario: Access denied
+    Given a successful login
+    When the client cd's to "forbidden"
+    Then the server returns an access denied error
+
+  Scenario: Not logged in
+    Given a successful connection
+    When the client cd's to "subdir"
+    Then the server returns a not logged in error

data/features/ftp_server/disconnect_after_failed_logins.feature

@@ -0,0 +1,25 @@
+Feature: Disconnect After Failed Logins
+
+  As an administrator
+  I want to make brute force attacks less efficient
+  So that an attacker doesn't gain access
+
+  Scenario: Disconnected after maximum failed attempts
+    Given the test server has a max of 3 failed login attempts
+    And the test server is started
+    Given the client connects
+    And the client logs in with bad user
+    And the client logs in with bad user
+    When the client logs in with bad user
+    Then the server returns a server unavailable error
+    And the client should not be connected
+
+  Scenario: No maximum configured
+    Given the test server has no max failed login attempts
+    And the test server is started
+    Given the client connects
+    And the client logs in with bad user
+    And the client logs in with bad user
+    And the client logs in with bad user
+    Then the server returns a login incorrect error
+    And the client should be connected

data/features/ftp_server/eprt.feature

@@ -0,0 +1,55 @@
+Feature: EPRT
+
+  As a programmer
+  I want good error messages
+  So that I can correct problems
+
+  Background:
+    Given the test server is bound to "::"
+    Given the test server is started
+
+  Scenario: Port 1024
+    Given a successful login
+    Then the client successfully sends "EPRT |1|1.2.3.4|1024|"
+
+  Scenario: Port 1023; low ports disallowed
+    Given the test server disallows low data ports
+    And a successful login
+    When the client sends "EPRT |1|2.3.4.3|255|"
+    Then the server returns an unimplemented parameter error
+
+  Scenario: Port out of range
+    Given a successful login
+    When the client sends "EPRT |1|2.3.4.5|65536|"
+    Then the server returns an unimplemented parameter error
+
+  Scenario: Port 1023; low ports allowed
+    Given the test server allows low data ports
+    And a successful login
+    Then the client successfully sends "EPRT |1|2.3.4.3|255|"
+
+  Scenario: Not logged in
+    Given a successful connection
+    When the client sends "EPRT |1|2.3.4.5|6|"
+    Then the server returns a not logged in error
+
+  Scenario: Too few parts
+    Given a successful login
+    When the client sends "EPRT |1|2.3.4|"
+    Then the server returns a syntax error
+
+  Scenario: Too many parts
+    Given a successful login
+    When the client sends "EPRT |1|2.3.4|5|6|"
+    Then the server returns a syntax error
+
+  Scenario: Unknown network protocol
+    Given a successful login
+    When the client sends "EPRT |3|2.3.4.5|6|"
+    Then the server returns a network protocol not supported error
+
+  Scenario: After "EPSV ALL"
+    Given a successful login
+    Given the client successfully sends "EPSV ALL"
+    When the client sends "EPRT |1|2.3.4.5|6|"
+    Then the server sends a not allowed after epsv all error

data/features/ftp_server/epsv.feature

@@ -0,0 +1,36 @@
+Feature: EPSV
+
+  As a programmer
+  I want good error messages
+  So that I can correct problems
+
+  Background:
+    Given the test server is bound to "::"
+    And the test server is started
+
+  Scenario: No argument
+    Given a successful login
+    Then the client successfully sends "EPSV"
+
+  Scenario: Explicit IPV4
+    Given a successful login
+    Then the client successfully sends "EPSV 1"
+
+  Scenario: Explicit IPV6
+    Given a successful login
+    Then the client successfully sends "EPSV 2"
+
+  Scenario: After "EPSV ALL"
+    Given a successful login
+    Given the client successfully sends "EPSV ALL"
+    Then the client successfully sends "EPSV"
+
+  Scenario: Not logged in
+    Given a successful connection
+    When the client sends "EPSV"
+    Then the server returns a not logged in error
+
+  Scenario: Unknown network protocol
+    Given a successful login
+    When the client sends "EPSV 99"
+    Then the server returns a network protocol not supported error

data/features/ftp_server/features.feature

@@ -0,0 +1,38 @@
+Feature: Features
+
+  As a client
+  I want to know what FTP extension the server supports
+  So that I can use them without trial-and-error
+
+  Background:
+
+  Scenario: TLS Disabled
+    Given the test server is started
+    And the client connects
+    When the client successfully requests features
+    Then the response should not include TLS features
+
+  Scenario: TLS Enabled
+    Given the test server has TLS mode "explicit"
+    And the test server is started
+    And the client connects
+    When the client successfully requests features
+    Then the response should include TLS features
+
+  Scenario: Argument given
+    Given the test server is started
+    And the client connects
+    When the client sends "FEAT FOO"
+    Then the server returns a syntax error
+
+  Scenario: IPV6 Extensions
+    Given the test server is started
+    When the client successfully requests features
+    Then the response should include feature "EPRT"
+    And the response should include feature "EPSV"
+
+  Scenario: RFC 3659 Extensions
+    Given the test server is started
+    When the client successfully requests features
+    Then the response should include feature "SIZE"
+    Then the response should include feature "MDTM"

data/features/ftp_server/file_structure.feature

@@ -0,0 +1,43 @@
+Feature: File Structure
+
+  As a server
+  I want to accept the obsolute file structure (STRU) command
+  For compatability
+
+  Background:
+    Given the test server is started
+
+  Scenario: File
+  Given a successful login
+  And the server has file "ascii_unix"
+  When the client successfully sets file structure "F"
+  And the client successfully gets text "ascii_unix"
+  Then the remote file "ascii_unix" should match the local file
+
+  Scenario: Record
+    Given a successful login
+    And the server has file "ascii_unix"
+    When the client sets file structure "R"
+    Then the server returns a file structure not implemented error
+
+  Scenario: Page
+    Given a successful login
+    And the server has file "ascii_unix"
+    When the client sets file structure "P"
+    Then the server returns a file structure not implemented error
+
+  Scenario: Invalid
+    Given a successful login
+    And the server has file "ascii_unix"
+    When the client sets file structure "*"
+    Then the server returns an invalid file structure error
+
+  Scenario: Not logged in
+    Given a successful connection
+    When the client sets file structure "F"
+    Then the server returns a not logged in error
+
+  Scenario: Missing parameter
+    Given a successful login
+    When the client sets file structure with no parameter
+    Then the server returns a syntax error

data/features/ftp_server/get.feature

@@ -0,0 +1,80 @@
+Feature: Get
+
+  As a client
+  I want to securely get a file
+  So that I have it on my computer
+  But nobody else can
+
+  Background:
+    Given the test server is started
+
+  Scenario: ASCII file with *nix line endings
+    Given a successful login
+    And the server has file "ascii_unix"
+    When the client successfully gets text "ascii_unix"
+    Then the local file "ascii_unix" should match the remote file
+    And the local file "ascii_unix" should have unix line endings
+
+  Scenario: ASCII file with windows line endings
+    Given a successful login
+    And the server has file "ascii_windows"
+    When the client successfully gets text "ascii_windows"
+    Then the local file "ascii_windows" should match the remote file
+    And the local file "ascii_windows" should have unix line endings
+
+  Scenario: Binary file
+    Given a successful login
+    And the server has file "binary"
+    When the client successfully gets binary "binary"
+    Then the local file "binary" should exactly match the remote file
+
+  Scenario: Passive
+    Given a successful login
+    And the server has file "ascii_unix"
+    And the client is in passive mode
+    When the client successfully gets text "ascii_unix"
+    Then the local file "ascii_unix" should match the remote file
+
+  Scenario: File in subdirectory
+    Given a successful login
+    And the server has file "foo/ascii_unix"
+    Then the client successfully gets text "foo/ascii_unix"
+
+  Scenario: Non-root working directory
+    Given a successful login
+    And the server has file "foo/ascii_unix"
+    And the client successfully cd's to "foo"
+    When the client successfully gets text "ascii_unix"
+    Then the remote file "foo/ascii_unix" should match the local file
+
+  Scenario: Access denied
+    Given a successful login
+    When the client gets text "forbidden"
+    Then the server returns an access denied error
+
+  Scenario: Missing file
+    Given a successful login
+    When the client gets text "foo"
+    Then the server returns a not found error
+
+  Scenario: Not logged in
+    Given a successful connection
+    When the client gets text "foo"
+    Then the server returns a not logged in error
+
+  Scenario: Missing path
+    Given a successful login
+    When the client gets with no path
+    Then the server returns a syntax error
+
+  Scenario: File system error
+    Given a successful login
+    When the client gets text "unable"
+    Then the server returns an action not taken error
+
+  Scenario: Read not enabled
+    Given the test server lacks read
+    And a successful login
+    And the server has file "foo"
+    When the client gets text "foo"
+    Then the server returns an unimplemented command error

data/features/ftp_server/get_ipv6.feature

@@ -0,0 +1,43 @@
+Feature: Get IPV6
+
+  As a client
+  I want to get a file
+  So that I have it on my computer
+
+  Scenario: Active
+    Given the test server is bound to "::1"
+    And the test server is started
+    And a successful login
+    And the server has file "ascii_unix"
+    And the client is in active mode
+    When the client successfully gets text "ascii_unix"
+    Then the local file "ascii_unix" should match the remote file
+
+  Scenario: Passive
+    Given the test server is bound to "::1"
+    And the test server is started
+    And a successful login
+    And the server has file "ascii_unix"
+    And the client is in passive mode
+    When the client successfully gets text "ascii_unix"
+    Then the local file "ascii_unix" should match the remote file
+
+  Scenario: Active, TLS
+    Given the test server is bound to "::1"
+    And the test server has TLS mode "explicit"
+    And the test server is started
+    And a successful login
+    And the server has file "ascii_unix"
+    And the client is in active mode
+    When the client successfully gets text "ascii_unix"
+    Then the local file "ascii_unix" should match the remote file
+
+  Scenario: Passive, TLS
+    Given the test server is bound to "::1"
+    And the test server has TLS mode "explicit"
+    And the test server is started
+    And a successful login
+    And the server has file "ascii_unix"
+    And the client is in passive mode
+    When the client successfully gets text "ascii_unix"
+    Then the local file "ascii_unix" should match the remote file