[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev lynxexec
Re: lynx-dev lynxexec
Thu, 17 Dec 1998 10:11:24 -0600 (CST)
On Thu, 17 Dec 1998 address@hidden wrote:
> > > -check; TERM=$OLDTERM; export TERM">SeqEd</A> editor for entering and
> > > modifying
> > > seqences
> > > And Lynx gives me the following
> > > Alert!:Executable link rejected due to `;' character.
> > These seems to be a more generic question:
> well yes - but the short answer to his question is that the link was
> rejected _because_ it contains more than one command (that was a change
> from the middle of 1997 - a security fix).
The function which checks for this and produces the error message is
exec_ok. Actually, the only CHANGES*.* entry I can find for 1997 that
mentions changing exec_ok is
* Modified the Unix "strange character" filter in exec_ok() of LYGetFile.c
to allow '+', '&' and '=' characters. - FM
and that is a relaxation. I believe exec_ok itself is much older than
Indeed exec_ok doesn't allow ';'. But that doesn't give much protection
against anything as long as '&' is acceptable...
(also linked from "Al's Picks":)
> He can always modify the
> source, but unless we add some sort of option to support it, in general
> Lynx won't allow that behavior any more.
> > different URL schemes have different sets of restricted characters
> > and different encoding/conversion rules.
> > I think of http URL (URI?), file://localhost (OS dependent)
> > and now the "lynexec" which is the shell command string.
> > What is the present lynx status for non-http HREF conversion?
That is quite a different topic. The ';' in lynxexec should be blocked
whether it is given as ';' or '%3B'.
The present (and past) status is... confused.
But, mostly lynx has to _decode_ URLs, not to generate them (the biggest
exception being file URLs). That makes it less important to know exactly
which character are restricted in which part of which URL scheme. If
there's a %NN it is just decoded when we need the decoded version.
Well that's "ideally". In practice that doesn't happen nearly everywhere
where it should.
The most important character shat should ALWAYS be escape in any kind of
URL scheme is '%'. A '%' should never be allowed to stand for itself,
since its special meaning applies to all parts of all URL schemes [maybe
except the protocol?].
> > > It would be a big job to put all of these long command lines in script
> > > files.
> > > How do I get Lynx to recognise ; as a valid char?
Simplest way: modify the function in question, in LYGetFile.c.
Hard way: make a convincing argument to lynx-dev why changing the code to
allow ';' generally in lynxexec:/lynxprog: would be good.