Kevin P. Fleming
kpfleming at linuxfromscratch.org
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
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