Change Details

NOTE: Final call for comments until May 10! If no new concerns are raised by then, the proposed guideline will be approved. ### Problem statement PHP `unserialize()` and `serialize()` can execute code when given malicious input. In most cases this serialization format is unnecessary. As a hardening measure against making a mistake that could result in remote code execution, we should avoid this format. ### Proposed guideline This RFC proposes the following: * New code SHOULD use JSON instead of PHP serialization whenever possible. * Serialization of primitive values and key-value structures MUST never use PHP serialization. * Any edge cases that require use of serialize or unserialize complicated classes, MUST protect the serialized blob with HMAC (e.g. keyed to `$wgSecretKey`) to protect against malicious modifications of the blob. In addition to the new guideline for new code, this RFC proposes that we start to (slowly) convert existing uses of PHP serialization. Most likely by using JSON. The eventual goal being to remove all legacy uses of php `unserialize()` Good first candidates for conversion: * LocalisationCache * MediaHandler metadata. The php serialization output format of the API is outside of the scope of this RFC, since we never ingest it.

### Problem statement PHP `unserialize()` and `serialize()` can execute code when given malicious input. In most cases this serialization format is unnecessary. As a hardening measure against making a mistake that could result in remote code execution, we should avoid this format. ### Proposed guideline This RFC proposes the following: * New code SHOULD use JSON instead of PHP serialization whenever possible. * Serialization of primitive values and key-value structures MUST never use PHP serialization. * Any edge cases that require use of serialize or unserialize complicated classes, MUST protect the serialized blob with HMAC (e.g. keyed to `$wgSecretKey`) to protect against malicious modifications of the blob. In addition to the new guideline for new code, this RFC proposes that we start to (slowly) convert existing uses of PHP serialization. Most likely by using JSON. The eventual goal being to remove all legacy uses of php `unserialize()` Good first candidates for conversion: * LocalisationCache * MediaHandler metadata. The php serialization output format of the API is outside of the scope of this RFC, since we never ingest it.

NOTE: Final call for comments until May 10! If no new concerns are raised by then, the proposed guideline will be approved. ### Problem statement PHP `unserialize()` and `serialize()` can execute code when given malicious input. In most cases this serialization format is unnecessary. As a hardening measure against making a mistake that could result in remote code execution, we should avoid this format. ### Proposed guideline This RFC proposes the following: * New code SHOULD use JSON instead of PHP serialization whenever possible. * Serialization of primitive values and key-value structures MUST never use PHP serialization. * Any edge cases that require use of serialize or unserialize complicated classes, MUST protect the serialized blob with HMAC (e.g. keyed to `$wgSecretKey`) to protect against malicious modifications of the blob. In addition to the new guideline for new code, this RFC proposes that we start to (slowly) convert existing uses of PHP serialization. Most likely by using JSON. The eventual goal being to remove all legacy uses of php `unserialize()` Good first candidates for conversion: * LocalisationCache * MediaHandler metadata. The php serialization output format of the API is outside of the scope of this RFC, since we never ingest it.