Programming language

Kevin P. Fleming kpfleming at
Tue Feb 1 17:11:14 PST 2005

Gerard Beekmans wrote:

> it's a more basic structure rather than relying on a program like ssh(d)
> to do the work for you. What if SSH isn't available? Say during an
> upgrade. And for it to work nicely you would want to setup keys so you
> don't have to enter a password. Then, without ssh there has to be some
> kind of authentication still. I'm not sure about that part yet.

I do not see any value in building any sort of authentication/security 
system into the alfs tool at all (is that a strong enough opinion?).

If you want safe transport across the network, either use SSH tunneling, 
tell the user to use a VPN, or build TLS support into alfs using the 
OpenSSL library.

If you want strong authentication, either use SSH tunneling, SSL 
certificates using the OpenSSL library, or full-blown SSL/TLS using SASL 
(which can tie into every authentication database imaginable).

> I think a plain client/server model is still the best no matter what we
> might run on top of it. It is just one less dependency. If your break
> ssl/ssh you can actually run the remote alfs-server to fix your ssl and
> ssh problems, rather than having to revert to a manual physical proces
> on the machine to do it that way (...and if the machine is hundreds of
> miles away, that becomes a problem).

Conversely, the project already has severely limited resources, so 
directing some of those resources into implementing any 
security/authentication system seems a poor choice, in my opinion. It 
also become a never-ending task, with drastic security implications for 
the maintainers of the code. I don't think any of us want to be seeing 
CERT advisories about the "alfs daemon that runs with root privileges".

More information about the alfs-discuss mailing list