Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I hope you are running an up-to-date Splunk version:

Beginning on September 13, 2020 at 12:26:39 PM Coordinated Universal Time (UTC), un-patched Splunk platform instances will be unable to recognize timestamps from events with dates that are based on Unix time, due to incorrect parsing of timestamp data.

https://docs.splunk.com/Documentation/Splunk/latest/ReleaseN...



I'm always left wondering how something like this could happen. I kind of get Y2K and stuff like overflows ... but this one? Really? Did someone put a regex like /^15... to "match" dates?


Yep, that's exactly what Splunk have done - scroll down the release notes linked to by the grandparent and the faulty regex is shown.

What's super daft is the proposed fix is only a further sticking plaster, adding support for the 16... range (and the 2020s decade) rather than all future dates. So in a couple of years a further patch will be needed...


To fix the fire this is probably the best solution because the risk of unintended side effects is very low. I would just hope it is then followed by a proper fix.


Wow ... I'm ... I'm sure there's a better way to handle this.


> Problem

> Beginning on January 1, 2020, un-patched Splunk platform instances will be unable to recognize timestamps from events where the date contains a two-digit year. This means data that meets this criteria will be indexed with incorrect timestamps.

> Beginning on September 13, 2020 at 12:26:39 PM Coordinated Universal Time (UTC), un-patched Splunk platform instances will be unable to recognize timestamps from events with dates that are based on Unix time, due to incorrect parsing of timestamp data.

> Impact

> ...

> The issue appears when you have configured the input source to automatically determine timestamps, ...

> There is no method to correct the timestamps after the Splunk platform has ingested the data when the problem starts. If you ingest data with an un-patched Splunk platform instance beginning on January 1, 2020, you must patch the instance and re-ingest that data for its timestamps to be correct.

> Cause

> The Splunk platform input processor uses a file called datetime.xml to help the processor correctly determine timestamps based on incoming data. The file uses regular expressions to extract many different types of dates and timestamps from incoming data.

> On un-patched Splunk platform instances, the file supports the extraction of two-digit years of "19", that is, up to December 31, 2019. Beginning on January 1, 2020, these un-patched instances will mistakenly treat incoming data as having an invalid timestamp year, and could either add timestamps using the current year, or misinterpret the date incorrectly and add a timestamp with the misinterpreted date.


And how would such a solution not be immediately thrown out during code review?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: