Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
  • We are using an internal debian repository for backports and internal software.

  • We chose reprepro to manage the repository, and we sign source packages (with debsign) so that the repository accepts our gpg keys as trusted.

  • We created an internal keyring similar to the debian or ubuntu keyring package, that we install before anything to be able to run "apt-get update" without getting any gpg key error.

The latest point is problematic, as we often get security related issues, although we are in a completely private network, which excludes unsafe package uploading from outside.

Question : What are the pros and cons of using signed packages in an internal repository ?

share|improve this question
1  
what do you mean by signed packages? I don't believe that apt has any mechanism for signed packages in a repository other than what it sounds like you are already using, which is that packages are digested (into md5sum/sha1/sha256), those digests go into the Pacakges file, the Packages file is digested into the Release file which is signed. If you already have a keyring package which is needed before using your repository, it sounds like you may already be doing all of this. –  stew Mar 23 '11 at 20:17
    
My question was not well formulated : Our problem is that the packaging process becomes quite complicated, so we're thinking about simply droping it ! –  Falken Mar 23 '11 at 20:26
add comment

1 Answer

up vote 3 down vote accepted

Repository signing helps the users know "yes, the repository I'm downloading packages from is one I trust". The if you tell them to ignore this check you'd have to worry about:

  • DNS poisoning (when they go to yourserver.com are they actually getting the right address?)
  • MITM (when they try to hit the repository at ip 1.2.3.4, are they getting the server they should be getting)
  • rogue entries in sources.list (somehow, i manage to put deb http://evilserver.xxx foo/" in your sources.list and now you install packages from evilserver.xxx which you shouldn't trust)

If either of the first two can be a problem (which is not likely in a controlled environment), then you'd still have the problem of replay attacks even with a signed repositry. (you roll out a security upgrade to patch a vulnerability, I get user to look at my repository instead of yours so user never gets the patch, I get to exploit the vulnerability).

On a controlled network, I'd not really worry about much of this. That being said, if you have the infastructure in place already to have signed repositories, running debsign doesn't sound too complicated.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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