[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 roland.mainz at nrubsig.org  2005-03-02 01:58 -------
(In reply to comment #3)
> (In reply to comment #2)
> > I think the patch is bad for two reasons:
> > 1. Disabling the SECURITY extension will break "xauth", almost every ssh
> > implementaion under the moon (except OpenSSH which may surive this condition,
> > ssh.com's ssh doesn't handle that case), the XC-APPGROUP extension (see [2]) and
> > a couple of other things...
> 
> xauth only needs the Security extension for the 'generate' command, which is not
> used in the default startx, and which anyway only makes sense in the context of
> the server supporting the Security extension in the first place. 
> BuildXCSecurity does not prevent xauth from supporting this command; it only
> means the built server will not support it.  so it does not break xauth.

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.

> openssh's Security integration has made a lot of people unhappy and is generally
> regarded as a bad move.  it silently changed the semantics of the -X option
> which breaks most modern apps.

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.
And this is no fatal condition for toolkits, they can easily trap the
"offending" X calls and handle them correctly (for example CDE2.x applications
don't have the problem and somewhere in Mozilla.org's bugzilla is a patch for
the Gecko Xlib port to let it run happily in X11 "untrusted" mode).

[snip]
> i would be surprised if ssh.com's implementation behaved differently.)  the
> point is, 'ssh -X' is broken anyway, disabling the Security extension in the
> server does not change that.

That implementation works completely different (and even handles the SECURITY
extension "timeout" correctly (openssh doesn't).

> it should be noted that openssh's X11 handling is done entirely without
> including any X11 headers or linking against any X11 libraries.
> 
> not supporting the Security extension in the server is clearly not fatal, since
> kdrive doesn't support it and works just fine with xauth and ssh.

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.

> > 2. AFAIK the XC-APPGROUP extension needs the SECURITY extension to provide
> > "tags" for display connections - and right now the only implemented way to make
> > such tags  is to generate a MIT-MAGIC-COOKIE-1 which marks all applications
> > which use that cookie with the "tag" (kaleb may correct me if I am wrong...). 
> 
> if this is true, then build-time logic is required to do one of two things:
> 
> a) if BuildAppgroup && !BuildXCSecurity, turn BuildXCSecurity on
> b) if BuildAppgroup && !BuildXCSecurity, turn BuildAppgroup off
> 
> either one, i'm not picky.

Kaleb can answer that...          
     
     
--           
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.