security files

Fri Sep 26 17:05:00 GMT 2003

> Sun puts it in jre/lib/security/java.security, I'm sure you can
> transpose filenames and follow the Bouncy Castle docs.

I've now moved on to investigating an apparently nice library that does ssh in java
(http://www.thestonecutters.net/xod/projects/tv/pokkari/ssh/). I'm still getting null
pointer exceptions left and right (could be protocol-related issues, or else things
related to compiling natively), but I may just get there. One problem got solved:
Apparently, the bytecode JDK allows you to move an integer to a byte without
explicit casting? I didn't know about this... In such case, I would think that gcj
is more logical. But then again, I've had to do this:
...
	private final int SSH_SMSG_STDOUT_DATA =		17;
...
//X	error!				byte packet_type = SSH_SMSG_STDOUT_DATA;
					byte packet_type = (byte) SSH_SMSG_STDOUT_DATA;
The problem occurs with:
Reading specs from /usr/local/gcc/3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs
Reading specs from
/usr/local/gcc/3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/../../../libgcj.spec rename spec
lib to liborig Configured with: ../gcc-3.3/configure --prefix=/usr/local/gcc/3.3
--enable-languages=c,c++,java --enable-threads=posix Thread model: posix
gcc version 3.3
This pokkari library looks promising (if I get it to work). It is way smaller and
easier to operate than the re-usable, aka "over-engineered" stuff based on the
so-called "JCE" standard, which only does a bit of "providing" of a few algorithms,
but needs megabytes already to do just that.
$ du pokkari-ssh -hs
163K pokkari-ssh
In the end, we're talking about a conversation like:
...
SSHConnection sshConnection=new SSHConnection("host","user","pwd");
String publickey=sshConnection.open();
//check key if you want to, and where you want to; or not; up to you
sshConnection.exec("ls -l");
//now read from the connection's stdin, write to its stdout/stderr, as you like
...
Otherwise, I'll look into CNI-wrapping something native, if I can find any (simple,
correct, fast, and acceptable footprint). It will take less time than jumping through
all these JCE hoops. Or even a vanilla native executable somewhere (self-contained
though) would do.
In the end, I'd just like to execute a script on the server from a java SWT program
on the client (win32/lin32), without the need to install dlls, jre's, security files,
and so on, on every client machine.