Auto backup restore hash not matching though it should

[grandrivers]

SHA256 values do not match, cannot restore.
d8fd4328f5fbea6cdd98a0311c3949be29830837f60b34e5ebeab33f66384831 <> d8fd4328f5fbea6cdd98a0311c3949be29830837f60b34e5ebeab33f66384831

[grandrivers]

it decrypts can see it decrypted but cant install

[randybarth]

ditto that. My workaround was to show info on the backup and copy the decrypted config file and put into a text file on my local machine. Then restore using Backup/Restore.

[grandrivers]

yeah mine too but i did pay for this feature

[phil.davis]

I just tried by doing a "Backup now" (which successfully made an entry in the list of backups) and then trying to restore. I get the "are you sure" prompt, then it works for a few seconds and gives:

The following input errors were detected:

    SHA256 values do not match, cannot restore. 4dac85ab31e9f466c1063bf8935a71a6224e2f79deb9afd7e4d7338b5ffa30e4 <> 4dac85ab31e9f466c1063bf8935a71a6224e2f79deb9afd7e4d7338b5ffa30e4

I wonder how long it has been like this?
I guess this will be related to the PHP floating point number comparison debacle for big numbers, in this case big string that are valid hexadecimal. Now I will go find that again in PHP land and see if my guess is right.

Edit1: I found that PHP big number comparison here: https://bugs.php.net/bug.php?id=54547
But that manifests itself as 2 big and unequal numbers being reported as equal.
This problem is a bit different, 2 apparently equal hex strings test as unequal.
It's going to be some type conversion thing, 1 of the 2 vars getting interpreted as a number, maybe.

Edit2: I modified the error message to display the types of the vars, PHP thinks they are both strings, and they look the same to me!

The following input errors were detected:

    SHA256 values do not match, cannot restore. 4dac85ab31e9f466c1063bf8935a71a6224e2f79deb9afd7e4d7338b5ffa30e4 <> 4dac85ab31e9f466c1063bf8935a71a6224e2f79deb9afd7e4d7338b5ffa30e4 string string

Edit 3: $ondisksha256 is 64 chars long, $sha256 is 65 chars long. There is a null or other non-displaying char in there somewhere:

The following input errors were detected:

    SHA256 values do not match, cannot restore. 4dac85ab31e9f466c1063bf8935a71a6224e2f79deb9afd7e4d7338b5ffa30e4 string 64 <> 4dac85ab31e9f466c1063bf8935a71a6224e2f79deb9afd7e4d7338b5ffa30e4 string 65

Edit 4: The 65-char string has an ASCII 10 (line feed) at the beginning, this one happens to end with an ASCII 52, which is the char "4" (correct and good):

The following input errors were detected:

    SHA256 values do not match, cannot restore. 4dac85ab31e9f466c1063bf8935a71a6224e2f79deb9afd7e4d7338b5ffa30e4 string 64 <> 4dac85ab31e9f466c1063bf8935a71a6224e2f79deb9afd7e4d7338b5ffa30e4 string 65 10 52

Enough! That data comes back from a curl_exec() call to the AutoConfigBackup server at "https://portal.pfsense.org/pfSconfigbackups/restore.php" Time to submit a bug and let the ESF guys fix it.

[phil.davis]

RedMine bug filed: https://redmine.pfsense.org/issues/3598

[cmb]

Thanks for the analysis, much appreciated. I made some (what I thought were) minor changes server-side yesterday or the day before (I've slept 3 hours since Monday morning between release engineering and support, have lost all concept of time) while awaiting 2.1.2 builds and I broke something apparently. I can't make heads or tails of it at this point, need sleep, I'll fix in the morning if someone else doesn't beat me to it.

Sorry for the trouble. The work around noted above will allow you to retrieve your backups in the mean time if you need them immediately.

[cmb]

A phantom new line has showed up for some reason out of nowhere, unrelated to anything that's changed recently. We're still looking for the source of it, but in the mean time, a new package v1.23 is out there that fixes the issue. If it's something we can fix only server-side, we will, for now if you upgrade the package it'll work.