X2Go Bug report logs - #258
SECURITY: x2goclient allows clipboard sniffing

Toggle useless messages

Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: submit@bugs.x2go.org

Subject: SECURITY: x2goclient allows clipboard sniffing

Date: Mon, 01 Jul 2013 04:38:28 +0200

Package: x2goclient
Severity: grave
Tags: security

Hi.

From: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714588


It seems that per default (and I even found no way to disable it)
x2goclient (and perhaps other
related tools?) transmit the content of the clipboard to the remote
host.

As this may easily contain passwords or other sensitive information,
this is a extremely
critical hole.


Cheers,
Chris.

Message #10 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Alexander Wuerstlein <snalwuer@cip.informatik.uni-erlangen.de>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 258@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#258: SECURITY: x2goclient allows clipboard sniffing

Date: Mon, 1 Jul 2013 13:43:56 +0200

On 13-07-01 04:56, Christoph Anton Mitterer <calestyo@scientia.net> wrote:
> Package: x2goclient
> Severity: grave
> Tags: security
> 
> Hi.
> 
> From: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714588
> 
> 
> It seems that per default (and I even found no way to disable it)
> x2goclient (and perhaps other related tools?) transmit the content of
> the clipboard to the remote host.

Yes, other related tools like X11. x2go is basically just a faster
version of the traditional xforwarding. In X11 every client can always
access the clipboard/selection/etc., so you will also have the same
security problems (by design). E.g. 'ssh -X user@evilhost "xclip -o"'
demonstrates this.

> As this may easily contain passwords or other sensitive information,
> this is a extremely critical hole.

I disagree, this is not a hole at all, it works as intended. Its just
that users are often not educated about the implications of passing
around passwords via the clipboard etc.

But I concur that the ability to switch off clipboard/selection/...
forwarding in the x2goagent/x2goclient would be nice to have. Patches
are of course always welcome.



Ciao,

Alexander Wuerstlein.

Message #15 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 258@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#258: SECURITY: x2goclient allows clipboard sniffing

Date: Mon, 01 Jul 2013 14:43:29 +0200

[Message part 1 (text/plain, inline)]

On Mon, 2013-07-01 at 13:43 +0200, Alexander Wuerstlein wrote: 
> Yes, other related tools like X11. x2go is basically just a faster
> version of the traditional xforwarding. In X11 every client can always
> access the clipboard/selection/etc., so you will also have the same
> security problems (by design). E.g. 'ssh -X user@evilhost "xclip -o"'
> demonstrates this.
Well but that "argument" doesn't really count:
1) Just because others do it plainly insecure, you cannot do it like
this as well... like as if Gentoo would say "if Debian breaks their
OpenSSL entropy, we should do so, too"... o.O

2) Literally no one who has a decent mind of security, will allow other
hosts do directly access their X server.. because then you're (security
wise) anyway screwed...
And I thought NX would secure what's sent from remote in order to not
being able to overtake the input/output devices of the hosts (whole)
Xserver).


> I disagree, this is not a hole at all, it works as intended. Its just
> that users are often not educated about the implications of passing
> around passwords via the clipboard etc.
Na I disagree... if even people would be educated (which is not
realistic) it will happen by accident, that you copy sensitive
information... sometimes other programs may do this even automatically
and you can't to anything against.


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #20 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Alexander Wuerstlein <snalwuer@cip.informatik.uni-erlangen.de>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 258@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#258: Bug#258: SECURITY: x2goclient allows clipboard sniffing

Date: Mon, 1 Jul 2013 16:01:32 +0200

On 13-07-01 15:03, Christoph Anton Mitterer <calestyo@scientia.net> wrote:
> On Mon, 2013-07-01 at 13:43 +0200, Alexander Wuerstlein wrote: 
> > Yes, other related tools like X11. x2go is basically just a faster
> > version of the traditional xforwarding. In X11 every client can always
> > access the clipboard/selection/etc., so you will also have the same
> > security problems (by design). E.g. 'ssh -X user@evilhost "xclip -o"'
> > demonstrates this.
> Well but that "argument" doesn't really count:
> 1) Just because others do it plainly insecure, you cannot do it like
> this as well... like as if Gentoo would say "if Debian breaks their
> OpenSSL entropy, we should do so, too"... o.O

It isn't like that at all, X11 clients and servers have to comply with
the respective parts of the protocol. If the protocol demands insecure
behaviour, its a design bug, or maybe, like in this case, a compromise
nobody likes: Since in X11 clients handle all the shortcuts and mouse
button events, since clients or toolkits handle the widgets, the only
option to implement C&P is to have clients ask the server for the
clipboard or selection contents. Its more a "there is no other way to do
it except to make it unusable" kind of problem imho.

> 2) Literally no one who has a decent mind of security, will allow other
> hosts do directly access their X server.. because then you're (security
> wise) anyway screwed...

I'm not only talking about 'xhost +' and the like, this would of course
be a major problem for more reasons than only the clipboard. And if you
wouldn't trust a host with 'ssh -X', then you also shouldn't trust it
with x2go. Just think of x2go as a variant of 'ssh -X' with image
compression and some extras. X11 protocol firewalling is not really one
of those extras. And since the x2goclient will always run in your local
X session, it will always be able to read your clipboard.

> And I thought NX would secure what's sent from remote in order to not
> being able to overtake the input/output devices of the hosts (whole)
> Xserver).

In a way, yes. Afaik you can avoid certain attacks of the "I'll attach
to the root window and get all key events" kind since windowed x2go
sessions give you a separate root window. But I imagine there are more
problems out there nobody thought of yet.



Ciao,

Alexander Wuerstlein.

Message #25 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 258@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#258: Bug#258: SECURITY: x2goclient allows clipboard sniffing

Date: Tue, 02 Jul 2013 03:27:49 +0200

[Message part 1 (text/plain, inline)]

Hey Alexander.

First,... I assume you're one of the NX/X2go developers?


