Scripting GPG – “It is NOT certain that the key belongs to the person named…”

GPG is great software for manually encrypting data using the OpenPGP standard – good encryption tools are more and more becoming essential to software development.

However using GPG from a script sometimes presents problems. Why would you want to GPG from a script? Well you might want to encrypt a backup from within your backup script to allow you to safely FTP the backup file to remote storage, for example.

Anyway, one such problem results in the following error message appearing, when you try to encrypt using an imported, but unsigned public key:

“It is NOT certain that the key belongs to the person named…”

GPG then says something along the lines of ‘do you want to continue anyway?’ and tries to read your response from the terminal – the script is unable to answer the question and so the whole process stalls…

One way to get around this problem is to manually set the trust level of the imported public key to ‘ultimate’ so that the situation no longer arises, instructions for how to do this can be found here:

http://www.somacon.com/p107.php

However in some cases this may not be easy or desirable, especially if you don’t have access to the command line – for example, you may be working with shared hosting. You may also want to ensure that the _whole_ process is automatic with no manual steps required.

So, another option is to pass the ‘–trust-model always’ argument to gpg, this will force GPG not to issue the warning and not ask for confirmation – so your script should proceed OK. For example:

[code]
gpg –encrypt –yes –no-tty –trust-model always –output backup.gpg –recipient backup@software-ireland.ie backup
[/code]

Older versions of GPG may not have this parameter, and will report an error when you pass it, in this case the depreciated ‘–always-trust’ argument can be used instead.

Be warned that this does reduce security slightly. If somebody somehow maliciously managed to substitute your public key for theirs and then managed to intercept the encrypted data, then they could decrypt it with their private key. However in most cases this is of small concern – but do be aware of the possible dangers of blindly encrypting without requiring signed public keys.

Script & Encrypt!