=?iso-8859-1?Q?Bj=F8rn_Mork?= <bjorn@mork.no> wrote:
Stripping NULs off the end of a string is interpreting them as string terminators. The RFC forbids this.
No, it doesn't. And even if it did, who cares?
It demands that implementations deal with embedded NULs. If FreeRADIUS strips any NULs, anywhere in the string, then FreeRADIUS is violating the RFC. IMHO.
Perhaps you could try understand what the server actually does, and why. a) type "octets" is treated as opaque binary blobs b) type "string" can't have embedded NUL's, because they are used in C as end-of-string markers. This is perfectly compatible with the RFC's, because FreeRADIUS used type "string" for printable data, and NUL isn't printable. The RFC's use type "text" for printable and "string" for octets, because the original RFC's used "string" for both, which was wrong. FreeRADIUS used "string" for printable, and "octets" for non-printable, because it was started before the RFC's were fixed. And as for RFC violations, the RFC's document a recommended way to do things. Nothing more. You can violate them at will if they're wrong. (As seen in the "string" -> "string, text" change above.) If the original RFC was perfect, why was it changed? FreeRADIUS violates a number of other recommendations in the RFC's, because time has shown those recommendations to be wrong or inefficient. e.g. the RFC 3579, section 2.6.1. It recommends keeping track of EAP sessions through some convoluted and fragile method. When Raghu did the original EAP implementation, he came up with a much better scheme. So much better, in fact, the there will be a new RFC within a year documenting his method as used in FreeRADIUS, and suggesting that it's probably a better way to do things. So don't get picky about RFC violations. Blind adherence to a specification is counter-productive. And if nothing else, the collective RADIUS experience of the FreeRADIUS developers is approaching the century mark. I'd be careful about arguing with people who have more experience than you in a field. Alan DeKok.