Question

We have a C/C++ project where we wish to encrypt (with GPG) every single source file, and have make (specifically, GNU Make) seamlessly work (as it does now with unencrypted source).

If we encrypt only the C or C++ files, this seems fairly easy to accomplish with a rule like this:

%.o : %.cc.gpg %.hh                                                             
    $(GPG) --decrypt $< | $(CXX) $(CFLAGS) -x c++ -c -o $@ -

However, if we start encrypting header files, it gets a lot trickier, as the C file may #include any number of headers. So it seems to me that first I need to generate a dependency list, then decrypt every one that is encrypted, and compile. Ideally, the decryption would be done in-memory, rather than leaving decrypted files laying around while compilation takes place.

Some notes, in anticipation of the comments I’ll get:

• The users’ workflow will involve GPG plugins for their editor, but the rest should be as seamless as possible (i.e. traditional commandline-based Linux svn + make + gcc workflow)
• We are using subversion for source control. We know and are OK with source being stored as binary blobs (as well as the implications of this, e.g. breaking svn diff)
• The subversion repo lives on an encrypted filesystem (LUKS), and access is only through https
• This is a management requirement
• In my web research of this problem, I’ve seen a lot of people argue against encrypting every source file. As I said, it’s a management requirement. But one thing that is not addressed by these arguments is keeping the source safe from sysadmins. Yes, at some point you have to trust people, but our source is kind of like the recipe to Coke: if it is uncontrolled, it could literally ruin the company. So why take chances?

Answer 1

You have two problems: 1) decrypting files in the build process and 2) keeping the cleartext in RAM. The second is a little out of my field; I’d suggest air-gapped workstations with nightly disc-scrubbing and a really good auditing system, and anyone who points out a flaw in security gets rewarded, not punished. Anyway let’s assume you’ve solved that problem. (At this point you could just decrypt the whole code base and work normally, but let’s try to find a tighter solution.)

For the decryption, you’re halfway there. Instead of decrypting in the %.o rule I’d break it into separate rules:

%.cc : %.cc.gpg                                                             
    $(GPG) --decrypt $<

%.o : %.cc %.hh                                                             
    $(CXX) $(CFLAGS) -x c++ -c -o $@ -

Now as you say, all you have to do is generate a dependency list. Then you can expand the first rule to cover encrypted headers and you’re golden.

If you’re using a civilized compiler like g++, you can (in general) generate a dependency list with g++ -M, and use that to write a “smart” %.o rule such as described here, which will handle all dependency problems automatically and invisibly.

The problem is that you can’t use g++ -M at first, because you’re in a viscous circle: you don’t want to decrypt all of the headers, just the ones you need, so you can’t do the decryption until you know which headers you need, but you won’t know that until you generate the dependency files, which means running g++, but g++ will pitch an error and quit if a needed header isn’t there already.

So we’ll cheat. Suppose we have a separate directory full of empty header files with the same names as the real header files (trivial to build/maintain with Make). We can direct g++ (and Make) to look there for any headers it can’t find in the usual place. That is not enough to actually compile objects, but it is enough to run g++ -M without error. The dependency list it constructs will be incomplete (because the real headers may #include each other) but it is enough for the first iteration. Make can decrypt those headers, then start over; when the results of g++ -M are the same as the list from the previous iteration, the process is complete, all needed headers have been decrypted and compilation can begin.

Is that outline enough, or do you need help with the nut and bolts?