FFe: Backport new RDP settings

[Robert Ancell]

We are shipping some GNOME 41 and some GNOME 42 components in jammy. In GNOME 42 the remote desktop support moved from VNC to RDP. We have the updated gnome-remote-desktop in jammy, but not the settings changes in gnome-control-center 41. The proposal is to backport these settings.

[Robert Ancell (robert-ancell)]

Proposed changes are in https://salsa.debian.org/gnome-team/gnome-control-center/-/tree/ubuntu/sharing-rdp

[Robert Ancell (robert-ancell)]

Freeze exception emails:
https://lists.ubuntu.com/archives/ubuntu-doc/2022-April/020825.html
https://lists.ubuntu.com/archives/ubuntu-translators/2022-April/007830.html

[Łukasz Zemczak (sil2100)]

Hey Robert! Can you provide some build logs of the new gnome-control-center changes (like, maybe a link to a PPA)? It's super late for such changes, but I'm less worried of regressions than of translators and documentation people not having enough time to handle these UI changes.

[Gunnar Hjalmarsson (gunnarhj)]

My first question would be: Can the changes to gnome-remote-desktop be reverted?

If that's not considered possible/desirable, I'd say that while this is awfully late for new translatable strings, I think the importance of the proposed change overweighs that we will see the new strings untranslated in many languages. Translators will have the opportunity to repair It in 22.04.1.

So from a translators POV I would prefer it to be uploaded ASAP, so the translators at least are given a chance to get at it (the deadline is on Thursday 21:00 UTC).

As regards docs, the related GNOME 41 docs (which will shipped with Ubuntu 22.04) is already not excellent:

https://help.ubuntu.com/stable/ubuntu-help/sharing-desktop.html

All they did so far for GNOME 42 is an additional comment (not visible to users):

https://gitlab.gnome.org/GNOME/gnome-user-docs/-/commit/b02a44c6

There is also a discussion about improving the docs:

https://gitlab.gnome.org/GNOME/gnome-user-docs/-/issues/135

So from a docs POV, the documentation/communication aspect of the change will result in confusion, which brings me back to the first question: Can the changes to gnome-remote-desktop be reverted?

[Jeremy Bícha (jbicha)]

Gunnar, on Friday, Seb fixed gnome-control-center to work with the new gnome-remote-desktop using VNC like was done in previous Ubuntu/GNOME releases.

However, we think that our users will be more comfortable using RDP.

The documentation you pointed to doesn't document VNC well.

The GNOME feature we are backporting would make that page out of date.
- Screen Sharing is now Remote Desktop
- For #7, there is now a Remote Control on/off switch
- There is no require a password or ask for access.

We also could document remote desktop using Discourse. Except for the translation problem, that is a faster way to provide Ubuntu-specific docs.

Marco was looking today at also allowing users to switch to VNC with this dialog as an Ubuntu patch. If we are able to do that, we think that fixes the main regression risk here.

If we don't provide this dialog, there really isn't a user-friendly for people to be able to share their desktop using RDP at all. That is a requested feature.

[Gunnar Hjalmarsson (gunnarhj)]

Thanks for your input, Jeremy.

We seem to be agreed that the insufficient documentation is the most important aspect of this. Somebody who really knows the topic needs to improve it. As far as I know the needed resources are not available in the docs team. Neither in the GNOME Help team.

Right, a discourse page could be published instantly. There is also the option that somebody updates sharing-desktop.page soon after the release. Maybe also for GNOME Help. Then we could add it to the desktop guide before the 22.04.1 point release.

Please note that the docs team or the translators team does not have a veto as regards freeze breaks. The decision lies with the release team. I merely wanted to express my frustration over the poor documentation of this rather advanced area.

[Marco Trevisan (Treviño) (3v1n0)]

More rationale from upstream.

00:03:00 <_pnowack> Trevinho: Assuming the backported UI works here, I think this change is good: It aligns with the state in GNOME 42 upstream and the RDP should be more stable than the VNC one. At least, when I found crashes I was able to fix them for the RDP backend and when I found bugs in FreeRDP upstream, then they were adressed pretty fast. The same cannot be said about libvncserver upstream
00:03:53 <Trevinho> _pnowack: also jadahl mentioned a security aspect of it, like keeping vnc enabled was a security concern per se
00:04:14 <Trevinho> can elaborate more on that?
00:05:18 <_pnowack> Trevinho: jadahl introduced for both the RDP and VNC backend an 'enabled' setting (which defaults to off). The reason is that the VNC server won't be silently enabled, when enabling RDP in g-c-c
00:05:30 <_pnowack> (VNC can still be used via grdctl though)
00:06:44 <_pnowack> Trevinho: Regaring security: VNC connections are not encrypted. Fedora uses some additional patches for this, but only a few clients support encrypted connections. For RDP, TLS is the default and g-r-d enforces that.
00:08:07 <_pnowack> which is also the reason why the new Remote Desktop panel has the 'Verify Encryption' button, allowing users to check the server certificate fingerprint (which should be the same, when connecting with an RDP client)
_pnowack> Also: The clipboard integration in the RDP backend is more advanced (as the protocol allows it to be): Not just text, can be copied, but also images and files. Also, the RDP protocol uses delayed clipboard data rendering, meaning the clipboard content is only transferred when requested (VNC sets the clipboard content, meaning it is directly requested and transferred)
00:11:37 <_pnowack> Of course, the used RDP client needs to support clipboard integration too, to make use of that
00:12:25 <_pnowack> (Remmina, for example, only implements the clipboard support for text and images, but not files.)

[Jeremy Bícha (jbicha)]

Gunnar, it looks like the GNOME did update their sharing-desktop.page for the bullet points I mentioned. Maybe you can use their version for jammy if this FFe is approved?

[Gunnar Hjalmarsson (gunnarhj)]

@Jeremy: Wow, that hadn't been pushed when I looked this morning. But we should probably use it in jammy then. I think I'll simply use a gnome-user-docs patch. Better untranslated than incorrect.

To the release team: I added a gnome-user-docs task to this bug, since the just mentioned measure would be a clear UIF break. Please take a stand on that too when making your decision.

[Robert Ancell (robert-ancell)]

Łukasz - PPA here https://launchpad.net/~robert-ancell/+archive/ubuntu/gnome-control-center

[Jonas Ådahl (jadahl)]

Some more upstream reasoning for switching from VNC to RDP:

Some releases ago an RDP backend was added to gnome-remote-desktop, using the FreeRDP's RDP implementation, while the VNC backend uses the LibVNCServer project's implementation. Over time, the RDP backend significantly surpassed the abilities of the VNC backend, both in terms of features and performance, and we had contemplated switching the default backend in the past already. It's also worth noting that the RDP protocol doesn't have awkward limitations on password length in the commonly used authentication mechanism. Also, from an "outsiders" point of view, FreeRDP feels like a much more active project than LibVNCServer, and RDP is simply a more capable protocol.

A side note about security of the VNC backend: the original intention with the VNC backend was to more or less mimic the functionality of vino, which had an out-dated fork of LibVNCServer bundled with it. Having a fork of a library that tends to get its fair share of CVE's didn't feel like a good idea, so the upstream library was used directly. However, to get the same level of encryption (anon-tls), LibVNCServer still needed to be patched. Patches were originally contributed in 2018, but has not landed yet, thus to get anon-tls encryption, distributions needs downstream patching. With the RDP backend, we both moved away from non-verifiable anon-tls as well as downstream patching.

One thing that has stopped us from switching the backend in the past has been the need to re-design the settings dialog. It had been planned to change the design of said dialog for some time already, but it was a non-trivial task, since it involved more complicated steps, such as TLS key/cert generation, management and verification. For GNOME 42, however, we managed to both get designs as well as implement them in Settings, thus it made us feel like it was a good opportunity to make the switch.

Originally we intended to have a "blue bar" with a note about the VNC backend being enabled, with the option of disabling it. This blue bar was disabled, after dropping the plan to try to automatically enable the VNC backend on upgrade. The primary reason for dropping this was that any risk of enabling the VNC backend by accident was too big of a risk, given the security implications of unknowingly running a VNC remote desktop server. It was also discussed whether it should be possible to configure the VNC backend as well as the RDP backend, but the design team decided against it; instead we added the command line utility 'grdctl' that allows configuration the VNC backend.

[Łukasz Zemczak (sil2100)]

Ok, thank you for all the great context everyone! I am still worried that all of this lands so late and just a few days before Final Freeze. That being said, as I see that Gunnar seems to be +1 on having this change in jammy, I would generally be fine with this FFe.

However, I see that the build FTBFS in the PPA that Robert provided?!
https://launchpad.net/~robert-ancell/+archive/ubuntu/gnome-control-center

This does feel great I must say. Have these changes not been tested before then? Can it be made buildable and testable before we accept the FFe and UIFe?

[Jeremy Bícha (jbicha)]

Yes, it is buildable. I was running it yesterday. It was just missing one build-dependency so I added it and have done a PPA build for you:

https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/ppa/+sourcepub/13423577/+listing-archive-extra

[Łukasz Zemczak (sil2100)]

Okay, thank you. In that case, please proceed o/

[Robert Ancell (robert-ancell)]

Uploaded as 1:41.4-1ubuntu11

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-user-docs - 41.5-1ubuntu2

---------------
gnome-user-docs (41.5-1ubuntu2) jammy; urgency=medium

  * debian/patches/update_sharing-desktop.page.patch:
    - Update to the GNOME 42 version to reflect significant changes to
      the gnome-remote-desktop and gnome-control-center packages
      (LP: #1968518).

 -- Gunnar Hjalmarsson <email address hidden> Tue, 12 Apr 2022 21:48:35 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-control-center - 1:41.4-1ubuntu11

---------------
gnome-control-center (1:41.4-1ubuntu11) jammy; urgency=medium

  * debian/patches/ubuntu/sharing-rdp/*.path:
    - Backport RDP support (LP: #1968518)
  * debian/patches/ubuntu/update-vnc-key.patch:
    - Dropped as fixed in the above backport.

 -- Robert Ancell <email address hidden> Wed, 13 Apr 2022 11:38:18 +1200

[Sebastien Bacher (seb128)]

Random thoughts there

VNC was never on by default, if it's enabled it is because the user went to the setting to turn it on so it shouldn't come to a surprise to them that they are sharing their desktop. Since it's an user decision and something they might rely on, it feels rude to turn if off for them on upgrade and probably not what users are going to expect?

we probably still want the blue bar since that's the only way to avoid the possibility of 'unknowingly running a VNC remote desktop server.'. Upgrades aren't the only case to consider, we will have users copying a grdctl cmd from the internet and forgetting about it or not understand what they are doing.

[Fran (pacod-u)]

So sorry that VNC support has been discontinued.

Just upgraded to 23.04 and found that the only solution to connect from my android devices over internet is run a VNC app to connect over a SSH tunnel to a vncserver in the :1 display, and from that :1 display start a remmina session using RDP to reach my main :0 display.

Also, "grdctl vnc enable" dind't make it work.

It's not very understandable why the VNC support has disappeared. We use it and love it so much. And the pair SSH tunnel + VNC session has been working for decades now in almost every client OS.

Thank you for all your work and all your efforts; hope you reconsider your decission.