GNOME, Linux

ThunderBolt Security Levels and Linux desktop

Recently I got Dell XPS 13 as my new work laptop and I use it with the TB16 dock. This dock doesn’t seem to fully work with Linux, only monitors work. But if you go to BIOS settings and set the Thunderbolt Security level to “No security”. Then suddenly almost everything is working.

However, it’s not an ideal solution, especially if you’re at least a bit paranoid. External Thunderbolt devices may connect to the machine via PCI-Express which means they can potencially read your system memory. That’s why Thunderbolt comes with a security system.

There are 4 security levels:

  • none (legacy mode): no security, everything gets enabled.
  • dponly: no PCIe tunneling, only USB and DisplayPort.
  • user: ask the user if it is ok to connect the device.
  • secure: as “user” but also create and use a random key that later can be used on subsequent connects of the same device to ensure its identity.

Intel is already working on a Linux implementation of TB security. But the user and secure levels need user’s action, so there will have to be some support for it in the desktop. I discussed that with designers and they don’t really like the idea of poping up dialogs asking users if they trust the device. “Do I trust this projector? I’m not really sure, but since I’m plugging it in, I guess I do”.

I also checked how it works in Windows 10. And it works exactly that way. I plugged in the dock and I got a bunch of dialogs asking about every single plugged-in device. The experience is pretty terrible. And I have to agree with the designers, I’m not sure how this improves security.

On the other hand, I don’t think it’s a good idea to leave the Thunderbolt port completely unprotected. There is one relevant use case: you leave your computer unattanded and even though you locked your screen, someone can access your system through an unsecured TB3 port.

I wonder if it could be solved by automatically switching to a “reject everything” mode once you lock your screen. You lock your screen, leave your computer, and any device plugged into the TB3 port would be rejected. Once you come back and unlock your screen, it’s your responsibility what you plug in and any plugged device would be accepted.

I wonder if there is any relevant use case which would not be covered well by this policy. Any ideas?

Fedora, GNOME

Printing Improvements for Fedora 27 Workstation

Fedora 26 is not out yet, but it’s already time to think about how to improve the Workstation edition of Fedora 27. One of the areas my team is focusing on is printing (the desktop side of it). For GNOME 3.24 and Fedora 26 Workstation we landed a new interface for the printing module in GNOME Control Center. It gives a much cleaner overview of printers that are set up on your system.

One thing that I think deserves an improvement is printer sharing. GNOME Control Center doesn’t allow you to easily share a printer with other devices over the network. I’ve heard users complain about it and the competition provides it (even though Windows do it very unintuitively). Sharing via IPP is a pretty low hanging fruit because that’s what CUPS already perfectly supports, you just need to expose it in the UI.

A common use case is sharing a printer with your mobile devices. iOS uses AirPrint which is an extension of the IPP,  you just need to convince the device that it’s talking to an AirPrint server. To support Android devices, I think the best way is to use Google Cloud Print. We already support Google Cloud Print, but from the client side. I wonder if it’d be useful to support the server side as well. Google provides an open source server implementation, but it’s written in Go and unnecessarily advanced for our use cases, so writing our own implementation would probably be a better way to go. But I wonder if it’d be worth it. Do people use Google Cloud Print? If not, how do you print from your Android device?

Or are there any other things you think we should improve in printing (desktop-wise)?

Fedora, GNOME, Linux

Nextcloud & Linux Desktop

I’ve used different services for my personal agenda and I always valued if they could well integrate into my Fedora Workstation. Some did it well, some at least provided a desktop app, some only had a web client. That’s fine for many people, but not for me. Call me old-school, but I still prefer using desktop applications and especially those who look and behave natively.

Last summer, I decided to install Nextcloud on my VPS. Originally I was planning to replace Dropbox with it, but then I found out I could actually use it for many other things, for all my personal agenda. Shortly after that I realized that I’d found what I was always looking for in terms of integration into my desktop. Nextcloud apps use standard protocols and formats and integrate very well with the desktop apps I use.

nextcloud

Nextcloud/ownCloud is supported by GNOME Online Accounts, so I log in to my server and automagically get this:

Files – my Nextcloud appears in Nautilus as a remote disk. I like that it doesn’t work like the official desktop client of Nextcloud or Dropbox and doesn’t sync files to the local drive. If you work with small files and documents remotely, you can hardly notice lags and they don’t consume space on your hard drive. If I want to work with large files (e.g. video) or offline, I just download them.

Documents – documents that are stored on your Nextcloud server appear among documents in GNOME Documents. The app makes an abstraction layer over different file sources and the user can work with documents no matter where they come from. A nice thing, but I’m a bit conservative in this and prefer working with files and Nautilus.

Contacts – the Nextcloud app for contacts uses CardDAV, so after a login in GOA your contact list appears in all applications that are using the evolution-data-server backend. In my case it’s Evolution and GNOME Contacts. Evolution is still my daily driver at work while I use the specialized apps at home.

Calendars – the calendar app for Nextcloud uses CalDAV, so after a login in GOA you get the same automagic like with contacts, your calendars appear in all apps that are using evolution-data-server. Again in my case it’s Evolution and GNOME Calendar.

Tasks – CalDAV is also used for tasks in Nextcloud, so if you enable calendars in GOA, your task lists will also appear in Evolution or GNOME Todo.

snc3admek-z-2017-03-01-22-47-36
GNOME Todo

Notes – the same applies to notes, you will also be able to automagically access them in Evolution or GNOME Bijiben.

News – the only thing I had to set up separately is a news reader. I use FeedReader which (among other services) supports Nextcloud/ownCloud, too. So I could replace Feedly with it and get a native client as a bonus.

snc3admek-z-2017-03-01-22-34-49
FeedReader

What’s really great is that except for the RSS reader everything is set up with one login. I’m done with Feedly, Evernote, Wunderlist and all those services that each require another login and generally have poor desktop integration. Now I can use Nextcloud, have all my data under control and get great and super-easy-to-setup integration into my desktop.

I can imagine even more areas where Nextcloud can improve my desktop experience. For instance, it’d be great if my desktop user settings could be synced via Nextcloud or I could back them up there and then restore them on my new machine. Or it’d be great if the desktop keyring could work with Passman and sync your passwords.

BTW integration into my Android phone is equally important to me and Nextcloud doesn’t fail me there either although setting it up was not as easy as in my Fedora Workstation. I needed to install CalDAV-Sync and CardDAV-Sync apps (DAVdroid which is officially recommended by Nextcloud never worked for me, a while back it didn’t want to sync my contact list at all, now it does, but doesn’t import photos). Then my contacts and calendars were synced to the default apps. For tasks I use OpenTasks. For RSS ownCloud/Nextcloud Reader and for notes MyOwnNotes. To access files Nextcloud provides their own app.

And if I’m not around my PC or phone, I can always access all the services via the web interface which is pretty nice, too. So all in all I’ve been really satisfied with Nextcloud and am really happy how dynamically it’s developing.

GNOME

GNOME hackaton in Brno

Last week, we had a presentation on Google Summer of Code and Outreachy at Brno University of Technology. Around 80 students attended which was a pretty good success considering it was not part of any course. It was a surprise for the uni people as well because the room they booked was only for 60 ppl.

The main reason why we did the presentation is that there have been very few students in Brno who participated in such programs. And the open source community is pretty big at local universities due to the presence of Red Hat. When we asked students who had heard of Google Summer of Code or Outreachy before only two raised their hands. That was even fever then we expected.

Shortly before the presentation, we discovered that the money reward for successfully finishing Google Summer of Code was not the same globally any more. And for the Czech Republic, it’s now $3600 instead of $5500. So considerably less, but still fairly attractive to local students.

As a follow-up to this presentation, we organized a GNOME hackaton in the Red Hat lab at BUT. Carlos Soriano was in charge of it with me, Felipe Borges, and Debarshi Ray helping him. Carlos prepared images for VirtualBox and KVM with a prepared development environment every student was supposed to download. People had to work in a virtual machine, but they didn’t have to spend time configuring and compiling everything and it assured that everyone had the same environment.

Around 12 students showed up which I think was a good turnout. 3 of them were women which is definitely higher % than the average at the uni. First Carlos told them to read the GNOME Newcomers guide and pick an app they’d like to contribute to. Then he created a dummy bug and showed students the whole process of fixing it from searching the code to the patch review. Then they were supposed to find some easy bug in the app of their choice and fix it.

Almost all students picked apps written in C, which is not so surprising because that’s the language they learn primarily at the university. Only one picked GNOME Music written in Python. The hackaton lasted for 5 hours and all students were busy for the whole time and almost everyone submitted some fix in the end.

Carlos is planning to do a follow-up with those who want to continue, probably before our (ir)regular Linux Desktop Meetup next week. Let’s see if some of them will make it to Google Summer of Code or Outreachy and even become long-term contributors to GNOME later on. It was the first time we actually made students to dip their fingers into the code. At all events before we had presentations on how they can contribute and pointed them to the docs to study at home, but the response was minimal. Maybe such a hackaton where you help students in person to make the first steps is the right approach to break through the barrier.

