[bug #64576] [pdf.tmac] pdf*href option handling insufficiently flexible

[Keith Marshall]

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/