removed some ancient files
authorAndreas Steffen <andreas.steffen@strongswan.org>
Fri, 15 May 2009 19:25:21 +0000 (21:25 +0200)
committerAndreas Steffen <andreas.steffen@strongswan.org>
Fri, 15 May 2009 19:25:21 +0000 (21:25 +0200)
src/pluto/PLUTO-CONVENTIONS [deleted file]
src/pluto/TODO [deleted file]
src/pluto/pluto-style.el [deleted file]

diff --git a/src/pluto/PLUTO-CONVENTIONS b/src/pluto/PLUTO-CONVENTIONS
deleted file mode 100644 (file)
index 16febc4..0000000
+++ /dev/null
@@ -1,125 +0,0 @@
-Notes on Pluto Conventions
-==========================
-
-Pluto has its own stylistic conventions.  They are fairly easily
-inferred by reading the code.
-
-- sample formatting:
-
-void
-fun(char *s)
-{
-    if (s == NULL)
-    {
-       return "";
-    }
-    else
-    {
-       switch (*s)
-       {
-       default:
-           s++;
-           /* fall through */
-       case '\0':
-           return s;
-       }
-    }
-}
-
-- a function definition has its function identifier at the margin
-
-- indentation is in steps of 4 columns (tabstops are every 8 columns)
-
-- try to keep lines shorter than 80 columns
-
-- space should be canonical:
-  + no line should have trailing whitespace
-  + leading whitespace should use tabs where possible
-  + indentation should be precise
-  + there should be no empty lines at the end of a file.
-
-- braces go on their own line, indented the same as the start of what they are part of
-
-- switch labels are indented the same as the enclosing braces
-
-- if a case falls through, say so explicitly
-
-- spaces follow control flow reserved words (but not function names)
-
-- the operand of return need not be parenthesized
-
-- be careful with types.  For example, use size_t and ssize_t.
-  Use const wherever possible.
-
-- we pretend that C has a strong boolean type.
-  We actually define bool with constants TRUE and FALSE.
-  Other types cannot be used as the complete expression in a test.
-  Hence:
-    if (s == NULL)
-  One exception: lset_t values can be treated as booleans
-  (technically they are, in the original sense of the word)
-
-
-- memsetting a pointer to binary zero is not guaranteed to make it NULL
-
-- side-effects of expressions are to be avoided.
-  BAD:  if (i++ == 9)
-  OK:  i++;
-
-- variables are to have as small a scope as is possible.
-  Move definitions into inner blocks whenever possible.
-  Often initializing definitions become possible and are clearer.
-
-- within a block that has declarations, separate the declarations from
-  the other statements with a blank line.
-
-- "magic numbers" are suspect.  Most integers in code stand for something.
-  They should be given a name, and that name used consistently.
-
-- don't use malloc/free -- use the wrappers (see defs.h)
-
-- it is good to put comments on #else and #endif to show what
-  they match with.  I use ! to indicate the sense of the test:
-  #ifdef CRUD
-  #else /* !CRUD */
-  #endif /* !CRUD */
-
-  #ifndef CRUD
-  #else /* CRUD */
-  #endif /* CRUD */
-
-- all functions and variables that are exported from a .c file should
-  be declared in that file's header file.  Because the .c includes the
-  header, the declaration and the definition will be checked by the
-  compiler.  There is almost no excuse for the "extern" keyword
-  in a .c file.
-
-- when lines are too long and expressions are to be broken, try to
-  break just before a binary operator.  The outermost binary operator
-  is preferred.  This is perhaps the most unconventional convention.
-  It allows the structure of code to be evident from a scan of the
-  left margin.  Example:
-                   if (next_step == vos_his_client
-                   && sameaddr(&c->spd.that.host_addr, &his_client))
-                       next_step = vos_done;
-  and
-                   p = oppo_instantiate(p, &c->spd.that.host_addr, &c->spd.that.id
-                       , NULL, &our_client, &his_client);
-  Note the different indentation of the continuations.  The continuation
-  of a control flow statement is not indented but other continuations are.
-
-- Never put two statements on one line.
-  REALLY BAD: if (cat);
-  Exception: some macro definitions.
-
-- C preprocessor macros are implemented by a kind of textual substitution.
-  Be sure to put parentheses around references to macro arguments and
-  around the whole macro body.  If the body is meant to be a statement,
-  put braces around it instead.
-
-    #define RETURN_STF_FAILURE(f) \
-       { int r = (f); if (r != NOTHING_WRONG) return STF_FAIL + r; }
-
-- adding #include statements adds dependencies.  The Makefile should be
-  changed to reflect them.  Target "makedepend" will try to list dependencies
-  in a way suitable for pasting into Makefile
diff --git a/src/pluto/TODO b/src/pluto/TODO
deleted file mode 100644 (file)
index 445a6e2..0000000
+++ /dev/null
@@ -1,128 +0,0 @@
-Pluto TODO list
-===============
-
-- should all log entries that are for errors say ERROR?
-
-- Add a "plug-in" facility so that others can add features without
-  changing the mainline code.  This is how X509/LDAP/biometric stuff
-  might be added.
-
-- (internal change only) routines for outputting payloads should plug
-  "np" into the previous payload so that a payload generating routine
-  need not know what the next payload will be.  This may be more bother
-  than it is worth.
-
-- notifications, in and out
-  + delete
-  + first contact
-  + last contact? (not part of drafts, but would be nice)
-
-- Make DNS usage for asynchronous (non-blocking)
-  + looking up KEY and TXT records during negotiation
-  + perhaps not for whack command arguments and ipsec.secrets since the
-    library code uses gethostbyname
-
-- check that ipsec auto and whack to agree on what is worth reporting
-
-- Should Pluto (rather than ipsec manual) install %passthrough conns?
-  That way Pluto would know of them.
-
-- For responding to Road Warriors, how can we decide if the RW has
-  gone away?  The rekeying event is perhaps too imprecise.  Even if
-  rekeying event is good enough, how do we know if the route should be
-  torn down?  Perhaps limiting a Phase 1 ID to one IP address would
-  help (limiting a client subnet to one peer already helps).  Perhaps
-  (in some rate-limited way) we can take an ICMP host unreachable
-  as a hint to do some authenticated and reliable probe.
-
-- it is annoying that Pluto and auto have different models for public keys.
-  + auto specifies one per connection
-  + Pluto allows one to be specified per id
-  Two connections with the same id are going to use the same key:
-  the one of the last conn to be added!
-
-  I think auto ought to be fixed.  It is hard for Pluto to warn when
-  there is a conflict since the deletion of a connection doesn't
-  prompt auto to tell pluto to delete the public key.
-
-- different connections with the same host IP addresses are randomly
-  interchangeable until the ID payload is received.  At least for the
-  Responder case (and eventually for the opportunistic Initiator).
-  Worse, all Road Warriors must be considered to have the
-  indistinguishable IP addresses.  This affects ISAKMP SA negotiation.
-  Currently, there is little flexibility in this negotiation, so the
-  problem is limited to the specification of acceptable authentication
-  method(s).  Correct, but more work than seems worthwhile, would be
-  to select the conn based on what is proposed.
-
-  Warning about such confusion at connection definition time isn't great
-  because there is no confusion when explicitly initiated (a particular
-  conn is specified).  Warning for a Road Warrior conn is possible
-  since it cannot be initiated (and has been implemented).
-
-- characterize and ameliorate DOS attacks.  Lots of rate limiting.
-
-- look at John Denker's wish list: http://www.quintillion.com/moat/wish.list
-
-- use of random numbers needs to be audited.
-
-- unknown (not just unimplemented) transforms cause a negotiation to
-  fail.  Only the transform should be rejected.
-
-- we need better policy control.  Our present flags need to be
-  modulated (forbid, allow, offer, require)
-
-- HS will specify how --copyright and --version should behave
-
-- HS will initiate project-wide terminology replacing ISAKMP SA, IPSEC
-  SA, Protection Suite, Phase 1, Main Mode, Phase 2, Quick Mode, ...
-  Simplicity and clarity will be a goal.
-
-- interface discovery ought to match what is specified in ipsec.conf.
-  This probably means grokking /proc/net/ipsec_tncfg.  Documented in
-  ipsec_tncfg(5).  This won't do for Hugh's debugging setup.
-
-
-Protocol Issues
-===============
-
-Notification and delete payloads seem to be "escape hatches" for the
-protocols.  As such, anything implemented using them seems to be
-kludged without being well designed or well situated or well
-constrained in the protocols.  Often the precise meaning (if any) or
-usage is under specified.  An implementation is allowed to ignore
-them, so they cannot really matter (but they too often do).  Their
-specification ought to be scrutinized by a protocol guru.
-
-Any extra payload in last main mode message is not protected (not
-authenticated by hash).
-
-Should notification payloads be interpreted before or after the normal
-payloads (i.e. understood in the context of, executed in the context of).
-
-What is the precise result of an INITIAL_CONNECTION?  What is a
-"system" (eg. does Phase 1 Identity count)?  What is "earlier" or
-"before" (simultaneous negotiation is possible, with time being only a
-partial order)?  Could it be used for FINAL_CONTACT (needed too)?
-
-Blasting out a pile of UDP messages, especially to a particular
-destination, is likely to provoke message loss.  The exchanges are
-just that, so they individually are self-throttling.  But what about
-multiple exchanges simultaneously?  What about notifications (example:
-when shutting down, a flurry of delete notifications are likely).
-Should the RFCs be designed to protect against this problem?
-
-draft-jenkins-ipsec-rekeying-03.txt rekeying is way too complicated.
-Our solution looks sound and simple (we have the Responder install the
-incoming IPSEC SA before sending its first reply).  In "2.2.1.4
-Responder Pre-Set-up Security Hole", the draft claims that setting up
-the IPSEC SA early leaves the Responder open to replay attacks.  I
-think that this is wrong: the Message Id, since it must not be reused,
-serves to prove that this isn't a replay.
-
-The details for notification messages suggested by
-draft-ietf-ipsec-notifymsg-02.txt are over-complicated, just to make
-them machine-comprehensible.  I think this is over-engineering,
-justified only if another level of negotiation is contemplated (ugh!).
-Plain text is probably sufficient for informing humans (I admit that
-there is a problem with I18N).
diff --git a/src/pluto/pluto-style.el b/src/pluto/pluto-style.el
deleted file mode 100644 (file)
index 0de474e..0000000
+++ /dev/null
@@ -1,4 +0,0 @@
-(c-add-style "pluto" '("bsd"
-                      (c-basic-offset . 4)
-                      (c-offsets-alias . ((substatement-open . 0)))))
-