On Mon, 2013-07-01 at 16:01 +0200, Alexander Wuerstlein wrote:
> It isn't like that at all, X11 clients and servers have to comply with
> the respective parts of the protocol. If the protocol demands insecure
> behaviour, its a design bug, or maybe, like in this case, a compromise
> nobody likes: Since in X11 clients handle all the shortcuts and mouse
> button events, since clients or toolkits handle the widgets, the only
> option to implement C&P is to have clients ask the server for the
> clipboard or selection contents. Its more a "there is no other way to do
> it except to make it unusable" kind of problem imho.
Well first I may have a misunderstanding about how NX works, but more on
that below:

With respect to the issue (transferring the clipboard) itself:
Don't get this in anyway offensive! But I think it's plain simple:

It may easily happen that people copy (by intention/accidentally or even
automatically by software) stuff to the clipboard which contains
sensitive information, which in turn can be anything from passwords to
my private love letters ;-)

And people don't see x2go (or VNC, or rdp) like a direct access to their
X server (as in plain X forwarding with xauth and that like).
This might be a misunderstanding... but it's how many similar such
"VNC-like" connections (i.e. a screen output into _one single_ X window)
work.
E.g. when I connect to my qemu virtual machines, I don't have to worry,
that the VM can overtake my X server,... the same for Virtualbox... and
I hope/believe for VNC/TightVNC/etc. and rdp connections (rdesktop and
friends).

This includes that users don't expect (or at least they shouldn't have
to) that such connections allow wiretapping, e.g. if such a system
supports audio forwarding... it shouldn't allow the remote side to
activate my MIC and listen to what I say/sing/etc.

The same holds true for the clipboard... at least per default it
shouldn't be ever sent to the remote side (or vice versa)... and IF one
activates it... people should be warned with big warnings what this
could mean.


That this can indeed lead to compromise showed a recent attack we've had
on one our institutes' machines, where sensitive information was caught
via an X2go connection and later on used for other attacks.


Now for the technical side... admittedly I don't know the details of how
NX interacts with X... but there must be some way to achieve blocking of
the clipboard sync.
Even if the protocol demands to send some content,... well then simply
hook in an clear it always (per default).



Now more off topic about how NX interacts with X:

I understand that NX is not like VNC, where it's more like send the
pixbuffers.... and where you obviously have not much security problems
in terms of taking over the local X server, since it's more like
displaying JPEGS (of course VNC has much other security problems).

I haven't found out what RDP actually does... but I'd assume it's rather
similar to VNC?

Now with NX I understand it's compression at the X protocol level, so
"no JPEGs being transferred"... but where do remotes X protocol go to?
Directly into the local X? Or is it taken by NX/X2go and rendered as if
NX/X2go would be an X server that is displayed in a _single_ window of
another one (i.e. like Xephyr)?


> And if you
> wouldn't trust a host with 'ssh -X', then you also shouldn't trust it
> with x2go.
Well this is _really_ serious news...
So why? I mean that's what most people expect I guess.. like when you
connect via ssh, that the remote cannot take over your local system...
(unless some serious hole would be find in the ssh client ;) )


> Just think of x2go as a variant of 'ssh -X' with image
> compression and some extras. X11 protocol firewalling is not really one
> of those extras. And since the x2goclient will always run in your local
> X session, it will always be able to read your clipboard.
So it directly goes into the local X server? Wow... that's awful... like
a security nightmare...


> In a way, yes. Afaik you can avoid certain attacks of the "I'll attach
> to the root window and get all key events" kind since windowed x2go
> sessions give you a separate root window. But I imagine there are more
> problems out there nobody thought of yet.
Who would know for sure what is expected to be possible and what not?

I mean don't take this rude... but for me this basically makes NX
unusable, since I basically only use it to connect to more or less
untrusted nodes.
If that means these can take over my X, or even more... than good
night :-/



Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #30 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Nable 80 <nable.maininbox@googlemail.com>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 258@bugs.x2go.org, x2go-dev@lists.berlios.de

Subject: Re: [X2Go-Dev] Bug#258: Bug#258: Bug#258: SECURITY: x2goclient allows clipboard sniffing

Date: Tue, 2 Jul 2013 11:10:18 +0400

Hi, Chris.

> So it directly goes into the local X server?
> Wow... that's awful... like a security nightmare...
Then, you don't use ssh -X/-Y, do you?

