Follow-up Comment #9, bug #64576 (group groff):
[comment #2 comment #2:]
> I reiterate that stuff like this:
> . while dpdf:href.opt\\$1 \{\
> . pdf:href.opt\\$1 \\$@
> . shift \\n[pdf:href.argc]
> . \}
> is too clever by half--by three quarters, maybe,
This, of course, is utter nonsense.
> if you're neither doing sanitization (which will need to be
> reversible for things like link text, and therefore even more
> tedious and difficult than sanitization already is), nor input
> validation.
>
> But the latter isn't even really what you want anyway.
You got that much right.
> There's no reason that every argument to a macro must be expected
> to be a valid *roff identifier.
Also true; however...
> This is simply a mistaken premise that appears to have driven
> several bad design decisions.
This conclusion is, once again, utter nonsense. The design is perfectly
sound; it is the implementation that is flawed. You even hinted at the fault,
and thus implicitly at a practical solution, in your reference to "input
validation", and *that* is readily accomplished:
. while \A'\\$1' \{\
. if !dpdf:href.opt\\$1 .break
. pdf:href.opt\\$1 \\$@
. shift \\n[pdf:href.argc]
. \}
will prevent any attempt to match any argument which could not be legitimately
incorporated into an identifier name, (and any which follow it), to a defined
macro name, (which is the intent of this while loop).
I have identified six loops, within _pdfmark.pdf_, which exhibit such
vulnerability, and thus, where similar input validation would be advisable; I
will fix them accordingly, in my OSDN _groff-pdfmark_ repository.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64576>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
