OpenSSH 4.2 released 183
BSDForums writes "OpenSSH 4.2 has been released. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support.
Changes since OpenSSH 4.1 include security bug fixes relating to GatewayPorts, and GSSAPI, which eliminates the risk of credentials being inadvertently exposed to an untrusted user/host. A new compression method, proactive changes for signed vs. unsigned integer bugs, and many additional bugfixes and improvements highlight this release."
The new compression method is pretty fantastic. (Score:4, Informative)
Re:The new compression method is pretty fantastic. (Score:5, Insightful)
Speaking of X11-related improvements... (Score:5, Informative)
- Implemented support for X11 and agent forwarding over multiplexed connections. Because of protocol limitations, the slave connections inherit the master's DISPLAY and SSH_AUTH_SOCK rather than distinctly forwarding their own.
This bugfix may very well affect the performance of OpenSSH when used to encrypt communications with a remote X11 server.
Re:Speaking of X11-related improvements... (Score:3)
Just use NX (Score:3, Informative)
Re:Just use NX (Score:2)
But it does look like its got promise. I tried the demo once, and was impressed.
Re:The new compression method is pretty fantastic. (Score:3, Informative)
Re:The new compression method is pretty fantastic. (Score:2)
Re:The new compression method is pretty fantastic. (Score:2)
VNC works with 128K to get a desktop, but id rather use native X11. ( seemless windows, cut/paste to the local machine, etc etc )
Re:The new compression method is pretty fantastic. (Score:2)
But, its a bit overkill and isnt as seemless as id like it.
But they didn't add new compression (Score:5, Informative)
" Added a new compression method that delays the start of zlib compression until the user has been authenticated successfully. The new method ("Compression delayed") is on by default in the server. This eliminates the risk of any zlib vulnerability leading to a compromise of the server from unauthenticated users." (emphasis mine)
OpenSSH used zlib before, and they're still using it now. All they've done is delay the start of compressed streams until after authentication. This is a security fix, not a speed boost.
Re:The new compression method is pretty fantastic. (Score:2)
You can login into your providers ssh server (if they have that) and forward/compress the port of your favourite usenet server. That way I had a 300kb/sec speed boost - I got more data than my adsl account normally could handle. Maybe with this compression boost there's even room for more bandwidth on my 8mbit account.
I'll bet my provider's going to be even more happy with me again.
Re:The new compression method is pretty fantastic. (Score:4, Informative)
This way we avoid pre-auth exposure to zlib bugs.
Compression algorithms do matter. (Score:3, Interesting)
It's factors like that which make OpenSSL, especially OpenSSL 4.2, very appealing to network administrators who must take into account bandwidth cos
Increased default key size. (Score:5, Interesting)
"- Increase the default size of new RSA/DSA keys generated by ssh-keygen from 1024 to 2048 bits."
It's good to see that the default size of the keys had been increased. It's only a matter of time before modern systems (or clusters of modern systems) are capable of defeating even 1024 bit keys routinely. This proactive doubling of the default keysize is sure to increase the overall security for OpenSSH users for some time.
Re:Increased default key size. (Score:1, Interesting)
Re:Increased default key size. (Score:2)
Re:Increased default key size. (Score:2)
What is considered "large" today will be amongst the smallest problems in the near future. That is just how fast technology progresses.
Re:Increased default key size. (Score:5, Insightful)
Cracking it on the first attempt and cracking it on the 10^50th attempt have equal probabilities.
True, but both probabilities are minute. The median of that range is 5*10^49 meaning that's the average number of tries you need. If you got lucky and found it in the first 10%, that's 10^49. If someone wanting to spy on you can muster the resources to crack that in a human lifetime, you've made an enemy of God!
Quantum computing opens up some interesting possibilities, but if a hypothetical Quantum computer in the year 2015 could search 1x10^23 keys per second (more than that massive distributed Internet project a while ago), it would still take millions of years on average.
10^50 is a big number.
Re:Increased default key size. (Score:5, Informative)
Moving to 2048 bits is the kind of "Even if you take the power of the sun and the whole galaxy too, and run it on hyperefficient nanowatt CPUs that can do one key/clock cycle, you're still going to run out of energy" move. Unless you happen to know a better algorithm than brute force, in which case 2048 bits may be just as screwed as 1024 bits...
Kjella
Mod this nonsense down, its all wrong. (Score:5, Informative)
Everyone knows a better algorithm than brute force: General Number Field Sieve, Number Field Sieve, Quadratic Sieve, and its likely new methods will be found. You don't brute force assymetric keys, brute forcing 1024 bit keys asymmetric keys would take just as long as brute forcing 1024 bit symmetric keys, that is to say it is not possible. Brute force means simply trying every possibility, the algorithm doesn't matter in that case. Trying 2^1024 possibilities is trying 2^1024 possibilities, regardless of how the key was generated or what its used for.
And finally, 1024 bit keys could certainly be broken without all the power of the sun, you are talking out of your ass, plain and simple. In fact, Bruce Schneier always says its likely that a billion dollars would be enough to put together the hardware required to break a 1024 bit key.
Re:Increased default key size. (Score:3, Insightful)
Re:Increased default key size. (Score:2)
The generation of server keys will take _much_ longer time on some architectures, and this was actually one of the arguments of not increasing the key length ea
Re:Increased default key size. (Score:2)
Longer passwords on UnixWare? (Score:4, Interesting)
- Portable OpenSSH: Added support for long passwords (> 8-char) on UnixWare 7.
I'm surprised that it has taken them this long to add support for long passwords to UnixWare 7. UnixWare 7 is a modern UNIX by all means, considering it is still being updated frequently. Can anybody shed some light as to why it took so long for this fairly rudimentary support to be added to the portable version of OpenSSH?
Re:Longer passwords on UnixWare? (Score:2)
Lets all support SCO! :) (Score:2)
Re:Longer passwords on UnixWare? (Score:4, Informative)
Re:Longer passwords on UnixWare? (Score:2)
Please excuse my obvious ass-kissing (Score:2)
Re:Please excuse my obvious ass-kissing (Score:5, Informative)
Host alias1
Hostname hostname
User username
[add extra options like authentication method, X11 forwarding, agent forwarding, private key to use and so on]
then you do scp file.tar.bz2 alias1/path or fish://alias1/some/path (and get a password prompt). Less typing - and works with bash completion too.
Re:Please excuse my obvious ass-kissing (Score:5, Insightful)
The fact is that in OSS world one should, atleast once a month raise fingers from the keyboard and stop to think "What am I missing from my daily environment? Are stupid, repetetive or borings things that I do all too frequently?". The odds are that I could easily fix most of them swiftly and the ones that might require moderate amounts of work to happen it's quite likely that someone hast stumbled on those very same issues before me and fixed them. (and experience in *nix world teaches me that frequently the fix is quite brilliant)
Re:Please excuse my obvious ass-kissing (Score:2)
Re:Please excuse my obvious ass-kissing (Score:2)
some cruddy examples of how to use it:
"cat filelist.txt |xargs -i ls -l {}"
"ls | xargs -i mv {} {}.bak"
It's a great workaround to the "file list too long" problem some tools exhibit. It saves my arse every month or so.
Cheers
Stor
Re:Please excuse my obvious ass-kissing (Score:2)
xargs has easily some problems with spaces.
True, but xargs also has "-0", which solves the problem quite nicely in the most common usage -- coupled with find. The "-print0" option causes find to output the results with null characters separating them, rather than newlines, and "-0" causes xargs to expect the input to be null-delimited.
for x in * ; do mv "$x" "$x".bak ; done
That can break down when there are too many files in the current directory because the command line becomes too long for the sh
Re:Please excuse my obvious ass-kissing (Score:2, Interesting)
It's not even hard to find a client. Modern Linux and BSD systems mostly have it, and if you're using Windows, you can download PuTTY and use it without even having to install it and make a mess. Great if you're a guest on somebody else's system.
I use ssh, sftp, scp, and vnc over ssh dail
Hey you insensitive clod! (Score:2)
Hey the SSH server and client can work on Windows too! Install Cygwin to find out. I've been using Cygwin/SSH for about 6 months now and I love it. SSH into the machine, remote (secure) VNC, scp/sftp it's all there and was pretty simple to setup.
I love Cygwin more, because it gives me SSH, but without each other I wouldn't use either.
From Bill Gates... (Score:3, Funny)
Keep up the good work guys.
It's our pleasure, Mr. Gates. (Score:3, Insightful)
Re:It's our pleasure, Mr. Gates. (Score:5, Insightful)
Re:It's our pleasure, Mr. Gates. (Score:2)
Except that BSD liscensing allows compaines like Microsoft the pervert a standard protocol, so that it is no longer interoperable, nor "ubiquitous"
There is nothing the prevents Microsoft from distributing a GPL'ed product except their own internal
Re:It's our pleasure, Mr. Gates. (Score:2)
I was aware of that argument before, but putting it in bold convinced me.
"The biggest difference is, of course, that they would have to publish any changes. To me, it seems obvious the you should WANT them publish any changes to SSH."
That's why these arguments never go anywhere. You don't just think I have different priorities, you
Re:It's our pleasure, Mr. Gates. (Score:2)
GPL allows all of the above
Whether or not you agree, and whether or not they are right, some of the companies out there want the freedom to customize code without releasing the changes.
And I want a Ferrari... doesn't mean you have to give it to me, especially for free.
Microsoft's breaking of Kerberos is just a minimal example of what can go wrong here.
It's not
Re:It's our pleasure, Mr. Gates. (Score:2)
Not necessarily. For example, they might recieve bug reports under NDA (not hard to imagine for security issues), and a source patch would violate that. They might also wish to license commercial code. Even if they don't want to do that, it makes people nervous when they have to rule out the ability to do that from the get-go.
"And I want a Ferrari... doesn't mean you have to give it to me, especially for free."
That doesn't make any sense. The maintainers give it away under th
Re:It's our pleasure, Mr. Gates. (Score:2)
Re:It's our pleasure, Mr. Gates. (Score:2)
Still no logging of sftp/scp transfers? (Score:2, Insightful)
Re:Still no logging of sftp/scp transfers? (Score:2)
Re:Still no logging of sftp/scp transfers? (Score:5, Informative)
http://sftplogging.sourceforge.net/ [sourceforge.net]
Don't know if i works against OpenSSH 4.2.
But it probably will soon.
Re:Still no logging of sftp/scp transfers? (Score:3, Insightful)
Slowing down dictionary attacks (Score:5, Informative)
1. Run sshd on a different port. The scripts won't find you there. I don't like this option, because it requires me to specify the alternative port every time i ssh, scp, rsync, or svn. It's still about the easiest and most effective method.
2. Limit the connection rate to the port you're running sshd on. In many scenarios, it won't hurt you if you can't connect to it more than once in 5 seconds, but this will make a dictionary attack from a single machine very tedious. In OpenBSD 3.7, you can use pf with max-src-conn-rate.
3. Use a script like DenyHosts [sourceforge.net] to monitor your authentication log, and add suspicious hosts to a block list (either temporarily or permanently). This looks like a very nice solution to me.
4. I got this one from my girlfriend: disable password authentication and use key-based authentication instead. This is my prefered solution, except that I have to solve some problems with public key authentication not working from some of the machines I use.
I hope this post is helpful to some of you. If you have any other methods that you would like to mention, I'd be glad to hear.
Re:Slowing down dictionary attacks (Score:2)
Your girlfriend rocks. I always disable password authentication on a new server before I enable sshd for the first time. I'm pretty certain I could safely give my root password out on IRC without much risk, although prudence says I'm not completely int
Re:Slowing down dictionary attacks (Score:3, Informative)
Yes, totally. I feel the luckiest guy in the world for having a girlfriend who's a hacker, too.
``What sort of problems do you have with public key authentication?''
From some machines, it just doesn't seem to use it. If I run ssh with -vv, it gives some messages about "we did not send a packet", then tries password auth instead. I don't have access to such a machine at the moment, otherwise I would be more specific.
Re:Slowing down dictionary attacks (Score:2)
Or even a more realistic scenario, sometimes you just want someone else to be able to log into your machine, be it a friend helping you or even an admin at a datacenter that doesnt want to have to dig out a keyboard+monitor t
Re:I get a truckload of dictionary attacks (Score:2, Interesting)
Box #1:
grep "authentication failure"
/var/log/messages|wc -l
1362
Box #2:
grep "authentication failure"
1520
Thank you very much for more great SSH tips, I hope you do not mind I recycled them at http://en.linuxreviews.org/Ssh [linuxreviews.org] (it is a wiki, so I can easily remove your work if you mind, or you can do it..)
Re:I get a truckload of dictionary attacks (Score:2)
I most certainly don't mind, otherwise I wouldn't have posted them here. You might want to change the wording, though. It sounds a bit strange the way it stands. If you do that, could you also change the link to my site to read "inglorion" instead of "Bob"; I prefer to use my handle rather than my name when it's not about personal communication.
Anyway, thanks for putting it there!
DenyHosts alternative. (Score:2)
Didn't know about DenyHosts, wrote something similar in sshd_failed_ips.pl [gazonk.org]. I didn't want a deamon or cron job when it's completely unnecessary, though me script does depend on TCP wrappers (any dist. not running that by default?)
Re:Slowing down dictionary attacks (Score:5, Informative)
iptables -A INPUT -j ACCEPT -p tcp ! --syn -s 0/0 -d (outer ip/net)
(you probably have this on your firewall already, allowing previously established connections)
iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --update --seconds 15 -j DROP
iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --set -j ACCEPT
These two will only allow new connections from the same IP with 15s intervals between them. Add them to your iptables setup scripts (or replace them where you ACCEPT ssh, if that's the case).
BR,
Joao S Veiga
Re:Slowing down dictionary attacks (Score:4, Informative)
I personally use the following to limit the number of connection attempts on my SSH server. The limit is set for only 3-connections in a minute, the first 2 exhaust the limit-burst, which then takes a minute to refill, effectively limiting the connection attempt rate to 1/minute.
iptables -A INPUT -p tcp --dport ssh -m limit --limit 3/minute --limit-burst 2 -j ACCEPT
Re:Slowing down dictionary attacks (Score:2, Informative)
If you want replies for previously accepted requests, do NOT use ! --syn
Instead you should use the state table (which is what iptables was designed for).
iptables -A INPUT -j ACCEPT -s 0/0 -d (outer ip/net) -m state --state ESTABLISHED,RELATED
This is light years more efficient and secure. Also check out the iptstate [phildev.net] package so you can actually see what is in the magic state table.
Re:Slowing down dictionary attacks (Score:4, Informative)
By accepting only non-syn packets, you are opening yourself up to "ACK" attacks and old-school router-penetrating scans. Also, things like 'ippacket' can forge packets by setting arbitrary bits. If the 'ack' flag is set (or in the case of your rule, anything including RST, PSH, URG, and even the two reserved bits), then the packet will zing right through your rule.
In this instance, the packet will pass thru the firewall, on to the destination host, which will then reply accordingly:
* If the port is not open, it will reply with ICMP Port Unreach (Type 3, Code 3) signifying a host is alive.
* If the port is open and these flags don't make sense to the host (invalid ACK window, or a FIN/ACK received without a FIN, or an ACK without a SYN, etc) then the host will reply with RST for that port. Implying the host is alive and that port is open.
These responses will only lead to further probes, etc.
For those who preach NAT until the cows come home, this will still happen because your firewall is still gonna un-NAT it and send it onward.
NAT will offer no protection in this situation. (and please do remember that the entire intar-web-net doesn't run on NAT. NAT is not a magical security tool and offers very little advantage with a magnatude of disadvantages, especially for high-load servers)
The state table checks, first, to see if the packet parameters match what has already transpired, session-wise. You can adjust the state timeouts to decrease or increase the time a session will remain 'open'. Now if the sessions are closed, it's removed from the state table period. No reply attacks, etc. The classic "Mitnick" attack will be avoided, too.
The state has expectations of how the packets flowing through should be handled. If you put the "-m state" checks very early in your ruleset, watch it with "watch iptables -L INPUT -nv" and then watch with 'iptstate' in another window. You'll see the first packet of a session (the initial SYN) will go thru the ruleset and be placed in the state table (upon being accepted of course)
EVERY packet from now until the final FIN/FIN-ACK will be matched against the state table in memory. The rule you are watching will only have ONE hit (for that session) even if you're transferring billions of bytes. The remainder is checked against the state table. It's very very cool and very very efficient and quite fast.
Anyhoo.. just wanted to clarify *why* you shouldn't use the ! --syn parameter.
Re:Slowing down dictionary attacks (Score:2)
That "established connections" rule came with scripts I've downloaded about 8 years ago (ipchains?), and I never gave it a second thought...
Out goes the ! --syn...
Re:Slowing down dictionary attacks (Score:2)
Re:Slowing down dictionary attacks (Score:3, Informative)
No need to specify the port every time on the comand line. Edit one of /etc/ssh_config, /etc/ssh/ssh_config or ~/.ssh/config, and add the configuration:
Host *
Port new_port
That changes the default for every host, so you'll probably decide to define only for your ho
Simple hack: sleep(10) (Score:4, Interesting)
int
auth_password(Authctxt *authctxt, const char *password)
{
struct passwd * pw = authctxt->pw;
int result, ok = authctxt->valid;
#if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE)
static int expire_checked = 0;
#endif
sleep(10);
That slows all password authentication attempts down enormously.
make
make install
service sshd restart
La Voila!
Re:Slowing down dictionary attacks (Score:2)
That's one thing I do. Get it working and Just Do It(tm). It will let you sleep better at night.
You may need to learn about ssh-agent. *sigh* ssh-agent rocks but it's another one of those things that's really easy to use once you know what's going on but before then you could be banging your head against it. The commands you need:
ssh-add
ssh -A
I always chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys2. Make sure you have that right
Re:Slowing down dictionary attacks (Score:5, Insightful)
This exponential backoff system works when you're trying to log in from a tty. When SSH, the system doesn't know whether this is the same user trying to authenticate. It's similar to sitting in front of a Linux box, trying to log in on VT 1, and when it backs off, switch to VT 2, and so on.
The situation could be improved somewhat by sshd tracking failed logins by IP address, and disallowing that IP address from logging in for a while. However, this complicates sshd and isn't really bullet proof, what with NAT making any number of machines appear to have the same IP address.
-d option for scp? (Score:2)
As a workaround you can wrap all the remote files in a temporary tar file to protect any sym.links etc, then scp the tar file and untar the tar file after the transfer but it would be much quicker and simpler if you could use scp to do this.
Re:-d option for scp? (Score:5, Informative)
I don't know your exact needs, but you can make this easy on yourself with a very short shell script, or even just an alias. Instead of using "scp", use "ssh" directly, something like: This runs "tar" on the remote server, $* is trying to convey the idea of passing all the params of the script/alias to the remote tar, and outputs to stdout. ssh redirects stdout across the network to its own stdout, which is then piped to local tar for extraction. -C compresses the stream, which is probably Good Enough, but under certain circumstances (CPU time vastly outweighs transfer time, think modem transfer here) it can be worthwhile to add bzip2 into the mix: Tune the script to your needs, and the reverse script is pretty easy too; ssh will redirect its stdin across the network just as easily if you use it in a pipe.
Note there is never a temporary file.
I belabor how this works because it took me a while to fully grasp how cool it is that ssh makes the Unix pipe idea fully work across the network. Note you can set up pipes on the remote side in the ssh command if you escape it correctly (apostrophes will usually do, but shell escaping can get evil). scp is more "convenience script" than "fundamental tool".
Re:-d option for scp? (Score:2)
The current workarounds for not having a -d option in scp tend to be problematic in various ways. For example, using tar becomes quite tedious when you want to copy only files in a particular directory, without recursively copying any su
rsync is your friend (Score:3, Informative)
Then add '-H' to preserve hard links. (Why isn't -H part of -a? Oh well.)
Re:rsync is your friend (Score:2)
FYI (from the rsync man page):
GSSAPI (Score:5, Informative)
It's also been on my "I really must implement that" list for waaaay too long. I find that more basic TLS-and-client-cert schemes do the job well enough most of the time.
Re:GSSAPI (Score:3, Interesting)
I finally got around to setting up a KDC for my domains. It's nice to run "kinit" once, and then have full access to every machine I'm supposed to have full access to. Implementing Kerberos for one service is massive overkill. Implementing it for IMAP, SMTP, LDAP, etc. at the same time is bliss.
The FreeBSD Handbook has a nice chapter [freebsd.org] on the subject. O'Reilly's "Kerberos: The Definitive Guide" is an excellent reference as we
Re:GSSAPI (Score:2)
Kerberos is not secure / much less secure than PKI (Score:2)
No modern authentication system should store secrets on the server, This is the reason we have PKI - we store the certificates on the server, and e
Proactive? (Score:2, Informative)
Re:Proactive? (Score:2)
Re:Proactive? (Score:2)
There are various levels of paranoia you can aim for when performing a code sweep, depending on your gcc compiler options (-Wall -Wsign-compare -Wshadow). So we tend to do it in stages so that we can look at chunks of code rather than huge unparsable diffs that will let bugs sneak through (there were a number of integer warnings slowly fixed in earlier releases, but Damien went through and cleaned up all the remaining ones for this release).
T
Upgrade? (Score:2)
Re:Upgrade? (Score:2)
HPN-SSH, faster network performance (Score:2, Informative)
there is a patch called HPN-SSH that addresses some issues in ssh that users encounter if they have access to faster networks. SSH has some static flow control buffer values that limit network performance. The work at PSC by Chris Rapier and Michael Stevens is really nice, is proven to work and is gaining (some) broader acceptance.
take it for a test run and if you like it, please encourage the OpenSSH folks to add it into the main trunk.
Coolest new feature: automatic multiplexing (Score:2)
- Added ControlMaster=auto/autoask options to support opportunistic
multiplexing (see the ssh_config(5) manpage for details).
'Multiplexing' means running more than one session across the same ssh connection. So if you use CVS over ssh, or rsync over ssh or even just lots of remote commands, you don't have to start up a new connection for each one. The first ssh connection stays
Re:Why you shouldn't use OpenSSH (Score:5, Insightful)
Frankly, I'd rather put up with arrogance and have access to amazing code, rather than dealing with a nice person who can't write code worthy of a cockfool.
Re:Why you shouldn't use OpenSSH (Score:2, Offtopic)
Re:Why you shouldn't use OpenSSH (Score:2)
Fortunately, decency and skill/talent are not mutually exclusive, and there are plenty of examples of that, so it's not too much to ask even of brilliant people that they also comport as decent human beings.
Re:Why you shouldn't use OpenSSH (Score:1, Flamebait)
He annoys people.
Re:Why you shouldn't use OpenSSH (Score:3, Insightful)
They can take the freedom to be different and we have to understand that we have to adopt to them.
Re:Why you shouldn't use OpenSSH (Score:2)
The OpenBSD community does tend to be a bit arrogant, but that's what you get from developing an OS which considers free-as-in
Re:Why you shouldn't use OpenSSH (Score:3, Insightful)
Re:Why you shouldn't use OpenSSH (Score:4, Insightful)
Like him or not, but it's a great program, and not using it just because you don't like the lead developer, when there are no actual reasons not to, is stupid.
Which idiot makes this insightfull? (Score:5, Insightful)
Are you mod fucking insane?
Re:Which idiot makes this insightfull? (Score:2)
Are you mod fucking insane?
That'd be a nice modding option, actually: "-1, Fucking insane".
Oh, and I absolutely agree with you!
zRe:Why you shouldn't use OpenSSH (Score:3, Insightful)
As a friend of mine says, "It's OK if they call you an asshole, if they say it with awe."
Theo is certainly opinionated, and he may or may not be an asshole, but his group produces some damn fine software. You may not like his methods, but it's difficult to argue with his results.
Re:Why you shouldn't use OpenSSH (Score:4, Insightful)
He gets results. For example, giving out contact information isn't the nicest way to get hardware docs and firmware, but it works.
Re:Why you shouldn't use OpenSSH (Score:2)
He gets results. For example, giving out contact information isn't the nicest way to get hardware docs and firmware, but it works.
de Raadt only releases contact information when everything else has failed for several months. The latest incident with Adaptec is an example of this.
Re:Why you shouldn't use OpenSSH (Score:5, Interesting)
That said, Theo is outspoken, loud, somewhat obnoxious and sometimes very hard to deal with. None of that affects the quality of his work. It certainly affects the quality of interaction you might have with Theo, or the perception you might have around his projects.
I certainly would not conduct my personal affairs with the same aplomb as Theo, nor would I piss in my own Corn Flakes quite like Theo can. This aside, Theo is an intelligent, smart individual and those who choose to draw from him that which is valuable will recognize that his different viewpoints, although sometimes objectionable, are just that : different viewpoints.
Sometimes, in the realm of the übergeek, it is difficult to remember that the goal is to produce the best software possible for the consuption and use of others.
I would never, (I repeat: NEVER), conduct my social affairs in the same fashion as Theo, however, I would be a happy man to be able to hang my hat on the solid line of quality software that he and his cadre of loosely joined pieces have brought us all.
I have partied with de Raadt, I have climbed, caved and even swooned over the same ladies. None of this matters. In the end, love Theo or hate him, he has contributed much to the OSS world and much to the security realm.
I may not choose to give him a grant allocation or hire him for my firm, however, Theo is Theo and at least he holds a consistent standard for himself and those who contribute to the projects he administrates. For this we can all be thankful. Interity is an essential element of honor; if you do not agree with how Theo condicts his affaris; so be it, but I think Theo makes the effort to conduct his own affairs within his own code of honor. Even if this code is incompatible with my own (and it appears to be) I have to respect that.
Re:Why you shouldn't use OpenSSH (Score:2)
Re:Did that say signed vs. unsigned integer bugs? (Score:2)
Here [phrack.org] is a phrack article on the topic.
Personally, I think the OpenBSD folks are doing things the hard way, by using an insecure language as the foundation of their work. That's the problem with C - you have to remember everything you learned over years of programming, all the time, or you risk making a mistake that can not only cause crashes, but ultimately compromise your entire machine, if not your en
Re:Did that say signed vs. unsigned integer bugs? (Score:2)