> And people don't see x2go (or VNC, or rdp) like a direct access
> to their X server (as in plain X forwarding with xauth and that like).
Why do you think so? Because they have it in window and didn't specify
any option that exactly means 'turn on X11 forwarding'?
After all, I think that it's not a grave issue as most people use X11
forwarding for rather trusted hosts (or just don't care).

One additional note: it's possible to turn on clipboard forwarding in
RDP and VNC (and it's a very useful thing) but AFAIR in most clients
_one have to specify it implicitly_ (and sometimes there's a separate
option that allows some restricted clipboard access, for example:
copying from remote to local but not vise versa). May be someone will
make a patch to implement such options in X2Go.

Message #35 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Nable 80 <nable.maininbox@googlemail.com>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 258@bugs.x2go.org, x2go-dev@lists.berlios.de

Subject: Re: [X2Go-Dev] Bug#258: Bug#258: Bug#258: Bug#258: SECURITY: x2goclient allows clipboard sniffing

Date: Tue, 2 Jul 2013 12:01:34 +0400

Sorry, quickfix:
s/implicitly/explicitely/

2013/7/2, Nable 80 <nable.maininbox@googlemail.com>:
> Hi, Chris.
>
>> So it directly goes into the local X server?
>> Wow... that's awful... like a security nightmare...
> Then, you don't use ssh -X/-Y, do you?
>
>> And people don't see x2go (or VNC, or rdp) like a direct access
>> to their X server (as in plain X forwarding with xauth and that like).
> Why do you think so? Because they have it in window and didn't specify
> any option that exactly means 'turn on X11 forwarding'?
> After all, I think that it's not a grave issue as most people use X11
> forwarding for rather trusted hosts (or just don't care).
>
> One additional note: it's possible to turn on clipboard forwarding in
> RDP and VNC (and it's a very useful thing) but AFAIR in most clients
> _one have to specify it implicitly_ (and sometimes there's a separate
> option that allows some restricted clipboard access, for example:
> copying from remote to local but not vise versa). May be someone will
> make a patch to implement such options in X2Go.
> _______________________________________________
> X2Go-Dev mailing list
> X2Go-Dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/x2go-dev
>

Message #40 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Alexander Wuerstlein <arw@cip.cs.fau.de>

To: x2go-dev@lists.berlios.de

Cc: Christoph Anton Mitterer <calestyo@scientia.net>, 258@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#258: Bug#258: Bug#258: SECURITY: x2goclient allows clipboard sniffing

Date: Tue, 2 Jul 2013 18:07:52 +0200

On Tue, 02 Jul 2013 03:27:49 +0200
Christoph Anton Mitterer <calestyo@scientia.net> wrote:

> Hey Alexander.
> 
> First,... I assume you're one of the NX/X2go developers?

I've submitted some patches, yes. But I don't commit things as often as I would
want to.

> On Mon, 2013-07-01 at 16:01 +0200, Alexander Wuerstlein wrote:
> > It isn't like that at all, X11 clients and servers have to comply
> > with the respective parts of the protocol. If the protocol demands
> > insecure behaviour, its a design bug, or maybe, like in this case,
> > a compromise nobody likes: Since in X11 clients handle all the
> > shortcuts and mouse button events, since clients or toolkits handle
> > the widgets, the only option to implement C&P is to have clients
> > ask the server for the clipboard or selection contents. Its more a
> > "there is no other way to do it except to make it unusable" kind of
> > problem imho.
> Well first I may have a misunderstanding about how NX works, but more
> on that below:
> 
> And people don't see x2go (or VNC, or rdp) like a direct access to
> their X server (as in plain X forwarding with xauth and that like).
> This might be a misunderstanding... but it's how many similar such
> "VNC-like" connections (i.e. a screen output into _one single_ X
> window) work.
> E.g. when I connect to my qemu virtual machines, I don't have to
> worry, that the VM can overtake my X server,... the same for
> Virtualbox... and I hope/believe for VNC/TightVNC/etc. and rdp
> connections (rdesktop and friends).

Well, in that aspect, VNC, RDP and x2go/NX are somewhat different. VNC and RDP
basically started from some dumb kind of framebuffer and keyboard/mouse event
forwarding. X11 has a far larger amount of functionality and a huge system of
extensions on top. x2go/NX starts out from X11 and changes some aspects,
pruning things that are slow or unnecessary (e.g. synchronous calls or
uncompressed bitmaps). So while with VNC/RDP you have a very simple starting
point from which you then can add some extensions like clipboards, with
X11/x2go/NX you have everything and need to throw away stuff that might be bad.
People are still in the process of figuring out the bad stuff, and generally its
the far more hazardous direction of development.

> This includes that users don't expect (or at least they shouldn't have
> to) that such connections allow wiretapping, e.g. if such a system
> supports audio forwarding... it shouldn't allow the remote side to
> activate my MIC and listen to what I say/sing/etc.

Well, if you switch on audio forwarding in RDP, the other side can do exactly
that...

> The same holds true for the clipboard... at least per default it
> shouldn't be ever sent to the remote side (or vice versa)... and IF
> one activates it... people should be warned with big warnings what
> this could mean.

I agree that this would be desirable.

> That this can indeed lead to compromise showed a recent attack we've
> had on one our institutes' machines, where sensitive information was
> caught via an X2go connection and later on used for other attacks.

Do you have any more in-depth writeup of that attack so we maybe can learn from
it and look at certain things more specifically?

> Now for the technical side... admittedly I don't know the details of
> how NX interacts with X... but there must be some way to achieve
> blocking of the clipboard sync.
> Even if the protocol demands to send some content,... well then simply
> hook in an clear it always (per default).

Yes, that should be possible. Its just that someone has to implement it.

> Now more off topic about how NX interacts with X:
> 
> [...]
> Now with NX I understand it's compression at the X protocol level, so
> "no JPEGs being transferred"... but where do remotes X protocol go to?
> Directly into the local X? Or is it taken by NX/X2go and rendered as
> if NX/X2go would be an X server that is displayed in a _single_
> window of another one (i.e. like Xephyr)?

Some protocol calls are taken as is and passed to the local X, others are
"transformed", e.g. made asynchronous, bitmap-compressed, etc.

> > And if you
> > wouldn't trust a host with 'ssh -X', then you also shouldn't trust
> > it with x2go.
> Well this is _really_ serious news...
> So why? I mean that's what most people expect I guess.. like when you
> connect via ssh, that the remote cannot take over your local system...
> (unless some serious hole would be find in the ssh client ;) )

Well, the remote can't take over your system afaik. But there are concerns
about the security of ssh -X vs. -Y. Keystroke monitoring is one of those
concerns.

> > Just think of x2go as a variant of 'ssh -X' with image
> > compression and some extras. X11 protocol firewalling is not really
> > one of those extras. And since the x2goclient will always run in
> > your local X session, it will always be able to read your clipboard.
> So it directly goes into the local X server? Wow... that's awful...
> like a security nightmare...

Yes, it can be.

> > In a way, yes. Afaik you can avoid certain attacks of the "I'll
> > attach to the root window and get all key events" kind since
> > windowed x2go sessions give you a separate root window. But I
> > imagine there are more problems out there nobody thought of yet.
> Who would know for sure what is expected to be possible and what not?
> 
> I mean don't take this rude... but for me this basically makes NX
> unusable, since I basically only use it to connect to more or less
> untrusted nodes.
> If that means these can take over my X, or even more... than good
> night :-/

Yes, connections to untrusted hosts are problematic. For this I consider VNC to
be more suited.


Ciao,

Alexander Wuerstlein.

Message #45 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 258@bugs.x2go.org

Cc: x2go-dev@lists.berlios.de

Subject: Re: [X2Go-Dev] Bug#258: Bug#258: Bug#258: SECURITY: x2goclient allows clipboard sniffing

Date: Tue, 02 Jul 2013 19:47:17 +0200

[Message part 1 (text/plain, inline)]

On Tue, 2013-07-02 at 18:07 +0200, Alexander Wuerstlein wrote: 
> Well, in that aspect, VNC, RDP and x2go/NX are somewhat different. VNC and RDP
> basically started from some dumb kind of framebuffer and keyboard/mouse event
> forwarding.
I knew (at least the VNC / RDP part)... and I started to realise the
difference from NX ;)

> X11 has a far larger amount of functionality and a huge system of
> extensions on top.
Sure...

>  x2go/NX starts out from X11 and changes some aspects,
> pruning things that are slow or unnecessary (e.g. synchronous calls or
> uncompressed bitmaps). So while with VNC/RDP you have a very simple starting
> point from which you then can add some extensions like clipboards, with
> X11/x2go/NX you have everything and need to throw away stuff that might be bad.
> People are still in the process of figuring out the bad stuff, and generally its
> the far more hazardous direction of development.
That's the problem... at least security wise... I mean it's no wonder
that no sane person uses ssh -X on other hosts (especially untrusted
ones)... the X protocol is so complex especially with all extensions..
and the typical attacks like global event grabbing or a "screen man in
the middle attack" where a new full screen window tricks you into
something evil... are probably just the simplest ideas of attacking.


> > This includes that users don't expect (or at least they shouldn't have
> > to) that such connections allow wiretapping, e.g. if such a system
> > supports audio forwarding... it shouldn't allow the remote side to
> > activate my MIC and listen to what I say/sing/etc.
> Well, if you switch on audio forwarding in RDP, the other side can do exactly
> that...
Sure... but at least you can turn it of (unfortunately many programs
don't do so by default, neither do they warn you what switching it on
means.


> > That this can indeed lead to compromise showed a recent attack we've
> > had on one our institutes' machines, where sensitive information was
> > caught via an X2go connection and later on used for other attacks.
> Do you have any more in-depth writeup of that attack so we maybe can learn from
> it and look at certain things more specifically?
Well the problem is that I'm not really allowed to give much defaults
(as you can see I also write from my private address)...
Simply said... an attacker took over root on the remote system... and it
seems he did just such sniffing stuff... :/


> > Now for the technical side... admittedly I don't know the details of
> > how NX interacts with X... but there must be some way to achieve
> > blocking of the clipboard sync.
> > Even if the protocol demands to send some content,... well then simply
> > hook in an clear it always (per default).
> 
> Yes, that should be possible. Its just that someone has to implement it.

AFAIU, one would need to do that on the nxproxy level then?


> > Now with NX I understand it's compression at the X protocol level, so
> > "no JPEGs being transferred"... but where do remotes X protocol go to?
> > Directly into the local X? Or is it taken by NX/X2go and rendered as
> > if NX/X2go would be an X server that is displayed in a _single_
> > window of another one (i.e. like Xephyr)?
> Some protocol calls are taken as is and passed to the local X, others are
> "transformed", e.g. made asynchronous, bitmap-compressed, etc.
I see...


> Well, the remote can't take over your system afaik. But there are concerns
> about the security of ssh -X vs. -Y. Keystroke monitoring is one of those
> concerns.
Why don't you do the following:
Not passing on any X stuff to the local X server... but staring an
Xephyr server and sending it there?

Admittedly I don't really know how the Xephyr server itself does things
(I once tried to ask the developers but got no reply)... and if that
would really work like a sandbox ...
At least my hope would be (as it was before with VNC/RDP/NX)... that any
evil remote... could at least only take over the one single window...
and in case of Xephyr... hopefully only the single Xephyr window.



First thanks for your answers...

I'd propose the following now:
As this bug is now cluttered all over with two different issues
- clipboard sniffing and the warning when it was activated
- security measures and better documentation about what NX/X2go really
does

I'd close this bug, and open two new ones, one for each issue...
referencing that old bug... so that all topics can be discussed (perhaps
fixed) in a more simple fashion.

Okay?


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #50 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: x2go-dev@lists.berlios.de, 258@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#258: Bug#258: Bug#258: SECURITY: x2goclient allows clipboard sniffing

Date: Tue, 02 Jul 2013 19:58:06 +0200

[Message part 1 (text/plain, inline)]

On Tue, 2013-07-02 at 11:10 +0400, Nable 80 wrote: 
> > And people don't see x2go (or VNC, or rdp) like a direct access
> > to their X server (as in plain X forwarding with xauth and that like).
> Why do you think so? Because they have it in window and didn't specify
> any option that exactly means 'turn on X11 forwarding'?
To be honest, I think both are strong reasons for expecting this... as
well as one easily tend to compare it with VNC (which gives you rather
the "secure" screenshots)...
But moreover... it's nowwhere really documented (at least where people
easily see it) - I didn't find it at all.
When one goes into the ssh/ssh_config manpages and read about the X
forwarding options... strongly warns one about the security implications
(which are basically like giving root to the remote).
When one reads the xauth manpage (and the fact that there is a dedicated
program which one needs to grant privileges)... one reads about what one
does.

