[J. Wunsch: hey (fwd)]

[Roland McGrath]

I can think of a third way to combat that problem: make the code that reads
the data files robust, so it checks for invalid data and makes sure it can
never crash due to bogus data.  I just added code to the GNU libc tz
implementation to do this.  It took me about five minutes, and the added
run-time overhead is not much given what's already going on to internalize
the data file.

It is a matter of security policy how you want to restrict the setting of
the TZ variable.  I wouldn't want it restricted at all.  Why shouldn't I
use my own timezone data files?  It's certainly the easiest way to test new
data files before installing them to point TZ at my own data files and run
`date'.

I prefer policies based on content rather than origin.  It is a matter of
local administrative quality whether the installed data files are more or
less likely to contain valid or correct data than ones a user maintains
himself.

If the intent is to avoid crashing programs, robust reading code is
protected against both mistakes and malice, whether installed system-wide
or self-inflicted by the individual user.

If the intent is to administratively restrict the time zones users can ask
for display in, then all you have succeeded in doing is forcing people to
use the cryptic 1003.1 TZ syntax instead of writing their own wonderful
zoneinfo files through the joys of zic.