removed roadmap.org file in favor of using github milestones
authorMichael Rash <mbr@cipherdyne.org>
Sat, 27 Apr 2013 01:56:26 +0000 (21:56 -0400)
committerMichael Rash <mbr@cipherdyne.org>
Sat, 27 Apr 2013 01:56:26 +0000 (21:56 -0400)
Makefile.am
roadmap.org [deleted file]

index f2e1e6d..049ab4f 100644 (file)
@@ -51,8 +51,6 @@ EXTRA_DIST = \
     ChangeLog \
     ChangeLog.git \
     CREDITS \
-    todo.org \
-    roadmap.org \
     extras/upstart/fwknop.conf \
     extras/fwknop.init.debian \
     extras/fwknop.init.openwrt \
diff --git a/roadmap.org b/roadmap.org
deleted file mode 100644 (file)
index 8a02d93..0000000
+++ /dev/null
@@ -1,69 +0,0 @@
-* 2.5
-** HMAC support
-   Usage of an HMAC will be optional and not the default in order to remain
-   backwards compatible with older non-HMAC capable versions of fwknop.  The
-   libfko API will change though, so backwards compatibility will be
-   maintained in the sense that an SPA packet produced by the fwknop-2.5
-   client can be decrypted by a pre-2.5 server, but pre-2.5 code cannot use
-   the libfko 2.5 code and vice versa.
-** OpenSSL compatibility by default for AES usage
-   The legacy way of generating salt + IV will be available through server
-   access.conf variable support and a client command line argument.  This will
-   allow users to upgrade and not break backwards compatibility from a raw SPA
-   communications perspective.
-** Key generation support
-   Allow encryption and HMAC keys to be automatically generated and stored.
-   This allows stronger keys to be used than normal user-provided passwords.
-** Key lengths passed to encryption routines - C strings not required
-   Specify encryption and HMAC key lengths via explicitly passing their length
-   to crypto routines.  This allows random data to be used for key information
-   from the key generation code, and does not force libfko to guess at key
-   length by the existence of a NULL char (which can now be part of a key).
-* 2.6
-** Privilege separation support
-   Only two areas of fwknopd need to run as root: packet acquisition and
-   firewall rule adjustment.  Everything else should run as non-privileged 
-   user.
-** UDP listener support (no pcap dependency)
-   Since nmap cannot tell the difference between a filtered or open UDP server
-   when nothing is sent back in response to a probe (no UDP server is ever
-   obligated to return anything out of necessity), there is room for a mode of
-   operation where fwknopd binds to a UDP port and uses it to acquire SPA
-   packet data.  The advantage of this approach is that a fwknopd would not
-   need to link against libpcap and can run as an unprivileged user except for
-   the code that must adjust the firewall rule set.
-** libcap-ng support
-   libcap-ng provides a way to drop privileges for certain operations, and
-   fwknopd should support this.
-** OpenBSD PF NAT support
-   Extend fwknopd's NAT capabilities into the PF world.
-** Optional OpenSSL direct usage for crypto operations
-   This would introduce a dependency on the OpenSSL library, but some users
-   may prefer this.  Usage of OpenSSL would cause current crypto code to not
-   be compiled in via autoconf #defines.
-** Build an Amazon fwknopd AMI
-   Create an Amazon AMI with fwknopd loaded and a default configuration that
-   supports SNAT+DNAT so that other Amazon VPC instances can be reached
-   through this host with SPA.
-* 2.7
-** Full IPv6 support
-   While updating the client to send SPA packets over IPv6 will be relatively
-   easy and some code has already been included for this, the fwknopd side
-   will be harder.
-** SELinux + AppArmor policy support
-   Both SELinux and AppArmor implement a Mandatory Access Control (MAC) layer
-   within the kernel, and the fwknop sources should include policies to
-   leverage these tools.
-** See what we can do for GPG support on Windows and other platforms (Android)
-   This one may be a long shot.
-* 2.8
-** Optional pthreads support
-   This should be an optional feature gated by autoconf #defines, and not
-   enabled by default.  For users that want this, it would make for a cleaner
-   way to implement firewall rules on the server side.
-** User interfaces: GNOME, KDE, Windows
-   Implement viable user interfaces for SPA packet creation.
-** Ruby bindings for libfko
-   Extend interpreted language support to Ruby.
-** ipfw NAT support
-   Extend fwknopd's NAT capabilities into the ipfw world.