With X2go/NX.. there seem to be no such emphasised warnings in the
obvious places.


> After all, I think that it's not a grave issue as most people use X11
> forwarding for rather trusted hosts (or just don't care).
Well... don't think so... even not for the trusted ones (not to talk
about untrusted hosts)... but this is probably since people have
different requirements on security.


> One additional note: it's possible to turn on clipboard forwarding in
> RDP and VNC (and it's a very useful thing) but AFAIR in most clients
> _one have to specify it implicitly_ (and sometimes there's a separate
> option that allows some restricted clipboard access, for example
Yes... it is... but there you have to at least enable it (even though
most programs miss a strong warning on what can then easily happen...)


But to be honest... the clipboard sniffing problem seems to be "boring"
compared with the "direct interaction" with my local x server... at
least with respect to my security thinking...


Oh and no one from the developers should get me wrong:
I do see that NX is very nice and great with respect to it's speed,
which is probably not doable with VNC like screenshoting.... but a) I
think people are not warned/told enough about what happens
(technically)... and b) clear information misses... on what could
actually happen (in the sense of "is it secure as it is, or can this
direct communication with the local X server cause troubles - perhaps
there are none... and they only issues where those with the global root
window.. which seems not possible with NX? But perhaps there are!).


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #55 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Moritz Struebe <Moritz.Struebe@informatik.uni-erlangen.de>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 258@bugs.x2go.org, x2go-dev@lists.berlios.de

