Compilation strategy

[Rob T]

On Monday, 17 December 2012 at 12:54:46 UTC, jerro wrote:
>> If we want to allow D to fit into various niche markets 
>> overlooked by C++, for added security, encryption could be 
>> added, where the person compiling encrypted .di files would 
>> have to supply a key. That would work only for certain 
>> situations, not for mass distribution, but it may be useful to 
>> enough people.
>
> I can't imagine a situation where encrypting .di files would 
> make any sense. Such files would be completely useless without 
> the key, so you would have to either distribute the key along 
> with the files or the compiler would need to contain the key. 
> The former obviously makes encryption pointless and you could 
> only make the latter work by attempting to hide the key inside 
> the compiler. The fact that the compiler is open source would 
> make that harder and someone would eventually manage to extract 
> the key in any case. This whole DRM business would also prevent 
> D from ever being added to GCC.

Of course open source code would never be encrypted, I was 
suggesting an entirely optional convenience feature for users of 
the compiler and not a general method of storing library files or 
for providing a fool proof method for the mass distribution of 
hidden content.

Having such a feature would allow a company or individual to 
package up their source code in a way that no one could look at 
with out a specific key. It does not matter if the compiler is 
open source or not, only a user with the correct key could 
potentially decrypt the contents in a way that was unintended.

Obviously anyone who has enough skills and the correct key to a 
specific encrypted package could decrypt the contents of that 
specific package (and then post it on usenet or bt or in a 
million+1 other ways), but you would still need access to the key 
and you would need access to a tool that decrypts the contents 
(such as the compiler itself), but that's what security is all 
about, it's simply a set of barriers that make it difficult, but 
not impossible, to break through. All security systems are 
breakable, end of story, no debate there, just take a look around 
you and see for yourself.

The difference between packaging in an encrypted archive, which 
is later decrypted and installed for use, is that in this case 
the source code is never left lying around in a form that is 
decrypted, it is also more secure because the source data is 
decrypted only when it is being compiled, and the decrypted 
content is immediately discarded (in a secure way) afterwards.

BTW, for the record I'm no fan of DRM in the general sense, but 
many companies think they need to lock out prying eyes and it's 
not my place to tell them that they should not be worried about 
it and fully open up their doors to whatever content they want to 
distribute.

--rt