Billion dollar companies spend money to buy Red Hat Enterprise Linux licenses, because promising 100% binary compatibility with RHEL isn't as good as being RHEL. If CentOS is even an option, Scientific Linux should be as well.
Would it be too hard to add non TCP traffic tunneling? This already supports DNS traffic through the tunnel but I wonder it is feasible to tunnel all kinds of traffic (UDP and ICMP mostly) through it?
The SSH connection is inherently a reliable stream, so you need to be careful - it should work if you drop UDP packets if the ssh stream's send buffer is full, but there might be severe performance traps down that route. Maybe an expert can elaborate. The other issue is you'd need to do manual NAT-like connection tracking to match up sources and destinations. I could imagine many UDP-based protocols not taking kindly to that sort of treatment.
By the way, (open-)ssh itself supports a tun/tap VPN mode (-w I believe) that creates actual network interfaces on the two endpoints, and thus can transport any IP traffic. It needs to be explicitly enabled on the server, and needs kernel tun/tap support, which is usually missing on VPSes that don't let you run your own kernel (modules).
What Debian released is an stable distribution that is going to be maintained for the next 3 or 4 years. It is better to release something stable and well tested than bleeding edge stuff.
Many people don't get Debian. This is a released aimed for servers and stable workstations. If you want or need bleeding edge stuff you can use Debian testing/unstable or Ubuntu as you suggested.
There also wasn't a lot of time before the freeze--- OpenSSL 1.0.0 was released on March 29, and the Debian "Squeeze" freeze was August 6. Dropping in a new version of OpenSSL four months before the freeze wasn't considered prudent. Even if OpenSSL itself could be tested in that time and considered rock-solid (probably possible), a lot of different packages depend on / link with OpenSSL, and linking them with a new version might expose subtle bugs or incompatibilities in those apps, which you'd want some time to notice/debug/fix, especially since it might require waiting on upstream developers to debug/fix things in their apps.
Post-release, OpenSSL 1.0.0 will now be migrated to unstable, and then any problems that causes or exposes can be found and fixed on a more generous schedule.
I agree. I use Debian not because it has the bleeding edge but because they have the most stable versions and they care about that. I love their system.
The next release of Debian stable will have Python 2.6 as default and it is expected for the first weekend of February, so it is safe to start with Python 2.6 right now.
True. However keep in mind who uses debian stable... people who won't jump on squeeze the moment it gets stable. It will still take months before the situation really changes. But yeah - I agree that 2.6 is pretty much safe for new stuff.
People who use Debian stable also aren't going to use your new library anyway. They're not running stable because they want to install a bunch of recent stuff, after all...
Why wouldn't they? I had to choose which version to target when writing some software lately. The production was debian stable yet I wanted to release the project for others. In the end I have to keep 2 branches - one for 2.X and another for 3.X - it was a trivial piece of code, so it's not a big problem, but I can imagine how silly it must be for bigger projects.
I did a little noodling around and found it's perfectly practical to use even several thousand iterations of a newer hash algorithm (SHA2-256) to produce passwords, rather than a few dozen iterations of an obsolete one. That should address some of the cryptographic concerns. It's also perfectly possible for the script to accept the master password through a JavaScript popup rather than from a text box inserted into the current page. That should address concerns about a "malicious webmaster" type attack.
So some of the most important criticisms of SuperGenPass (which is undeniably very slick and pleasant to use) are at least addressable.
SuperGenPass is good if all you care about are website passwords. I also need to save passwords for FTP/SSH/Internal Business Apps. SuperGenPass won't be helpful and I would definitely prefer to use one solution for all my password needs.