I’m pretty sure Carlos will also blog about his findings and it will be much more insightful since he spent a lot of time preparing the hackaton and was the one who talked to the students the most.

img_-dhuozj
Carlos showing students how to fix a bug in GNOME

 

Fedora, GNOME, Uncategorized

Dark Adwaita and HighContrast Themes for Qt

One of our goals for Fedora Workstation is to run Qt applications in GNOME as seamlessly as possible. Their look should be as close to their GTK+ counterparts as possible, you shouldn’t have to set things on two different places just to make the change in both GTK+ and Qt applications.

A while back, we introduced the Adwaita theme for Qt and QGnomePlatform which makes sure all settings get translated from the GTK+ world to the Qt one. The original Adwaita theme was written from scratch. To write a theme for Qt is pretty complex and the look of Adwaita for Qt was close to Adwaita for GTK+, but not close enough. Then Martin Bříza, who is working on this, decided to change the approach and based the new version on the default KDE theme and kept changing it until he got a theme that is very similar to Adwaita for GTK+. And indeed it’s now much closer than the first version.

Martin also worked on the dark variant of Adwaita for Qt, so that if you switch to this variant, Qt apps still don’t look out of place. Or if there is a Qt app that uses a dark theme it can have a look that fits into GNOME.

Martin didn’t stop there. GNOME also offers a high contrast theme for those with visual impairment which prevents them from using standard themes. They’re also not left behind. If you switch to the HighContrast theme in GNOME Qt apps will switch to it, too.

On the video below, you can see a mix of Qt and GTK+ apps and how they change when you switch between different themes:

These changes should land in Fedora 26 Workstation, but you can already try them out. Martin created a Copr repository. Keep in mind it’s work in progress. If you’d like to report bugs or help with tuning the themes, all the code is on Github.

GNOME

Dark title bars for apps with dark UI

I really like the polished look of GNOME and its default theme Adwaita, but there is one thing that has been bugging me for some time. By default server side window decorations are light and if an app has a dark UI and uses a server side window decorations, you get a dark window with a light title bar. It doesn’t look every nice and when you maximize the window, it’ll get even worse because you get a nice black-and-white hamburger (black top bar, light title bar, and dark window content).

There are quite a few apps suffering from this: Atom, Firefox Developer Edition, Blender,…

But Mutter actually allows the clients to set a theme for their window decorations even though they’re rendered on the server side. They just need to set an x window property GTK_THEME_VARIANT=dark.

And I think the difference speaks for itself:

snimek-z-2017-01-10-18-55-41

snimek-z-2017-01-10-16-52-05

You can test it by executing: xprop -f _GTK_THEME_VARIANT 8u -set _GTK_THEME_VARIANT dark

and clicking the window where it should apply.

Are you a user of one of the apps that would benefit from it? Or even a contributor? Try to convince the project to implement this tiny change. If you’re a distro maintainer of such an app, you may consider applying a small patch.

Fedora, GNOME, LibreOffice, Linux

Installing flatpaks gets easier in Fedora 25

A lot of users complained that installing flatpaks was too difficult. And they were right, just look at the installation instructions on the Flatpak download page at LibreOffice.org. But that was never meant to be the final user experience.

flatpak-logo

Richard Hughes integrated Flatpak support into GNOME Software and the Red Hat desktop apps team worked with him to make sure it works well with apps we’ve already packaged for Flatpak. And this is the result. As you can see installing LibreOffice for Flatpak is now a matter of a couple of clicks with GNOME Software 3.22.2 in Fedora 25:

 

Flatpak allows you to generate a .flatpak bundle which includes the app and all the necessary info for installation of the app and setting up its repo for future updates. You can also create a .flatpakref file which doesn’t contain the app, but all the installation info and the app is downloaded during the installation. This format is also supported by GNOME Software now. LibreOffice offers a .flatpak bundle because it’s more similar to what users are used to from Windows and macOS.

As you can see on the video, installing .flatpak bundles is a matter of downloading the file and opening it directly with GNOME Software or double-clicking it. There is one prerequisite though. You need to have a repo of the runtime the app requires enabled which I had because I had been using the GNOME runtime for other apps already. Installation of runtimes is being streamlined as well. As a runtime provider, you can ship .flatpakrepo file which includes necessary info for setting up the repo and is as easy to install as .flatpak and .flatpakref. For Fedora Workstation we’re currently considering to enable repos of most common runtimes by default, so users would not have to deal with them at all, the required runtimes would get installed automatically with the app.