Subject: Re: [X2Go-Dev] Bug#258: Bug#258: Bug#258: Bug#258: SECURITY: x2goclient allows clipboard sniffing

Date: Wed, 03 Jul 2013 10:13:53 +0200

[Message part 1 (text/plain, inline)]

Hey.

On 2013-07-02 19:47, Christoph Anton Mitterer wrote:
> I'd propose the following now:
> As this bug is now cluttered all over with two different issues
> - clipboard sniffing and the warning when it was activated
> - security measures and better documentation about what NX/X2go really
> does
>
> I'd close this bug, and open two new ones, one for each issue...
> referencing that old bug... so that all topics can be discussed (perhaps
> fixed) in a more simple fashion.

I think this is a good Idea. I just want to warn you that this issue
will not have an very high priority, as most/all core devs work in
scenarios where host _and_ client are trusted. None the less
contributions to the documentation are very welcome, and can be easily
contributed without coding skills. ;) - If you need pointers on getting
started feel free to ask.

Morty


-- 
Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter)
Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme)
Friedrich-Alexander-Universität Erlangen-Nürnberg
Martensstr. 1
91058 Erlangen

Tel   : +49 9131 85-25419
Fax   : +49 9131 85-28732
eMail : struebe@informatik.uni-erlangen.de
WWW   : http://www4.informatik.uni-erlangen.de/~morty

[smime.p7s (application/pkcs7-signature, attachment)]

Message #60 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: x2go-user@lists.berlios.de

Cc: 258@bugs.x2go.org

Subject: Re: [X2Go-User] Limiting clipboard sharing

Date: Tue, 28 Jan 2014 15:49:10 +0000

[Message part 1 (text/plain, inline)]

Hi Kris,

On  Mo 27 Jan 2014 18:46:59 CET, Kris Ilowiecki wrote:

> Hello,
>
> I am quite new to X2Go, and really impressed by it. I'd like to  
> switch from opennx to X2Go, but I can't find a way to limit  
> clipboard sharing.
>
> Opennx, as well as other NX forks, has the options to enable clipboard
> sharing both ways, one-way, or disable it completely. So far I have  
> failed to find a setting to limit this in X2Go.
>
> I'd need clipboard sharing to work only in the client->server
> direction, or at least to disable it completely.
>
> I have searched for it for quite a while, but the best I have  
> managed to find is a bug report
> http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=258
> and a mailing list question without a single reply.
>
> Is there some way to configure it?
> If not, is it going to be hard to write a patch that would turn
> this off at compilation time?
> I've also been thinking of using some external programs to achieve  
> the effect, e.g. putting X2Go inside Xephyr, or the other way round...
>
> Any hints most welcome
>
> Many thanks,
> Kris

There should be two approaches...

 1) disable clipboard server-side for all users
 2) disable clipboard in X2Go Client / PyHoca-GUI on the client-side

The first is easy. Please look at /usr/bin/x2gostartagent of  
x2goserver package and make clipboard configurable via  
/etc/x2go/x2goserver.conf. Send a patch to our BTS [1].

The second approach is for us devs, I guess...

The workaround provided by Mike#2 is a fine approach, but not a real  
solution to this problem.

Mike#1

[1] http://wiki.x2go.org/doku.php/wiki:bugs
-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Message #65 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Kris Ilowiecki <kril@sourcecap.ch>

To: x2go-user@lists.berlios.de

Cc: 258@bugs.x2go.org

Subject: Re: [X2Go-User] Limiting clipboard sharing

Date: Tue, 28 Jan 2014 17:11:36 +0100

Hi Mike#1,

On 01/28/2014 04:49 PM, Mike Gabriel wrote:
> There should be two approaches...
>
>   1) disable clipboard server-side for all users
>   2) disable clipboard in X2Go Client / PyHoca-GUI on the client-side
>
> The first is easy. Please look at /usr/bin/x2gostartagent of x2goserver
> package and make clipboard configurable via /etc/x2go/x2goserver.conf.
> Send a patch to our BTS [1].
>

Thank you very much!
The first approach is indeed what is needed in my case.
I will have a look there.

I have been looking through the sources, and my most recent idea was
experimenting with editing /usr/bin/nxagent to run nxagent.bin
with something like "-clipboard no"

I will try the exact approach you are suggesting, though
my bash+awk aren't that good

Many thanks,
Kris

> The second approach is for us devs, I guess...
>
> The workaround provided by Mike#2 is a fine approach, but not a real
> solution to this problem.
>
> Mike#1
>
> [1] http://wiki.x2go.org/doku.php/wiki:bugs

Message #70 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Krzysztof Ilowiecki <krzysztof.ilowiecki@sourcecap.ch>

To: x2go-user@lists.berlios.de

Cc: 258@bugs.x2go.org

Subject: Re: [X2Go-User] Limiting clipboard sharing

Date: Tue, 28 Jan 2014 19:05:49 +0100

