Hi
On 7/5/22 16:30, Tim Düsterhus, WoltLab GmbH wrote:
"Make the iterator_*() family accept all iterables" [1]
[…]
[1] https://wiki.php.net/rfc/iterator_xyz_accept_array
Both votes in the RFC were accepted 17:2 (89%), albeit with some voters
only participating in one of
Hi
I just opened the vote on:
"Make the iterator_*() family accept all iterables" [1]
The RFC contains two votes, each of which requires a 2/3 majority.
Voting will run 2 weeks until:
2022-07-19 at 14:45 UTC
Please find the below resources for your reference:
RFC:
Hi
On 6/21/22 16:27, Tim Düsterhus, WoltLab GmbH wrote:
https://wiki.php.net/rfc/iterator_xyz_accept_array
which I am officially opening up for discussion, just in time for PHP 8.2.
Voting will start in 2 weeks on 2022-07-05. Voting will end in 4 weeks
on 2022-07-19.
Tomorrow is the 5th
Hi Internals
as at least one participant in the previous thread [1] voiced the need
for an RFC, I've written up an RFC:
https://wiki.php.net/rfc/iterator_xyz_accept_array
which I am officially opening up for discussion, just in time for PHP 8.2.
Voting will start in 2 weeks on 2022-07-05.
Hi Internals!
On 2/24/22 15:11, Tim Düsterhus, WoltLab GmbH wrote:
Please find the thread in the GitHub PR at:
https://github.com/php/php-src/pull/7921#discussion_r813743903
[…]
1. Disallow both serialization and unserialization.
This will make the serialization issue very obvious
Hi Guilliam,
On 2/25/22 13:11, Guilliam Xavier wrote:
I would prefer option 2 (if possible), to avoid potentially breaking
existing code.
Sure, that's possible. Otherwise I wouldn't have proposed it :-)
The solution for this is simply an additional private property
$isPoisoned that is set
Hi Internals!
during code review of the "Redacting parameters in back traces" RFC [1]
an issue with the proposed serialization behavior of
SensitiveParameterValue objects became apparent that was not noticed
before the RFC went into voting:
The RFC proposed that serialization was allowed,
Hi Tyson
On 2/13/22 16:50, tyson andre wrote:
Currently, there doesn't seem to be an exact fit for indicating that a method
isn't supported on an object by design (and will throw unconditionally).
(For example, when implementing an interface or overriding a base class, e.g.
an Immutable
Hi Internals!
On 2/22/22 13:25, Tim Düsterhus, WoltLab GmbH wrote:
As a reminder: Voting for the "Redacting parameters in back traces" RFC
closes in a little more than 25 hours.
I just closed the vote. The "Redacting parameters in back traces" RFC
http
Hi Internals!
On 2/9/22 14:02, Tim Düsterhus, WoltLab GmbH wrote:
"Redacting parameters in back traces" [2]
[…]
2022-02-23 at 13:30 UTC
[…]
[2] https://wiki.php.net/rfc/redact_parameters_in_back_traces
I'm not sure if a vote-closing reminder is required by the process, some
R
Hi Internals!
As I've announced on Monday [1] I've just started the vote on my RFC
"Redacting parameters in back traces" [2]
Voting will be for the concept, but a proof of concept implementation
exists.
The RFC will require a 2/3 majority. Voting will run 2 weeks until:
2022-02-23 at 13:30
Hi Dan
On 2/7/22 17:36, Dan Ackroyd wrote:
So basically all the other languages I researched do not provide
arguments within back traces.
Uh, that kind of suggests that providing arguments at all is a
mistake, and that removing could be the way to go. I mean other than
everyone complaining
Hi Internals!
On 1/31/22 10:54, Tim Düsterhus, WoltLab GmbH wrote:
I plan to open voting on Wednesday, February, 2nd. Voting will run 2
weeks, 2/3 majority with the concept being voted on as explained in the
"Proposed Voting Choice" section:
https://wiki.p
Hi Alex
On 2/1/22 07:38, Alexandru Pătrănescu wrote:
I think storing the original value within the replacement value should be
considered and voted in this RFC as well, even if implemented in a separate
PR.
I did write some code where I process programmatically the backtraces and
while I might
Hi Alex
On 2/1/22 07:38, Alexandru Pătrănescu wrote:
I think storing the original value within the replacement value should be
considered and voted in this RFC as well, even if implemented in a separate
PR.
I did write some code where I process programmatically the backtraces and
while I might
Hi Internals!
On 1/10/22 15:05, Tim Düsterhus, WoltLab GmbH wrote:
https://wiki.php.net/rfc/redact_parameters_in_back_traces
At the end of last week I've updated the RFC a little based on the
questions Derick Rethan asked me for episode #97 of PHP Internals News
podcast:
https
Hi Benjamin
On 1/15/22 7:07 PM, Benjamin Eberlei wrote:
I believe it wouldn't hurt the RFC to add more words around the fact that
stacktraces are often sent to third party services (Exception Tracking
software) and as such a redaction of the parameters would be powerful for
additional redaction
Hi Lynn
On 1/12/22 9:30 AM, Lynn wrote:
I was thinking more of a "keep track of the values replaced, and in the
end purge all those values from the end-result" kinda thing.
Thank you for the clarification. This still is not in scope, because I
believe that to be harmful, as the parameter
Hi Lynn
On 1/11/22 11:23 AM, Lynn wrote:
One possible addition; would it be possible to analyze the masked values
and mask any 100% matches elsewhere?
No, this is not in scope for this RFC, as it would require accurate
tracking of variable contents across reassignments and possibly function
Hi Pierre
On 1/11/22 4:48 AM, Pierre Joye wrote:
Also sensitive data goes way beyond arguments, GDPR brings a lot of
issues here too. Userland packages like monolog provide filters or
custom output, I think that is where it should be handled.
I believe that the author of a function is in the
Hi Alex
On 1/11/22 4:10 AM, Alexandru Pătrănescu wrote:
As the trace in the exception is in the same format as the one generated
by debug_backtrace(),
do you intend to have the changes affecting debug_backtrace()
and debug_print_backtrace()?
My proof of concept patch adjusts the internal
Hi Dan
On 1/10/22 6:01 PM, Dan Ackroyd wrote:
How do other languages handle this problem? Or how do they avoid it in
the first place?
Ryan already replied here, but I've also researched this:
- Java is unable to provide parameters in stack traces.
- In C you generally have a core dump which
Hi Internals!
this is a follow-up for my "Pre-RFC" email from last Friday, January, 7th.
Christoph Becker granted me RFC editing permissions and I've now written
up our proposal as a proper RFC:
https://wiki.php.net/rfc/redact_parameters_in_back_traces
I recommend also taking a look at my
Hi Internals!
PHP's stack traces in exceptions are very useful for debugging, because
they include the original parameters for each stack frame, allowing the
developer to see exactly what data is passed to a function call.
Unfortunately sometimes this verbosity is a drawback. Specifically
24 matches
Mail list logo
