fix: replace null character when serializing

[SebastianKrupinski]

• Resolves: [Bug]: Error PHP unserialize #47879
• Resolves: [Bug]: Trying to share a calendar in the iOS app breaks it #48914

Summary

Serialize() creates string with null character, this causes issues when saving data in certain databases

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[SebastianKrupinski]

/backport to stable30

[SebastianKrupinski]

/backport to stable29

[SebastianKrupinski]

/backport to stable28

[tcitworld]

While this seems a much simple way of fixing the issue that what I've tried at #39084, what happens when you unserialize the values? Are the objects valid and make sense, since you loose the fact that a property is set to null?

You also need to add a repair step to remove all broken values (see preSchemaChange in file Version1032Date20230630084412.php of my own PR).

[SebastianKrupinski]

While this seems a much simple way of fixing the issue that what I've tried at #39084, what happens when you unserialize the values? Are the objects valid and make sense, since you loose the fact that a property is set to null?

Yes, they properly unserialize to a php object. If you replace the null character with a space. Tested this.

You also need to add a repair step to remove all broken values (see preSchemaChange in file Version1032Date20230630084412.php of my own PR).

yes, a repair step will be needed. I just need to investigate, if we can just do one for Postgres only, MySQL seems to handle null character properly.

[tcitworld]

But the property that was previously null will now be set to a space. Won't that cause any trouble?

[SebastianKrupinski]

But the property that was previously null will now be set to a space. Won't that cause any trouble?

So this is the value that was causing the issue,
O:48:"Sabre\CalDAV\Xml\Property\ScheduleCalendarTransp":1:{s:8:" * value";s:6:"opaque";}

The part to the sting that is the issue is the " * value" the space before and after the * are a null characters, basically this "null*null". The word value is actually a property inside the object. I don't know all the in and outs of serialize but to me it looks like "null*null" is a marker for a private property.

On that note, you might be right if there is a value that is null and serialize converts it to a null character then there might be a issue. But then we are back to square 1, and there is no real way to fix this for postgres. The only other way I can think of, would be to replace the null with the word null and then replace it again on unserialize.

[tcitworld]

But then we are back to square 1, and there is no real way to fix this for postgres. The only other way I can think of, would be to replace the null with the word null and then replace it again on unserialize.

The only way I've thought of is to have the column type accept null terminators, by setting it to BLOB. But data migration is a hassle.

I think your solution might be an easier workaround that we can try until some other serious issue gets reported. It just needs the cleanup step.

[SebastianKrupinski]

I think your solution might be an easier workaround that we can try until some other serious issue gets reported. It just needs the cleanup step.

I agree, done and done, made the repair step actually check if the property is broken, instead of just blindly removing them all.

[SebastianKrupinski]

Done. Made it handle all object properties and run as a expensive repair step.

[ChristophWurst]

Looks sane!

Could you add a test for the unserialization of a legacy object?

[SebastianKrupinski]

Could you add a test for the unserialization of a legacy object?

Done.

Did one for the current double encoding and for the legacy single encoding.