[Swan-dev] [Swan-commit] Changes to ref refs/heads/master

Andrew Cagney andrew.cagney at gmail.com
Wed Jan 20 01:33:48 UTC 2016


On 19 January 2016 at 14:18, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
> | From: Andrew Cagney <andrew.cagney at gmail.com>
>
> | I'm testing a change that accumulates the ascii representation of the
> | entire remote SA payload into that buffer. If no proposals match it
> | will get logged as a single line.
>
> Is there a reasonable limit one should follow for the width of a log
> line?  I've developed a bunch of superstitions over the years but
> nothing concrete.  1024 seems wide but my guess that up to 4k might be
> safe (but inhumane).

I suspect AUDIT has a far smaller limit.  I don't want to know.

>
> | Anyway, this is all mute as I'm going to move the structure to the
> | heap: tiny uClinux stack; and buffers on the stack just scare me.
>
> Yes.  The heap scares me in different ways.
>
> If you are going to use the heap, it is almost as easy to expand the
> buffer as it is to deal with overflow.  You can arrange the code so
> that even the first allocation is a kind of overflow.

Except that means implementing realloc, which we don't have.  Which
means looking at lswalloc.h, which .....

Cleaning up this hack, and moving it out of ikev2_spdb_struct.c and
into a proper home would be nic.

> I admit that the current form with snprintf-before-checking would need
> to be reworked.
>         do {} while (!print_joint(...));
> and print_join would need to return TRUE on -1 case.  Or print_join
> could absorb the role of snprintf, with all the varargs horror.

That's why I didn't implement it.

> | Yes, constantly having to re-work important patches because someone
> | keeps tinkering with the colours gets tedious.
>
> Ahh.  Sorry.  I thought that since it was in master it was fair game.

The broad strategy is to firstly merge in a bug-compatible SA rewrite;
and then start fixing bugs.

One one of those changes, and the one causing much of the angst, is to
log the entire rejected proposal so that an end-user can see what went
wrong.  It unfortunately touches many parts of the file, and is also
likely see continued tweaking as we refine its output.

In case your curious, there's also:

- support ESNs in proposals
- move the local proposal suite to the connection so it isn't
re-created each time a state is created
- fix that code emitting IKEv2 attributes
- parse the proposals before allocating any state

the last is most exciting

and I'm sure there's other stuff


More information about the Swan-dev mailing list