Re: lynx-dev patch to add description of extended INCLUDE syntax to lynx.cfg

[Vlad Harchev]

On Mon, 31 May 1999, Henry Nelson wrote:

> > 1) It can't be done for sake of backward compatibility
> 
> Please explain why multiple include files are necessary for backward
> compatibility.  Or the reverse of the question, why a single include file
> prevents backward compatibility.

 Seems that description of INCLUDE setting was misinterpreted by you (if it's
so confusing, it's my fault). Sysadmin don't have to put line INCLUDE:~/lynx.cfg
in global lynx.cfg (and this line won't be implied by lynx) - only if sysadmin
wish to include the user-specific conf. file, the line similar to given should
be specified. So keeping of additional user-include file is not required.
By backward compatibility I meant the following: if some admin have already 
used this feature, then removing support for it will break his configuration.

> > 2) It's powerful thing and it's mostly targeted to ISPs that provide "lynx
> >    account" to their users - without this setting, user was unable to select
> 
> I doubt that you will find many ISPs that are so kind.

  I hope you are wrong. But even on multi-user systems such as in universities
this will be also useful (when users are not able to compile any program I
mean). Ask Larry Virden what he think about it.
  And I also hope that business (fighting with competitors) will force such
ISP to use this feature (to provide more flexibility to their customers than
others or like others if competitors already do provide).
 
> >    colors (if compiled without lss) since COLOR setting is initialized in
> >    lynx.cfg - with this setting, sysadmin can allow inclusion of 
> > user-written
> 
> If the user has shell access, this is not true.  The user can have a complete
> lynx.cfg with ALL of the settings in his $HOME and invoke lynx with the -cfg=
> command-line option.

  May be this functionality is not so useful if user is able to build their
own lynx. But if unable, IMO all good admins will make 'lynx' as
globally-visible script that will prohibit passing options to lynx binary (eg
it will pass only urls) - so users will be unable to fine-tune configuration
of lynx.
 But this feature was mainly targeted to ISPs.

> >    and some other settings that are key for security like TRUSTED_EXEC will 
> > be
> >    safely ignored. So extending INCLUDE syntax allows user to fine tune lynx
> >    by settings not only in .lynxrc, but by some in lynx.cfg, with security 
> > in
> >    mind. If you as sysadmin INCLUDE user-written file without extended 
> > syntax,
> >    then you have a risk of havving security hole. So, without extended 
> > INCLUDE
> >    syntax sysadmin from the following 2 way
> >       a) provide a user the ability to control lynx settings by including
> >          user-defined configuration file (making security hole)
> >       b) restricting user from fine-tuning lynx making it more pleasant to 
> >          work with lynx for user
> >   definitely was choosing b)
> >   Now with extended include syntax it's possible to choose a) without 
> > security 
> Lynx has always provided exactly what you are describing here, just by a
> different mechanism.  Security risk features have never been allowed to be
> overridden by defines in lynx.cfg from the compile-time selections.  Thus
> an ISP could provide whatever level of security he/she were comfortable with
> by editing userdefs.h and/or selecting configure options.

 "Security risk features have never been allowed to be overridden by defines
 in lynx.cfg from the compile-time selections."

 I don't think it's so ^. If the values of these settings are not allowed to 
override compile-time selections, then why do they exist? But even if you are 
right, then ISP should recompile lynx if some setting must be changed - this
is not elegant ( at least then "have never been allowed" should be replaced
with "can be disallowed").

> > 3) It's not targeted for people that use their computer personally.
> 
> !

 I meant the people that are both admins and users at the same time.

> >  If you have found the description too complex (and understood what that
> > syntax means) please write another - I don't insist on my description of
> 
> No.  It is your baby.  Although I doubt you would listen to anything I
> say, I would suggest that you consider prefixing your explanation of
> the feature with a comment that it is intended mainly for ISPs, and that
> general users may ignore it.

 This (targeting mainly for ISPs) may be deduced, but adding explicit note may
be not bad idea.

> >  Better think when you post anything. Seems that you are reading and writing
> > to lynx-dev due to absence of work - seems you are just adminning. Please
> > think carefully about each feature that was added to lynx (and then 
> 
> I am truly sorry you cannot accept my criticisms in a constructive manner.
> (I have a sneaking suspicion that you will find that I am one of the few
> who has thought in depth about the utility and repercussions of this
> feature.)  You're on your own now.  Good luck.

 You criticisms can only be accepted in destructive manner - removing
features. I found you one (only one, not one of the few) who has thought in
depth on the useless of this feature. 
 I hope that "You're on your own now.  Good luck." is said for all
features I've implemented, not only extended INCLUDE syntax - sorry if it
hurts you, but I tired explaining basic things to you. IMO you don't have good
logic or are too busy to think carefully. Sorry again. And remember, there is
another solution - I can post all patches directly to Tom to avoid your
non-motivated or badly thought criticisms. Sorry.
  And remember that you don't have to use all features lynx provides. If you 
didn't find some feature useful for you, it doesn't mean that it's useful for
others.

> __Henry
> 
 
 Best regards,
  -Vlad