Open Source Stack Exchange is a question and answer site for people organizing, marketing or licensing open source development projects. It only takes a minute to sign up.
Sign up to join this community
I am working on a little project, and I consider making it open source (GPLv3). But there is one little problem:
There are a few lines of code I don't want to show off to the public because of a security reason. The reason is because the contents of the function could 'give away' secret keys.
May I do something like this?
void aFunction
{
//Hidden because of security reason
}
Without this function, the program complies but doesn't fully work.
You are not generally required[1] to release any secret keys necessary to make an application run. Instead, users can obtain their own key.
However, redacting your source code is not a suitable approach, for the primary reason that this is inconvenient and risky for you. When you publish a new version of the code you have to make sure to always redact it. If you are publishing via a version control system such as Git, you have to make sure that no published version in the whole history of the project contains these secrets.
Instead of redacting that code, make it configurable. Store the secrets in a configuration file or in environment variables (both have different risks). It is easier to prevent a config file from being checked into version control than to prevent only the contents of a single function.
If you need to redact behaviour rather than data such as keys, then this becomes more complicated, both legally and technically: you could extract the sensitive behaviour into plugins of your application. However, that may be problematic if you accept outside contributions to your software and if you would like to distribute these plugins, since in-process plugins to a GPL system must also be licensed under the GPL.
[1]: If you are embedding GPLv3 software in a “User Product” and you are able to update the software of such a device, then you must also give recipients of the software the means to update the device with their modifications. This may involve providing keys, e.g. for signed bootloaders.
There are two different issues here:
For the legal side, there is one major case where this would not be allowed. If your project uses someone else's code that is under the GPL (or other copyleft license), then the terms of the GPL require your code to also be licensed as a whole under the GPL when you choose to distribute it. If you choose to distribute the code in binary form, then an issue arises, because the GPL requires that you accompany distribution of GPL'd binaries with their full corresponding source code. Omitting aFunction in the program's corresponding source would be a GPL violation, since you distributed a derivative of someone else's GPL-licensed code in binary form but failed to share the complete corresponding source of the binary.
If you are the sole author of the code, or distribute the incomplete source only, or are not using a copyleft license that requires corresponding source alongside binaries, then you do not have this issue. For example, the permissive MIT/X11 license requires no corresponding source to accompany a binary, so if you choose to share almost everything except one function, you're going above and beyond what such a permissive license requires.
On the technical side, the fact that you feel the need to do this strongly suggests some kind of inferior security through obscurity. This is captured in Kerckhoffs's principle, which may be summarized as, "The security of a system should depend entirely on the secrecy of a random key value. It should not be a problem if an attacker learns how the system operates."
If you have a security system that relies on its operation remaining secret rather than on a random key value, it probably is not a very strong security system. (All serious modern cryptographic systems are designed with this principle in mind.) When distributing your source code, you should keep the key secret, but simply provide users a way to generate or provide their own key(s). The key is not code within the software system; it is a configuration value provided to the system. (I have a related answer for the question Open Source Projects with Encryption Keys.)
Alternatively, if your secret system is a system for flagging bad behaviors (e.g., Stack Exchange bans users after a they match a secret pattern of bad behavior) and you keep it secret to keep users from skirting the line, I still think configurable-values are the way to go. Don't write you system to say
after 3 bad actions, ban the user for 24 hours
Instead, say
after N bad actions (which is the set of actions in {A1, A2, A3,...}), ban for H hours
where N, {A}, and H are values specified by the administrator running the system.
