Problems with X.org and incompatibilities with in-house software

[Richard Brown]

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 at 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?