Why don't they upload packages to the normal package repository? Is this a general convention... do other distros separate the repositories also?

  • I'd suggest not having other distro's as that could possibly be excessively long, also by archive to you mean package repo? I'm guessing you do, but making sure you don't mean an svn/git branch or something. Nov 22, 2010 at 11:57
  • debian.org/security Mar 25, 2015 at 0:57

4 Answers 4


Debian has a distribution channel that provides security updates only so that administrators can choose to run a stable system with only the absolute minimum of changes. Additionally, this distribution channel is kept somewhat separate from the normal channel: all security updates are fed directly from security.debian.org, whereas it is recommended to use mirrors for everything else. This has a number of advantages. (I don't remember which of these are official motivations I read on Debian mailing lists and which are my own mini-analysis. Some of these are touched on in the Debian security FAQ.)

  • Security updates are spread immediately, without the delay incurred by mirror updates (which can add about 1 day of propagation time).
  • Mirrors can go stale. Direct distribution avoids that problem.
  • There is less infrastructure to maintain as a critical service. Even if most of Debian's servers are unavailable and people can't install new packages, as long as security.debian.org points to a working server, security updates can be distributed.
  • Mirrors can be compromised (this has happened in the past). It's easier to watch a single distribution point. If an attacker managed to upload a malicious package somewhere, security.debian.org could push a package with a more recent version number. Depending on the nature of the exploit and the timeliness of the response, this could be enough to keep some machines uninfected or at least warn administrators.
  • Fewer people have upload rights on security.debian.org. This limits the possibilities for an attacker trying to subvert an account or machine in order to inject a malicious package.
  • Servers that don't need ordinary web access can be kept behind a firewall that only allows security.debian.org through.
  • 4
    The security repo pre-dates signing the release files for repositories, so mirroring it was discouraged, as it diluted the implicit trust of downloading from security.debian.org. That argument has gone away to some extent now that package metadata is signed.
    – jmtd
    Jan 24, 2011 at 13:50
  • host security.debian.org does resolve to a bunch of addresses, so maybe it is a pool of machines, even if it technically does not have mirrors. Nov 7, 2014 at 1:53

I'm pretty sure Debian puts security updates in the regular repo as well.

The reason to have a separate repo that only contains security updates is so you can set up a server, only point it at the security repo, and automate updates. Now you've got a server that is guaranteed to have the latest security patches without accidentally introducing bugs caused by incompatible versions, etc.

I'm not sure if this exact mechanism is used by other distros. There's a yum plugin to handle this kind of thing for CentOS, and Gentoo currently has a security mailing list (portage is currently being modified to support security-only updates). FreeBSD and NetBSD both provide ways to do security audits of installed ports/packages, which integrate well with the built-in update mechanisms. All told, Debian's approach (and probably Ubuntu's, since they're so closely related) is one of the slicker solutions to this problem.

  • 1
    yes because a security patch could never possibly introduce another bug. Nov 22, 2010 at 23:00
  • "s. Now you've got a server that is guaranteed to have the latest security patches without accidentally introducing bugs caused by incompatible versions, etc." is that not what that means? I suppose I could sat that incompat versions is the arguable point... what does that mean exactly... most of the time people who backport only security patches aren't doing it because they feel that ABI/API is the only thing they're looking at. Nov 24, 2010 at 0:18
  • 1
    @xeno Are you critisizing the idea of splitting these repos up, or are you alerting us that there are no guarantees?
    – tshepang
    Nov 26, 2010 at 7:27
  • 1
    @xeno Depending on how upstream handles things, bugfix patches can be too intrusive for a 'stable' release.
    – tshepang
    Nov 26, 2010 at 8:24
  • 4
    The vast majority of security patches are trivially small: re-ordering the arguments to a memset, fixing a bounds check on a strncmp or what-have-you. Of course, they could plausibly introduce other bugs, but the risk is very small and theoretical, whereas the discovered security bug is very much practical.
    – jmtd
    Jan 24, 2011 at 13:49

It helps with two things:

  1. safety - first get your security fixes, then you are at lower risk while updating the rest
  2. security updates should be stored at a high security level, as you tend to rely on them to protect the rest of your system, so it could be that this repo has stronger security controls to prevent compromise

there could well be other reasons, but those are the two I would find useful

  • You sure about stored at a high security level? I say that because you express doubt, could be.
    – tshepang
    Dec 19, 2010 at 8:12
  • Well spotted Tshepang - I haven't got visibility of the environment that repo exists in, but that is they way I would set it up :-)
    – Rory Alsop
    Dec 19, 2010 at 12:05
  • 5
    There is at least some form of higher security level: only the security team can push a package onto security.debian.org. I don't know the implementation details. Dec 19, 2010 at 16:21

According to Salvatore Bonaccorso of the Debian security team (via private email to me), it is not recommended to configure the security archive only, "to run a stable system with only the absolute minimum of changes." For example in this case you will not receive Linux kernel rebases to new stable versions.

Also, not all security fixes are included in the regular archive, because sometimes they fail to build for certain architectures. In this case the fix cannot be included in the regular archive, but will still be included in the security archive, even if not for all architectures.

Salvatore Bonaccorso recommends to always enable both archives - the regular archive AND the security archive.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.