linux-ipsec: more problems

Some more problems seen/found in the Raleigh bakeoff... As before, (a) my list access is send-only until I'm back, (b) due to export regulations this mail is in "whiny mode", complaining without offering suggestions about solutions, (c) this is in random order, and (d) I'm including even things that are my department, to get them on the record.

Along with --version, the commands need to recognize --help, so one can get a syntax summary without having to fumble around trying to provoke a syntax error.

The program that dumps core when invoked without arguments was probably tncfg.

It is absolutely necessary for operational use that there be a way for configuration commands to fetch things like keys from files, doing it *themselves* rather than using shell syntax to make the shell do it. The problem with the shell is that it can supply such data to the programs only as arguments or environment variables, and both of those routes are exposed to scrutiny by "ps". The programs must do the file reads themselves.

To maximize portability, source code probably ought to avoid using gcc compiler functionality that goes beyond standard C -- for example, inline functions -- although this is not an immediate problem.

CVS/RCS comments that lie are very bad; they should be truthful or should not be present at all.

The Ottawa Pluto interoperability bug may justify a right-way/wrong-way flag even if we were in the right. (We haven't gotten any useful testing done in that area yet, but problems in that area do seem possible.)

"usage error in gparse" is not a good syntax-error report -- it is highly
desirable to at least report *where* the error was discovered, to give the user some hint what he did wrong.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

We need to invest some effort defining good standard notations for things like SAs, and then fixing *everything* to use them. In particular, input and output should use the same notations; there is far too much cut-and- paste currently needed when constructing input based on output.

Speaking of standard notation: it should never be necessary to remember which inputs/outputs are hexadecimal, because hex numbers should always begin with "0x", on both input and output. This notation may not be ideal but it is the accepted standard.

The /proc file which shows the result of an eroute command has a name ending in "route", not "eroute" -- such inconsistencies can be confusing and should be fixed.

Invocations of perror() should be systematically rooted out of the code, because they almost never give enough information to be useful. Even
"can't happen" errors need more context than, say, perror("write") gives.

                                                           Henry Spencer
                                                       henry@zoo.toronto.edu