Blogs

My Work on Debian LTS (August 2020)

In August 2020, I have worked on the Debian LTS project for 16 hours (of 8 hours planned, plus another 8 hours that I carried over from July).

For ELTS, I have worked for another 8 hours (of 8 hours planned).

LTS Work

  • LTS frontdesk: triage wireshark, yubico-piv-tool, trousers, software-properties, qt4-x11, qtbase-opensource-src, openexr, netty and netty-3.9
  • upload to stretch-security: libvncserver 0.9.11+dfsg-1.3~deb9u5 (fixing 9 CVEs, DLA-2347-1 [1])
  • upload to stretch-security: php-horde-core 2.27.6+debian1-2+deb9u1 (1 CVE, DLA-2348 [2])
  • upload to stretch-security: php-horde 5.2.13+debian0-1+deb9u3 (fixing 1 CVE, DLA-2349-1 [3])
  • upload to stretch-security: php-horde-kronolith 4.2.19-1+deb9u1 (fixing 1 CVE, DLA-2350-1 [4])
  • upload to stretch-security: php-horde-kronolith 4.2.19-1+deb9u2 (fixing 1 more CVE, DLA-2351-1 [5])
  • upload to stretch-security: php-horde-gollem 3.0.10-1+deb9u2 (fixing 1 CVE, DLA-2352-1 [6])
  • upload to stretch-security: freerdp 1.1.0~git20140921.1.440916e+dfsg1-13+deb9u4 (fixing 14 CVEs, DLA-2356-1 [7])
  • prepare salsa MRs for gnome-shell (for gnome-shell in stretch [8] and buster [9])

ELTS Work

  • Look into open CVEs for Samba in Debian jessie ELTS.

No Debian LTS Work in July 2020

In July 2020, I was originally assigned 8h of work on Debian LTS as a paid contributor, but holiday season overwhelmed me and I did not do any LTS work, at all.

The assigned hours from July I have taken with me into August 2020.

light+love,
Mike

Ayatana Indicators / IDO - Menu Rendering Fixed with vanilla GTK-3+

At DebConf 17 in Montreal, I gave a talk about Ayatana Indicators [1] and the project's goal to continue the — by then already dropped out of maintenance — Ubuntu Indicators in a separate upstream project, detached from Ubuntu and its Ubuntu'isms.

Stalling

The whole Ayatana Indicators project received a bit of a show stopper by the fact that the IDO (Indicator Display Object) rendering was not working in vanilla GTK-3 without a certain patch [2] that only Ubuntu has in their GTK-3 package. Addressing GTK developers upstream some years back (after GTK 3.22 had already gone into long term maintenance mode) and asking for a late patch acceptance did not work out (as already assumed). Ayatana Indicators stalled at a level of 90% actually working fine, but those nice and shiny special widgets, like the calendar widget, the audio volume slider widgets, switch widgets, etc. could not be rendered appropriately in GTK based desktop environments (e.g. via MATE Indicator Applet) on other distros than Ubuntu.

I never really had the guts to sit down without a defined ending and find a patch / solution to this nasty problem. Ayatana Indicators stalled as a whole. I kept it alive and defended its code base against various GLib and what-not deprecations and kept it in Debian, but the software was actually partially broken / dysfunctional.

Taking the Dog for a Walk and then It Became all Light+Love

Several days back, I received a mail from Robert Tari [3]. I was outside on a hike with our dog and thought, ah well, let's check emails...

My Work on Debian LTS (June 2020)

In June 2020, I have worked on the Debian LTS project for 8 hours (of 8 hours planned).

LTS Work

  • frontdesk: CVE bug triaging for Debian jessie LTS: mailman, alpine, python3.4, redis, pound, pcre3, ngircd, mutt, lynis, libvncserver, cinder, bison, batik.
  • upload to jessie-security: libvncserver (DLA-2264-1 [1], 9 CVEs)
  • upload to jessie-security: mailman (DLA-2265-1 [2], 1 CVE)
  • upload to jessie-security: mutt (DLA-2268-1 [3] and DLA-2268-2 [4]), 2 CVEs)

Other security related work for Debian

  • make sure all security fixes for php-horde-* are also in Debian unstable
  • upload freerdp2 2.1.2+dfsg-1 to unstable (9 CVEs)

References

My Work on Debian LTS (May 2020)

In May 2020, I have worked on the Debian LTS project for 14.5 hours (of 14.5 hours planned).

LTS Work

  • Frontdesk: CVE bug triaging for Debian jessie LTS: exim4, cups, log4net, apt, openconnect, libexif, json-c, tomcat8, and graphicsmagick.
  • review and sponsor upload to jessie-security: libexif (DLA-2214-1 [1], 5 CVEs)
  • review and sponsor upload to jessie-security: libexif (DLA-2222-1 [2], 4 CVEs)
  • upload to jessie-security: json-c (DLA-2228-1 [3] and DLA-2228-2 [4], 1 CVE)
  • upload to jessie-security: php-horde-gollem (DLA-2228-1 [5], 1 CVE)
  • upload to jessie-security: php-horde (DLA-2280-1) [6], 1 CVE)
  • start looking into the current FreeRDP (v1.1) and FreeRDP (v2) CVE hell...

