search

arpa2 / tlspool

TLS daemon with PKCS #11 backend
Other
6 stars 7 forks source link

Error code standardisation #92

Closed vanrein closed 5 years ago

vanrein commented 5 years ago

The pioc_error structure is the one part of the TLS Pool command structures that does not have a standard size on all systems. Change it to int32_t, even if this is a break with the API -- at least it is a modest one.

Introduce com_err table name tlsP with any errors that the TLS Pool might ditch, and add generic error_message() information from the table to the message field that may be more specific, but also lack generic pieces.

Replace the retro-fitted use of errno values. This practice is overruled by com_err, which gives us our own, almost unique table. Also, with the exception of 0==success the errno values are not portable in their integer format, so they cannot be sent over a network connection (!) even though codes 0-255 were kept open in com_err to keep them available for at least local use.

We also use GnuTLS error codes a lot. This is not good, as the TLS Pool does not want to go that far in being linked to that particular implementation of TLS. Would GnuTLS perhaps consider using com_err too? Note that GnuTLS uses multiple ranges at this time, each would then be an error table.

Ref: A Common Error Description Library for UNIX by Ken Raeburn and Bill Sommerfield. It's ancient, but answers to the problem of error number spaces that still exists today!

vanrein commented 5 years ago

Note that we will be able to incorporate Kerberos error codes with this! MIT krb5 uses com_err.

vanrein commented 5 years ago

Having found com_err, it's a bit annoying that other's haven't also...

# Everybody  uses           0 to           0
# UNIX       uses           1 to         255
# Unbound    uses         -10 to          -1
# GnuTLS     uses        -500 to          -1 (overlap!)
# BerkeleyDB uses      -30999 to      -30800
# TLS Pool   uses -1167372288 to -1167372033
# MIT krb5   uses -1765328384 to -1765328129 (multi-range)
#
# Our module name "tlsP" landed us in the given range.
vanrein commented 5 years ago

Pfew. The only definition of variable size is struct pioc_error { int tlserrno; ... }; if we assume that char is always 8 bits. All other fields are int32_t and co, from <stdint.h> and <stdbool.h>.

We can have any sizing for local habits, but might get in trouble when sending. DER helps us out, but it would be complicating to have error messages of 64 bit, or having to deal with them. In practice, nobody sends these; POSIX usually ends in the range 1..255 and com_err is defined for int32_t in spite of its long output type (which was how we spoke of 32-bit integers in 1989).

So... as long as we have no mangling problems due to migrations pioc_error.tlserrno -> errno -> pioc_error.tlserrno we shall be fine. I added a test program errorsizes.c to validate just that with the utmost tediousness.

vanrein commented 5 years ago

We might, some day, change send_error() in service.c to take in just an error code and no string, or an optional string. We leave it for now; a string can hold more detail and is therefore useful. To client can be relieved from the com_err() linking and looking, so the protocol should keep the message too. There is, in fact, no better place to store a message, even if just a literal/fixed string, than in the place where it is generated and sent, so as long as we can provide for it we probably will.

vanrein commented 5 years ago