Slashdot Mirror
Billennium's Over - Anything Break?
An Anonymous Coward writes: "The billennium party at OpenProjects.Net rocked! Check out the log for the whole event over here. Please don't forget to use one of the mirrors. Thanks :-)" Well, anyone have anything break due to the rollover?
I use a thingy that portions my web logfiles into daily files, each prepended with the current unix timestamp. I found that scripts I run to do stuff with the most recent day's logfile broke because 1000000000access_log.gz comes before 999999999access_log.gz.
The simple solution is to move the old 999 files to another directory. This problem wouldn't have cropped up since 1973 when it passed eight 9s, and won't happen again for another 300 years when it passes ten 9s.
Still, a bug's a bug, and that's one more than I had in the new millenium.
Kevin Fox
I stored the date as a 9 character string in the MySQL table. Oops.
I increased it to 10 chars but now it doesn't sort it correctly. Ooops.
I had the expire date on the cookies set to "999999999". Ooops.
I'm sure loads more will pop up.
The Y2k+1 "bug" really got me.
Apparently there is a bug in older version of KMail from KDE 1.x that prevents KMail from correctly displaying the current date since billenium. More information about KMail billenium bug is on www.kde.org.
This was sent out to the freebsd mailing lists by John Polstra:
This morning a bug was discovered in most versions of CVSup up to and including SNAP_16_1c. The bug causes all newly-updated files to receive incorrect timestamps. Usually the files receive timestamps from early in 1970. This bug has been present for a very long time,
but it only began to have an effect when the Unix representation of the date and time passed 1,000,000,000. That occurred on 9 September
2001 at 01:46:40 UTC. Yes, other people had Y2K bugs, but I managed to produce an S1G bug.
There was more, but that was the jist.
From my understanding the major problem doesn't occur till 2038 when 32-bit time reaches 2,147,483,647 seconds. 2,147,483,647 is the biggest number a 32-bit system can register.
Now that you mention it one of my hard drives completely stopped working. At first I thought it was because i had it sitting on my floor and I stepped on it. I didn't even realize that it was probably from the whole 1 billion thing. Man, what was I thinking?
knode (0.4)
The kde news reader now orders incoming messages false. All new messages after the billenium are ordered older than the ones from before.
--
Karma 50, and all I got was this lousy T-Shirt.
OpenLDAP has massive breakage both in the 1.2 and 2.x series with the S2G Unix time rollover.
The slurpd server completely fails to push updates from the master server to the slaves, due to string compares of timestamps in 1.2 and a related problem in 2.x. There are patches for both in OpenLDAP CVS.
The problem is detailed in the openldap-bugs mailing list -- it was extremely scary to come to work this morning and find out that all the LDAP servers had stopped pushing updates, causing account creations to fail and mail to bounce!
The fact that Perl has vague distinctions between strings and numbers has very little to do with the situation at hand. The problem with the billennium bug is that there's a risk that programmers did not allocate enough digits to hold a date correctly; since both Perl and Python reallocate memory to handle larger values internally, your Python will succeed or fail in an equal number of situations as Perl. It's not an issue of the actual program language, the issue is how the date is persistently stored when the program ends (a database, columnar text file, or whatever).
You're not flamebait because you're a Python bigot, you're flamebait because your post is an invalid rant and off-topic.
I/O Error G-17: Aborting Installation
It's the GOD DAMN APOCOLYPSE Outside! Dont any of you guys ever even open a Window!? sheesh... after all those rants about how the military should switch to linux, the world ended yesterday.
Well anyway, I declare myself God until further notice.
-- 'The' Lord and Master Bitman On High, Master Of All
This morning a bug was discovered in most versions of CVSup up to
and including SNAP_16_1c. The bug causes all newly-updated files to
receive incorrect timestamps. Usually the files receive timestamps
from early in 1970. This bug has been present for a very long time,
but it only began to have an effect when the Unix representation of
the date and time passed 1,000,000,000. That occurred on 9 September
2001 at 01:46:40 UTC. Yes, other people had Y2K bugs, but I managed
to produce an S1G bug.
I have fixed the bug and have released a new snapshot of CVSup,
SNAP_16_1d. I have also created binary packages for FreeBSD-4.x which
can be installed using "pkg_add". For information about updating your
CVSup installation, look here:
http://people.freebsd.org/~jdp/s1g/
To fix the bug, both the client and the server need to be upgraded to
SNAP_16_1d. The FreeBSD mirror site maintainers have been working
feverishly to upgrade their installations. Many of them are already
upgraded, and the rest will be upgraded soon. Meanwhile, all CVSup
users should upgrade their CVSup installations.
I apologize for the inconvenience caused by this bug, and thank you
in advance for your patience.
John Polstra
-- unix is for people without a social life - Patrick van Eijk
I would like to make your attention on bug which was introduced tonight and can affect some people who are using (var)char field to store timestamp data.
It is not worst security bug. It affects only people who already had bug in their code. Just now this bug become visible/exploitable.
This is not MySQL bug. This is how people use their database. Also similar situation can be found in other software. I would like to inform people in public list as maybe some people have to search similar problems.
The problem: Computers store time and date usually as integer value representing amount of seconds from 1 January 1970. Tonight it overrolled from 999999999 to 1000000000.
Possible bug and exploit relies on fact that some people have used character type of field to store this seconds information (we have already such case)
example:
mysql> create table session (expire varchar(100) not null);
Query OK, 0 rows affected (0.31 sec)
mysql> insert into session values (999999997), (999999998), (999999999),
(1000000000), (1000000001);
Query OK, 5 rows affected (0.00 sec)
Records: 5 Duplicates: 0 Warnings: 0
mysql>
mysql> select * from session;
+------------+
| expire |
+------------+
| 999999997 |
| 999999998 |
| 999999999 |
| 1000000000 |
| 1000000001 |
+------------+
5 rows in set (0.00 sec)
mysql>
Let's assume that this table contains values we use somewhere to authenticate users. After user logs in, we write down session expiry time and later we check it like this:
mysql> select count(*) from session where expire >= '1000032535';
+----------+
| count(*) |
+----------+
| 3 |
+----------+
1 row in set (0.00 sec)
mysql>
WOW, what happened? Shouldn't be 100003253 bigger than any value in table? It worked yesterday!
In MySQL we suggested people to use quotation marks around integer values. This can avoid many web-based attacks targeted to modify SQL commands (more information on http://www.mysql.com/doc/G/e/General_security.html ). This is the reason why people put quotation marks around integer expressions and this is correct. Also automatic type casting will fix the source problem is column data is integer or some time/date vale. But when both column is character type and expression, they get compared as strings. And as we know, strings get sorted in order:
1,11,2,22
but integers:
1.2.11.22
So, this is why 100003253
It is possible that some web applicatons have endless expiry times now and not only in MySQL contexts.
(Shamelesly ripped from ntk.net).
Actually, I think most of the posts I've read so far indicate not a problem in storage allocation, but instead a problem in sorting -- IE, they used a string sort rather than numeric.
your Python will succeed or fail in an equal number of situations as Perl
Sorry, I disagree. I'm neither a Python nor Perl biggot (don't have much time to devote to either), but the point made in the parent post was that in a strongly typed language like Python, programmers are prevented from using the wrong form of comparison. Yes, Perl has different comparison methods for numeric and string and yes, the programmer has nobody to blame but themselves if they make such a mistake, but having the language do a bit of idiot-proofing will ultimately yield fewer bugs. So no, I don't think there will be an equal number of failures in Python.
Note that I don't think this makes Python "better" or Perl "worse." It's just a feature that needs to be considered when choosing a language for a project.
GreyPoopon
--
Why is it I can write insightful comments but can't come up with a clever signature?
We use an older version of UW IMAP ad UW Pine both patched to use Maildir support (because they are too short-sighted to integrate such support themselves).
After the roll-over both programs started mis-sorting newly arrived messages to the top of the folder, rather than the bottom (but newly arrived messages are still sorted below older, within each category of 'before' and 'after' the 1 billion second point). Also getting 'mailbox changed unexpectedly, reloading' messages constantly.