Other security related work for Debian

  • review and sponsor uploads of libexif to stretch, buster and unstable (8 CVE fixes for stretch, 5 CVE fixes for buster) [7]
  • revisit long overdue uploads of ssvnc to stretch and buster (4 CVE fixes each) [8]
  • upload php-horde-gollem to stretch and buster (1 CVE fix each) [9]
  • upload php-horde to stretch and buster (1 CVE fix each) [10]

Credits

  • Many thanks to Hugh McMaster for handling all the libexif security upload preparations himself. This was really good work.

Q: Remote Support Framework for the GNU/Linux Desktop?

TL;DR; For those (admins) of you who run GNU/Linux on staff computers: How do you organize your graphical remote support in your company? Get in touch, share your expertise and experiences.

Researching on FLOSS based Linux Desktops

When bringing GNU/Linux desktops to a generic folk of productive office users on a large scale, graphical remote support is a key feature when organizing helpdesk support teams' workflows.

In a research project that I am currently involved in, we investigate the different available remote support technologies (VNC screen mirroring, ScreenCasts, etc.) and the available frameworks that allow one to provide a remote support infrastructure 100% on-premise.

In this research project we intend to find FLOSS solutions for everything required for providing a large scale GNU/Linux desktop to end users, but we likely will have to recommend non-free solutions, if a FLOSS approach is not available for certain demands. Depending on the resulting costs, bringing forth a new software solution instead of dumping big money in subscription contracts for non-free software is seen as a possible alternative.

As a member of the X2Go upstream team and maintainer of several remote desktop related tools and frameworks in Debian, I'd consider myself as sort of in-the-topic. The available (as FLOSS) underlying technologies for plumbing a remote support framework are pretty much clear (x11vnc, recent pipewire-related approaches in Wayland compositors, browser-based screencasting).

My Work on Debian LTS (April 2020)

Due to sickness I was not able to complete my 8 hours of work on Debian LTS as planned. I only worked 1.5 hours this month, moving the remaining 6.5 hours over to May.

LTS

  • Triage sqlite3, nginx, libsixel.
  • Drop EOL'ed libperlspeak-perl from dla-needed.txt.
  • Update security tracker's metadata (patch URLs) for ansible

Other security related work for Debian

  • Upload to buster: gosa 2.7.4+reloaded3-8+deb10u2 (1 CVE)
  • Upload to stretch: gosa 2.7.4+reloaded2-13+deb9u2 (1 CVE plus many bug fixes)
  • Upload to stretch: gosa 2.7.4+reloaded2-13+deb9u3 (1 more CVE)

Q: RoamingProfiles under GNU/Linux? What's your Best Practice?

This post is an open question to the wide range of GNU/Linux site admins out there. Possibly some of you have the joy of maintaining GNU/Linux also on user endpoint devices (i.e. user workstations, user notebooks, etc.), not only on corporate servers.

TL;DR; In the context of a customer project, I am researching ways of mimicking (or inventing anew) a feature well known (and sometimes also well hated) from the MS Windows world: Roaming User Profiles. If anyone does have any input on that, please contact me (OFTC/Freenode IRC, Telegram, email). I am curious what your solution may be.

The Use Case Scenario

In my use case, all user machines shall be mobile (notebooks, convertibles, etc). The machines maybe on-site most of the time, but they need offline capabilities so that the users can transparently move off-site and continue their work. At the same time, a copy of the home directory (or the home directory itself) shall be stored on some backend fileservers (for central backups as well as for providing the possibility to the user to login to another machine and be up-and-running +/- out-of-the-box).

The Vision

Initial Login

Ideally, I'd like to have a low level file system feature for this that handles it all.

My Work on Debian LTS (March 2020)

In March 2020, I have worked on the Debian LTS project for 10.25 hours (of 10.25 hours planned).

LTS Work

  • Frontdesk: CVE Bug Triaging for Debian jessie LTS: libpam-krb5, symfony, edk2 (EOL), icu, twisted, yubikey-val, netkit-telnet(-ssl), libperlspeak-perl (new EOL). and glibc.
  • Upload to jessie-security: tinyproxy (DLA-2163-1 [1], 1 CVE, 1 severe bug [2]).
  • Revisit CVE-2015-9541 in jessie's qtbase-opensource-src and agree with Dmitry Shachnev from Debian's KDE/Qt Team about tagging this CVE '<ignored>' in Debian's security tracker. The proposed upstream patch uses an API not available in jessie's Qt5 version (QStringView API) and the serious of patched ot be applied would be quite invasive.
  • Prepare upload of libpam-krb5 4.6-3+deb8u1 (1 CVE) (will be uploaded during the day).
  • Look closer into CVE-2019-17177 for FreeRDP v1.1 (and decide to ignore it, as patchwork would have to be applied all over the code).

UBports: Packaging of Lomiri Operating Environment for Debian (part 02)

Before and during FOSDEM 2020, I agreed with the people (developers, supporters, managers) of the UBports Foundation to package the Unity8 Operating Environment for Debian. Since 27th Feb 2020, Unity8 has now become Lomiri.

Recent Uploads to Debian related to Lomiri

Over the past 7-8 weeks the packaging progress has been slowed down due to other projects I am working on in parallel.

Syndicate content