Re: [Security-Discuss] apparent bug in 2006.0 timezone update for Java code

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-48-62730394
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed


On Oct-17-06, at 6:02 PM, Robert M. Riches Jr. wrote:

Sorry I haven't replied to this sooner... it actually got lost in all  
my mail... =(

>>> I'm seeing an apparent bug in the 2006.0 timezone (and glibc)
>>> update that only affects Java code.  The 'date' command shows
>>> the correct time.  C code that uses gettimeofday() and
>>> localtime() gets the correct time.  However, Java code that
>>> uses Calendar.getInstance() is now returning the time in UTC,
>>> while it has always returned the time in the local time zone.
>>> I'm using j2sdk-1.4.2_09-1mdk and j2re-1.4.2_09-1mdk supplied
>>> by Mandriva, in the club commercial area IIRC.
>>>
>>> Any suggestions before I file a bug report?
>>
>> I don't use java here, so I'm not sure.  But maybe Gwenole has an  
>> idea?
>
> Acting on a tip from Aragorn in newsgroup
> alt.os.linux.mandriva, I diffed the changelog entries of the
> packages that in this batch of updates.  Nothing seemed to
> indicate a change in behavior should be expected.

No, there would have been nothing to do that.

> Then, I checked the .rpmnew files I had seen generated
> during the update and found /etc/localtime.rpmnew.  The old
> /etc/localtime file had a modification date of around
> Feb. 17, 2006, which is when I installed Mandriva 2006, so
> it did not appear to have changed in the updates.  Then, I
> noticed the checksum of /etc/localtime differed from the
> checksum of /usr/share/zoneinfo/America/Los_Angeles, which
> is the time zone the system had been set to since
> installation.

Right.  /etc/localtime is in the glibc package, but since it already  
existed, is marked "noreplace", and was not the "stock" /etc/ 
localtime from the package (ie. md5's differed) rpm made the  
package's /etc/localtime as /etc/localtime.rpmnew, meaning it did not  
touch or otherwise replace your locale setting.

> I ran Mandriva Control Center, and changed the timezone to
> .../Lima and back to .../Los_Angeles and saved.  This
> updated the timestampd of /etc/sysconfig/clock but did _NOT_
> change its contents.  It apparently _did_ copy
> /usr/share/zoneinfo/America/Los_Angeles to /etc/localtime
> and restart ntpd.  Now, magically, apparently due to the
> updating of /etc/localtime, the same Java code now returns
> local time.

Why should it change the contents of /etc/sysconfig/clock?  If it was  
originally set to "Los_Angeles", then you changed it, then you  
changed it *back* to "Los_Angeles" and *then* looked at the contents  
of the file well, no... for all intents and purposes it would look  
unchanged.  What would frighten me more is if you changed the  
location in MCC, quit MCC, then looked at the file and noticed it  
hadn't been changed.

And yes, it probably did copy the zoneinfo file; it would have copied  
it when you changed it to "Lima" then copied the other one again but  
I don't think it even changed.  You said yourself the timestamp was  
from when you installed Mandriva, so (logically) nothing touched it.   
All you really did was copy the same file to the same place.  Post-  
and pre- upgrade, the Los_Angeles zoneinfo file contents would have  
been in /etc/localtime.

> Now, the question is whether a bug report should be filed.
> From a user perspective, ideally, updating the timezone
> package should get everything (/etc/localtime) back in sync
> so nothing in the system misbehaves.  It appears perhaps the
> scripts run during an update of this package should look in
> /etc/sysconfig/clock and copy the correct updated file from
> /usr/share/zoneinfo/America/Los_Angeles to /etc/localtime.
>
> Should I file a report or not?

I don't know.  I didn't see this behaviour with any of the upgrades I  
did prior to releasing the update (on every arch and every  
platform).  As for why java, and java alone did this, I'm not sure.   
I would be concerned if after the update, the "date" program was  
showing the wrong information.

Maybe a reset (which is effectively what you did) is what was needed  
for java.  I'm not sure.  From our end, we're not touching /etc/ 
sysconfig/clock, nor are we touching /etc/localtime, so where is the  
breakage?  Logically, one would have to assume java (I can't say for  
100% because I didn't test any java anything here when doing the  
upgrade).

You could file a bug report, but without more information, I'm afraid  
not too much would happen with it.  I don't see anything that the  
glibc package (or rpm installing it), did wrong.


-- 
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}





--Apple-Mail-48-62730394
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFUsnULrxeMv7jCtQRAkZDAJ9khSu/6hTX3e440y+/2cwdTRsnIQCgsZE7
AR2mVNi4+5aqKsJ3GR2++js=
=tXEr
-----END PGP SIGNATURE-----

--Apple-Mail-48-62730394--