[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

On Wed, 2015-08-19 at 20:59 +0100, Colin Watson wrote:
> I tried some experiments with ForwardX11Trusted=no today, and
> frankly,
> it doesn't even pass the laugh test for usability.

Well but it's ssh "Secure Shell" - and not ush (Usability Shell).
So the defaults should be always the secure ones, and not the fancy-out
-of-the-box™. :-)

I don't mind though, to leave the defaults as is in stable.

> Run xterm and try to
> select something, bam, your xterm crashes with BadAccess.

Which means that people would typically note quite quickly that they
need to open up things more (if they want to continue).

In my opinion this is much less worse, than having the current default,
where people who may be at risk wouldn't notice anything.

> Now, I didn't do very exhaustive testing or anything, but to
> me,
> those ten years haven't actually made a perceptible difference to how 
> X
> clients respond to failures from the SECURITY extension.

But just because clients are broken (in that respect) doesn't justify
to "work around" their issues, by making things in ssh less secure.

> So: I don't think that this decision is realistically just up to me. 
> If
> I change ssh back to use ForwardX11Trusted=no by default, a bunch of
> other maintainers are going to be asked to fix their software in 
> various
> ways: the SECURITY extension may say no to something, but you might
> reasonably expect that double-clicking in your terminal won't make it
> explode in your face. 

Fixing all clients is probably unrealistic,... but anyway, the choice
should be in the hands of the sysadmin. X forwarding is probably anyway
a rather insecure thing (whether ForwardX11Trusted is yes or no). IMHO
it should generally not be enabled per default.

Having ForwardX11Trusted=no may be enough for many clients people would
use (e.g. such which just display stuff?),... and it's the secure and
expected default for those that read the manpage (but not necessarily
the Debian-modified manpage).


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: