Support Signing

[caarlos0]

add support to signing packages (on all packagers):

• deb
• rpm
• apk

[erikgeiser]

Before anyone starts implementing anything I want to say this: I know the gpg agent is convenient but please let's use golang.org/x/crypto/openpgp instead of calling the gpg binary. Just in case anyone would want to do that.

[erikgeiser]

So I took a quick look at our options and the situation looks rather different between the formats:

DEB:

There seem to be two incompatible schemes for signature creation/verficiation: dpkg-sig and debsigs. Here is a short overview from an askubuntu answer:

In order to sign a package, you can use either: debsigs or dpkg-sig. The signatures are not compatible with one another, so you'll need to make sure the user is using the proper tool on the receiving side for verifying signatures.

dpkg-sig is easier to use for both you and the user, but debsigs is the tool with built-in support (which is disabled by default) on Ubuntu and Debian.

I found concise technical explanation of debsigs signature creation in the Arch wiki that says that we basically just need to concatenate debian-binary, control.tar.gz and data.tar.gz, sign it and place the detached signature named _gpgorigin next to the files inside the ar.

However, according to this blog there seem to be 3 types of depsigs signatures (origin, maint and archive) and instructions from the Arch wiki only seem to cover the origin type. Maybe the others only differ in the file name of the detached signature but I haven't looked into it, yet.

The origin depsigs signature should be rather easy to implement in nfpm.

RPM:

It looks like we almost have an upstream solution via an rpmpack pull request: google/rpmpack#39. However, it is from January and still not merged, maybe we should ask what the plans are. We could also hack it into the rpm itself via custom tags like we did with the changelog. Of cource, the upstream solution would be much, much nicer.

APK:

According to the Alpine wiki, signatures over APKINDEX.tar.gz file have to be prepended before the APKINDEX.unsigned.tar.gz file itself. However the signatures are not PGP signatures but an RSA signed SHA1 hash wrapped a modified tar.gz file (without the end-of-tar record at the end of the file, whatever that means).

---

General Considerations:

So, we have 2 types of key material, pgp and RSA, which we can handle with the Go standard library. Then we have the two schemes for deb packages of which we could support one or both. With depsigs we could support all 3 signature types. Signing rpms with rpmpack seems to be simple as creating a detached signature over the data that's provided by the library. So the configuration options are completely different between the formats, so it is probably not a bad idea to expose the configurations options as package specific options in the nfpm config. This would also allow us to add signature support for one format after the other and not all at once.

We could accept pgp keys in the ASCII-armored (.asc) format or in the binary format (.gpg). It's possible to auto-detect the type, but that's a bit awkward because it basically involves trying to read the key in one format and then try again with the other format if the first attempt failed.

Also, how do we support password protected pgp files? If we don't support password protected keys then the raw key will be passed through build systems and whatnot and as soon as anyone else can accesses the key it is worthless. If we allow users so set a key in the config, this implies that the config is now sensitive material and users will accidentally upload it to Github.

The best way is probably to pass it as an environment variable, but that's hard to debug. If a signature is configured in the config files, will the build fail if the environment variable is unset?

What are your thoughts on these points?

[caarlos0]

Yeah, I agree the configs should be package-specific.

About the signature, I would say either read from an environment variable or from a file, and its up to the user to secure their keys...

---

specifically about apk, we can base the implementation in this pr: #126

[erikgeiser]

Maybe I will start to implement some of this over the weekend to see how things go. This will probably still require some discussions. Maybe a WIP branch in this repo would be a good idea, or do you rather prefer a WIP-PR?

EDIT: I already have the openpgp signing (and verifying for tests) part working and well tested with armored and non-armored key files and with and without passphrases.

[erikgeiser]

I implemented debsigs signatures and the blog was right, verifying these signatures is a major PITA (worse than doing the PGP signing stuff) and I would not wish it on my endusers. Maybe we should also implement the dpkg-sig scheme and always do both so endusers can verify whatever they like.

EDIT: nevermind, I found out that dpkg-sig and debsigs signatures are mutually exclusive.

[caarlos0]

Maybe a WIP branch in this repo would be a good idea, or do you rather prefer a WIP-PR?

WIP PR is fine by me... if you think its best to have a temporary develop branch thats OK too, I think you have perms to create one :)

[Slach]

@erikgeiser thanks a lot for this feature great work ;)

[caarlos0]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.