|Deletions are marked like this.||Additions are marked like this.|
|Line 4:||Line 4:|
|* '''Website''': http://www.debian.org/security/||* '''Website''': https://www.debian.org/security/|
|Line 10:||Line 10:|
| * '''Read the FAQ first''': http://www.debian.org/security/faq
* '''Developer's reference''': [[http://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security|Dealing with a security issue in your package]].
| * '''Read the FAQ first''': https://www.debian.org/security/faq
* '''Developer's reference''': [[https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security|Dealing with a security issue in your package]].
|Line 16:||Line 16:|
|. See list of members here: http://www.debian.org/intro/organization||. See list of members here: https://www.debian.org/intro/organization|
|Line 33:||Line 33:|
| * http://security-tracker.debian.org/tracker/
| * https://security-tracker.debian.org/tracker/
Debian Security Team
Unix groups: security, sec_public, sec_embargo, sectracker
Interacting with the team
Read the FAQ first: https://www.debian.org/security/faq
Developer's reference: Dealing with a security issue in your package.
Public IRC channel: #debian-security
Reporting a bug tagged "security"
See list of members here: https://www.debian.org/intro/organization
The normal procedure is that some member of the team claims a reported issue and takes it from there until the advisory is fully released.
Next to the "full members" (part of the 'security' group), the team also has "assistants" (only in the sec_embargo group). This last role is usually for new members of the team. An assistant can read almost all data that the full members can, and construct a full advisory, but not actually install the updated packages into the archive. A full member will review the assistant's work and release it.
The security team evaluates security threats, and produces updated packages for our stable and old-stable releases, and release these packages through security.debian.org together with an advisory mail.
The preferred situation is that the regular maintainer of an affected package (who is most familiar with its ins and outs) prepares updated packages or a ready to use patch which, after approval, will be uploaded to security-master. If the regular maintainer can't or won't provide updates (in time), the security team will take the task of creating the updated packages.
Security for testing and unstable is not officially guaranteed, but the team tracks those distributions as well in the security tracker. A number of regular volunteers outside of the team help with triaging issues on the security tracker.
Some brief links: