On Sun, May 20, 2018 at 12:18 AM, Robert Story <rst...@freesnmp.com> wrote:
> On Sat, 19 May 2018 14:07:56 -0700 Bart wrote:
> BVA> strlcpy() implementations typically scan for the end of the
> BVA> source argument passed to strlcpy(). Hence avoid passing an
> BVA> unterminated string to strlcpy().
>
> I'm going to say -1, but for the patch and not the need to fix the
> issue.
>
> This code is treating 'a' and 't' hints the same. There should
> never be UTF-8 in an ascii string. Why not revert back to the
> original code for 'a' case and put UTF-8 handling where it belongs,
> under the 't' case.
>
There's a much longer discussion to be had here, one hint at how complex
the discussion will get is that RFC2571 says that SnmpAdminString is
"encoded as an octet string using the UTF-8 transformation" and has a
DISPLAY-HINT of "255a". So, does "a" mean UTF-8 or ASCII or is it
fundamentally a little indeterminate due to ancient mistakes and current
conventions?
My personal feeling is that if a string is valid UTF-8 (which can be
determined in one pass using the algorithm I pointed to in the bug), it
should be output as-is, whether the DISPLAY-HINT is "a" or "t". We should
protect against not just NUL bytes as the current code does but also
control characters (e.g., if there's an embedded "\n" in the string, will
that foil a future log parser that's trying to do line-based parsing of a
log file?).
I do not think that now is the time to try to deal with any of the
fundamentals, but just not regress from previous released behavior, and
deal with the underlying issue in 5.8.1 / 5.7.4.
Bill
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
