Hi Martin,
Ouch...i think this would be a more clean and less atackable aproach, maybe there would be also an option to use pipes, so instead to provide a file, call the command on its place and send the output to the application? to reduce the requirements for openca and dependencies...
I see some problems on writing confident material on the disk because even on *nix'es you can try to recover files - I had this idea some time ago: Whats about creating a special Ram-Disk or Crypto-Loop device to use as temporary "file" storage ?
but i think, we should also review the code, since we use sometimes temp files for usage with openssl i think... most probably we put senestive data to the harddrive there too in one or another case? or did we remove those issues already?
yes, this is a terrible idea, no commandline pwds, there must be other ways like the stdin, if this works, this is the way to go!- somehow I have to provide the Java tool with the passwords forSo Password in the ps command is a NOGO for me, because this can be seen by ANY user - I see a security breach in this....
key and keystore. This is currently done on the commandline.
Drawback: it briefly shows in the ps command.
Another approach would be to pipe the stuff into the Java command
via STDIN. Environment is not accessible by Java, AFIK.
greetings dalini
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel
