Biometric's are not useful as a general purpose authentication technique. They are effectively a plaintext password which you can't change. The fact that you "type" it by putting your finger on a sensor, or looking at a camera, or having your hand measured doesn't change the fundamental nature of the password.
Which is not to say that they don't have uses. But they are limited. A certain amount of trust has to already exist. The entity which is being authenticated to needs to be able to trust the biometric reader. If you can't trust the reader, then you don't know if it's actually performing the biometric measurement or just replaying a previously recorded measurment.
So it works fine, for example, for checking the identities of people entering a secure facility. The same company owns the building and the reader, and perhaps has a guard watching people enter so that they know the reader isn't being tampered with.
It does not work, for example, for authenticating to a web site. Sending a JPEG of your fingerprint (or something similar) to your bank's web site doesn't really provide any authentication at all. Moreover, if you are using your fingerprint as a password at lots of web sites, then if any of them get hacked the attacker can then impersonate you to all the other web sites. I guess then you can start using a different finger, but that only works so many times.
The solution in this case is a smart card or something similar. You carry the smart card, and your fingerprint unlocks it. The card can then perform strong crypto-based authentication to whatever web sites, etc. require it. Your fingerprint (or other biometric measurement) only travels between you and the card you carry. This helps protect you against entrusting everybody with a copy of your biometric password. And the remote sites don't have to trust the fundamentally weak biometric password getting sent to them over the Internet.
"RouterCLI is a cisco-like shell for small or diskless linux distributions. Pre-alpha includes interface configuration, routing manipulation, ping,telnet and trace utilities, I still think about libtecla, access-lists and config."
I'm sure it's coincidence, but the timing is kinda funny. Actually looks like it might become a useful little tool. And we can tell it's not really based on the leaked Cisco source by the use of fork():-)
Actually it's simple. The operating system (actually starting from the BIOS) keeps a log of the hash of each peice of software as it gets submitted to the TCPA chip.
I know it's conceptually simple. But in practice, how long is that list of acceptable hashes going to be? And how often is it going to change?
It doesn't matter how many spywares and trojans are running. Everthing is encrypted and you know exactly which peice of software you are talking to.
No, if you have allowed "Owner Override", then you have no idea what software you are talking to. That's the whole point to owner override from what I can tell. The owner can have the machine pretend to be running whatever software they want. Which is basically what the situation is today.
I'll admit, the "owner override" is a clever gambit. It sounds reasonable at first, but it basically nullifies the whole system. A digital signature is supposed to actually mean something. But if the system is set up so that anybody (I.e., any machine owner) can "sign" random values with the TCPA key, then that signature doesn't mean anything at all. It's worthless.
What they actually do is deny you an internet connection unless your computer is "Trusted and compliant".
Yep. And let me tell you the demand for this type of functionality is very high in a corporate environment. And if Linux can't offer that functionality, it runs a very real chance of being entirely eliminated from many corporate networks. If that's what you want, then keep fighting it.
The president's cybersecurity advisor called on ISP's to make plans to install exactly these sort of routers and impose Trusted Computing compliance on their customers as part of their terms of service.
I don't find this likely to happen. I'd also love to see a reference.
You can get EVERY benefit and NONE of the abuses from identical hardware where the owner is given a printed copy of his key. They simply refuse to offer such a machine because the true motivations for the system are the malicious purposes.
Which key is that? The owner key which is generated on-demand during the take_ownership function? The only way the user could get a printout of this key, which is generated after the user has possession of the device, is for there to be a valid TCPA command for reading out the private key. The whole point is to not have any software API for reading out the private keys. If I wanted that, I'd just put my SSH keys on a damn USB dongle.
That is pure marketing smoke screen.
Oh good lord. Take off the tin-foil hat. I'm not a marketer, and I don't work for any organization with any vested interest in TCPA. I'm an administrator who knows first hand that passwords get sniffed and SSH private keys get stolen. And right now we have no good defense against it. Putting on my tin-foil hat, I have to wonder which side you're on that you are so against the idea of me having a secure place to keep my SSH keys.:-P
Personally I don't find remote attestation to even be a terribly useful feature. I think in practice, the massive number of valid software combinations will make it worthless.
Besides, letting users specify arbitrary software configurations would make the whole thing basically pointless. Even if it did work (something I don't consider likely. See the previous paragraph,) what's the point if you can't tell how filled with spyware and trojans the users computer actually is? Which is exactly what will happen if you give users the power to override the attestation.
All of which ignores the point. Just don't use it. Microsoft is going to make their customers their bitch. If you don't want that to happen to you, you have to stop using their software. Period. No amount of whining out of the EFF is going to change that fact.
Once again, a reader with no clue how TCPA works. Please Google for 'tcpa linux' and educate yourself before spouting off this mis-informed meme again.
User hostile hardware chips meant to prove to record companies that the DRM software on the machine is not circumvented I hope we never see.
Hacker hostile hardware chips meant to prove to me that the SSH software on the machine is not circumvented I hope we do see. Of course, it's the same hardware. Too bad so many Linux users are so remarkably mis-informed about what TCPA is and does. Please actually google for 'tcpa linux' and read some of the information there. The hardware itself is not evil, and actually could have a lot of very nice uses.
Re:Couch Potatoes Deserve to be Kept Down
on
Free Culture
·
· Score: 1
I found a partial version on Google. It seems to be corrupt at the end, but most of it is there. Search for quayle.mov
You got me. What's an "NCA"? I've read some of the TCPA spec, so I've got a pretty good idea of what it does. I've got a fleeting impression of NGSCB; enough to give me a rough idea of the role of the Nexus. But I'm not familiar with "NCA". Is that roughly a "trusted" application?
Re:Couch Potatoes Deserve to be Kept Down
on
Free Culture
·
· Score: 1
Dan Quayle really did say a lot of stupid things. He was never meant to be in front of a camera. Years ago, I had a quicktime movie with a bunch of clips of him saying stupid stuff. I should try to find it. My favorite Quayle quote:
They all have one thing in common: it's about not trusting the machine's owner, and using someone's computer to serve someone else's interests.
That's only because the author left out some very nice examples. Here's one. The secure key storage can provide a place to keep SSH private keys where they can't be stolen if your box is rooted. And the secure I/O can let you enter your passphrase without it being snarfed if your box is rooted.
The basic TCPA technology is, like most tech, amoral. You can use it for lots of things. Some good, some bad. Is Microsoft going to do nasty stuff with it? Of course, they're Microsoft. But that doesn't mean we can't do cool stuff with it under Linux.
Applications like online casinos would also benefit from a magical honesty pill which users could take to prevent them from cheating - but it's not going to happen.
Keep in mind that casios don't have to trust the users. The example was allowing the users to trust the casios, which is a fairly difficult problem even in a real life casino.
On the other hand, the specific example of a casino is fairly poor. The algorithm for a secure coin toss between untrusted parties is old and well documented. It allows the outcome of the coin toss to be determined in such a way that neither party can determine the outcome in advance of the final revealing. It's trivial to expand a coin toss, which is just a bit, to more bits to enable a game of blackjack or poker to be played securely online. I don't think any online casios actually do this, but they could. No need for TCPA.
Virtualization is actually pretty easy to handle. Something like VMWare is just another application. You can attest to the exact version of the VM which is running just like any other application. The whole TCPA is built on layers of software. The TCPA chip hashes the BIOS, which hashes the bootloader, which hashes the kernel, which hashes the applications, etc. As long as each layer follows the protocol, the chain of hashes stays intact. Adding a VM is just another layer.
Which is not to say that any old VM will be trusted by any given remote site. But Microsoft can certainly make it's VM "trusted" if it wants.
Seems to me that we can do that too in software.. SSH verifies the other computer when you connect. It's called keeping the private key private..
Uh, yeah. Whatever. SSH clients and servers can and do get trojaned in the wild. Just because that remote server returns the same public key it always has doesn't mean the binary hasn't been replace with one that records keystrokes. Remote attestation can be used to give you assurance that the remote server is patched in an up to date manner and running unmodified binaries.
The fact is that while SSH has improved many aspects of network computing, it still has vulnerabilities. Passwords and passphrases can get grabbed with a keystroke logger. Daemon and client binaries can get trojaned. Private key files can get copied off of the machine. TCPA actually addresses all of these shortcomings in one way or another.
I suggest you go ahead and start learning MacOSX now. TCPA is coming to the PC platform (and is in fact already shipping on a number of IBM products.)
P2P Networks ** I don't think that corperations see that as bettering the internet.
Well, see, that's the funny part. Anybody can write software which takes advantage of TCPA. So while the RIAA/MPAA thinks it's a grand idea so that they can protect their online media offerings, they are going to absolutely crap their pants when, not if a P2P network starts using it to make it difficult/impossible to determine exactly who is making files available.
Yes, thank you for the english lesson. But it's obviously the [i]need[/i] for secrecy which is the whole issue. My point, which I thought was pretty clear, is that hardware companies often keep the documentation secret without bothering to determine if there is in fact any need for it. To the detriment of many of their customers I might add.
Finally, an admission that the hardware vendors claim of secret interfaces is often just BS:
One of the most common phrases we heard from chip vendors in the first few years was "we'll never tell you that." "That" being CPU information, chipset information, motherboard information or any combination of the three. The designs for these three systems constitute highly guarded secrets. It seems amazing, even now, that vendors are able to let us build a GPLed BIOS that by its nature exposes some of these secrets.
How was it possible for us to get this type of information? Simple, businesses are not charities. If there is no business case for releasing this information to us, they do not do it. If, however, there is a business case, then it happens?sometimes with astonishing speed.
Read that last paragraph again. The hardware vendors basically say "that's a secret" whether it really is or not. Unless you pay them, or show them that they are losing money, they won't even bother deciding if it's really something that has to be kept secret.
That's the weird thing about the place. It's considered basically uninhabitable by humans. Yet nature as a whole seems entirely unfazed by the radition and is thriving in the absence of humans.
On the other hand, it really isn't that weird. The "nature preserve" aspect is only disturbing in relation to the empty roads and buildings. Without those features to provide the desolation aspect, nothing would seem amiss. Plus, nobody is keeping track of the average lifespan of those horses, which is almost certainly below average.
Still, a fascinating photo-essay either way. And I think it's funny that her Kawasaki probably would have been worth as much as a whole town in that part of the world in 1985.
McDonalds is my guess. Someone else guessed AutoZone because they are also moving away from SCO Unix. But I think McDonalds will have better PR punch, so that's where I'm putting my money. I think it's also realistic to assume that they will also make the announcement during the "earnings" call itself so as to minimize the amount of time they have to spend discussing just how horrible their balance sheet was last quarter.
Given the effectiveness of caller-id when it comes to the spammers of the phone world, I don't think it's the best model. Basically, caller-id allows anybody who has a PBX connected with digital trunks to the network to forge whatever caller-id information they want. Most telemarketers left it blank. Lots of legit companies send the id information for their main switchboard number, no matter what actual phone line the call is travelling down.
The problems reside in keeping trade secrets and sometimes even in using licensed code in your drivers. Imagine if you licensed some sort of technology from someone for a cost for use in your drivers.
Hopefully what companies will learn is that the hardware interface is a dumb place to keep secrets. There is nothing intrinsic to a NIC interface or a video card interface which needs to be kept secret. Plenty of companies have developed competitive hardware offerings with open specs on the hardware interface.
Designing your hardware so that it requires software licensed from a third party to drive it is a stupid strategic move. Same with designing your hardware so that there is some sort of "secret" embodied in the hardware interface. Such design choices reduce the market share available to your product without providing any obvious benefit.
I do have to say I find it hard to believe that there is ever any valuable trade secrets which would be revealed in the specs for the hardware. Most likely, the specs would just reveal that the hardware is fundamentally cheap-ass and has pushed most of the heavy lifting into the driver. Bascially using spare CPU cycles to subsidize a cheap produce (ala winmodems). Good hardware which actually does the work itself will have a simple interface, consisting of some setup routines, interrupt handling and I/O.
This slide indicates the full source is 50gb and took a week to setup and 2 hours a day to update.
The weird thing about that slide is that it indicates that the project is "29M LOC". Now, by my math, that indicates about 1,700 bytes of storage used per line of code. There has to be something artificially inflating the size, or decreasing the LOC. I mean, even assuming 170 character lines, that works out to 10 lines of comments for every line of code. I wonder if the 50GB refers to the size of the multi-version repository, or to just a single check out?
Either way, if the LOC is 6M for NT and 29M for 2K (numbers taken from the slides you linked), I can easily imagine it all fitting into a net-friendly sized zip file. Hell, my 2.4.23 tarball is about 29MB and has 3.6M lines (including comments) in the.c files. Multiply that by 10x and it's not even half an ISO image.
Slashdot Mirror
Biometric's are not useful as a general purpose authentication technique. They are effectively a plaintext password which you can't change. The fact that you "type" it by putting your finger on a sensor, or looking at a camera, or having your hand measured doesn't change the fundamental nature of the password.
Which is not to say that they don't have uses. But they are limited. A certain amount of trust has to already exist. The entity which is being authenticated to needs to be able to trust the biometric reader. If you can't trust the reader, then you don't know if it's actually performing the biometric measurement or just replaying a previously recorded measurment.
So it works fine, for example, for checking the identities of people entering a secure facility. The same company owns the building and the reader, and perhaps has a guard watching people enter so that they know the reader isn't being tampered with.
It does not work, for example, for authenticating to a web site. Sending a JPEG of your fingerprint (or something similar) to your bank's web site doesn't really provide any authentication at all. Moreover, if you are using your fingerprint as a password at lots of web sites, then if any of them get hacked the attacker can then impersonate you to all the other web sites. I guess then you can start using a different finger, but that only works so many times.
The solution in this case is a smart card or something similar. You carry the smart card, and your fingerprint unlocks it. The card can then perform strong crypto-based authentication to whatever web sites, etc. require it. Your fingerprint (or other biometric measurement) only travels between you and the card you carry. This helps protect you against entrusting everybody with a copy of your biometric password. And the remote sites don't have to trust the fundamentally weak biometric password getting sent to them over the Internet.
This just in. routercli-0.1.pre-alpha From the project page:
:-)
"RouterCLI is a cisco-like shell for small or diskless linux distributions. Pre-alpha includes interface configuration, routing manipulation, ping,telnet and trace utilities, I still think about libtecla, access-lists and config."
I'm sure it's coincidence, but the timing is kinda funny. Actually looks like it might become a useful little tool. And we can tell it's not really based on the leaked Cisco source by the use of fork()
Seeing as how I don't even get seven channels, I don't think I'm the target market. It does sound cool though.
Actually it's simple. The operating system (actually starting from the BIOS) keeps a log of the hash of each peice of software as it gets submitted to the TCPA chip.
:-P
I know it's conceptually simple. But in practice, how long is that list of acceptable hashes going to be? And how often is it going to change?
It doesn't matter how many spywares and trojans are running. Everthing is encrypted and you know exactly which peice of software you are talking to.
No, if you have allowed "Owner Override", then you have no idea what software you are talking to. That's the whole point to owner override from what I can tell. The owner can have the machine pretend to be running whatever software they want. Which is basically what the situation is today.
I'll admit, the "owner override" is a clever gambit. It sounds reasonable at first, but it basically nullifies the whole system. A digital signature is supposed to actually mean something. But if the system is set up so that anybody (I.e., any machine owner) can "sign" random values with the TCPA key, then that signature doesn't mean anything at all. It's worthless.
What they actually do is deny you an internet connection unless your computer is "Trusted and compliant".
Yep. And let me tell you the demand for this type of functionality is very high in a corporate environment. And if Linux can't offer that functionality, it runs a very real chance of being entirely eliminated from many corporate networks. If that's what you want, then keep fighting it.
The president's cybersecurity advisor called on ISP's to make plans to install exactly these sort of routers and impose Trusted Computing compliance on their customers as part of their terms of service.
I don't find this likely to happen. I'd also love to see a reference.
You can get EVERY benefit and NONE of the abuses from identical hardware where the owner is given a printed copy of his key. They simply refuse to offer such a machine because the true motivations for the system are the malicious purposes.
Which key is that? The owner key which is generated on-demand during the take_ownership function? The only way the user could get a printout of this key, which is generated after the user has possession of the device, is for there to be a valid TCPA command for reading out the private key. The whole point is to not have any software API for reading out the private keys. If I wanted that, I'd just put my SSH keys on a damn USB dongle.
That is pure marketing smoke screen.
Oh good lord. Take off the tin-foil hat. I'm not a marketer, and I don't work for any organization with any vested interest in TCPA. I'm an administrator who knows first hand that passwords get sniffed and SSH private keys get stolen. And right now we have no good defense against it. Putting on my tin-foil hat, I have to wonder which side you're on that you are so against the idea of me having a secure place to keep my SSH keys.
Personally I don't find remote attestation to even be a terribly useful feature. I think in practice, the massive number of valid software combinations will make it worthless.
Besides, letting users specify arbitrary software configurations would make the whole thing basically pointless. Even if it did work (something I don't consider likely. See the previous paragraph,) what's the point if you can't tell how filled with spyware and trojans the users computer actually is? Which is exactly what will happen if you give users the power to override the attestation.
All of which ignores the point. Just don't use it. Microsoft is going to make their customers their bitch. If you don't want that to happen to you, you have to stop using their software. Period. No amount of whining out of the EFF is going to change that fact.
Once again, a reader with no clue how TCPA works. Please Google for 'tcpa linux' and educate yourself before spouting off this mis-informed meme again.
User hostile hardware chips meant to prove to record companies that the DRM software on the machine is not circumvented I hope we never see.
Hacker hostile hardware chips meant to prove to me that the SSH software on the machine is not circumvented I hope we do see. Of course, it's the same hardware. Too bad so many Linux users are so remarkably mis-informed about what TCPA is and does. Please actually google for 'tcpa linux' and read some of the information there. The hardware itself is not evil, and actually could have a lot of very nice uses.
I found a partial version on Google. It seems to be corrupt at the end, but most of it is there. Search for quayle.mov
You got me. What's an "NCA"? I've read some of the TCPA spec, so I've got a pretty good idea of what it does. I've got a fleeting impression of NGSCB; enough to give me a rough idea of the role of the Nexus. But I'm not familiar with "NCA". Is that roughly a "trusted" application?
Dan Quayle really did say a lot of stupid things. He was never meant to be in front of a camera. Years ago, I had a quicktime movie with a bunch of clips of him saying stupid stuff. I should try to find it. My favorite Quayle quote:
"The future will be better tomorrow!" WTF?
They all have one thing in common: it's about not trusting the machine's owner, and using someone's computer to serve someone else's interests.
That's only because the author left out some very nice examples. Here's one. The secure key storage can provide a place to keep SSH private keys where they can't be stolen if your box is rooted. And the secure I/O can let you enter your passphrase without it being snarfed if your box is rooted.
The basic TCPA technology is, like most tech, amoral. You can use it for lots of things. Some good, some bad. Is Microsoft going to do nasty stuff with it? Of course, they're Microsoft. But that doesn't mean we can't do cool stuff with it under Linux.
Applications like online casinos would also benefit from a magical honesty pill which users could take to prevent them from cheating - but it's not going to happen.
Keep in mind that casios don't have to trust the users. The example was allowing the users to trust the casios, which is a fairly difficult problem even in a real life casino.
On the other hand, the specific example of a casino is fairly poor. The algorithm for a secure coin toss between untrusted parties is old and well documented. It allows the outcome of the coin toss to be determined in such a way that neither party can determine the outcome in advance of the final revealing. It's trivial to expand a coin toss, which is just a bit, to more bits to enable a game of blackjack or poker to be played securely online. I don't think any online casios actually do this, but they could. No need for TCPA.
Virtualization is actually pretty easy to handle. Something like VMWare is just another application. You can attest to the exact version of the VM which is running just like any other application. The whole TCPA is built on layers of software. The TCPA chip hashes the BIOS, which hashes the bootloader, which hashes the kernel, which hashes the applications, etc. As long as each layer follows the protocol, the chain of hashes stays intact. Adding a VM is just another layer.
Which is not to say that any old VM will be trusted by any given remote site. But Microsoft can certainly make it's VM "trusted" if it wants.
Now give me your money, and here's your yearly upgrade of office.
Or not. As the suckers who bought into "Software Assurance" or whatever it's called found out.
Seems to me that we can do that too in software.. SSH verifies the other computer when you connect. It's called keeping the private key private..
Uh, yeah. Whatever. SSH clients and servers can and do get trojaned in the wild. Just because that remote server returns the same public key it always has doesn't mean the binary hasn't been replace with one that records keystrokes. Remote attestation can be used to give you assurance that the remote server is patched in an up to date manner and running unmodified binaries.
The fact is that while SSH has improved many aspects of network computing, it still has vulnerabilities. Passwords and passphrases can get grabbed with a keystroke logger. Daemon and client binaries can get trojaned. Private key files can get copied off of the machine. TCPA actually addresses all of these shortcomings in one way or another.
I suggest you go ahead and start learning MacOSX now. TCPA is coming to the PC platform (and is in fact already shipping on a number of IBM products.)
P2P Networks
** I don't think that corperations see that as bettering the internet.
Well, see, that's the funny part. Anybody can write software which takes advantage of TCPA. So while the RIAA/MPAA thinks it's a grand idea so that they can protect their online media offerings, they are going to absolutely crap their pants when, not if a P2P network starts using it to make it difficult/impossible to determine exactly who is making files available.
Yes, thank you for the english lesson. But it's obviously the [i]need[/i] for secrecy which is the whole issue. My point, which I thought was pretty clear, is that hardware companies often keep the documentation secret without bothering to determine if there is in fact any need for it. To the detriment of many of their customers I might add.
Finally, an admission that the hardware vendors claim of secret interfaces is often just BS:
One of the most common phrases we heard from chip vendors in the first few years was "we'll never tell you that." "That" being CPU information, chipset information, motherboard information or any combination of the three. The designs for these three systems constitute highly guarded secrets. It seems amazing, even now, that vendors are able to let us build a GPLed BIOS that by its nature exposes some of these secrets.
How was it possible for us to get this type of information? Simple, businesses are not charities. If there is no business case for releasing this information to us, they do not do it. If, however, there is a business case, then it happens?sometimes with astonishing speed.
Read that last paragraph again. The hardware vendors basically say "that's a secret" whether it really is or not. Unless you pay them, or show them that they are losing money, they won't even bother deciding if it's really something that has to be kept secret.
That's the weird thing about the place. It's considered basically uninhabitable by humans. Yet nature as a whole seems entirely unfazed by the radition and is thriving in the absence of humans.
On the other hand, it really isn't that weird. The "nature preserve" aspect is only disturbing in relation to the empty roads and buildings. Without those features to provide the desolation aspect, nothing would seem amiss. Plus, nobody is keeping track of the average lifespan of those horses, which is almost certainly below average.
Still, a fascinating photo-essay either way. And I think it's funny that her Kawasaki probably would have been worth as much as a whole town in that part of the world in 1985.
You know you are a sysadmin when you hear the phrase "users are losers" and don't think of drugs.
McDonalds is my guess. Someone else guessed AutoZone because they are also moving away from SCO Unix. But I think McDonalds will have better PR punch, so that's where I'm putting my money. I think it's also realistic to assume that they will also make the announcement during the "earnings" call itself so as to minimize the amount of time they have to spend discussing just how horrible their balance sheet was last quarter.
Given the effectiveness of caller-id when it comes to the spammers of the phone world, I don't think it's the best model. Basically, caller-id allows anybody who has a PBX connected with digital trunks to the network to forge whatever caller-id information they want. Most telemarketers left it blank. Lots of legit companies send the id information for their main switchboard number, no matter what actual phone line the call is travelling down.
The problems reside in keeping trade secrets and sometimes even in using licensed code in your drivers. Imagine if you licensed some sort of technology from someone for a cost for use in your drivers.
Hopefully what companies will learn is that the hardware interface is a dumb place to keep secrets. There is nothing intrinsic to a NIC interface or a video card interface which needs to be kept secret. Plenty of companies have developed competitive hardware offerings with open specs on the hardware interface.
Designing your hardware so that it requires software licensed from a third party to drive it is a stupid strategic move. Same with designing your hardware so that there is some sort of "secret" embodied in the hardware interface. Such design choices reduce the market share available to your product without providing any obvious benefit.
I do have to say I find it hard to believe that there is ever any valuable trade secrets which would be revealed in the specs for the hardware. Most likely, the specs would just reveal that the hardware is fundamentally cheap-ass and has pushed most of the heavy lifting into the driver. Bascially using spare CPU cycles to subsidize a cheap produce (ala winmodems). Good hardware which actually does the work itself will have a simple interface, consisting of some setup routines, interrupt handling and I/O.
Hmmm. Executable data files. Frankly, M$ can damn well keep executable data files to themselves. Have they learned nothing?
This slide indicates the full source is 50gb and took a week to setup and 2 hours a day to update.
.c files. Multiply that by 10x and it's not even half an ISO image.
The weird thing about that slide is that it indicates that the project is "29M LOC". Now, by my math, that indicates about 1,700 bytes of storage used per line of code. There has to be something artificially inflating the size, or decreasing the LOC. I mean, even assuming 170 character lines, that works out to 10 lines of comments for every line of code. I wonder if the 50GB refers to the size of the multi-version repository, or to just a single check out?
Either way, if the LOC is 6M for NT and 29M for 2K (numbers taken from the slides you linked), I can easily imagine it all fitting into a net-friendly sized zip file. Hell, my 2.4.23 tarball is about 29MB and has 3.6M lines (including comments) in the