Of course, the parent poster wasn't just complaining that Linux exposes this information as files rather than via sysctl. The real problem is that the format of the information changes frequently, and varies between platforms./proc/cpuinfo, for example, varies widely between x86, ppc and sparc.
It's exactly this sort of inattention to detail that makes me not enjoy developing on Linux.
Browsers include SSL natively, but there's no spec for just signing something and sending it plaintext. There are SSL ciphersuites that don't encrypt data, but do send an mic or hmac. For example, TLS_RSA_WITH_NULL_MD5 and TLS_RSA_WITH_NULL_SHA.
"Huh? I know TLS theoretically supports other key transfer mechanisms than diffie-hellman, but the last time I checked there wasn't anything else actually implemented...."
Check the IANA registry of TLS ciphersuites(http://www.iana.org/assignments/tls-p arameters). Those without "EDH" in their names aren't performing ephemeral diffie-hellman key negotiation.
"Care to point to a section in the spec where it says you can skip secure key exchange, or post some code, or a trace of a real live browser doing this?"
The SSL and TLS specs allow multiple ways of deriving the master_secret, which is used to derive the symmetric keys. Quoting from RFC 4346 (http://www.ietf.org/rfc/rfc4346.txt), section 8:
8.1.1. RSA
When RSA is used for server authentication and key exchange, a 48-
byte pre_master_secret is generated by the client, encrypted under
the server's public key, and sent to the server. The server uses its
private key to decrypt the pre_master_secret. Both parties then
convert the pre_master_secret into the master_secret, as specified
above.
RSA digital signatures are performed using PKCS #1 [PKCS1] block type
1. RSA public key encryption is performed using PKCS #1 block type 2.
8.1.2. Diffie-Hellman
A conventional Diffie-Hellman computation is performed. The
negotiated key (Z) is used as the pre_master_secret, and is converted
into the master_secret, as specified above. Leading bytes of Z that
contain all zero bits are stripped before it is used as the
pre_master_secret.
If RSA keying is used, then there is no perfect forward secrecy. In English, that means that if an attacker can capture the TLS handshake and if the attacker can compromise the server's private key, then the attacker can decode any data from that session. If ephemeral Diffie-Hellman keying is used, this attack is not feasible, since the server's RSA keypair wasn't used to secure the key exchange (it would only have been used to authenticate the server's identity).
Also note that the client doesn't generate an asymmetric key pair (as you claimed), and that the key negotiation algorithm is independent of protection against replay attacks.
that depends on what SSL ciphersuite your browser negotiated. Some SSL ciphersuite support DHE keying. For others, the client generates a random key, encrypts it with the server's public key, and sends it to the server.
One important reason *to* upgrade to Vista is its improved Kerberos support - it will finally support AES Kerberos tickets. Not only is this more secure than Microsoft's current RC4-based tickets, but it should make interoperability with other platforms much easier.
Could you provide any citation indicating that the Kerberos developers claim that PKI is more secure than Kerberos? Just one would suffice.
As for PKI, you've failed to provide a single example of a common PKI that handles revocation or manages private keys usefully. Certainly SSL, the most widely depolyed example of PKI, is basically encryption for show, since I don't know of any browser that checks for revocation (and some of them even allow expired certs by default), and they ship with so many CAs trusted that you can't be sure of who you're talking to.
As for KDC host-based security, the same argument can be made against a CA. If a CA's private key is compromised, you're screwed. And since most CAs issue certs for multiple security domains, the potential damage is far greater than a KDC compromise.
It boils down to this. If someone cracks my Kerberos password, I can contact my sysadmin and have him change my password. If someone breaks into my system and steals my credential cache, there is a very narrow window of damage. Most KDCs issue tickets good for 8-10 hours, and renewable up to a week at most. On the other hand, most certificates are good for 1-2 years. And mos PKI systems don't bother with revocation, since no one's figured out how to make it scale. So if someone steals my private key, I'm pretty much screwed.
How can you claim that Kerberos is "fairly poor security wise" ? I would argue that it's vastly *more* secure than PKI. You don't need to send your password over the network to authenticate, and it's actually possible to lock user accounts (unlike PKI, where you'd need a working revocation system to do that). And Kerberos doesn't store copies of the users' passwords on the server - it stores hashes of them (specifically, the output of the string-to-key function for each enctype you have enabled).
As for OpenSSH's support for Kerberos, I'm less than impressed. It was an uphill battle several years ago to get it to support gssapi-with-mic, so that it could handle user authentication with a Kerberos ticket, rather than tunneling a username/password pair to it. And it still doesn't support the new gssapi-keyex host authentication mechanism (so that you don't need a known_hosts file and ssh server keys at all).
That wasn't my point. The parent post said that Java wasn't available for many platforms. I've pretty much shown that that isn't the case.
If you want to run Java on the BSDs, I believe its possible to run the Linux/x86 version in compatibility mode. Granted, this sucks, but it's something. You might want to look at GNU Classpath, GCJ or Jikes. Between the three of them, you have (most of) the components you'd need for a free JVM + Java standard library.
I'm a big fan of Python. I used it almost exclusively before taking my current job. But let's be honest, Python and Java just aren't intended for the same type of applications.
Python's standard library just doesn't have the breadth of Java's. For small apps, the CPython VM is lighter than Sun's JVM, but CPython's VM is lacking several capabilities that I'd consider pretty essential -- chief among them is the ability to return unused memory back to the OS. And for many tasks, CPython is still effectively single-threaded due to its global interpreter lock. Java has never suffered from either of these problems. These aren't trivial issues or the result of nitpicking -- they're rather severe limits (which make me seriously question the suitably of Python for enterprise apps, eg. Zope). Of course, once CPython does get decent threading, it's likely that it's GC subsystem will need to be totally rewritten. I apologize if it sounds like I'm beating up on Python. That's not my intent here. I love Python, and I only wish I could stop more people from using Perl:)
In fairness, it does look like the Python community is trying to address some of these problems. I just read a paper presented last week at PyCon 2005 on CPython's memory management. The author is developing some patches to let CPython return unused memory to the OS for most object types (except for Number, List and Dictionary). The memory manager still can't defragment its heap, so this isn't a perfect solution. As of a few weeks ago it looks like these patches haven't yet been accepted.
How is the autovacuum daemon a kludge? It scans the internal state of tables and vacuums when necessary. And with the cache manager (ARC) and I/O throttling (bgwriter) work in PostgreSQL 8.0, vacuum doesn't impose nearly the overhead that it used to. What's the problem?
You're telling me that MySQL locks the entire table when I insert a row? You must be joking - that would bring a database to it's knees.
MySQL can use different "storage engines" for different tables. One of their older (and arguably, more widely deployed) engines in MyISAM, which does table-level locking (their newer engine, InnoDB, does row-level locking). From the MySQL Manual (sec 7.3.1):
Currently, MySQL supports table-level locking for ISAM, MyISAM, and MEMORY (HEAP) tables, page-level locking for BDB tables, and row-level locking for InnoDB tables.
In MySQL (with MyISAM tables), the reason things like count(*) are fast is that MyISAM pre-computes those values. It can do this because it locks the table on insert and update. PostgreSQL doesn't lock the table on modifications -- it allows concurrent access via Multi-Version Concurrency Control (MVCC). Basically, each row in the DB has additional information (used internally by PostgreSQL), which stores which transaction created and last modified the row. PG uses this to determine if any given row should be "visible" to the current transaction. Because this informaiton is constantly changing (and varies from transaction to transaction), you can't precompute things like count(*) and sum(*). See http://developer.postgresql.org/pdf/internalpics.p df for more info (start around page 56).
Just remember that almost no open-source databases use parallelized algorithms. PostgreSQL, Firebird and MySQL certainly don't. OpenIngres is the only one I know of with a parallel query engine. By this I mean the ability of a single query to use multiple processors (say, for handling a complex join and a large sort). The only way PG, FB and MySQL can use multiple CPUs is if you have multiple queries running. But for OLAP-style workloads, you won't see much benefit from SMP.
This is because MySQL silently creates default values for every column. It uses "" for VARCHAR columns and 0 for numeric columns. So when you try to insert a string into an integer column, it's using the default value. Why its creators decided to implement this "feature" escapes me.
Well, many of these NSS features are already implemented in ZFS. For instance, ZFS has a compression scheme called LZJB; it's the same algorithm used to compress Solaris crash dumps. It doesn't need journaling, since it uses copy-on-write. And I can't imagine that Sun would release a new filesystem that doesn't support quotas and ACLs (UFS has supported ACLs for years; and I imagine Sun's customers would demand the same feature on ZFS).
Yes, there are things that NSS (and the IBM ZFS) do that Sun's ZFS doesn't, but it certainly looks like an interesting, useful filesystem.
Well, in a modular kernel, you can avoid loading those modules you don't need....
Further, you've provided absolutely no evidence supporting your claim that the Linux kernel is "leaner" than the Solaris and WinNT kernels. You only linked to a feature list for an entire operating system, which has nothing to do with the size of a kernel (and even if Solaris' kernel is bigger than Linux, what does that have to do with the suitability of Linux or Solaris to any given task?).
But let's look at this feature list you've offered up as proof:
Predictive Self-Healing is mostly in user-space. It's a framework in which various daemons report error codes to a user-space daemon, which diagnoses the problem and takes appropriate action (restarting services, increasing filesystem size, taking hardware offline, etc). There's likely little new kernel code here.
N1 Grid Containers does require new kernel code. But so does User Mode Linux, which accomplishes a similar goal. Conviently, you neglect to mention that.
DTrace is kernel space, but it's implemented in a modular fashion - the various DTrace probe providers don't have to be loaded. And since the probe points are dynamically generated, there's little bloat.
Dynamic File System (ZFS) is a new filesystem driver. Solaris already has a lot of these. So does Linux. In fact, Linux has more (how's that for bloat).
Process Rights Management is a new permission system. This will add some kernel code, but not reams. This really is just integration of existing Trusted Solaris code.
IP Filter - Sun removed SunScreen and replaced it with IPF. Big woo.
First of all, you don't see open-source developers decompiling closed-source software to try to improve their own code, so your claims are pretty fanciful. And even if they did, the copyright holders could sue the developers and force the offending code to be removed.
AFAICT the main difference is that Solaris has earned itself the reputation for slowness by insisting to write everything to disk before saying ready
Except that UFS logging ("journalling") has been available since Solaris 7. It wasn't turned on by default, but a simple edit of/etc/vfstab is all that's needed.
As for the rest of your claims, every piece of closed-source software I've seen specifically prohibits decompilation/disassembly.
Slashdot Mirror
Of course, the parent poster wasn't just complaining that Linux exposes this information as files rather than via sysctl. The real problem is that the format of the information changes frequently, and varies between platforms. /proc/cpuinfo, for example, varies widely between x86, ppc and sparc.
It's exactly this sort of inattention to detail that makes me not enjoy developing on Linux.
Check the IANA registry of TLS ciphersuites(http://www.iana.org/assignments/tls-p arameters). Those without "EDH" in their names aren't performing ephemeral diffie-hellman key negotiation.
"Care to point to a section in the spec where it says you can skip secure key exchange, or post some code, or a trace of a real live browser doing this?"The SSL and TLS specs allow multiple ways of deriving the master_secret, which is used to derive the symmetric keys. Quoting from RFC 4346 (http://www.ietf.org/rfc/rfc4346.txt), section 8:
8.1.1. RSA When RSA is used for server authentication and key exchange, a 48- byte pre_master_secret is generated by the client, encrypted under the server's public key, and sent to the server. The server uses its private key to decrypt the pre_master_secret. Both parties then convert the pre_master_secret into the master_secret, as specified above. RSA digital signatures are performed using PKCS #1 [PKCS1] block type 1. RSA public key encryption is performed using PKCS #1 block type 2. 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. Leading bytes of Z that contain all zero bits are stripped before it is used as the pre_master_secret.
If RSA keying is used, then there is no perfect forward secrecy. In English, that means that if an attacker can capture the TLS handshake and if the attacker can compromise the server's private key, then the attacker can decode any data from that session. If ephemeral Diffie-Hellman keying is used, this attack is not feasible, since the server's RSA keypair wasn't used to secure the key exchange (it would only have been used to authenticate the server's identity).
Also note that the client doesn't generate an asymmetric key pair (as you claimed), and that the key negotiation algorithm is independent of protection against replay attacks.
that depends on what SSL ciphersuite your browser negotiated. Some SSL ciphersuite support DHE keying. For others, the client generates a random key, encrypts it with the server's public key, and sends it to the server.
If you are using ZFS in a mirror or raidz configuration, then the checksums do let the fs detect and correct corrupted data.
One important reason *to* upgrade to Vista is its improved Kerberos support - it will finally support AES Kerberos tickets. Not only is this more secure than Microsoft's current RC4-based tickets, but it should make interoperability with other platforms much easier.
Could you provide any citation indicating that the Kerberos developers claim that PKI is more secure than Kerberos? Just one would suffice.
As for PKI, you've failed to provide a single example of a common PKI that handles revocation or manages private keys usefully. Certainly SSL, the most widely depolyed example of PKI, is basically encryption for show, since I don't know of any browser that checks for revocation (and some of them even allow expired certs by default), and they ship with so many CAs trusted that you can't be sure of who you're talking to.
As for KDC host-based security, the same argument can be made against a CA. If a CA's private key is compromised, you're screwed. And since most CAs issue certs for multiple security domains, the potential damage is far greater than a KDC compromise.
It boils down to this. If someone cracks my Kerberos password, I can contact my sysadmin and have him change my password. If someone breaks into my system and steals my credential cache, there is a very narrow window of damage. Most KDCs issue tickets good for 8-10 hours, and renewable up to a week at most. On the other hand, most certificates are good for 1-2 years. And mos PKI systems don't bother with revocation, since no one's figured out how to make it scale. So if someone steals my private key, I'm pretty much screwed.
How can you claim that Kerberos is "fairly poor security wise" ? I would argue that it's vastly *more* secure than PKI. You don't need to send your password over the network to authenticate, and it's actually possible to lock user accounts (unlike PKI, where you'd need a working revocation system to do that). And Kerberos doesn't store copies of the users' passwords on the server - it stores hashes of them (specifically, the output of the string-to-key function for each enctype you have enabled).
As for OpenSSH's support for Kerberos, I'm less than impressed. It was an uphill battle several years ago to get it to support gssapi-with-mic, so that it could handle user authentication with a Kerberos ticket, rather than tunneling a username/password pair to it. And it still doesn't support the new gssapi-keyex host authentication mechanism (so that you don't need a known_hosts file and ssh server keys at all).
Why on earth would you want to use Heimdal?
That wasn't my point. The parent post said that Java wasn't available for many platforms. I've pretty much shown that that isn't the case.
If you want to run Java on the BSDs, I believe its possible to run the Linux/x86 version in compatibility mode. Granted, this sucks, but it's something. You might want to look at GNU Classpath, GCJ or Jikes. Between the three of them, you have (most of) the components you'd need for a free JVM + Java standard library.
- 32-bit Windows
- 64-bit Windows (as a RC)
- 32-bit Linux x86
- 64-bit Linux x86
- 32-bit Solaris x86
- 32-bit Solaris SPARC
- 64-bit Solaris x86
- 64-bit Solaris SPARC
- 32-bit AIX POWER
- 64-bit AIX POWER
- 31-bit z/OS
- 64-bit z/OS
- 32-bit i5/OS POWER
- 64-bit i5/OS POWER
- IRIX
- OpenVMS Alpha
- OpenVMS IA64
- Tru64
- HP-UX PA-RISC
- HP-UX IA64
Is that enough platforms for you? No, it doesn't cover everything, but there certainly are a lot there.I'm a big fan of Python. I used it almost exclusively before taking my current job. But let's be honest, Python and Java just aren't intended for the same type of applications.
Python's standard library just doesn't have the breadth of Java's. For small apps, the CPython VM is lighter than Sun's JVM, but CPython's VM is lacking several capabilities that I'd consider pretty essential -- chief among them is the ability to return unused memory back to the OS. And for many tasks, CPython is still effectively single-threaded due to its global interpreter lock. Java has never suffered from either of these problems. These aren't trivial issues or the result of nitpicking -- they're rather severe limits (which make me seriously question the suitably of Python for enterprise apps, eg. Zope). Of course, once CPython does get decent threading, it's likely that it's GC subsystem will need to be totally rewritten. I apologize if it sounds like I'm beating up on Python. That's not my intent here. I love Python, and I only wish I could stop more people from using Perl :)
In fairness, it does look like the Python community is trying to address some of these problems. I just read a paper presented last week at PyCon 2005 on CPython's memory management. The author is developing some patches to let CPython return unused memory to the OS for most object types (except for Number, List and Dictionary). The memory manager still can't defragment its heap, so this isn't a perfect solution. As of a few weeks ago it looks like these patches haven't yet been accepted.
How is the autovacuum daemon a kludge? It scans the internal state of tables and vacuums when necessary. And with the cache manager (ARC) and I/O throttling (bgwriter) work in PostgreSQL 8.0, vacuum doesn't impose nearly the overhead that it used to. What's the problem?
MySQL can use different "storage engines" for different tables. One of their older (and arguably, more widely deployed) engines in MyISAM, which does table-level locking (their newer engine, InnoDB, does row-level locking). From the MySQL Manual (sec 7.3.1):
and from Section 7.3.2:
This is one of the many problems with MySQL. I agree with you that Oracle (and PostgreSQL) are much better designed.
In MySQL (with MyISAM tables), the reason things like count(*) are fast is that MyISAM pre-computes those values. It can do this because it locks the table on insert and update. PostgreSQL doesn't lock the table on modifications -- it allows concurrent access via Multi-Version Concurrency Control (MVCC). Basically, each row in the DB has additional information (used internally by PostgreSQL), which stores which transaction created and last modified the row. PG uses this to determine if any given row should be "visible" to the current transaction. Because this informaiton is constantly changing (and varies from transaction to transaction), you can't precompute things like count(*) and sum(*). See http://developer.postgresql.org/pdf/internalpics.p df for more info (start around page 56).
Just remember that almost no open-source databases use parallelized algorithms. PostgreSQL, Firebird and MySQL certainly don't. OpenIngres is the only one I know of with a parallel query engine. By this I mean the ability of a single query to use multiple processors (say, for handling a complex join and a large sort). The only way PG, FB and MySQL can use multiple CPUs is if you have multiple queries running. But for OLAP-style workloads, you won't see much benefit from SMP.
Does Postgres still make really bad optimizer choices if the data-types being compared aren't identical?
In version 8.0 (current at beta4), the optimizer will automatically cast the columns to a common type and pick a better plan.
Does Postgres have a decent replication engine, or standby database option?
There are several. Have you looked at Slony-I ?
Does Postgres have a native Windows port yet?
Version 8 will. You can download the beta today if you'd like.
This is because MySQL silently creates default values for every column. It uses "" for VARCHAR columns and 0 for numeric columns. So when you try to insert a string into an integer column, it's using the default value. Why its creators decided to implement this "feature" escapes me.
Well, many of these NSS features are already implemented in ZFS. For instance, ZFS has a compression scheme called LZJB; it's the same algorithm used to compress Solaris crash dumps. It doesn't need journaling, since it uses copy-on-write. And I can't imagine that Sun would release a new filesystem that doesn't support quotas and ACLs (UFS has supported ACLs for years; and I imagine Sun's customers would demand the same feature on ZFS).
Yes, there are things that NSS (and the IBM ZFS) do that Sun's ZFS doesn't, but it certainly looks like an interesting, useful filesystem.
Do you understand how operating systems work? No, I'm serious.
Just because Sun claims that lots of "enterprise features" doesn't mean they're all in the kernel. You do understand the concept of userspace, yes?
Well, in a modular kernel, you can avoid loading those modules you don't need....
Further, you've provided absolutely no evidence supporting your claim that the Linux kernel is "leaner" than the Solaris and WinNT kernels. You only linked to a feature list for an entire operating system, which has nothing to do with the size of a kernel (and even if Solaris' kernel is bigger than Linux, what does that have to do with the suitability of Linux or Solaris to any given task?).
But let's look at this feature list you've offered up as proof:
Predictive Self-Healing is mostly in user-space. It's a framework in which various daemons report error codes to a user-space daemon, which diagnoses the problem and takes appropriate action (restarting services, increasing filesystem size, taking hardware offline, etc). There's likely little new kernel code here.
N1 Grid Containers does require new kernel code. But so does User Mode Linux, which accomplishes a similar goal. Conviently, you neglect to mention that.
DTrace is kernel space, but it's implemented in a modular fashion - the various DTrace probe providers don't have to be loaded. And since the probe points are dynamically generated, there's little bloat.
Dynamic File System (ZFS) is a new filesystem driver. Solaris already has a lot of these. So does Linux. In fact, Linux has more (how's that for bloat).
Process Rights Management is a new permission system. This will add some kernel code, but not reams. This really is just integration of existing Trusted Solaris code.
IP Filter - Sun removed SunScreen and replaced it with IPF. Big woo.
So, your claims don't add up.
Your comparison to 9/11 is absurd.
First of all, you don't see open-source developers decompiling closed-source software to try to improve their own code, so your claims are pretty fanciful. And even if they did, the copyright holders could sue the developers and force the offending code to be removed.
The Solaris kernel is modular as well. Do you have any basis for claiming that the Solaris kernel is bloated? I doubt you've seen the source code.
Except that UFS logging ("journalling") has been available since Solaris 7. It wasn't turned on by default, but a simple edit of
As for the rest of your claims, every piece of closed-source software I've seen specifically prohibits decompilation/disassembly.