mwilck

This idea was inspired by the recent discussion on the "talk" mailing list about the (in)security of the German ID card. The Chaos Computer Club and other researchers claim that the ID card is insecure. Actual attacks that have been demonstrated are based on keyloggers. Keyloggers might be the biggest security threat for Linux users at this time. Keyloggers are trivial to write for Linux and readily installable, and a keylogger with normal user rights may read root's password. One might ask "Why are we caring about local root exploits at all as long as users run stuff like sudo in X terminals"? Keyloggers can even read the input from devices like the Yubikey.

Almost all our laptops, and many servers, feature a TPM today. The TPM doesn't have the best reputation in the community because it could be used to lock down platforms or do nasty things with DRM. Under normal conditions on PCs, the TPM is controlled by the system owner and could actually be useful for almost anything involving crypto. Unfortunately the integration of the TPM in the OS is essentially non-existent. The introduction of the TPM2.0 standard complicates matters, because we now have two different devices with different APIs. The goal of this project would be to identify reasonable use cases for the TPM, evaluate exisiting projects, and create ways how to integrate it into various workflows in openSUSE.

The HPLIP package contains a custom implementation of mDNS queries (actually, 2: one in the core C code and one in python for the administration tools). This implementation is simplistic and sub-optimal. I fixed a problem of this implementation in the past, but unfortunately my patches don't apply on the latest HPLIP releases, and aren't easily forward-ported. The Right Thing to do for mDNS on Linux use use avahi calls. I want to look into using avahi for this purpose in HPLIP.

Recent multipath-tools contains a patch series that allows latency-based path prioritization. However the code is clumsy and not well designed. More importantly, I think that the applied algorithm, which is based on simple methods like comparing averages and standard deviations, is suboptimal. I consider replacing it with a clustering-based approach, using the open source cluster library.

We currently maintain all drivers in the SUSE kernel tree. While this is a well-established procedure, it also has a number of drawbacks in my opinion. I've been experimenting with a different model, tracking (so far, only one) driver in a separate git repository, and packaging it as kernel module package (KMP). This way of working fits my own mental model of code development better than the quilt style we employ in day-to-day driver maintenance.

I've got a small filtering proxy in our home LAN, used as a web filter for my kids. One most annoying mis-feature is that every time a Linux computer with a "modern" UI such as GNOME connects to the network, a popup window asks the user to enter "tickets" for my Fritz! box, although NM correctly sets up the proxy and net surfing is possible just fine. Currently the only workaround for this is to deactivate NM's "connectivity check" altogether. IMO that's not the right solution - if NM is able to detect and configure proxies for the system, it should also be able to use these proxy settings for its connectivity check. This touches on the fact that proxy configuration support is generally in a miserable state (not only) on Linux.

Project Description

Obtaining correct information about devices in the system is crucial for multipath-tools. Properties of devices depend on each other. Certain properties matter in some parts of the code and some in others.

Project Description

multipathd is multi-threaded, but it uses a single lock that essentially kills most benefits of