> Perhaps the safest here is to stop processing after reading ":-"
> or some such (and discard it!) - that would be guaranteed to never
> pass through to the program anyway, because it might be a runtime
> option and already gets intercepted by the option parser.
>
As an afterthought: I find that
> On Mon, Mar 13, 2023 at 10:37:30AM +0100, felix.winkelm...@bevuta.com wrote:
> > Another problem with run-time option processing pointed out by
> > florz. This allows passing arguments that look like run-time
> > options, when preceded by "--".
>
> This needs more thought - simply adding "--" to
I really like these, I'll miss the -:b . My desired solution would be a way to
turn off some or all switches. For some programs I'd disable for production,
e.g. setuid, static compiled security related utils, we do a lot of these and
I've wondered about security implications of these switches.
On Mon, Mar 13, 2023 at 10:37:30AM +0100, felix.winkelm...@bevuta.com wrote:
> Another problem with run-time option processing pointed out by
> florz. This allows passing arguments that look like run-time
> options, when preceded by "--".
This needs more thought - simply adding "--" to stop it
On Sun, Mar 12, 2023 at 06:04:49PM +0100, felix.winkelm...@bevuta.com wrote:
> As rightly pointed out by florz and others, the "b" (break on
> repl) offers a potential security vulnerability by allowing
> code from stdin to be interpreted. This patch simply removes
> the option, as it doesn't seem
Another problem with run-time option processing pointed out by
florz. This allows passing arguments that look like run-time
options, when preceded by "--".
felix
From fae3f9ddeabccae4851ff451fb2aaf05a02e44e3 Mon Sep 17 00:00:00 2001
From: felix
Date: Mon, 13 Mar 2023 10:35:32 +0100
Subject:
