"J.H.M. Dassen (Ray)" <[EMAIL PROTECTED]> writes:
> On Mon, Nov 30, 1998 at 19:11:10 +0100, Niels M�ller wrote:
>
> > Other mostly orthogonal sub-projects are: Configuration (including reading
> > appropriate config files and better command line options), better user
> > authentication methods than passwords,
>
> I'd suggest using PAM (http://www.kernel.org/pub/linux/libs/pam/) for that,
> and have simple password code as a fallback for systems that lack PAM.
PAM support is on the TODO list. But that was not quite what I was
thinking of. As far as I know, PAM is still password authentication,
although a better and more flexible interface than the traditional
functions (but I haven't read the PAM docs yet). Authentication using
public key cryptography, and a user's file of authorized keys, would
not have much to do with PAM, I think.
> > Currently I'm working on the gc and object-system. Unfortunately, this
> > means some changes to many parts of lsh. But it has to be done, and the
> > sooner the better.
>
> Actually, the presence of gc was something I was a bit surprised about. I'm
> not exactly an expert on memory management issues, but wouldn't it make more
> sense to use either an existing garbage collection library, or a debugging
> tool to track leaks
> (http://www.cs.colorado.edu/homes/zorn/public_html/MallocDebug.html
> http://www.fsf.org/software/checker/checker.html or
> http://iseran.ira.uka.de/~armin/ccmalloc/)?
I'll try to explain how I think about gc, as I'm afraid some may find
it a little unorthodox.
The reason behind the decision to use a gc is that the explicitly
deallocating an object is a very global operation. The requirement to
do this makes it *MUCH* more painful to modularize the code. On the
other hand, most of the data in lsh (i.e. all strings) can be managed
quite easily in a producer/consumer fashion. So we only need to use
the gc for objects such as packet handlers, instances of
cryptoalgorithms, and other closures. These are quite few, perhaps one
or two dozen of objects per connection.
Thus, the cost of doing automatic gc on this will be small, while it
makes coding the objects much more straight-forward. And as a simple
mark&sweep algorithm should be adequate, implementation is almost
trivial (what makes the implementation a little more interesting is
that I want to describe the object types in such a way that I can
generate the gc glue needed for proper marking and deallocation
automatically. As a side effect, this should also make the sanity
checks (basically run-time type checking on all casts) more reliable).
Tools like checker and purify may be great for *detecting* memory
leaks (I've used purify a little, and it's really a great tool). But
they *don't* solve the problem of deciding exactly when each object
can be freed, and it is this problem that makes explicit memory
management destroy modularity boundaries.
Personally I think that the *single* most important advantage of using
a higher level languages like python or perl or scheme rather than
plain C is that you don't have to mess with memory deallocation. But
that's no reason why we should have to suffer when we write C-code; a
gc should take care of most of it in one place, in a few hundred lines
of code.
As for existing garbage collection libraries, I don't have much
experience. I think a conservative collector (such as Bohm's, which is
the only widely used gc-library I have read about) is way overkill for
an application like lsh. And I want to use consumer/producer memory
management for some objects, in particular strings, to keep gc
overhead down.
> Anonymous read-only CVS access is very important, I think.
A agree. Do you think an http interface is good enough, for now, or is
it crucial that it is accessible with the plain cvs client?
> > I'm not very familiar with the pserver-feature of cvs, but my impression
> > is that it is not very secure.
>
> I'm not so sure about that. Several large projects like GNOME and mozilla
> use it succesfully. Perhaps you can ask in comp.software.config-mgmt about
> this?
Quoting the cvs manual:
Security considerations with password authentication
....................................................
The passwords are stored on the client side in a trivial encoding
of the cleartext, and transmitted in the same encoding. The encoding
is done only to prevent inadvertent password compromises (i.e., a
system administrator accidentally looking at the file), and will not
prevent even a naive attacker from gaining the password.
The separate CVS password file (*note Password authentication
server::.) allows people to use a different password for repository
access than for login access. On the other hand, once a user has
non-read-only access to the repository, she can execute programs on
the server system through a variety of means. Thus, repository access
implies fairly broad system access as well. It might be possible to
modify CVS to prevent that, but no one has done so as of this writing.
Furthermore, there may be other ways in which having access to CVS
allows people to gain more general access to the system; no one has
done a careful audit.
I should look closer at the pserver features, but I hesitate to allow
anonymous users to execute cvs commands directly on the server. In
particular as Lysator's backup system is not bullet-proof. At Idonex,
the anonymous cvs server runs on a daily *copy* of the real
repository, on a standalone machine; that arrangement makes me feel
better.
/Niels
