23

I ran dpkg-buildpackage after getting a apt-get source nginx of a backports version of nginx and modifying debian/rules to include the uwsgi module. The last results of the command were:

dpkg-deb: building package `nginx' in `../nginx_0.7.67-3~bpo50+1_i386.deb'.
dpkg-deb: building package `nginx-dbg' in `../nginx-dbg_0.7.67-3~bpo50+1_i386.deb'.
 signfile nginx_0.7.67-3~bpo50+1.dsc
gpg: keyring `/home/shogun/.gnupg/secring.gpg' created
gpg: skipped "Faidon Liambotis <paravoid@debian.org>": secret key not available
gpg: [stdin]: clearsign failed: secret key not available

 dpkg-genchanges  >../nginx_0.7.67-3~bpo50+1_i386.changes
dpkg-genchanges: warning: the current version (0.7.67-3~bpo50+1) is smaller than the previous one (0.7.67-3)
dpkg-genchanges: not including original source code in upload
dpkg-buildpackage: binary and diff upload (original source NOT included)
dpkg-buildpackage: warning: Failed to sign .dsc and .changes file

It complains that because I'm not the original maintainer of the package, my key didnt match.

Is this really necessary and if so how can I make it use my keys to do the gpg matching?

meder omuraliev
  • 1,701
  • 3
  • 20
  • 30

3 Answers3

34

PGP-signing Debian packages is not necessary if you built them for your own private use. It's just the common authentication method for (official) Debian developers when they upload new packages into the Debian "unstable" branch.

To avoid the error message just use:

dpkg-buildpackage -uc -us

(see also the manpage of dpkg-buildpackage)

Signum
  • 1,228
  • 1
  • 12
  • 14
  • I just looked at the parent directory and it seems it didnt create those .deb files based on the modification dates from `ls -al`. It failed to create them because of the failed verification of the gpg, right? Meaning with your new command, it should create them? Or am I mistaken? – meder omuraliev Oct 17 '10 at 10:38
6

When you make a different version of a package (as you did, since you changed the build rules), you should really add a changelog entry. That way, your package will have a different version number (so you'll know immediately that it's not the standard package from the distribution), and you'll have a trace of what you changed.

Edit debian/changelog, and add an entry mimicking the format of existing entries. Date it from today, and pick a version number like 0.7.67-3~bpo50+meder1 (you want something for which dpkg --compare-versions says your version is more recent). Put your email address as maintainer; that way, you have a clear indication that this is a package you modified, and dpkg-buildpackage will ask for your GPG passphrase.

If you're an Emacs user, install the dpkg-dev-el package, and use the C-c C-a and C-c C-c commands to add and finalize your changelog entry.

5

While signing a package isn't necessary, and the -uc -us options can be used to avoid that step, it can also be helpful to sign a package, especially if others will be using it, or you'll be sending it via insecure communications paths. And it isn't hard at all.

To generate a good signature, see the man page for dpkg-buildpackage. By default it signs packages with gpg. From the error messages it printed, it seems you simply hadn't generated a gpg key yet. See e.g. GnuPrivacyGuardHowto - Community Ubuntu Documentation for some instructions and background.

As @Gilles notes, you should also change the package version number via the changelog file, and provide the email address for the gpg key you'll be using. An easy way to do that is to just run the dch --local foo command, where "foo" is a keyword for the change. If you really don't want to do that, and need to specify a different maintainer or uploader name/address, or a specific key to be used when signing, you can also use the -m, -e or -k option when building.

See Howto to rebuild Debian packages for more tips.

The tricky part comes when someone is trying to decide if a given package is signed by someone they trust. Check out the PGP web of trust to deal with the subtle issues involved.

nealmcb
  • 297
  • 3
  • 9