Page MenuHomePhabricator

Weird block expiry bug
Closed, DuplicatePublic

Description

So we have a glitch/bug that SQL triggered (inadvertantly) when he jokingly went to proceed to block the user Oshwah on enwiki. SQL set the block to expire in 3.14159265359 seconds and it ended up generating a block log entry "SQL (talk | contribs) blocked Oshwah (talk | contribs) with an expiration time of 06:36, 18 January 1975 (autoblock disabled) ‎(I'm sure I'll have to apologize for this later. WHEEEEEE)". Noticing this SQL promptly unblocked and apologized. But it gets wierder as the block message to Oshwah appeared to claim that the block was set to expire on 11:36, 10 May 2021.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 23 2016, 4:06 AM
Ajraddatz triaged this task as Low priority.Apr 23 2016, 4:23 AM
Majora added a subscriber: Majora.Apr 23 2016, 4:23 AM
Cyberpower678 raised the priority of this task from Low to Normal.Apr 23 2016, 4:41 AM

It would seem that putting decimals in the seconds results in erroneous block expiries. <--Yes that's a word now

The block time is parsed using PHP's strtotime() function (see SpecialBlock::parseExpiryInput()). strtotime() is known to be extremely lenient and prone to interpreting very stupid inputs as valid values. Other fun block durations to try include "100000 years" and "a potato" (see T51580).

In this case: strtotime( '3.14159265359 seconds' ); → 1620646599. This happens to be the Unix timestamp for Monday, May 10, 2021, 11:36:39 UTC. I'm not going to even attempt to figure out where this output comes from, but it sure does.

I think this is the expected behavior.

Oops, sorry Cyberpower for removing you as a subscriber ... I was trying
to figure out how to subscribe *myself* and was having great difficulty
due to my screen reader. I finally managed it with Firefox ...

Couldn't we check if something strange is being sent to the function to begin with. If we are setting seconds, we could validate it as an integer for example.

Now that I think about it, further examples might help. Both of these displayed correctly when I did them (2008/2009), but no longer do so.

Firstly, I blocked myself as a test for 2.71828 seconds, which now displays as 02:37 (UTC), 1 January 1970:
https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=block&user=&page=Graham87&year=&month=-1&tagfilter=&subtype=

Then I blocked Giano for what was supposed to be 3.14159 seconds, but apparently appeared as 3 hours, here:
https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=block&user=&page=User%3AGiano+II&year=&month=-1&tagfilter=&subtype=

That block now displays as 03:16, 1 January 1970 (UTC).

Jay8g added a subscriber: Jay8g.Apr 24 2016, 5:07 AM

Couldn't we check if something strange is being sent to the function to begin with. If we are setting seconds, we could validate it as an integer for example.

The function is supposed to check for strange values itself. It does reject some inputs, at least. Trying to second-guess it and writing our own parser doesn't seem very worthwhile to me. It seems that the only situation where this causes problems is joke blocks. ;)

Couldn't we check if something strange is being sent to the function to begin with. If we are setting seconds, we could validate it as an integer for example.

The function is supposed to check for strange values itself. It does reject some inputs, at least. Trying to second-guess it and writing our own parser doesn't seem very worthwhile to me. It seems that the only situation where this causes problems is joke blocks. ;)

I would say for the case of seconds, we need to round that number to an integer. Alternatively we could leave it, as an Easter egg for April Fools.

Ha, I actually figured out what '3.14159265359 seconds' means. It means 3:14 AM today, plus 159265359 seconds. Nothing we could round here.