AS A security-conscious data customer
I WANT to be able to verify the authenticity / integrity of replication packets
SO THAT the risks to my own systems are mitigated

One of the identified risks [from a BBC audit] is that updates come in plain text from a public FTP server without any signing.

To solve this we could either gpg-sign our data, and/or serve up the data using TLS. gpg signing seems to fit us (MB) better.

Therefore, we should sign each update packet and data dump using GPG and add checking of signatures to the sync client.

~~~~

I think this is purely MBS, apart perhaps from the initial creation of a gpg signing key.

ExportAllTables should be modified as follows:

• for fullexport (where each dump has its own directory), run something like:
  • "md5sum -b *.tar.* > md5sums"
  • "gpg ... --detach-sign --armor md5sums"

• for replication packets, as well as producing replication-N.tar.bz2, also produce "replication-N.tar.bz2.asc" (gpg ... --detach-sign replication-N.tar.bz2)

LoadReplicationChanges should be modified as follows:

• also download the .asc file
• only proceed once we've successfully downloaded both the .asc and the .tar.bz2
• verify the signature (gpg --verify foo.asc); bail if the verification fails
• continue as normal, unpacking and processing the tar file
• as well as deleting the tar file, also delete the asc file

I don't think there's a requirement for anything to automatically verify the fullexport sums / sigs.

Additional notes:

• for now, let's not modify the nagios replication check (e.g. to also check the .asc files). We can revisit that decision if it turns out to be a bad idea.
• distributing our signing key to our customers is out of scope of this ticket
• installing gpg then becomes a dependency of an MB slave.