= 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 11. * If you add a security patch, and pkgrel was an integer (let's say '1'), then you should increment pkgrel to 21. * If you add a security patch when the pkgrel was already in an XY form, increment it to XY+1. (Alternatively, you can use X+1Y 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).