"Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> writes:
If the TZ environment variable needs to be checked for mischief-making time zone abbreviations, the same check needs to be applied to values derived from time zone files
Yes, quite right. Presumably the same check should be applied to each. Another issue is, what check would be reasonable? The simplest check is to restrict the abbreviation to what POSIX requires, namely, N bytes (where 3 <= N <= TZNAME_MAX) that contain only ASCII letters, digits, "-", or "+". A reasonable value for TZNAME_MAX might be 255, assuming the implementation doesn't specify it. One way we can be more generous is to lower the "3" to "2" (or "1") in the above-mentioned check. I doubt whether it's reasonable to lower it to zero. This would be easy. If we want to allow other characters in the zone name, it will be a hassle, but one possibility is to relax the character-set restrictions, as follows: * Every character in the abbreviation must be alphanumeric in the current locale (as specified by LC_CTYPE). * The following checks are relevent for locales with multibyte encodings: - The abbreviation cannot have invalid byte sequences. - The abbreviation must end in the initial shift state. A problem with this more-generous approach is that the locale might change just before localtime() is called; presumably this would require revalidating the zone.