If your apps or gadgets break down on Sunday, this may be why: Gpsd bug to roll back clocks to 2002 Come Sunday, October 24, 2021, those using applications that rely on gpsd for handling time data may find that they're living 1,024 weeks – 19.6 years – in the past. A bug in gpsd that rolls clocks back to March, 2002, is set to strike this coming weekend. The programming blunder was identified on July 24, 2021, and the …
Multiple companies get caught out, ringing up hundreds of millions or billions of losses (or, god forbid, human lives - it's in tanks and rockets, FFS, as well as trucks). The more litigious sue Miller. A defence fund is set up, but Miller doesn't have the time to focus on the code while coping with the case, and doesn't want the future grief so (entirely understandably) quits.
For a while, nobody wants to hold the hot potato.
Eventually, one or more big companies (*cough* Google *cough*) put their hands in their pockets to pay for development without so much as a thank you to Miller. Code development resumes. While the legal cases rumble away for decades, the stress exasperating any age-related heath conditions.
The moral? Stick to sudoku.
You forgot the part where Google stops accepting outside contributions to the source, and makes it a byzantine service that only runs on specific hardware using obscure Google-specific network packages. All the while adding privacy-invading antifeatures to the official builds that force you to try to recompile it yourself, but while you're busy fighting the Google build system they're busy making those antifeatures part of the NTP standard.
In parallel, Google starts flogging Time-As-A-Service, only to abandon it several years later.
Cynical? Moi?
I fear you are just too much on the money with that Google prediction, but all of these "Nebraska Problems" (waves at OpenSSL) underpin so much of modern computer systems and the internet.
Open source and volunteer effort is a great development model that has pulled us all up by our bootstraps to where we are today, but when (effectively) the whole world is now entirely relying on these libraries to be robust and bug-free (well, as bug-free as possible), is it really not time to effectively mandate something like a 0.1% tax/tithe on software/hardware busineses to give solid permanent financial backing to these essential systems that they all rely on and to ensure some paid development and testing/QA help so that these are not all entirely dependent on volunteer labour?
(I picked 0.1% of out thin air: maybe it wouldn't be enough, maybe it would be way, way, more than enough, based on the size of some of the huge companies who would be liable to pay it, but in the overall scheme of things, it's surely a small enough percentage that no company that would be liable to pay it could really argue that it was particularly burdensome? It is after all through mutual co-operation that most of humanity's great developments have been made…)
as far as I know it only affects 32-bit systems that still have time_t defined as a 32-bit integer. There are certain backwards compatibility issues in 32-btt Linux, though, and there are time functions (as I recall) that support a 64-bit time_t on 32-bit. But legacy applications could still fall on their faces if they rely on time_t not rolling over.
FreeBSD's headers defines time_t as 64bit when the pointer size is 64bit. I do not have a convenient 32-bit linux handy but in a 64-bit version it is also a 64-bit value for time_t. As far as I recall 32-bit Linux is also a 32-bit value for time_t.
still embedded may need 32-bit in 2038 so probably best to change it to ALWAYS 64-bit at some point.
No? Well, he's the guy that maintained the UNIX timezone database.
All by himself.
Then one day he announced he was retiring, and people realized he was doing this huge important task all by himself, and finally got him some help.
But most GNSS manufacturers just ignore gpsd. Even when we find bugs in their stuff.
I'd bet that would change if there was a periodic name-'em-and-shame-'em errata list published.
Many of the comments here are spot on, but let me throw in a few more:
o It is estimated that .6% of the "PC" base still runs Windows XP, and it is estimated that in one country 60% of their desktop computers runs XP.
o a friend of mine that works for one of those agencies we dare not talk about confirmed that many of the systems we do not want to think about are still running XP.
I mention this not to pick on Microsoft...but if this issue was found to be in XP, how the heck do you fix it?
o What if your closed-source software was written by DEC/SGI/Sun?
Years ago I was involved with a large project to rewrite all the code running on some ancient IBM mainframes at a little facility called the Houston Space Center, in charge of the Shuttle flights. The reason this project was important was that not only had the programmers that wrote the code retired, many of them were dying.
It is relatively easy to bring people back from retirement.
Slide rules typically did not need bug fixes.
This issue is not limited to the FOSS community by a long shot, and actually is easier to correct in FOSS than in closed systems.
Is it safe to assume the issue was NOT related to lack of support for the hardware and operating system? IBM mainframes pretty much continue to run (successfully) applications written 50 years ago.
The issue is nobody teaches COBOL anymore, and there are 'better' languages and 'cheaper' hardware... so it comes down to a financial rather than a technical issue.
Yeah?
Can someone please clarify what the article doesn't... is this a rollover only bug or a permanent one?
By which I mean: if a clock using this code is affected, can you simply reset / force a re-read of the GPS time signal and all will be well again; or will all reads fail continually?
I infer that "turning it off and on again" is not a fix.
Apparently it's slightly like defining a count of weeks since week zero as a 9 bits number instead of 10 bits, so week 512 is read as week 0, week 513 is read as week 1, and so on. It was meant to run up to week 1023, and it will.
The software needs to be updated from time to time anyway, to redefine which week numbers relate to a recent past "week 0" - let's say W > 500 relates to the actual last week 0, and 0 <= W <= 500 is counting from the NEXT week 0.
Anything that I've just said may be wrong.
..but the system still works.
The system is running Windows 10 and a number of Tuesdays ago it stopped automatically updating the time on startup. Now every time you boot it you've got to manually tell NTP to sync the clock. It hasn't caused the system to stop although in this day and age with everything certified against everything else it might, I just haven't found anything yet. (Its obviously a sequencing bug, their NTP is running and timing out before the network is ready to respond)(their fault -- wired network and anyway Linux works just fine, always has worked and probably always will work.)
The point is, this bug is inconvenient, its been patched but if it causes a problem its going to be really obvious and will spur someone to upgrade or fix it. Nothing to get worked up about......
This issue only affects installations that have their own, private GPS receiver wot they bought special to do the time thing.
And it affects the whole installation, because it's in the way the GPS receiver is being read.
It follows that you'd only spend that money if accurate time is quite important for what you're doing!
Time on a desktop is usually immaterial, except for stupid emails appearing in the past/future because of when your email client though you sent it.
Time for many other systems is critical, if you have to keep backup software in sync, check for main-in-the-middle attempts based on suspicious network delays, have mobile masts syncing transmissions so they don't interfere with each other too much, align some bit of hardware with something "out there", etc, etc, etc.
This post has been deleted by its author
Digital signatures, at least here in Spain, usually include a timestamp (generated using a GPS based time). This timestamp could be used in court to demonstrate that you signed X before time Y, which clearly opens up all sorts of legal problems if the timestamp is not correct.
We really need to start treating critical software infrastructure like we do for things like transportation and fuel, food supply chains, medical supply chains, etc.
As an emergency preparedness and response professional with an IT background, it is woefully inadequate and quite potentially a major hazard that libraries and small infrastructure projects like this hinge on a developer or developers who are volunteering their time and effort with no continuity planning, funding, time or means to respond to a bug or vulnerability because nobody wants to do it. Not everyone has a Google, IBM-hat, HPE/HPI, or Microsoft in their corner giving them time to do this utterly thankless, time consuming, but absolutely critical work to make sure that things will work further up the stack.
It's not flashy, on a resume most employers will give it a glance and even if they know what it is this person does and just how important it is, it rates a little above "that's nice" unless they're "concerned it may impact your productivity". It's a damned shame and I wonder how much chaos, insanity and murder is going to have to occur to get people and business to actually give a shit.
"We really need to start treating critical software infrastructure like we do for things like transportation and fuel, food supply chains, medical supply chains, etc."
I don't know what it's like in Europe but here in the US, especially in the older parts of the country (Northeast) the "so called" critical infrastructure has been neglected for decades if not for over a century!
Very little money and effort is put into maintaining and modernizing water and sewer systems because for they most part they "just work"! When they fail they fail massively! Like Flint Michigan polluting the drinking water with massive amounts of lead from lead pipes. Like NYC having massive sewer failures when the remnants of a hurricane passed over the city costing millions of dollars and many lives.
(Buy as we saw, no one takes responsibility, they can just blame Climate Change!)
First it was Y2K, then 24/10/2021.
Is it just me or is there a non-zero chance "Fail Deadly" systems could on this day wrongly conclude something terrible has happened?
Either way I may well dig out the Geiger counter(s) and tinned food just in case bad things happen.
Protip: quite a lot of tinned food notably kidney beans is NOT SAFE to eat cold even when in date, never do this.
Also useful: somewhere on dead tree edition I have the "idiots guide to metallurgy, crop rotation, and other such useful skills".
I thought that canned kidney beans had been cooked (and the toxin destroyed) as part of the canning process. This is also based on experience, as I have eaten canned kidney beans which were just re-heated, whereas dried beans must be cooked for >1hr to be edible. I couldn't get the link above to work, but was it referring to dried or canned beans?
Asda tinned red kidney beans, online, says "Check product is piping hot before serving." But they basically always say that. NHS says on the following link that tinned beans are already safely cooked. It says if not, DO NOT SLOW COOK.
https://www.nhs.uk/live-well/eat-well/beans-and-pulses-nutrition/
There are a few thousand of these projects - not too many for a public database. How about one of the big FOSS groups maintaining a list of critical projects, their maintainers etc. OASIS / EFF / FSF etc or even a new group (El Reg ...). Then it would be possible to organise financial support or extra humans to help on a more rational basis. Such database would have to avoid pointing rogue states or other actors wishing to cause chaos at a list of humans to delete.
Bomb#20: In the beginning, there was darkness. And the darkness was without form, and void.
Boiler: What the hell is he talking about?
Bomb#20: And in addition to the darkness there was also me. And I moved upon the face of the darkness. And I saw that I was alone. Let there be light.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
