[lenlynch]

Thank you jggimi!

Originally Posted by jggimi

Perhaps your interactive use is with a Unicode-capable terminal such as xterm(1), and cron(1) runs in a standard shell which may not have LC_CTYPE set.

I do SSH using a client that is configured for UTF-8 support, so that is indeed something to follow-up on. Great point.

I do see this with regards to X/xenocara and xterm, which provides some outline to the problem of there being a protocol specific issue of negotiating character encodings between different systems...

http://undeadly.org/cgi?action=artic...20160308204011

It also points to the larger concern of data handling safety, which can not be guaranteed between non-OpenBSD systems interacting.

LOCALE(1) manpage hints at parts of the system are not UTF-8 friendly:

     A locale is a set of environment variables telling programs which
     character encoding, language and cultural conventions the user prefers.
     Programs in the OpenBSD base system ignore the locale except for the
     character encoding, and it is not recommended to use any of these
     variables except that the following non-default setting is supported as
     an option:

           export LC_CTYPE=en_US.UTF-8
...

     The OpenBSD base system supports two locales: the default of LC_CTYPE=C
     selects the US-ASCII character set and encoding, treating the bytes 0x80
     to 0xff as non-printable characters of application-specific meaning.
     LC_CTYPE=POSIX is an alias for LC_CTYPE=C.  The alternative of
     LC_CTYPE=en_US.UTF-8 selects the UTF-8 encoding of the Unicode character
     set, which is supported by many parts of the system, but not yet fully
     supported by all parts.

Updated this post, there was an error in my conclusion, which was removed, sorry in advance.

Has anyone heard-of/experienced security issues with cron and UTF-8 ?

Thanks in advance.