1. Introduction

This document documents the work of the Frugalware Security Team. Primarily it’s for new developers or for existing developers who join the Security Team.

2. Handling security bugs

  1. The security team opens a new task in the BTS, with a [SEC] prefix.

  2. The maintainer fixes the issue in -current and decides if the issue needs fixing in -stable or not. If yes, then changes the status of the task to "Fixed in -current", otherwise closes the task.

  3. If there is no patch for the issue yet, then set the status to "Researching". This indicates that you, the maintainer, is aware of the problem, but don’t yet have enough a solution.

  4. The security team regularly searches for "Fixed in -current" bugs, fixes the issue in -stable and releases a new FSA.

3. How to release an FSA?

  1. Check if the backport built by syncpkgd is ready (the binary packages should be uploaded for each arch).

  2. Open the -stable Changelog file of the package. There you can see the vulnerable and unaffected versions of the package.

  3. Add a new entry to the frugalware/xml/security.xml file in the homepage-ng repo.

  4. Commit, push. The commit hook will check if the xml is valid, so most common errors can be avoided. In rare cases, the announcement may not appear on the frugalware-security list. If this is the case, then ask on -devel about what the problem might be.

  5. Close the task in the BTS, filing in FSAxxx in the closure message.

4. How to notice security issues

  1. Subscribe to Secunia Security Advisories List at http://secunia.com/secunia_security_advisories/ page. This is the best place to notice issues.

  2. Read the mails one-by-one and check if the advisory affects -current or -stable.

  3. Open a task in BTS if necessary. Please fill in the form correctly, provide a patch if you can.

You can also read other mailing lists, like https://lists.grok.org.uk/mailman/listinfo/full-disclosure, but Secunia monitors them, so you won’t miss anything. (You just notice things later.)

5. How to get patches

Secunia announces security issues days after they released so there is a good chance to find a patch.

  1. First of all sometimes upstream fixes it with a new version.

  2. Fixed in cvs/svn/whatever and you are able to find the patch (unlike PHP)

  3. If these two fail, there is http://security.ubuntu.com/ubuntu/pool. Secunia also mails you if the bug fixen in Ubuntu, so steal the patch from them :) You only need the $package-$pkgver.diff.gz. There is a changelog in it, where you can find the filename of the fix.

  4. It’s also a good idea to take a look on RedHat/Gentoo bugzilla. They attach fixes most the time.

So it’s good to read the Secunia mails carefully as you’ll always know when the patch is available.

6. Versioning

We use integers in pkgrels for normal packages, but -stable updates are different. Here are the cases:

  • If you do a version bump (we refer to them as secfix bump usually in -stable commit messages), then you need to set pkgrel to 1<release_codename>1.

  • If you add a security patch, and pkgrel was an integer (let’s say 1), then you should increment pkgrel to 2<release_codename>1.

  • If you add a security patch when the pkgrel was already in an X<release_codename>Y form, increment it to X<release_codename>Y+1. (Alternatively, you can use X+1<release_codename>Y if there is already a newer version in -current.)

This ensures that:

  • The version of the security update will be larger than the one in -stable, so that the package will be upgraded when the user does a pacman-g2 -Syu on -stable.

  • The version of the security update will be smaller than the one in -current, so that the package will be upgraded when the user upgrades to a new version (current or new stable).