lynx-dev EXTERNAL vs lynx{exec,prog} and mailto (was: [PATCH])

[Klaus Weide]

On Mon, 10 Jul 2000, Vlad Harchev wrote:
> On Sun, 9 Jul 2000, Klaus Weide wrote:
> > On Sat, 8 Jul 2000, Vlad Harchev wrote:
> > >  I already told about my attitude towards extending EXTERNAL.
> > 
> > But you didn't really tell why, or did I miss it?
> 
>   The reasons: 
> 1) this is duplication of already existing functionality (CERN rules) 

Well it isn't - as CERN rules is currently, it doesn't provide that
kind of functionality securely.

> 2) If support for it for all cases is needed (not only interception of
>       ACTIVATE command) then it's very hard to hack the code properly in all
>       cases (there can be one - in getfile() - but this starts looking like 
>       duplication of CERN rules functionality again)

a) Wrt. 'support for all cases (not only ACTIVATE)' - the 'if' is still an
open question.  (Somebody else than me also asked for being able to still
access the built-in handling.)

b) Wrt. 'hard to hack the code properly in all cases' - for a mail(to)
specific hook, which you now favour, you'd probably have to do this anyway
'in getfile()' (or lower).


> > I just think the above would be a logica extension that doesn't require
> > much extra effort or code, *if* you were to extend the EXTERNAL mechanism
> > anyway.
> 
>    Now I begin to think that exactly 2 slots (primary + the one popping
> menu of all choices) is a good idea. More than 2 slots makes no sense to me (I
> think user will be unable to remember everything).

'Exactly 2 slots' is just a special case of the more general proposal -
the case that is current (after the '[PATCH]' patch) behavior.


> > > > In any case, whether the abocve is used or not: As soon as Enter/Return
> > > > or an Enter/Return-like key can run EXTERNAL commands, *there should be
> > > > a mechanism for protection*.  Like the TRUSTED_EXEC mechanism, where
> > 
> > > > IOW, something like the TRUSTED_EXEC / TRUSTED_LYNXCGI mechanism should
> > > > be applied to "auto-invoked" EXTERNAL commands, too.
> > > 
> > >  I think efforts should be redirected to securing lynx{prog,exec} and to
> > > allowing mailto: to be subject of CERN rules (using the patch you'll 
> > > suply)
> > > and to supporting external handler for mailto: urls. 
> > 
> > Securing lynx{prog,exec}: good luck.  Are you going to do it?
> 
>   May be.
> 
> > The kind of people for whom this mechanism was primarily intended, and who
> > invented and extended it, have all left the building (read: are not active
> > on the list any more).  It's fairly hard to understand how even the existing
> > protections are supposed to be used and how they work together.
> 
>   Have you read the branch for LYNXPROG_URL_TYPE and LYNXEXEC_URL_TYPE? It's
> trivial. As for protection - I'm starting to think that quoting every special
> character with backslash and using system() (there is no need to enclose
> arguments into single or double quotes) will be very (if not most) reliable
> solution. It really works - try it yourself, at least with bash. Probably 
> POSIX should be consulted for whether it works on any UNIX.
>   What do you think?

It's not trivial IMHO.  Consider how EXEC_LINKS interacts with EXEC_SCRIPTS.
Examine how EXEC_SCRIPTS gets enabled.  Ask yourself whether you understand
the difference between TRUSTED_EXEC and ALWAYS_TRUSTED_EXEC, or what exactly
is the effect of -exec, -locexec, -noexec, and -restrictions=exec switches.
Consider in which cases dangerous characters casue rejection, and in which
cases they don't.  How all this gets possibly modified by (userdefs.h) compile
time and (lynx.cfg) run time options.  Examine whether the documentation
(such as there is) actually describes the implemented behavior correctly.
Consider the cases where the rules are or may be modified: jumps files,
bookmark files.  Then tell me whether you still think it is trivial.

  Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden