3

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.

  • 1
    Why do you want to open-source your code, and which license would you use? Would the software still run fine without that code? What kind of security features would you be hiding, e.g. secret keys or usage of private APIs? – amon Nov 16 '17 at 17:41
  • If you did that, then the source code would not work anymore. Unless the function does nothing to begin with. If you only want to distribute the binary, then just do that. It would not be Open Source, though. – Brandin Nov 16 '17 at 19:39
  • 1
    @amon GPLV3 license. The reason is because the contents of the function could 'give away' secret keys. And it without this function, the program complies but doesn't fully work. – Hugo Woesthuis Nov 16 '17 at 19:58
  • @HugoWoesthuis If you don't give away the secret key, but your program needs it in order for it to work properly, how do you expect the end user to actually run your program? GPL is about releasing source that actually works. Of course, if you are the copyright owner, you could always choose to release it under two licenses: a binary-only version (proprietary license) and a GPL-version which is missing the functionality provided by the key. – Brandin Nov 16 '17 at 20:31
8

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.

  • Actually, if you distribute the sensitive parts as a plugin, you don't have to license them under the GPL. You're the copyright holder; you have more extensive rights than everyone else (theirs are only the rights granted by the license; yours are everything). Those rights include the ability to not comply with the license you set. – ArtOfCode Nov 19 '17 at 18:47
  • You're of course right, I fixed that “or” to an “and”: only after the author accepts outside contributions do they become bound by the GPL as well. (Unless they introduce a CLA first.) – amon Nov 19 '17 at 18:59
4

There are two different issues here:

  • a legal "May I...?"
  • a technical "Should I...?"

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.

  • BTW, technically, the secret function might be inside a plugin. AFAIK, the plugins of a GPLv3 software are not necessarily required to be GPL. You could for example provide with your GPL software a fake plugin which is enough to make the software useful and usable. – Basile Starynkevitch Nov 23 '17 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.