I would like to export my solution with password encryption in a way it only can be imported by an Servoy application server and not by Servoy developer.
This for the sake of source protection.
Is this possible ?
Regards,
you can’t import a password protected solution, into developer!
try it! export with password and try to import it into a clean developer.
Thanks, Harjo ! I did not test it before.
Do you know if this behaviour is documented by Servoy ?
No I don’t know, but I find it quit obvious, that a password protected solution, stays protected!
Related to this subject, I would like to know if it is possible the protect the source code, but external partners can use the source code I wrote.
I have a full framework written in Servoy.
I want external users to use the framework, to build solutions based on my framework, but I don’t want them full access to the framework source.
But they need the framework in development, to test solutions.
Compare it like a plugin. I can use the methods of a plugin, but I don’t know what coding is behind.
It would be nice if I can protect my Servoy solution also like this.
I can imagine that when I use the JSDocs, that like this I can show the options of my framework methods.
Is this possible, or is this one step too far?
Martin
If I remember correctly David Workman did something like that in the past, you could ask him.
you can’t import a password protected solution, into developer!
I assume you mean that you can’t when you don’t know the password, right?
Paul
pbakker:
you can’t import a password protected solution, into developer!
I assume you mean that you can’t when you don’t know the password, right?
Paul
Indeed!
martinh:
I have a full framework written in Servoy.
I want external users to use the framework, to build solutions based on my framework, but I don’t want them full access to the framework source.
But they need the framework in development, to test solutions.
currently this is not possible directly in servoy, we are looking into possible solutions for this after the release of Servoy 6
What you could look at currently is to use some kind of obfuscation…
So have a special workspace where clean checkout your solutions, run some kind of js obfuscation over your files, and then make your export.
To get things straight: when a solution is exported with a password this password is not asked when trying to import this solution in Application server (I experienced this myself) but it is asked when trying to import this solution in Developer.
On this topic, I had assumed that the file itself was password protected, but I was surprised to discover that a password protected .servoy file can be unzipped without a password, and the entire source is readable in solution.xml with any text editor. So be aware that while your code can’t be imported into developer without a password, it’s certainly not secure from prying eyes.
I would say to Servoy :
Time for some ‘enhanced security’
We would like to distribute our solutions to end-users and in the current insecure way we can’t.
I would like to vote for a secure password encrypted solution-export only to be imported in App.server with password.
But now I think about it : Servoy Developer is open source so readable for everyone…
Maybe a separate (online ?) not open source servoy tool to encrypt solution files ?
Regards,
this is how it is designed.
the soluton password is for developers not for runtime
it is meant for that users van use it as a module at runtime (so the app server) but cant really program with it.
if we really protected the zip, then the servoy file can never be used without a password so it doesnt make much sense then because what would that do? everybody that would use your solution needs to have the password. so then it is just a secure transport… but for that you have many other ways.
Perhaps an option to delete the .servoy file after import would help. For example, if you have application servers running on a LAN at sites without internet access then you want a way to deliver solution updates securely. The fewer manual steps the better.
jcompagner:
this is how it is designed.
the soluton password is for developers not for runtimeit is meant for that users van use it as a module at runtime (so the app server) but cant really program with it.
if we really protected the zip, then the servoy file can never be used without a password so it doesnt make much sense then because what would that do? everybody that would use your solution needs to have the password. so then it is just a secure transport… but for that you have many other ways.
Hi Johan,
I mean secure so that if an end user distributes the file (with password) to someone else that file cannot be easily hacked as is the case nowadays.
IMHO the only way to achieve better security is to implement some kind of decrypting at import.
It would be even greater if the App.Server had online access to developer bound encryption keys at a secure Servoy site (hardcoded in Servoy app.server).
Nice selling point for Servoy…
I cannot imagine that all Servoy developers do the solution import themselves online at all of their customers/end users sites.
Keep in mind also that the source code is kept as plain text in the repo as well, has been since version 3 (at least thats when I started using servoy, probably was also for earlier versions) and can be reverse engineered without much difficultly into the full source tree. That was the premise of my project back before we had a good VCS to use with servoy (viewtopic.php?f=15&t=8966&p=44709)
So even if that one file is super protected, it is all still plain text in the database.
Please see my email sent to Servoy regarding Javascript security:
We propose having two export options which are independent of each other, and if both options are used, each password should be unique:
- Require password to import solution: password1
- Require password to view source code: password2
The first option would behave like the current export option. If the first option is checked and password1 is supplied then the protected solution would require password1 to be entered prior to importing the solution into the developer or the application server.
The operation of the application server would not be affected whether or not the second option is checked and password1 is supplied. If the solution is protected with the second option checked and password2 supplied then the developer operation would change as follows:
- The exporting developer would encrypt the embedded JavaScript source code contained in the .servoy file using a single key embedded within the JAVA code for the Servoy developer. The embedded key would not be contained in any of the source code available under the open source license since the key would be treated as data.
- The importing developer would use the embedded key to decrypt the embedded source code contained in the .servoy file if and only if the same password2 supplied for the second option during the export process is supplied during the import process.
We are making the assumption that the application server does not use the source code to compile the imported solution and place the results into the servoy_repository database. We are assuming the meta-objects and compiled JavaScript code are contained in the exported solution and placed directly into the servoy repository upon import. Our assumptions may be incorrect but the larger goal is to be able to protect the IP contained within the JavaScript code using a method other than obfuscation. Unlike obfuscation, the proposed source code encryption would not affect the JavaScript compile time or require the use of custom or proprietary frames. It would be of great value to any ISVs who have non-SAAS customers.
Thank you for your consideration.
ryanparrish:
Keep in mind also that the source code is kept as plain text in the repo as well, has been since version 3 (at least thats when I started using servoy, probably was also for earlier versions) and can be reverse engineered without much difficultly into the full source tree. That was the premise of my project back before we had a good VCS to use with servoy (viewtopic.php?f=15&t=8966&p=44709)So even if that one file is super protected, it is all still plain text in the database.
Oops, I didn’t know / expect that.
Also time for some extra Servoy ‘enhanced’ security I would think.
rvpm:
We propose having two export options which are independent of each other, and if both options are used, each password should be unique:
- Require password to import solution: password1
- Require password to view source code: password2
The first option would behave like the current export option. If the first option is checked and password1 is supplied then the protected solution would require password1 to be entered prior to importing the solution into the developer or the application server.
the second option is the way it behaves now when you export it. not the first.
rvpm:
The operation of the application server would not be affected whether or not the second option is checked and password1 is supplied. If the solution is protected with the second option checked and password2 supplied then the developer operation would change as follows:
- The exporting developer would encrypt the embedded JavaScript source code contained in the .servoy file using a single key embedded within the JAVA code for the Servoy developer. The embedded key would not be contained in any of the source code available under the open source license since the key would be treated as data.
- The importing developer would use the embedded key to decrypt the embedded source code contained in the .servoy file if and only if the same password2 supplied for the second option during the export process is supplied during the import process.
We are making the assumption that the application server does not use the source code to compile the imported solution and place the results into the servoy_repository database. We are assuming the meta-objects and compiled JavaScript code are contained in the exported solution and placed directly into the servoy repository upon import. Our assumptions may be incorrect but the larger goal is to be able to protect the IP contained within the JavaScript code using a method other than obfuscation. Unlike obfuscation, the proposed source code encryption would not affect the JavaScript compile time or require the use of custom or proprietary frames. It would be of great value to any ISVs who have non-SAAS customers.
Thank you for your consideration.
Embedded keys are just giving you a false security sense, it is not secure at all, If somebody really wants it it can crack it quite easily
and if it is cracked then we need to update the keys or the method, but that would mean that all existing export from older version can never be imported again…
But to get your 2 passwords that you have above
2> is the way we have it now, the developer can only import and use it when it knows the key and can then look at all the sources.
1> is just the same as you zipping the .servoy file and use encryption of your zip utility… (or using any other tool there are many file encryption tools)
But of course if you use <1> then <2> is just some added addition, a developer needs to know both of them to be able to import it in its workspace.
ryanparrish:
Keep in mind also that the source code is kept as plain text in the repo as well, has been since version 3 (at least thats when I started using servoy, probably was also for earlier versions) and can be reverse engineered without much difficultly into the full source tree. That was the premise of my project back before we had a good VCS to use with servoy (viewtopic.php?f=15&t=8966&p=44709)So even if that one file is super protected, it is all still plain text in the database.
Johan,
Can you comment on the above. Secure transport is meaningless if you can pull the source code as this easy out of the repository.