On 01/28/2014 05:11 PM, Kris Ilowiecki wrote:
> I have been looking through the sources, and my most recent idea was
> experimenting with editing /usr/bin/nxagent to run nxagent.bin
> with something like "-clipboard no"
>
> I will try the exact approach you are suggesting, though
> my bash+awk aren't that good

just a short update, the crude approach I had tried
(hacking /usr/bin/nxagent) seems to be working.
I just had made the mistake of typing "-clipboard no" instead of
"-clipboard none" or "-clipboard client".

I will have a closer look at editing the x2gostartagent to read 
x2goserver.conf, but I don't know if I'll succeed at this point.

Many thanks,
Kris

Message #77 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: 258@bugs.x2go.org

Cc: control@bugs.x2go.org, 507@bugs.x2go.org, 508@bugs.x2go.org

Subject: Make clipboard security choosable from client

Date: Fri, 27 Jun 2014 18:13:17 +0000

[Message part 1 (text/plain, inline)]

clone #258 -1
reassign -1 x2goserver
retitle -1 Provide support in X2Go Server for making clipboard  
security choosable by the client
block #258 by -1
block #507 by -1
block #508 by -1
thanks


Hi all,

I am currently working on making the clipboard modes configurable on  
the X2Go Client side.

Clipboard modes in NX are:

  o c+p in both directions (server->client, client->server)
  o c+p server->client
  o c+p client->server
  o no copy+paste at all

Greets,
Mike
-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Message #86 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: o.schneyder@phoca-gmbh.de

Cc: 258@bugs.x2go.org

Subject: Clipboard mode configuration via X2Go Client session profiles

Date: Sun, 29 Jun 2014 15:01:19 +0000

[Message part 1 (text/plain, inline)]

Hi Alex,

I have recently added means to set the clipboard (security) mode in  
X2Go sessions. That there is no way of restricting clipboard  
functionality in X2Go sessions has been quite an issue a while back on  
our mailing list and on the Debian bug tracker.

So, what I have done...


NX:

First, a patch for NX was necessary [1]. This patch adds the clipboard  
NX option to nxagent/x2goagent. There was some code for that already  
present in NX, but it looked like the feature never got finished (or  
other).


X2Go Server:

Second, I added a new cmdline arg to x2gostartagent and  
x2goresume-session [2]. Clients, that want to set the clipboard mode,  
have to send "both", "server", "client", or "none" as 10th cmdline  
parameter to x2gostartagent and as 8th cmdline parameter to  
x2goresume-session. If the client does not send that field, X2Go  
Server uses the default mode ("both").

If you want to test if an X2Go Server supports the clipboard mode  
feature, you can query

  $ x2gofeature X2GO_CLIPBOARD_MODES
  ok


Client-side:

Third, and this is what this mail is about, X2Go Client needs to send  
the clipboard mode to the server (x2gostartagent, x2goresume-session).  
In Python X2Go / PyHoca-GUI, I have already implemented this.

Python X2Go stores the clipboard information in ~/.x2goclient/sessions  
under the option name "clipboard=<str>" where its values can be  
"both", "server", "client", "none".

Relevant commits are: [3], [4], [5].

In X2Go Client's session profile window, the clipboard mode has to be  
made configurable.

Whenever you have time, can you take a look at that? Thanks.

light+love,
Mike



NX:

[1]  
http://code.x2go.org/gitweb?p=nx-libs.git;a=commitdiff;h=0cf283dca109ff29e18cd36fdbd2e51dadd52772;hp=c62b81304ca9906fe608f7387025162107d8d8ab

X2Go Server:

[2]  
http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=669b3aabb8f574a2bb30d415fb38b1ccf6837f0d

Python X2Go (combine the two commits to make sense):

[3]  
http://code.x2go.org/gitweb?p=python-x2go.git;a=commitdiff;h=08ff742334427cbe52ee02c354b9d73c53459f2e
[4]  
http://code.x2go.org/gitweb?p=python-x2go.git;a=commitdiff;h=2aa779efe39a045e6492ff891e5c5ce34393d6fc

PyHoca-GUI (session profile manager):

[5]  
http://code.x2go.org/gitweb?p=pyhoca-gui.git;a=commitdiff;h=d9d413b00fc92e35e4c9f752c853ba72c1399384
-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Message #91 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: 258-submitter@bugs.x2go.org

Cc: control@bugs.x2go.org, 258@bugs.x2go.org

Subject: X2Go issue (in src:x2goclient) has been marked as pending for release

Date: Mon, 30 Jun 2014 17:15:43 +0200 (CEST)

tag #258 pending
fixed #258 4.0.2.1
thanks

Hello,

X2Go issue #258 (src:x2goclient) reported by you has been
fixed in X2Go Git. You can see the changelog below, and you can
check the diff of the fix at:

    http://code.x2go.org/gitweb?p=x2goclient.git;a=commitdiff;h=eb6feb3

The issue will most likely be fixed in src:x2goclient (4.0.2.1).

light+love
X2Go Git Admin (on behalf of the sender of this mail)

