Alan Cox wrote:
disabled, removed extensions. How many of these are disabled as a result
of actual broken code, vs, how many are disabled because, "we don't like
how it looks"?
Most are disabled because they don't work (and often havent worked for
ages, or have been disabled by distributions by default for years and
nobody noticed), others are just not shipped by default and probably work
(eg Xprint still gets some love now and again).
There are other things to think about - eg X extensions that are old and
unmaintained often pre-date the world of the 'leet hacker dude' and the
coding isn't neccessarily as robust as it should be. Enabling such things
by default is exposing people to a risk with no economic justification.
Really the only way to maintain an X extension is to have someone who
uses it and has a true self interest in keeping it working, whether
because they work for a vendor whose customer pays good money for a
system that delivers the feature, or because they need it in-house.
The extensions are still there in the history of the codebase. It just
needs someone who needs that extension to check it out, rebuild test and
debug it. If it's cheaper to maintain it than port the code using it then
it makes sense for those who can save money to maintain it or pay someone
to do so, if not then it's probably time to go. Rational economic
behaviour ought to resolve such questions (ok given perfect information I
admit)
Some of the ancient video drivers would certainly be more expensive to
port than to simply replace the few remaining cards for example.
Alan
_______________________________________________
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Yes. I can certainly conclude that security issues would be a reason for
code to be disabled.
If the code is broken or has some problems like that, then, yes, not
building it in seems to be reasonable.
I do apologise for the tone of my original letter. We will be staying
with X in the future and we will not be moving to another platform.
I do still find backwards comptability to be important, especially in
the core protocol. We use a mix of new and old stuff, and the network
transparency is also a very important feature to us as well.
I can understand if an extension has broken code or has some security
problems it may be a good idea to disable that. I do not fault that.
One of the extensions removed was Xtrap. I suppose that its
functionality can be found in XRecord, i suppose. One area of course
that is useful for us for that is screen reader software for
accessibility for the blind.
Having a mechanism for OCR software to insert text or give text to
another application, is also a valuable feature as well.
It may also be of interest security mechanisms in regading to one
application accessing data of another application. Perhaps there should
be some kind of security measure to prevent an application from doing
this that one does not wish to have access to this feature. One
possibility might be a security interface that would allow a security
manager program to monitor requests for such actions, and perhaps give
the user notification of them to ask if the user wishes to deny or allow
one client to for instance access keyboard strokes going to the X server
as a whole or to a single client. Certainly capturing keystrokes to
particular xclients and for the entire server can be valuable, its a
mechanism that may be needed by something but it could be disallowed
except for progrms which the user explicitely allows it for.
The user could in their X configuration perhaps specify a program which
would control access to those kinds of interclient features. It could be
provided initially exclusive access to APIs to monitor requests for
controlled activities, and to permit or deny them, and provide if it
chooses access to these APIs, and other controlled APIs to other programs.
There is good reason for such features being avialable in certain cases
and not allowed in others. In some cases a bad or compromised program
could log passwords, and if programs running at different privelege
levels are being displayed to the same Xserver, we wouldnt want a
program which perhaps has been hijacked running as a nonpriveleged user
to access data regarding other clients, including ones perhaps running
as root.
While we are on security issues, what would prevent X being run as non
root? Perhaps there could be some way added to the OS if necessary so
that X can be given access to just those resources it needs, such as
input and output devices. Perhaps allowing for a special X user who has
access to just those resources it needs?
_______________________________________________
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
