Commit acba722b authored by Niels Möller's avatar Niels Möller

*** empty log message ***

Rev: ChangeLog:1.96
Rev: NEWS:1.21
Rev: doc/TODO:1.56
parent aff35468
1999-09-07 Niels Mller <nisse@cuckoo.localdomain>
* abstract_io.h channel.c channel.h channel_commands.c client.c
command.c gc.c gc.h io.c lsh.c lsh.h lsh_writekey.c lshd.c
read_data.c read_packet.c server_password.c service.h sexp_conv.c
sexp_parser.c sexp_streamed_parser.c tcpforward_commands.c
tcpforward_commands.h werror.c: Cleaned up and deleted old dead
code.
* src/Makefile.am.in (liblsh_a_SOURCES): Removed sexp_parser.c
* configure.in: Bumbed version to 0.1.9.
* src/server_session.c (do_spawn_shell): Use better exception
......
News for the lsh-0.1.9 release
Lot's of bug fixes. This version actually seems to work.
Bazsi's public key patches is in, although I haven't been able
to test them.
The SEXP parser is rewritten to use the new exception
framework. The program that makes the most of of this rigth
now is lsh_writekey. Its core reads like
(params
(private object io_write_file_info)
(public object io_write_file_info))
(lambda (backend)
(let ((key (read (stdin backend))))
(prog1 (transport (open backend public) (private2public key))
; FIXME: Add encryption here
(canonical (open backend private) key))))))
The sexptest program has been renamed to sexp_conv. It reads
an sexp (for now, only canonical and transport syntax are
supported) on stdin, and prints it using advanced, transport
or canonical syntax. More features could be added.
The --debug option now dumps both sent and received packets,
and it includes a human readable name of the packet type.
Packets of type SSH_MSG_USERAUTH_REQUEST are suppressed,
however, because they typically contains user passwords.
There is one known bug: Running without pty allocation (lsh
-nt) doesn't work, at least not for me.
News for the lsh-0.1.8 release
Reworked all the error handling to use exceptions. No new
......
ERROR HANDLING
Consider return values from handlers. A return value has several
components:
x Success/failure indication
x Next action (continue, close immediately, flush buffers then close,
exit...)
x Process return value in case the proper action is to exit.
It should be possible to encode all this information into a simple
integer. And some actions are orthogonal. For instance, a handler may
fork, and send a few messages. Now, both the fork action and any error
codes from writing must be taken care of.
Perhaps errors when processing data on one socket should propagate to
another one?
Can one safely assume that the only error that can occur when sending
a packet (typically by A_WRITE(connection->write, packet)) is LSH_FAIL
| LSH_CLOSE?
What about returning errors from commands? We can either do
COMMAND_RETURN(c, NULL) to invoke the commands continuation with an
error value, or we could decide that the continuation should be
invoked only if the command was successful. Or we could use a separate
continuation for errors; that would be similar to a primitive
exception system.
EXCEPTIONS
When using exceptions in commands like do_request_service, when should
......@@ -208,12 +176,9 @@ Description: Baby Shell for Novices with DOS compatible commands). Perhaps
we need to change our name?
Get a decent source of random (the current version will fall back to a
really poorly seeded generator if /dev/urandom is not available); most
likely, reusing the rand* from GPG's g10 is the best option. Werner
Koch is now working on making a libgcrypt out of GPG's random and
crypto code.
Use UNUSED where parameters are unused intentionally.
really poorly seeded generator if /dev/urandom is not available). Two
main alternatives are Werner Koch's code in GnuPG, and Peter Gutmann's
libcrypt.
Make it cleaner wrt. more gcc warnings.
......@@ -275,7 +240,6 @@ Bazsi. Hmm, this is probably not a bug. I have to find out what the
right way is to handle the poll conditions POLLERR, POLLHUP and
POLLERR.
Implement some limit on the amount of data that may be buffered for
write on a connection. When the limit is exceeded, the connection
should be dropped. The problem: if a client connects and sends a lot
......@@ -284,12 +248,6 @@ will eventually run out of memory.
Consider removing the write-attribute from ssh_channel.
Try to get rid of some of the LSH_*-status codes, in particular
LSH_CHANNEL_READY_REC. Use functions instead. The reason is that the
function that wants to start receiving is not necessaily called from
the functions in channel.c, and therefore the status code doesn't pass
through channel_process_status().
Let init_channel take enough arguments to initialize the window- and
packet-size fields properly. It's too easy to forget them.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment