[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #56633] Know how protection: Running encrypted
[Octave-bug-tracker] [bug #56633] Know how protection: Running encrypted program files
Tue, 16 Jul 2019 03:46:45 -0400 (EDT)
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
Follow-up Comment #4, bug #56633 (project octave):
Thank you very much for your valuable comments! I will try to answer all
questions from bottom to top starting with Kai Torben:
[comment #1 Kai Torben's comment #1:]
> 1. Octave is free/libre and open source software. This is the nature of the
GPL to not obfuscate:
My concern is not the obsfuscation but what Mike pointed to: Protection of
privacy is important to our work.
[comment #1 comment #1:]
> 2. If you write software depending on Octave, please make sure, that you do
not violate the GPL license terms:
Thank you for the hint! I just checked it again and found we are perfectly
aligned with octave license conditions.
[comment #1 comment #1:]
> 3. If you earn money using Octave, please consider contributing back. I've
seen you already submitted patches to Octave. Development power is needed,
otherwise jwe would not mind a small tip for all his great effort you benefit
from, and your customers as well.
This is _a must_ in my eyes: Octave saves us money and we earn some money with
our code written in octave, therefore we are donating back in form of (yet
small) code contributions and my work power as much as I can do to improve
octave. I also sent the donation link last year to my boss and it was very
easy to convince him of the good purpose to donate money to octave. I think I
can convince him again this year :)
[comment #2 Mike's comment #2:]
> However, I do think this is entirely outside of the scope of Octave. Privacy
software is really hard to get right, and Octave is already hard enough. I do
not think it is worth the risk to Octave and its maintainers to try to take
something like this on.
> I would recommend using the GnuPG program to encrypt and decrypt files as
needed, and maybe something like an encrypted loop back device to host the
files while they are temporarily decrypted to be read by Octave.
I agree that it is not a good idea to overload octave with specific
implementations of security code. Even when using the common libraries for
this, small portions of code inside octave can break the whole chain.
My recommendation is to provide a (plugin?) interface that allows octave to
read source code (and maybe even data files) from a stream or file provider.
This is very similar to Mike's suggestion using some kind of loop back
decryption device. Maybe it is already a good solution to read source code
from a (relatively) secure anonymous pipeline
at least under unix. I don't know if this would work under windows too.
[comment #3 Michael's comment #3:]
> User code can be written in such a way that it is made clear that it is only
for use by those who have been granted permission by the owners. Managing that
and taking action is case of violations is up to the software owners.
You are right that users have to complement security code with legal measures.
But the outside world is not every where respecting these rules. Best
protection of know how stays privacy.
What do you think about my suggestions? Would it be possible adding pipeline
reading/interpretation of source code to octave?
Reply to this item at:
Message sent via Savannah