[Bug 2606] Can't build without XC-SECURITY

[bugzilla-daemon at freedesktop.org]

Please do not reply to this email: if you want to comment on the bug, go to    
       
the URL shown below and enter yourcomments there.     
   
https://bugs.freedesktop.org/show_bug.cgi?id=2606          
     




------- Additional Comments From ajax at nwnk.net  2005-03-02 11:34 -------
(In reply to comment #4)
> It will break the "generate" command which is needed to grant applications
> access to the display when there is no cookie yet - the usual usecase for this
> is when the Xserver uses the SUN-DES-1 or MIT-KERBEROS-5 auth. and need to grant
> a remote application access to the display where the remote machine isn't part
> of the SecureRPC domain or part of the Kerberos system. Feel free to kill the
> SECRUITY extension but don't forget to disable the user-to-user auth. schemes as
> well.

So when the user asks to build without Security, they get a server that lacks
support for the Security extension, and all that that entails including broken
SUN-DES-1.  Seems pretty straightforward to me.

> Well, that's cleary the fault of the toolkits. AFAIK they were informed about
> the exploits around a _year_ before the first ssh version implemented the usage
> of the SECURITY extension.

Granted.

> This is FATAL for most ssh implementations _except_ openssh. I have excplitly
> listed that case... it's the only ssh implementation which can recover from that
> case AFAIK.

It is fatal iff:
- the ssh implementation implements Security integration (ie, is not PuTTY,
TeraTerm, lsh, or most of the Java ssh implementations i've seen), AND
- the user asks for X forwarding using the -X flag to openssh or the +x flag to
ssh.com's ssh.

The failure mode here is exactly what the user asks for: They built a server
without the Security extension, and then required the ssh client to use the
Security extension.

There's one other failure mode I suppose:

- The ssh implementation requires the Security extension even for normal (ie,
trusted) forwarding.  (ssh.com?)

This in my mind would be a regression in the ssh client, as it would no longer
be able to interoperate with X servers from before 6.3, when the Security
extension was introduced.  It is in any case giving the user what they asked for.

There is a BuildXCSecurity option in imake.  As a user I expect that if I turn
off any particular option in imake it will build to completion and make a
reasonable attempt at giving me what I asked for.  So, either the option needs
to disappear (and we just build with the Security extension all the time), or
the code or Imakefiles need to be fixed.

I am absolutely not suggesting turning off Security by default; I'm just asking
that my build not fail when I ask to not have it.          
     
     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         
     
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.