Differences

This shows you the differences between two versions of the page.

--- rfc:not_serializable [2023/11/26 15:39] – created maxsem
+++ rfc:not_serializable [2023/12/10 12:31] (current) – maxsem
@@ Line 1: / Line 1: @@
 ====== PHP RFC: #[NotSerializable] ======
   * Version: 1.0
-  * Date: 20123-11-26
+  * Date: 2023-11-26
   * Author: Max Semenik, maxsem.wiki@gmail.com
-  * Status: Draft
+  * Status: Under discussion
   * First Published at: http://wiki.php.net/rfc/not_serializable
 ===== Introduction =====
-The elevator pitch for the RFC. The first paragraph of this section will be slightly larger to give it emphasis; please write a good introduction.
+Some classes aren't supposed to be serialized. Currently, while PHP internal classes have a nice way of preventing being serialized/unserialized, userspace doesn't. I'm proposing to make them equal.
+Compare the internals simply slapping ''ce_flags |= ZEND_ACC_NOT_SERIALIZABLE'' to userspace having to do something like this:
+<code php>
+class MyClass
+{
+    public function __sleep() // Wait, what its signature is supposed to be? Does it matter?
+    {
+        throw new Exception('This class must not be serialized');
+    }
+    public function __wakeup()
+    {
+        throw new Exception('This class must not be unserialized');
+    }
+}
+</code>
+Not only is this method bulky, it's also less readable. It also lacks a way to indicate the intention to various code analysers so that they could detect attempts to serialize such classes.
+===== Analysis =====
+As of the time I'm writing this, there are 94 uses of ''@not-serializable'' in php-src. Examples include:
+  * Closures
+  * Various connections like ''PDO'', etc.
+  * Reflection
+What could userspace use this for?
+  * Wrappers for all the above. Imagine a PDO wrapper that creates connections on demand. If the connection hasn't been established yet, its serialization will succeed, which results in unpredictable behavior.
+  * Secret information that shouldn't be accidentally exfiltrated by being serialized.
+  * Security-sensitive classes that are unsafe to unserialize with arbitrary data ([[https://github.com/wikimedia/mediawiki-libs-ScopedCallback/blob/master/src/ScopedCallback.php|example in the wild]]).
 ===== Proposal =====
-All the features and examples of the proposal.
+Introduce a new attribute that would expose this functionality to userspace.
-To [[http://news.php.net/php.internals/66051|paraphrase Zeev Suraski]], explain hows the proposal brings substantial value to be considered
+<code php>
-for inclusion in one of the world's most popular programming languages.
+#[NotSerializable]
+class MyClass
+{
+}
-Remember that the RFC contents should be easily reusable in the PHP Documentation.
+serialize(new MyClass()); // Exception: Serialization of 'MyClass' is not allowed
+</code>
-If applicable, you may wish to use the language specification as a reference.
+The non-serializable flag is inherited by descendants:
-===== Backward Incompatible Changes =====
+<code php>
-What breaks, and what is the justification for it?
+class MyOtherClass extends MyClass
+{
+}
-===== Proposed PHP Version(s) =====
+serialize(new MyOtherClass()); // Exception: Serialization of 'MyOtherClass' is not allowed
-List the proposed PHP versions that the feature will be included in.  Use relative versions such as "next PHP 8.x" or "next PHP 8.x.y".
+</code>
-===== RFC Impact =====
+The above requires no changes to the engine whatsoever, all functionality is already present - it merely gets exposed to userspace.
-==== To SAPIs ====
-Describe the impact to CLI, Development web server, embedded PHP etc.
-==== To Existing Extensions ====
+This feature will be exposed to reflection by the following additions to ReflectionClass:
-Will existing extensions be affected?
-==== To Opcache ====
+<code php>
-It is necessary to develop RFC's with opcache in mind, since opcache is a core extension distributed with PHP.
+public const int IS_NOT_SERIALIZABLE = ZEND_ACC_NOT_SERIALIZABLE;
-Please explain how you have verified your RFC's compatibility with opcache.
+public function isSerializable(): bool {}
+</code>
-==== New Constants ====
+===== Backward Incompatible Changes =====
-Describe any new constants so they can be accurately and comprehensively explained in the PHP documentation.
+The only breaking change is the addition of a new non-namespaced class.
-==== php.ini Defaults ====
+===== Proposed PHP Version(s) =====
-If there are any php.ini settings then list:
+.4.
-  * hardcoded default values
-  * php.ini-development values
-  * php.ini-production values
 ===== Open Issues =====
 Make sure there are no open issues when the vote starts!
-===== Unaffected PHP Functionality =====
-List existing areas/features of PHP that will not be changed by the RFC.
-This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.
-===== Future Scope =====
-This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC.
 ===== Proposed Voting Choices =====
-Include these so readers know where you are heading and can discuss the proposed voting options.
+Implement this RFC? (Yes/no, 2/3 approval required.)
 ===== Patches and Tests =====
-Links to any external patches and tests go here.
+ * Proposed PR: https://github.com/php/php-src/pull/12788
-If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.
-Make it clear if the patch is intended to be the final patch, or is just a prototype.
-For changes affecting the core language, you should also provide a patch for the language specification.
 ===== Implementation =====
@@ Line 76: / Line 93: @@
   - a link to the language specification section (if any)
-===== References =====
-Links to external references, discussions or RFCs
 ===== Rejected Features =====
 Keep this updated with features that were discussed on the mail lists.

Differences

Page Tools