Slashdot Mirror

I've been using the beta scp from the author of PuTTY, a very good free SSH1 client for Win32.

You should also try PuTTY.

It's all about who controls access to the information. If you carry a tracking device that belongs to you and is under your control, that's ok: you can consult the logs to find out who/what has requested information, define policy about how the information is to be given out, etc.

If the automation belongs to another body, like the government or the phone company, that's not good: you can't be sure what it is doing with your information.

The case where the collection of personal information depends on a larger infrastructure is an interesting one. Some people have put thought a certain amount of thought into this...

Oh, and it's illegal to use in the US without an RSA license. Damn patent laws.

Without much installation or downloading, there is a freeware application out there called PuTTY.EXE. Enjoy.

You! Reading this article! Do you use ssh and pgp? If not, why not? You're part of the problem!

If you're not using PGP (yet), drop by http://www.pgpi.com/ and have a look around. http://www.pgpi.com/cgi/download-wizard .cgi will let you easily determine exactly which version of is appropriate for your OS and location. PGP installation is pretty straightforward and there is ample online documentation and tutorials. Not only does PGP become more useful each time a new person starts using it, but the more people we have using PGP routinely the harder it will be to remove our freedom to do so. There's no reason not to use encryption, except for inertia. And I guarantee it's not as hard to install or use as you may be thinking.

Using a nice pgp-aware mailer like mutt is a nice step, too.

If you ARE using telnet or rlogin or ftp, then you have problems now and you don't even realize it. Did you realize that every time you telnet or rlogin or ftp to a remote host that you are transmitting your username and password in clear text? Sniffing passwords is a trivial task, mostly due to the widespread use of insecure protocols such as telnet. ssh is a drop-in, secure alternative for telnet, rlogin, rsh, and ftp. Not only is it secure, but it's easier to use and more featureful as well. On top of security it adds such features as compression, encrypted traffic, encrypted tunnels, and completely automatic and secure X11 forwarding. Plus with RSA Authentication you can eliminate passwords entirely. A cracker can't crack a password that doesn't exist.

Unix users can obtain ssh from ftp://ftp.cs.hut.fi/pub/ssh/ and have it up and running in a matter of minutes. I recommend the 1.2.27 version of ssh (as opposed to the v2 platform) due to licensing difficulties with the v2 platform. Non-unix users have even more options.

For Win32 there's SecureCRT (http://www.vandyke.com) which is an excellent, albeit commercial solution. There's also a very nice, free implementation of ssh which works with Tera Term. You can grab it from http://hp.vector.co.jp/author s/VA002416/teraterm.html

There's even an opensource ssh for win32 at http://www.chiark.greenend.o rg.uk/~sgtatham/putty.html although I must admit that I'm not sure I trust an ssh implementation done by a guy who refuses to implement RSA Authentication.

For Macintosh, I understand that there's a nice plug-in for NiftyTelnet at http://www.lysator.liu.se/~jon asw/freeware/niftyssh/ although I've not used it.

There's never been a better time to be more secure. Simply by installing a couple of easy-to-use applications you could be on your way to a more secure, more private computing experience. Your data is yours, and here are two ways to ensure that it stays that way.

Yeah, I ripped this shamelessly from my .plan -- so sue me, it's still useful information...

Bruce

The Apple Public Source License - Our Concerns Bruce Perens , Primary Author: The Open Source Definition. Co-Founder: The Open Source Initiative.
Wichert Akkerman: Debian Project Leader.
Ian Jackson: President, Software in the Public Interest. Author, Debian package installation tool `dpkg'.

We welcome Apple Computer, Inc. as a participant in the Free Software Community. We feel that a few problems in the present version of the Apple Public Source License (the APSL) disqualify it as "Open Source(TM)" or "Free Software". We hope that Apple can address these issues to everyone's satisfaction.

The participation of companies like Apple and IBM should be considered in the same way as the participation of any free software developer. Everyone is welcome to make a contribution. Individually, we each decide whether or not to accept a particular developer's contribution, for reasons that range from technical to legal and licensing concerns. We openly discuss these issues before our community, often quite harshly, as a means of developing consensus and charting our course. One consensus that we've reached is the Open Source Definition, a generally accepted definition of Free Software licensing, written by Bruce Perens and the Debian GNU/Linux developers in 1997.

We note that much of the material that Apple has just released under the APSL originated at The University of California, Berkeley and at Carnegie-Mellon University. That work was sponsored by the U.S. Government, paid for with our taxes, and was already available as Free Software under the BSD license and other well-accepted Open Source licenses. Many of these files do not significantly differ from the pre-Apple versions except that they bear the addition of a new copyright and license. Other files are entirely authored by Apple or bear significant modifications that should indeed be considered Apple's property. Where Apple has not significantly modified individual files from their pre-Apple versions, their original licenses should be preserved without the addition of the APSL.

Section 2.2(c) of the APSL requires that the producer of modifications to APSL-licensed code use a particular URL in the Apple.com domain to notify Apple. While the demise of Apple Computer, Inc. is unlikely in the near future, that sad event would leave us unable to comply with this section of the APSL. This would constitute a restriction on all rights granted by the license, including those rights necessary to qualify under the Open Source Definition. The Free Software community plans a very long lifetime for its software, and we hope that Apple will cooperate by changing this provision so that APSL-licensed software could survive without Apple. We suggest that the simple publication of modifications, such as posting on a personal web site accessible to the global internet and pointed out in any binary distributions, be all that is required. This is consistent with other licenses in our community.

Section 9.1 of the APSL allows Apple to terminate our rights to use any or all APSL-covered code, at its sole discretion, in the event of an unproven claim of infringement, no matter how specious. This is derived from a similar objectionable portion of IBM's Jikes license, which disqualified that license from being referred to as "Open Source". We hope that Apple will consider the investment that members of the Free Software community will put into APSL-licensed code when they write modifications for it. An arbitrary termination could cause us to suddenly lose that investment at some future date, with no chance for appeal. The licenses accepted by our community do not provide the possibility of termination in this manner. If termination due to an infringement claim is to be allowed at all, it should be explicitly limited to the particular source-code lines that are considered to infringe upon an existing patent. This would make it possible for the free software community to "write around the problem" and create a non-infringing version. The authors of the APSL apparently did not consider that patents expire. It should be possible for us to store infringing code for restoral to use upon the expiration of the patent in question. Apple might also consider if it's possible to allow third-parties to defend the disputed code from an infringement claim that would cause us all to lose our rights under the APSL.

We also regret to note that that Eric Raymond, with the best of intentions, jumped a little too fast to embrace the APSL in his enthusiasm to welcome Apple to our community. He placed the Open Source designation on a license that wasn't quite ready for that. We invite Eric and other members of the Free Software community to join us in requesting the few simple changes to the APSL that we have outlined in this letter.

Contact: Bruce Perens <bruce@perens.com> 510-526-1165 (USA) Links to Relevant Information

• The Open Source Definition.
• The Debian Free Software Guidelines, from which the Open Source Definition is derived.
• Is Your Software In Danger of Termination, an open letter on the topic of license termination.
• Debian GNU/Linux and GNU/Hurd Distribution.
• Software in the Public Interest.