= Security support

== 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.

== Handling security bugs

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

. 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.

. 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.

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

== How to release an FSA?

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

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

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

. 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.

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

== How to notice security issues

. Subscribe to Secunia Security Advisories List at
http://secunia.com/secunia_security_advisories/ page.  This is the best place
to notice issues.
. Read the mails one-by-one and check if the advisory affects -current or
-stable.
. 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.)

== How to get patches

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

. First of all sometimes upstream fixes it with a new version.
. Fixed in cvs/svn/whatever and you are able to find the patch (unlike PHP)
. 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.
. 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.

== 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).