https://bugzilla.wikimedia.org/show_bug.cgi?id=68565

            Bug ID: 68565
           Summary: SnakUnserializer must not fail on mismatching hashes
           Product: MediaWiki extensions
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: Unprioritized
         Component: WikidataRepo
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]
       Web browser: ---
   Mobile Platform: ---

SnakUnserializer will check the hash of the unserialized snak against the snak
field in the serialization, and fails if they are not equal. The fail-fast
approach is counter to the need to be able to read old or seemingly corrupt
data.

There are two critical cases:

1) the value type used in the snak is not configured on the local system. The
value would then unserialize into a UnDeserializableValue object, which would
round-trip cleanly - but with the hash check, the unserialization is aborted.

2) the structure of the snak or value class changes a bit (e.g. we decide to
add a field, or apply additional normalization). Even if the unserialization is
backward compatible, we would still fail because the hash is now different.

Number (2) is especially bad because getHash() is implemented as sha1(
serialize( $this ) ). This uses php's internal serialization, not
SnakObject::serialize - so it would change even if we just re-arrange the
members in a class, or rename a private field. If we change this to sha1(
serialize( $this->serialize() ) ), we would have more control, but could still
never add or re-arrange fields.

So, in order to be able to read legacy data, SnakUnserializer must not be picky
about the hash. Perhaps an SerializationErrorMonitor of some sort could be
injected to decide whether to ignore the problem, log it, or throw an
exception, depending on the needs of the respective use case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to