Using deltas to speed up SquashFS updates

The ebuild repository format that is used by Gentoo generally fits well in the developer and power user work flow. It has a simple design that makes reading, modifying and adding ebuilds easy. However, the large number of separate small files with many similarities do not make it very space efficient and often impacts performance. The update (rsync) mechanism is relatively slow compared to distributions like Arch Linux, and is only moderately bandwidth efficient.

There were various attempts at solving at least some of those issues. Various filesystems were used in order to reduce the space consumption and improve performance. Delta updates were introduced through the emerge-delta-webrsync tool to save bandwidth. Sadly, those solutions usually introduce other inconveniences.

Using a separate filesystem for the repositories involves additional maintenance. Using a read-only filesystem makes updates time-consuming. Similarly, the delta update mechanism — while saving bandwidth — usually takes more time than plain rsync update.

In this article, the author proposes a new solution that aims both to save disk space and reduce update time significantly, bringing Gentoo closer to the features of binary distributions. The ultimate goal of this project would be to make it possible to use the package manager efficiently without having to perform additional administrative tasks such as designating an extra partition.

Read on… [PDF]

Getting tokens for verification

Recently I’ve been working on implementing SSL authentication in Okupy (as you can see from the previous post). The specifics of chosen solution required the authentication to occur on a separate virtual host. Due to specifics of django, it was impossible to directly access the initial session from the dedicated vhost.

I had two possibilities. The supposedly simpler one involved passing the session identifier to the dedicated vhost so that it would be able to access the session information and store the authentication result there. But it involved hacking a fair bit of django (since the new versions no longer give access to the session identifier directly), starting the session early (it needn’t be started until the user is actually authenticated) and could introduce security issues.

The other involved passing the authentication results outside of the session framework and using dedicated tokens to claim the results. Those tokens have similar requirements to the tokens used e.g. for e-mail address verification.

First of all, the tokens must be guaranteed to be unique. Otherwise, there would be a finite probability that two users will be given same token. In case of e-mail address verification, this would mean that one user could confirm the other user’s (possibly invalid) e-mail address. In case of SSL authentication, one user would be able to claim other user’s login.

Secondly, the tokens need to be semi-random and hard to guess. The user, being able to obtain multiple valid authentication tokens in sequence (e.g. through requesting multiple valid e-mail account verifications), must not be able to predict the value of the token for another (possibly invalid) address. At least with reasonable resources.

Continue reading “Getting tokens for verification”

SSL certificate login for okupy

In this year’s GSoC, I’m co-working on identity.gentoo.org that intends to become a central place for logging in to various Gentoo sites. One of the fancy features that I’d like to implement is SSL-certificate based login.

The client certificate-based authentication is a kind of public key authentication. In order to login, you provide the server with your certificate (containing your public key) and a signature made with your private key. Your private key is never exposed to the server which greatly improves security, and you don’t have to have a store of random passwords.

Unlike many common authentication methods that are implemented in application space, client certificates are part of the SSL/TLS protocols. As a result, they’re supported quite widely by web browsers. But this also introduces a few limitations that will affect the use.

Continue reading “SSL certificate login for okupy”

Keeping the majority happy

One of the major problems that I have faced in Gentoo is that whatever I was doing on a larger scale made some people really unhappy. I would even say that the specifics of Gentoo make it even possible for users to get outraged (and obviously, let all the world know how outraged they are) by a few files they don’t like having installed.

This brings the question whether we should struggle to keep all of our users happy, or whether keeping majority of our users satisfied is sufficient.

I don’t believe that it is actually possible to keep everyone happy. It’s a kind of never-ending struggle that consumes valuable time and demands sacrifices. You work on making one user happy, the other one doesn’t like the result. You work towards the second one, third one is unhappy. You satisfy all three of them, now fourth comes outraged with the net result.

Continue reading “Keeping the majority happy”

Local device access — from plugdev to logind

One of the more curious problems of running Linux on desktops is handling the local device access. The idea is usually quite simple: local users should have access to devices such as removable media (floppies, pendrives), scanners, speakers, webcams and ability to power off or reboot the computer. At the same time, remote users should have that access restricted.

Why? I think the main rationale behind this is that those users have physical access to those functions (yes, you could say that they have physical hard drive access too). They can insert the floppies, plug the pendrive, press the power button or just pull out the plug. They usually suffer the speaker noises and scare in front of the webcam.

At the same time, remote (or inactive users) shouldn’t be given the right to shut down the system unexpectedly, shout into the speakers, stream the user’s webcam or install Windows to his pendrive. I think that doesn’t need explaining.

I would like to shortly describe a few attempts to solve the problem and the issues with them.

Continue reading “Local device access — from plugdev to logind”