"Secure coding" audit checkers and Kerberos

[Ken Raeburn]

On Oct 14, 2008, at 22:36, Russ Allbery wrote:
> It sounds like one of the root problems is not so much what  
> functions you
> use as having a uniform error handling method.  Every approach  
> requires
> error handling.  If you find a general solution to error handling,  
> then
> you can take that out of the set of things you have to worry about,  
> and
> more options come into play (such as using asprintf/vasprintf  
> everywhere
> you have variable-length output instead of trying to decide on a  
> static
> buffer size).

I'd rather see the simple things constructed such that the possible  
errors are minimized or (except for allocation failures) eliminated.   
I don't think we necessarily want one error handling strategy that  
provides the flexibility to pass back a dozen or more different  
possible errors from a ticket request to also be the way we indicate  
that a strdup-type function encountered its only possible error,  
inability to allocate storage.  (Though I'm assuming that at that  
level we don't want friendly checks for NULL inputs that generate  
EINVAL or something.)  And depending on what sort of string operations  
Greg finds are commonly being done, I think we can probably make  
building blocks that can easily be reviewed and shown not to be able  
to produce any errors beside allocation failures.

(Cases where we might prefer truncation over huge outputs are another  
story, of course.)

Ken