[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev patch to add description of extended INCLUDE syntax to lynx
From: |
Henry Nelson |
Subject: |
Re: lynx-dev patch to add description of extended INCLUDE syntax to lynx.cfg |
Date: |
Mon, 31 May 1999 18:31:05 +0900 (JST) |
> 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.
> 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.
> 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.
> 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.
> 3) It's not targeted for people that use their computer personally.
!
> 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.
> 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.
__Henry