crypto: explain why we're keeping the secret key in a git repo
TL;DR: this is a trade-off, see the text in the documentation.
Change-Id: If56c173d3ddee55027337561ca6f7239262cff3d
diff --git a/crypto/README.md b/crypto/README.md
new file mode 100644
index 0000000..2a7b937
--- /dev/null
+++ b/crypto/README.md
@@ -0,0 +1,25 @@
+# Isn't this horribly insecure?
+
+Yes, there is a private key in a publicly accessible git repository.
+We have decided that this is not a security problem for us.
+
+These keys control signing of FW images which might be -- eventually -- deployed to devices.
+Now that the key has been effectively leaked, that implies that anyone can produce a malicious FW image which will still be accepted via RAUC.
+We are not relying on signature verification for FW image installations; we're just using that as a better checksum control.
+We're using RAUC and we've ensured that only root can invoke a `rauc install ...`, which means that nobody but root can install a malicious image.
+Root can already do *anything* on these devices, and that's by design, we are not using signed boot images verified by the boot loader, or anything like that, really.
+So what we've lost is a safeguard from RAUC saying "hey, that FW image that you're downloading, that has not been produced by CESNET".
+
+If we used a "real setup" with a proper CA and key management, we would probably have one certificate chain for "development builds" in the CI, and some re-signing for images that have been "approved" (merged patches).
+We would also require something for developers' local workflow with transient keys, probably short-lived ones.
+We would have to set up some key management.
+We would have also needed to define a process on how to configure a device to accept the development images.
+
+However, any developer is allowed to propose patches, and these patches would get auto-signed by the CI anyway.
+Granted, it would not be the "production signature", but these boxes will *have* to accept these devel signatures anyway.
+We would also have to deal with the back-and-forth of key signing and certificate renewal.
+
+What we chose instead is to "disable" RAUC signature verification.
+Now that anyone in the world can build an image and have it signed, we have downgraded RAUC's signature checking to a glorified checksum.
+
+TL;DR: this means that we are effectively not using RAUC's image verification.