---
commit eb6feb3e7c40274aa7b7a36bb9148090cab9ec4f
Author: Oleksandr Shneyder <o.shneyder@phoca-gmbh.de>
Date:   Mon Jun 30 16:01:16 2014 +0200

    Add "clipboard" parameter to session profile and to command line options. Replace qCritical() with printError() by argument parsing. (Fixes: #258).

diff --git a/debian/changelog b/debian/changelog
index 19e3e2f..2d5b6d3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -45,6 +45,9 @@ x2goclient (4.0.2.1-0x2go1) UNRELEASED; urgency=low
       enabled.
     - Fork x2goclient on windows and terminate child processes if x2go client
       crashed. (Fixes: #159).
+    - Add "clipboard" parameter to session profile and to command line options.
+      (Fixes: #258).
+    - Replace qCritical() with printError() by argument parsing.
     - Update translation files.
     - Update russian translation.
     - Update string "&Clipboard Mode" and translate in russian translation file.

Message #103 received at 258@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: 258-submitter@bugs.x2go.org

Cc: control@bugs.x2go.org, 258@bugs.x2go.org

Subject: X2Go issue (in src:x2goclient) has been marked as closed

Date: Tue, 21 Oct 2014 13:26:09 +0200 (CEST)

close #258
thanks

Hello,

we are very hopeful that X2Go issue #258 reported by you
has been resolved in the new release (4.0.3.0) of the
X2Go source project »src:x2goclient«.

You can view the complete changelog entry of src:x2goclient (4.0.3.0)
below, and you can use the following link to view all the code changes
between this and the last release of src:x2goclient.

    http://code.x2go.org/gitweb?p=x2goclient.git;a=commitdiff;h=04ed56d4162f000b093bea13aa2582c2de718144;hp=85bf0c6e7539910fff779689528009a897cdceb4

If you feel that the issue has not been resolved satisfyingly, feel
free to reopen this bug report or submit a follow-up report with
further observations described based on the new released version
of src:x2goclient.

Thanks a lot for contributing to X2Go!!!

light+love
X2Go Git Admin (on behalf of the sender of this mail)

---
X2Go Component: src:x2goclient
Version: 4.0.3.0-0x2go1
Status: RELEASE
Date: Tue, 21 Oct 2014 12:38:56 +0200
Fixes: 108 159 253 258 336 474 522 525 566 568 571 580 587 590 597 603 607 608 609 612 636
Changes: 
 x2goclient (4.0.3.0-0x2go1) RELEASED; urgency=low
 .
   [ Mike Gabriel ]
   * New upstream release (4.0.3.0):
     - Disallow server-side users to override X2Go Server commands via
       ~/bin (or similar). (Fixes: #336).
     - Avoid unitialised variables on early calls of ONMainWindow::closeEvent()
       or ONMainWindow::closeClient(). (Fixes: #253).
     - Update translation files. Add empty Portuguese translation. Update
       qt_<lang>.qm files from Debian unstable as of today.
     - Update German translation file (after session folder feature got added).
     - Makefile.man2html: Test if man2html exists. If not, don't fail.
     - Honor exports (client-side shared folders) from broker session profiles.
       Thanks to Ming Song for providing a patch for this (Fixes: 612).
   * debian/control:
     + Add B-D: apache2-dev. On squeeze / lucid builds, this is a superfluous
       B-D, but for later Debian/Ubuntu versions, this smoothes the installation
       of the x2goplugin-provide bin:package.
     + Update B-D: apache2-dev | libc6-dev. The apache2-dev package does not
       exist on all Debian/Ubuntu versions.
   * x2goclient.spec:
     + Adapt to building for openSUSE/SLES.
     + openSUSE: Make Qt4 Linguist tools available for Makefile.
     + Upgrade versioned BR for libssh-devel (0.6.3 or patched 0.5.5).
     + The libqt4-linguist split off happened in openSUSE 13.1.
     + Add x2goclient-rpmlintrc file.
     + In openSUSE, it is openldap2-devel, in Fedora/RHEL it is openldap-devel.
     + In openSUSE, openssh is openssh (not openssh-clients / openssh-server).
 .
   [ Oleksandr Shneyder ]
   * New upstream release (4.0.3.0):
     - Fix running x2goclient without arguments on Windows. (Fixes: #522).
     - Save proxy output in $HOME/S-$SESSION-ID/session.log if debugging is
       enabled.
     - Fork x2goclient on windows and terminate child processes if X2Go Client
       crashed. (Fixes: #159).
     - Add "clipboard" parameter to session profile and to command line options.
       (Fixes: #258).
     - Replace qCritical() with printError() by argument parsing.
     - Update translation files.
     - Update russian translation.
     - Update string "&Clipboard Mode" and translate in russian translation file.
     - Grammar fix in russian translation.
     - Add x2gohelper to start X2Go Client on Windows and clean child processes
       if X2Go Client crashes. (Fixes: #525).
     - On Windows rename x2goclient.exe to x2goclient-mainprocess.exe and
       x2gohelper.exe to x2goclient.exe.
     - Start x2gohelper from X2Go Client. Revert name changing of X2Go Client and
       x2gohelper.
     - Add Makefile for x2gohelper.
     - Add support for sessions folders.
     - Add folder explorer: a GUI to manage of session subfolders.
     - Support for sessions subfolders in sessionmanagedialog.
     - Session name autocompletion only for sessions in current folder.
     - Support for session subfolders and command-line options "--session"
       and "--sessionid".
     - Disable session explorer "back" button if user sessions are disabled.
     - Include <QDir> in sessionexplorer.cpp.
     - Remove deprecated workaround in wapi.cpp.
     - Save folder icons Base64 coded. Save icons under General\icon_<PATH>.
       (Fixes: #580).
     - Fix placing sessions folders in broker mode.
     - Fix onmainwindow.cpp after 76ae96781f1d2d5754ee4751539d5de47f1d0297.
     - Add support for session selection in broker mode.
 .
   [ Mike DePaulo ]
   * New upstream release (4.0.3.0):
     - Make X2Go Client aware of the Cinnamon (CINNAMON) desktop environment.
       (Fixes: #571)
     - Make X2Go Client aware of the Trinity (TRINITY) desktop environment.
       (Fixes: #609)
     - Make X2Go Client aware of the Openbox (OPENBOX) window manager.
       (Fixes: #607)
     - Make X2Go Client aware of the IceWM (ICEWM) window manager.
       (Fixes: #608)
     - Windows: Fix not being able to add the server to the known_hosts file when
       the username has non-English characters. (Fixes: #566)
       (NOTE: This fix only works when the non-English characters are in the same
       language as the Windows "system locale" AKA "Language for non-Unicode
       programs." Bug #611 was written for fixing the issue for languages other
       than the system locale.)
       Thanks George Trakatelis (uom.edu.gr) for submitting part of this fix.
     - Windows: Install VcXsrv "misc" fonts by default, and make all 4 font
       groups optional: misc, 75dpi, 100dpi and others (Fixes: #108)
       Note: The fact that all the fonts are included makes the installer about
       30MB larger.
     - Windows: Bundle new version of VcXsrv: 1.15.2.1-xp+vc2013+x2go1
       This new version is based on upstream VcXsrv 1.15.2.0, but still
       compatible with Windows XP. It also has its bundled OpenSSL updated to
       1.0.1j. It is compiled with Microsoft Visual C++ 2013 and contains 1
       X2Go-specific change, winmultiwindow.patch. This patch fixes an issue
       when resizing the NX-proxy window on specific multiple monitor setups.
       (Thanks Oleksandr Shneyder for the patch) (Fixes: #568) (Fixes: #594)
     - Windows: Port from MinGW 4.4 + Qt 4.8.5 to MinGW 4.8.2 + Qt 4.8.6,
       including fix for QTBUG-38706 (Fixes: #474, #603)
     - Windows: Fix missing VcXsrv/zlib1.dll . The impact of this bug was that
       VcXsrv would not start if the cwd was changed from the x2goclient
       directory. (The start menu and desktop shortcuts do have the x2goclient
       directory as the cwd. So they were not affected.) (Fixes: #587)
     - Windows: Make the desktop shortcut optional during install,
       but still the default.
     - Windows: Upgrade libssh from 0.5.5 to 0.6.3. This fixes connecting to
       hpn-enabled SSH servers. The Pageant support patch from the KDE Windows
       project was ported to 0.6.3 by myself and Mike Frederick.
       (Gmail: psududemike) (Fixes: #590)
     - Windows: Win32 OpenSSL updated from 1.0.1h to 1.0.1j, which fixes the
       CVEs announced on 2014-08-06 & 2014-10-15.
     - Windows: Replace Cygwin Bash (sh.exe) with Cygwin Dash (ash.exe renamed
       to sh.exe). This also means fewer Cygwin .DLLs are bundled.
       (Fixes: #636)
     - Windows: cygwin packages (excluding OpenSSH, which is at the patched
       version of 6.6.1p1-3-x2go1) updated from latest versions as of 2014-06-09
       to latest versions as of 2014-10-18. This includes openssl 1.0.1j-1, which
       fixes the CVEs announced on 2014-08-06 & 2014-10.15.
       (Cygwin openssl was also individually updated in 4.0.2.1+hotfix1+build2,
       but only to 1.0.1i-1.)
     - Windows: Build nxproxy.exe with Cygwin's libpng 1.5.x rather than 1.2.x.
       (This may improve performance when PNG compression is selected.)
     - Windows: Build cygwin openssh without krb5 or tcp_wrappers support because
       X2Go Client for Windows does not use either feature.
       (On Windows, Kerberos 5 (GSSAPI) support is provided by PuTTY.)
     - Windows: Fix text not being rendered properly at end of NSIS installer
       (Fixes: #597)
 .
   [ Stefan Baur ]
   * New upstream version (4.0.3.0):
     - Update German translation file.
 .
   [ Ricardo Díaz Martín ]
   * New upstream version (4.0.3.0):
     - Update Spanish translation file.
 .
   [ Martti Pitkanen ]
   * New upstream version (4.0.3.0):
     - Update Finnish translation file.
 .
   [ Jos Wolfram ]
   * New upstream version (4.0.3.0):
     - Update Dutch translation file.
 .
   [ Robert Parts ]
   * New upstream version (4.0.3.0):
     - Add Estonian translation file.
 .
   [ Klaus Ade Johnstad ]
   * New upstream version (4.0.3.0):
     - Update Bokmal (Norway) translation file.
 .
   [ Daniel Lindgren ]
   * New upstream version (4.0.3.0):
     - Update Swedish translation file.
 .
   * Translation status:
     OK - Updating 'x2goclient/x2goclient_de.qm'...
       Generated 566 translation(s) (566 finished and 0 unfinished)
     INCOMPLETE - Updating 'x2goclient/x2goclient_da.qm'...
       Generated 536 translation(s) (526 finished and 10 unfinished)
       Ignored 30 untranslated source text(s)
     OK - Updating 'x2goclient/x2goclient_es.qm'...
       Generated 566 translation(s) (566 finished and 0 unfinished)
     OK - Updating 'x2goclient/x2goclient_et.qm'...
       Generated 566 translation(s) (566 finished and 0 unfinished)
     OK - Updating 'x2goclient/x2goclient_fi.qm'...
       Generated 566 translation(s) (566 finished and 0 unfinished)
     INCOMPLETE - Updating 'x2goclient/x2goclient_fr.qm'...
       Generated 254 translation(s) (201 finished and 53 unfinished)
       Ignored 312 untranslated source text(s)
     OK - Updating 'x2goclient/x2goclient_nb_no.qm'...
        Generated 566 translation(s) (566 finished and 0 unfinished)
     OK - Updating 'x2goclient/x2goclient_nl.qm'...
       Generated 566 translation(s) (566 finished and 0 unfinished)
     UNTRANSLATED - Updating 'x2goclient/x2goclient_pt.qm'...
       Generated 0 translation(s) (0 finished and 0 unfinished)
       Ignored 566 untranslated source text(s)
     INCOMPLETE - Updating 'x2goclient/x2goclient_ru.qm'...
       Generated 552 translation(s) (543 finished and 9 unfinished)
       Ignored 14 untranslated source text(s)
     OK - Updating 'x2goclient/x2goclient_sv.qm'...
       Generated 566 translation(s) (566 finished and 0 unfinished)
     INCOMPLETE - Updating 'x2goclient/x2goclient_zh_tw.qm'...
       Generated 397 translation(s) (372 finished and 25 unfinished)
       Ignored 169 untranslated source text(s)

Send a report that this bug log contains spam.