Re: RFC [Discussion]: Redacting parameters in back traces
| From: | Ryan Jentzsch | Date: | Mon, 10 Jan 2022 22:59:29 +0000 |
| Subject: | Re: RFC [Discussion]: Redacting parameters in back traces | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116859@lists.php.net to get a copy of this message | ||
Answering the question: How do other languages handle this problem? Or how
do they avoid it in
the first place?
Python basically doesn't handle the problem at all and offers this advice: Be
sure to delete all debugging related code before code delivery!
See section [9.2.1 production code cannot contain any debug entry points]
https://www.fatalerrors.org/a/python-general-programming-specification-09-security-programming-specification.html
On Mon, Jan 10, 2022 at 10:01 AM Dan Ackroyd <Danack@basereality.com> wrote:
> Hi Tim,
>
> On Mon, 10 Jan 2022 at 14:05, Tim Düsterhus, WoltLab GmbH
> <duesterhus@woltlab.com> wrote:
> >
> > this is a follow-up for my "Pre-RFC" email from last Friday, January,
> 7th.
> >
> > https://wiki.php.net/rfc/redact_parameters_in_back_traces
> >
>
> How do other languages handle this problem? Or how do they avoid it in
> the first place?
>
> From the RFC:
> > Specifically the back trace collection should be updated to use an
> object of class
> > \SensitiveParameter as the value for all parameters that are marked with
> the
> > \SensitiveParameter attribute.
>
> To me....these words are not clear. Does the following sentence say
> the same thing?
>
> "When the backtrace is generated, any parameter that has a
> 'SensitiveParameter' attribute will not have it's value stored in the
> backtrace, but instead will be replaced with an SensitiveParameter
> object.
>
> If so, the RFC could be updated to be clearer.....if not, then the RFC
> should be updated to be clearer.
>
> Also, having parameters replaced with another type doesn't seem
> obviously correct. There should probably be some words justifying why
> that is the correct thing to do, rather than just replacing any values
> with "****REDACTED***" or other simple behaviour.
>
> > On shared web hosting, the customer might not be able to configure it.
>
> My personal opinion is that shared web hosting shouldn't be a thing
> that exists in 2022. And definitely shouldn't be used for anything
> where secrets need to be maintained. Yeah shared hosts might have a DB
> they can connect to, but those credentials should only be usuable from
> the shared host to the DB.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>