lsh 0.1 released (gpl'ed ssh) and expo pics
Mark Mealman
> check http://linuxtoday.com/
> also, my expo pics are up at http://158.59.192.56/le99/
>
Been waiting for a GPL ssh replacement.
Much too useful an admin tool not to have gpl'd.
Any chance it's going to forward X requests any time soon, or is that
feature a tricky bit of code work to pound out?
-Mark
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Miquel van Smoorenburg
Mark Mealman <mmea...@concentric.net> wrote:
>Been waiting for a GPL ssh replacement.
>Much too useful an admin tool not to have gpl'd.
>
>Any chance it's going to forward X requests any time soon, or is that
>feature a tricky bit of code work to pound out?
Compared with encryption theory, certificates, public/private keys
and all that, forwarding X11 requests is completely trivial. However
because of that I think they will concentrate on getting the core
right, and adding things like X forwarding as a finishing touch.
Mike.
--
Indifference will certainly be the downfall of mankind, but who cares?
J.H.M. Dassen
> Compared with encryption theory, certificates, public/private keys and all
> that, forwarding X11 requests is completely trivial. However because of
> that I think they will concentrate on getting the core right, and adding
> things like X forwarding as a finishing touch.
One of the core issues at the moment is interoperability with SSH2; SSH2
didn't implement the documented protocol properly, and although there have
been improvements, I doubt lsh 0.1 is interoperable with SSH2 at this point.
Lsh can do with more developers, especially ones with experience with both C
and Scheme. See http://www.net.lut.ac.uk/psst/ .
Ray
--
Cyberspace, a final frontier. These are the voyages of my messages,
on a lightspeed mission to explore strange new systems and to boldly go
where no data has gone before.
Rob Browning
> Lsh can do with more developers, especially ones with experience
> with both C and Scheme. See http://www.net.lut.ac.uk/psst/ .
I'd qualify on the C/Scheme front, but I'm presuming that it needs
non-us developers, right? and further, I'm not a cryptography
expert...
--
Rob Browning <r...@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
J.H.M. Dassen
> I'd qualify on the C/Scheme front, but I'm presuming that it needs non-us
> developers, right? and further, I'm not a cryptography expert...
There are quite a few things to be done that do not require cryptography
expertise (e.g. documentation, most of the work on identifying
interoperability issues with SSH2, implementing some features). The core
crypto code of lsh is well-tested (it comes from Pike mostly). The SSH2
protocol is quite modular, so deep knowledge of crypto isn't required.
As to whether you need to be non-us, US developers are definitely welcome,
but should be aware of the regulations. As I understand things, it's
probably safe if you distribute/export contributions in patch form, as long
as these contributions do not directly affect the cipher code. After all,
one could modify lsh's sources to do ROT-13 encryption only; then it should
be safe to export from the US.
HTH,
Ray
--
PATRIOTISM A great British writer once said that if he had to choose
between betraying his country and betraying a friend he hoped he would
have the decency to betray his country.
- The Hipcrime Vocab by Chad C. Mulligan
Philip Hands
> There are quite a few things to be done that do not require cryptography
> expertise (e.g. documentation, most of the work on identifying
> interoperability issues with SSH2, implementing some features). The core
> crypto code of lsh is well-tested (it comes from Pike mostly). The SSH2
> protocol is quite modular, so deep knowledge of crypto isn't required.
Do you happen to know what the deal is as far as being contaminated by
having seen ssh code ? Are they trying to ensure clean room
conditions as far as the ssh code is concerneted ? I've seen a fair
amount of the ssh v1.2 code (being it's Debian maintainer), but the
only bit of ssh v2 I've read is the license. Does that mean I'm OK ?
On a related subject, has anyone else looked at packaging lsh?
I started on it, then it occured to me that I might be unable to
contribute to lsh without opening them up to claims of copyright
infringment from SSH Communications Security Ltd.
Cheers, Phil.
J.H.M. Dassen
> Do you happen to know what the deal is as far as being contaminated by
> having seen ssh code ?
IANAL.
> Are they trying to ensure clean room conditions as far as the ssh code is
> concerneted ?
I'm not sure how clean room conditions can be created at all when the ssh
code is free for download.
SSH want SSH2 to be a proper RFC, so there must be an independent
implementation; I'm doubt they're completely unhappy about lsh.
> On a related subject, has anyone else looked at packaging lsh?
I have a preliminary debianisation (mainly because it helps me compile it
easier). There are a couple of problems with packaging lsh I can see now.
- The daemon isn't a real daemon yet. I have patches for that which haven't
been incorporated upstream.
- It relies on a non-free interpreter (scsh) for building. Tommi Virtanen has
sent me details on how to use scm instead, so it'll be fit for non-us/main
rather than non-us/contrib.
- I don't know how to resolve the port conflict. Port 22 is for the SSH
protocol, both v1 and v2. lsh can fallback to calling sshd1 (just like
sshd2 can), but I'm not sure how to properly ensure it, rather than sshd1,
gets port 22.
- Last time I checked, lsh and SSH2 weren't interoperable yet. (SSH2 used
to not implement the spec properly; some improvements were made, but the
issue isn't gone yet I fear)
Ray
--
LEADERSHIP A form of self-preservation exhibited by people with auto-
destructive imaginations in order to ensure that when it comes to the crunch
it'll be someone else's bones which go crack and not their own.
- The Hipcrime Vocab by Chad C. Mulligan
Philip Hands
> I have a preliminary debianisation (mainly because it helps me compile it
> easier). There are a couple of problems with packaging lsh I can see now.
> - The daemon isn't a real daemon yet. I have patches for that which haven't
> been incorporated upstream.
> - It relies on a non-free interpreter (scsh) for building. Tommi Virtanen has
> sent me details on how to use scm instead, so it'll be fit for non-us/main
> rather than non-us/contrib.
> - I don't know how to resolve the port conflict. Port 22 is for the SSH
> protocol, both v1 and v2. lsh can fallback to calling sshd1 (just like
> sshd2 can), but I'm not sure how to properly ensure it, rather than sshd1,
> gets port 22.
If you tell me an easy way to diagnose the presence of lsh, then I'll
just make execution of sshd1 conditional on it not being there.
BTW, what are you going to call it, given that we already have:
Package: lsh
Version: 0.62-9
Architecture: i386
Depends: libc6
Installed-Size: 89
Maintainer: Joey Hess <jo...@master.debian.org>
Description: Baby Shell for Novices with DOS compatible commands
Is there any other psst implementation ? If not you could call it
psst, or perhaps psst-lsh ? Although there's still the name conflict
with lsh, I'd imagine.
> - Last time I checked, lsh and SSH2 weren't interoperable yet. (SSH2 used
> to not implement the spec properly; some improvements were made, but the
> issue isn't gone yet I fear)
Is it possible to spot ssh2 at the other end, and have lsh just give
up immediately.
I doubt there there are many people that are going to be using both in
the near future, since they appeal to different people.
For the odd one or two that might want to mix and match, they can
always explicitly run ssh1 when confronted with a machine from the
other camp, and force the other end to drop back to ssh1 as well.
Cheers, Phil.
sha...@clifford.livenet.net
> "J.H.M. Dassen" <jda...@wi.leidenuniv.nl> writes:
>
> > I have a preliminary debianisation (mainly because it helps me compile it
> > easier). There are a couple of problems with packaging lsh I can see now.
> > - The daemon isn't a real daemon yet. I have patches for that which haven't
> > been incorporated upstream.
> > - It relies on a non-free interpreter (scsh) for building. Tommi Virtanen has
> > sent me details on how to use scm instead, so it'll be fit for non-us/main
> > rather than non-us/contrib.
> > - I don't know how to resolve the port conflict. Port 22 is for the SSH
> > protocol, both v1 and v2. lsh can fallback to calling sshd1 (just like
> > sshd2 can), but I'm not sure how to properly ensure it, rather than sshd1,
> > gets port 22.
>
> If you tell me an easy way to diagnose the presence of lsh, then I'll
> just make execution of sshd1 conditional on it not being there.
Why can't lsh and ssh provide ssh and sshd packages? That way only one can be
installed -- like many other daemons do.