Actually, he didn't say the piracy was affecting his bottom line. He simply said it wasn't helping sales. Was that accidental or intentional? I strongly suspect that the piracy isn't hurting sells either, which means the answer to his question is "nothing." If he can post data which shows that sales are dropping and that those dropped sales don't correlate to, say, his book being replaced by a newer textbook in university courses, then I'll reconsider.
What you're talking about is called split tunneling. There is some security risk with allowing split tunneling, although it's not "...horrifically broken and insecure..." as you suggest, particularly if you require the client to have a local firewall before you bring up the VPN. (Decent VPN software will allow this.) The problem with not allowing split tunneling is that it greatly increases the load on your network, since all traffic is routed through you before going to the client, and that you break lots of things for the VPN'd user. For example, if I"m VPN'd and split tunneling is disallowed, I can't use a local network printer until I break the VPN.
Like every other situation, there is a trade off between security and functionality. Increasing security decreases functionality and vice versa. Whether or not it makes sense to allow split tunneling is greatly dependent upon the situation.
The CNN article commenting on the proposed bill says:
Another example: Web browsers could also be regulated and subject to Federal Trade Commission enforcement action unless "informed consent" is obtained each time the desktop icon is double-clicked. (Every Web browser allows the user to "designate" files to be uploaded--ever post a photo?--and request that files be downloaded.)
This appears to be covering things like uploading a photo or downloading a program to install. That doesn't even cover the half of it. What happens when you visit a web page? Your browser sends a GET request and downloads the file - it copies a file from the server to your computer. If the page is not static, of course, the file is generated on the fly by scripts. But if that isn't covered, then I'll simply code my P2P app to ROT13 all files. When you download it, a script reads it and generates the stream that's transferred to you. I'm no longer copying a file, so the law doesn't apply to me.
What happens when you visit many, many websites? They read your cookies. The cookie is a file on your computer. It's transferred from your computer to their server. What happens when you download your email, particularly if you're accessing a 'Nix based mail server where mail is stored in mbox or mailbox format? What happens when you open a file with your Word processor on a remote share? In short, what happens almost any time you do anything on a networked computer? Is every application you run going to have to nag you to death every time you open it?
This is so ludicrous that not even Congress could pass it.
It isn't clear to me why this is a failure, or a negative result if you prefer. Granted, the carbon didn't sink to the bottom of the ocean, but it was still removed from the water, which should allow the water to absorb additional CO2 from the air. It seems to me that, so long as the CO2 is pulled from the atmosphere, it's still an effective means of combating warming. Isn't one of the proposed remedies to increase the plant mass? Why isn't this just as effective as increased plants? What am I missing?
All of the other examples you list - from messengers to telegraph to satcom - are technologies. The government's use of these technologies doesn't impact other uses of them in any way. The Internet, on the other hand, is a particular implementation of a technology. If the military wants to use TCP/IP as a military asset, few people would have any problem with that. But the ability to protect something necessarily means having at least some control over it. It means the ability to take action against anything interpreted as a threat, and the military/government definition of "threat" can be quite broad and quite self serving. (Go through airport security if you'd like to get an idea of how the government thinks security ought to be implemented.) So if the military wants to claim the Internet as a military asset, then I have a big issue with that. And I'm speaking as someone who is drawing a retirement pension from the US military.
Doesn't this suggest an obvious solution to CAPTCHA? Just use cursive text rather than try to obscure the text with funky backgrounds. If the spammers do manage to crack the CAPTCHA, then incorporate their technology into mainstream OCR programs.
Lots of mainstream media sources provide "personal comments." They're called editorials. And yes, I damned sure do see a meaningful distinction between what's said in an article and what's said in an editorial. And yes, if an article is immediately followed by an editorial which is clearly labeled as an editorial, then I see a huge difference there too.
If you think there's no difference in putting editorial comment in an article and in a personal comment attached to the article, you must work for Fox News.
Here's an email from one of Comcast's engineers recently sent to Dave Farber's Interesting People mailing list. It clarifies the policy quite well:
From: "Livingood, Jason" Subject: Clarifying Misconceptions of the New Comcast Congestion Mgmt Syste
Hi Dave
I wanted to try to clear up a misconception about how the new Comcast congestion management system works. I believe we have both heard people complain that they fear that they will be unable to use their provisioned speeds during off-peak hours, for example, or at all times of the day, or that users are somehow throttled to a set speed. Neither of these two things are correct. Part of the problem appears to be confusion over how a user's traffic enters a lower priority QoS state, so I hope to clarify that here
In order for any traffic to be placed in a lower priority state, there must first be relatively high utilization on a given CMTS port. A CMTS port is an upstream or downstream link, or interface, on the CMTS in our network. The CMTS is basically an access network router, with HFC interfaces on the subscriber side, and GigE interfaces on the WAN/Internet side. Today, on average, about 275 cable modems share the same downstream port, and about 100 cable modems share the same upstream port (see page 5 of Attachment B of our Future Practices filing with the FCC, available at http://downloads.comcast.net/docs/Attachment_B_Future_Practices.pdf). We define a utilization threshold for downstream and upstream separately. For downstream traffic, a port must average over 80% utilization for 15 minutes or more. For upstream traffic, a port must average over 70% utilization for 15 minutes or more
When one of these threshold conditions has been met, we consider that individual port (not all ports on the CMTS) to be in a so-called Near Congestion State. This simply means that the pattern of usage is predictive of that network port approaching a point of high utilization, where congestion could soon occur. Then, and only then, do we search the most recent 15 minutes of user traffic on that specific port, in order to determine if a user has consumed more that 70% of their provisioned speed for greater than 15 minutes. By provisioned speed, we mean the "up to" or "burst to" speed of their service tier. This is typically something like (1) 8Mbps downstream / 2Mbps upstream or (2) 6Mbps downstream / 1Mbps upstream
So how does this work in action? Let's say that a downstream port has been at 85% utilization for more than 15 minutes. That specific downstream port is identified as being in a Near Congestion State since it exceeded an average of 80% over that time. We then look at the downstream usage of the ~275 cable modems using that downstream port. That port has a mix of users that have been provisioned either 8Mbps or 6Mbps, so 70% of their provisioned speed would be either 5.6Mbps or 4.2Mbps, respectively. So let's use the example of a user with 8Mbps/2Mbps service on this port. In order for their traffic to be marked with a lower priority on this downstream port, they must be consuming 5.6Mbps in the downstream direction for 15 minutes or more, while said port is highly utilized
Once that condition has been met, that user's downstream traffic is now tagged with the lower priority QoS level. This will have *no* effect whatsoever on the traffic of that user, until such time as an actual congestion moment subsequently occurs (IF it even occurs). Should congestion subsequently occur, traffic with a higher priority is handled first, followed by lower priority (and this is not a throttle to X speed)
I hope this helps. You can others can feel free to contact me directly if you have any questions Regards Jason Livingood
- Engineering & Technical Operation
For verification, you can find the original in the IP Archives. Date of the email is 2008-09-24 12:37:35
I've been running my own mail server for over a decade now, using a DSL connection and a Linux box thrown together from spare parts for most of that time. (I finally bought a cheap refurbished rack server a few months back, but that certainly isn't a requirement.) I ran QMail for several years but have been running Exim for the last three or four. I use Debian but setup of a mail server is trivial on any modern distro for anyone with a geek bent. I don't have hard records but would estimate that my downtime averages a few hours a year. You need an ISP that allows you to run services. I used Speakeasy for awhile but they aren't available where I'm now living, so I use a small local ISP.
That seems accurate to me. After all, what happens when a DNS record gets updated? With the new behavior, you won't see the change until your cached record expires. That may be preferable to a gaping security hole which lets attackers poison your cache, but I don't think it's accurate to call the issue a bug in BIND. I believe BIND was working as intended to allow updated records to overwrite older ones.
I am not and was not defending IPv6. I'm no more fond of it than you are. I was pointing out that your solution has serious performance implications, and you've said nothing to alter my opinion.
The question of routers versus layer three switches is irrelevant. Putting the opcodes into hardware rather than software isn't going to change the fundamental issue. With IP addresses falling on a base 2 boundary, many of the most common operations are a simple AND of two numbers. That's one clock for most processors. You're masking bits. Arithmetic operations, on the other hand, require several clock cycles. Hardware doesn't change that.
And an IP stack on a computer is one thing. The difference may or may not be insignificant there. But network operations are another matter entirely. And I can guarandamntee you that the difference won't be insignificant there.
From an IP stack development perspective, the only complication I see with this method is that IPv4 functioned so nicely since he subnet landed on a base-2 boundary. by placing it on a base-10 boundary instead, it would require an arithmetic comparison vs a binary comparison.
That's the only complication, huh? If you've really implemented IP stacks, you should understand the difference between those two in terms of processor clock cycles. Think in terms of, say, a router trying to match an access list to traffic on a gigabit link at wire speed. That "only complication" just slowed your entire network to a crawl.
Well that whole 640k thing with regard to IP addresses has been largely negated by the adoption of routers within the home.
Uh, what? If anything, routers by themselves increase the need for IP addresses since they increase the number of subnets, and the more subnets you have the more inefficiently you're using your address space.(1) I suspect that you're talking about the use of NAT (Network Address Translation), which allows you to use private IP space behind your router but still reach the public Internet.
(1)Inefficient in terms of total number of host IPs available. More subnets are more efficient in that they can often reduce waste in terms of unused addresses.
It might be safe but unless you're quite knowledgeable about encryption, gut feelings about what seems safe aren't very reliable. I still suspect that doing this opens up more areas of attack. Note that I'm making no claims of expertise, so I don't KNOW this to be the case. I'm just saying that I'd be leery.
I haven't read the page in detail but this appears to be a tutorial on using rsync over ssh. That would encrypt the transmission but it wouldn't result in an encrypted file on the other end. Am I missing something?
Interesting. Things like this are why I always hedge my bets and say things like "...unless there's some capabilities that I'm not aware of, rsync has no encryption capabilities..."
That being said, I'd be extremely leery of this program. The website says: "Rsyncrypto does, however, do one thing differently. It changes the encryption schema from plain CBC to a slightly modified version. This modification ensures that two almost identical files, such as the same file before an after a change, when encrypted using rsyncrypto and the same key, will produce almost identical encrypted files." I'm far from an expert at crypto but I know enough to be extremly suspicious of that claim. A "slight change" in an encryption algorithm can be enough to transform an algorithm from highly secure to trivially crackable. And I strongly suspect that making similar files produce similar encrypted files means that there's a great deal of info about the unencrypted file suddenly available from examining the encrypted file. I wouldn't trust this without extensive review from some heavy weights in the crypto field.
I can't speak for this guy, but there are times when I want to access stuff from my work computer or someone else's computer, where I'm not authorized to install software and have no control over the OS.
Nowhere do I see that it only needs to work on one home computer. He just specifies "from my local computer to a non-trusted FTP site."
The real problem is not knowing about rsync since it's designed for exactly his problem.
No, rsync isn't a very good solution for a couple of reasons. First, unless there's some capabilities that I'm not aware of, rsync has no encryption capabilities. Given an unencrypted file tree and an encrypted version of the file tree, rsync has no way to compare the two for changes. The only solution to that which I see is to maintain a local encrypted mirror of your file tree. So then you need twice as much space, since you're maintaining two local file trees, and you need a tool to update automatically sync the local file tree and the local encrypted version of the file tree. If you have that tool, then it may work or be hacked to work with a remote file tree, completely removing the need for rsync. Even supposing that you found a tool to do that which won't work with a remote file tree, you're nullifying the primary advantage of rsync.
rsync is designed to do incremental updates. If you have a text file and change one word, rsync doesn't transfer the whole file. It only sends enough info to correctly update the remote file so that it matches the new local file. (Or vice versa, of course.) But when you change a single word and reencrypt a text file, the whole file changes. So rsync will have to transfer the whole file. So will any other solution, of course, but it does mean that rsync loses much of the capability which makes it so valuable.
You could do something like unencrypt the local file tree mirror, rsync with the working file tree, reencrypt the file tree and then rsync the local encrypted tree with the remote encrypted tree mirror, but that's a lot of work and processing power and hardly matches the clean, integrated solution that the article is asking for. It's probably more cumbersome than whatever it is he's doing now.
The problem is FTP. It is an old deprecated protocol that is inherently insecure and even FTP w/ SSL is simply a work around to a broken problem.
Wow. It might be better to understand the problem before you make suggestions. FTP isn't the problem. FTP is just a way to move files from here to there. It's unsecured and untrusted but, in this case, SO IS THE REPOSITORY. Exactly what benefit do you get from using SSH to securely transfer files to an unsecure location? That's like using an armored truck to move your valuables to the QuickStorage down the road. What's wanted is an automated way to encrypt the files locally, then transfer the encrypted files to an untrusted site. If the files are encrypted, then it doesn't matter that FTP is unsecured.
I'm assuming that the point is to make sure that people who search for your name (from a perspective boss to a perspective boy/girlfriend) can find the truth. You can also add a note pointing out that a scummy site has falsely used your name.
In my case, I really don't need that much horsepower, although it's nice when I decide to recompile my kernel.:-) But these were about the cheapest rackmount servers I could find. If I could have picked up something with half the power for half the price, I'd have done it but there's nothing out there I could find.
Slashdot Mirror
Actually, he didn't say the piracy was affecting his bottom line. He simply said it wasn't helping sales. Was that accidental or intentional? I strongly suspect that the piracy isn't hurting sells either, which means the answer to his question is "nothing." If he can post data which shows that sales are dropping and that those dropped sales don't correlate to, say, his book being replaced by a newer textbook in university courses, then I'll reconsider.
What you're talking about is called split tunneling. There is some security risk with allowing split tunneling, although it's not "...horrifically broken and insecure..." as you suggest, particularly if you require the client to have a local firewall before you bring up the VPN. (Decent VPN software will allow this.) The problem with not allowing split tunneling is that it greatly increases the load on your network, since all traffic is routed through you before going to the client, and that you break lots of things for the VPN'd user. For example, if I"m VPN'd and split tunneling is disallowed, I can't use a local network printer until I break the VPN.
Like every other situation, there is a trade off between security and functionality. Increasing security decreases functionality and vice versa. Whether or not it makes sense to allow split tunneling is greatly dependent upon the situation.
The CNN article commenting on the proposed bill says:
Another example: Web browsers could also be regulated and subject to Federal Trade Commission enforcement action unless "informed consent" is obtained each time the desktop icon is double-clicked. (Every Web browser allows the user to "designate" files to be uploaded--ever post a photo?--and request that files be downloaded.)
This appears to be covering things like uploading a photo or downloading a program to install. That doesn't even cover the half of it. What happens when you visit a web page? Your browser sends a GET request and downloads the file - it copies a file from the server to your computer. If the page is not static, of course, the file is generated on the fly by scripts. But if that isn't covered, then I'll simply code my P2P app to ROT13 all files. When you download it, a script reads it and generates the stream that's transferred to you. I'm no longer copying a file, so the law doesn't apply to me.
What happens when you visit many, many websites? They read your cookies. The cookie is a file on your computer. It's transferred from your computer to their server. What happens when you download your email, particularly if you're accessing a 'Nix based mail server where mail is stored in mbox or mailbox format? What happens when you open a file with your Word processor on a remote share? In short, what happens almost any time you do anything on a networked computer? Is every application you run going to have to nag you to death every time you open it?
This is so ludicrous that not even Congress could pass it.
It isn't clear to me why this is a failure, or a negative result if you prefer. Granted, the carbon didn't sink to the bottom of the ocean, but it was still removed from the water, which should allow the water to absorb additional CO2 from the air. It seems to me that, so long as the CO2 is pulled from the atmosphere, it's still an effective means of combating warming. Isn't one of the proposed remedies to increase the plant mass? Why isn't this just as effective as increased plants? What am I missing?
Right. There's no way to open up a phone and, say, cut the wires to the speaker or stuff cotton in the device...
All of the other examples you list - from messengers to telegraph to satcom - are technologies. The government's use of these technologies doesn't impact other uses of them in any way. The Internet, on the other hand, is a particular implementation of a technology. If the military wants to use TCP/IP as a military asset, few people would have any problem with that. But the ability to protect something necessarily means having at least some control over it. It means the ability to take action against anything interpreted as a threat, and the military/government definition of "threat" can be quite broad and quite self serving. (Go through airport security if you'd like to get an idea of how the government thinks security ought to be implemented.) So if the military wants to claim the Internet as a military asset, then I have a big issue with that. And I'm speaking as someone who is drawing a retirement pension from the US military.
Frankly, I don't see a set dividing line....? Nothing is really centered.
You just use the wrong keyboard.
Doesn't this suggest an obvious solution to CAPTCHA? Just use cursive text rather than try to obscure the text with funky backgrounds. If the spammers do manage to crack the CAPTCHA, then incorporate their technology into mainstream OCR programs.
Lots of mainstream media sources provide "personal comments." They're called editorials. And yes, I damned sure do see a meaningful distinction between what's said in an article and what's said in an editorial. And yes, if an article is immediately followed by an editorial which is clearly labeled as an editorial, then I see a huge difference there too.
If you think there's no difference in putting editorial comment in an article and in a personal comment attached to the article, you must work for Fox News.
Here's an email from one of Comcast's engineers recently sent to Dave Farber's Interesting People mailing list. It clarifies the policy quite well:
From: "Livingood, Jason"
Subject: Clarifying Misconceptions of the New Comcast Congestion Mgmt Syste
Hi Dave
I wanted to try to clear up a misconception about how the new Comcast congestion management system works. I believe we have both heard people complain that they fear that they will be unable to use their provisioned speeds during off-peak hours, for example, or at all times of the day, or that users are somehow throttled to a set speed. Neither of these two things are correct. Part of the problem appears to be confusion over how a user's traffic enters a lower priority QoS state, so I hope to clarify that here
In order for any traffic to be placed in a lower priority state, there must first be relatively high utilization on a given CMTS port. A CMTS port is an upstream or downstream link, or interface, on the CMTS in our network. The CMTS is basically an access network router, with HFC interfaces on the subscriber side, and GigE interfaces on the WAN/Internet side. Today, on average, about 275 cable modems share the same downstream port, and about 100 cable modems share the same upstream port (see page 5 of Attachment B of our Future Practices filing with the FCC, available at http://downloads.comcast.net/docs/Attachment_B_Future_Practices.pdf). We define a utilization threshold for downstream and upstream separately. For downstream traffic, a port must average over 80% utilization for 15 minutes or more. For upstream traffic, a port must average over 70% utilization for 15 minutes or more
When one of these threshold conditions has been met, we consider that individual port (not all ports on the CMTS) to be in a so-called Near Congestion State. This simply means that the pattern of usage is predictive of that network port approaching a point of high utilization, where congestion could soon occur. Then, and only then, do we search the most recent 15 minutes of user traffic on that specific port, in order to determine if a user has consumed more that 70% of their provisioned speed for greater than 15 minutes. By provisioned speed, we mean the "up to" or "burst to" speed of their service tier. This is typically something like (1) 8Mbps downstream / 2Mbps upstream or (2) 6Mbps downstream / 1Mbps upstream
So how does this work in action? Let's say that a downstream port has been at 85% utilization for more than 15 minutes. That specific downstream port is identified as being in a Near Congestion State since it exceeded an average of 80% over that time. We then look at the downstream usage of the ~275 cable modems using that downstream port. That port has a mix of users that have been provisioned either 8Mbps or 6Mbps, so 70% of their provisioned speed would be either 5.6Mbps or 4.2Mbps, respectively. So let's use the example of a user with 8Mbps/2Mbps service on this port. In order for their traffic to be marked with a lower priority on this downstream port, they must be consuming 5.6Mbps in the downstream direction for 15 minutes or more, while said port is highly utilized
Once that condition has been met, that user's downstream traffic is now tagged with the lower priority QoS level. This will have *no* effect whatsoever on the traffic of that user, until such time as an actual congestion moment subsequently occurs (IF it even occurs). Should congestion subsequently occur, traffic with a higher priority is handled first, followed by lower priority (and this is not a throttle to X speed)
I hope this helps. You can others can feel free to contact me directly if you have any questions
Regards
Jason Livingood
- Engineering & Technical Operation
For verification, you can find the original in the IP Archives. Date of the email is 2008-09-24 12:37:35
I've been running my own mail server for over a decade now, using a DSL connection and a Linux box thrown together from spare parts for most of that time. (I finally bought a cheap refurbished rack server a few months back, but that certainly isn't a requirement.) I ran QMail for several years but have been running Exim for the last three or four. I use Debian but setup of a mail server is trivial on any modern distro for anyone with a geek bent. I don't have hard records but would estimate that my downtime averages a few hours a year. You need an ISP that allows you to run services. I used Speakeasy for awhile but they aren't available where I'm now living, so I use a small local ISP.
That seems accurate to me. After all, what happens when a DNS record gets updated? With the new behavior, you won't see the change until your cached record expires. That may be preferable to a gaping security hole which lets attackers poison your cache, but I don't think it's accurate to call the issue a bug in BIND. I believe BIND was working as intended to allow updated records to overwrite older ones.
I am not and was not defending IPv6. I'm no more fond of it than you are. I was pointing out that your solution has serious performance implications, and you've said nothing to alter my opinion.
The question of routers versus layer three switches is irrelevant. Putting the opcodes into hardware rather than software isn't going to change the fundamental issue. With IP addresses falling on a base 2 boundary, many of the most common operations are a simple AND of two numbers. That's one clock for most processors. You're masking bits. Arithmetic operations, on the other hand, require several clock cycles. Hardware doesn't change that.
And an IP stack on a computer is one thing. The difference may or may not be insignificant there. But network operations are another matter entirely. And I can guarandamntee you that the difference won't be insignificant there.
From an IP stack development perspective, the only complication I see with this method is that IPv4 functioned so nicely since he subnet landed on a base-2 boundary. by placing it on a base-10 boundary instead, it would require an arithmetic comparison vs a binary comparison.
That's the only complication, huh? If you've really implemented IP stacks, you should understand the difference between those two in terms of processor clock cycles. Think in terms of, say, a router trying to match an access list to traffic on a gigabit link at wire speed. That "only complication" just slowed your entire network to a crawl.
Well that whole 640k thing with regard to IP addresses has been largely negated by the adoption of routers within the home.
Uh, what? If anything, routers by themselves increase the need for IP addresses since they increase the number of subnets, and the more subnets you have the more inefficiently you're using your address space.(1) I suspect that you're talking about the use of NAT (Network Address Translation), which allows you to use private IP space behind your router but still reach the public Internet.
(1)Inefficient in terms of total number of host IPs available. More subnets are more efficient in that they can often reduce waste in terms of unused addresses.
It might be safe but unless you're quite knowledgeable about encryption, gut feelings about what seems safe aren't very reliable. I still suspect that doing this opens up more areas of attack. Note that I'm making no claims of expertise, so I don't KNOW this to be the case. I'm just saying that I'd be leery.
I haven't read the page in detail but this appears to be a tutorial on using rsync over ssh. That would encrypt the transmission but it wouldn't result in an encrypted file on the other end. Am I missing something?
Interesting. Things like this are why I always hedge my bets and say things like "...unless there's some capabilities that I'm not aware of, rsync has no encryption capabilities..."
That being said, I'd be extremely leery of this program. The website says: "Rsyncrypto does, however, do one thing differently. It changes the encryption schema from plain CBC to a slightly modified version. This modification ensures that two almost identical files, such as the same file before an after a change, when encrypted using rsyncrypto and the same key, will produce almost identical encrypted files." I'm far from an expert at crypto but I know enough to be extremly suspicious of that claim. A "slight change" in an encryption algorithm can be enough to transform an algorithm from highly secure to trivially crackable. And I strongly suspect that making similar files produce similar encrypted files means that there's a great deal of info about the unencrypted file suddenly available from examining the encrypted file. I wouldn't trust this without extensive review from some heavy weights in the crypto field.
I can't speak for this guy, but there are times when I want to access stuff from my work computer or someone else's computer, where I'm not authorized to install software and have no control over the OS.
Nowhere do I see that it only needs to work on one home computer. He just specifies "from my local computer to a non-trusted FTP site."
The real problem is not knowing about rsync since it's designed for exactly his problem.
No, rsync isn't a very good solution for a couple of reasons. First, unless there's some capabilities that I'm not aware of, rsync has no encryption capabilities. Given an unencrypted file tree and an encrypted version of the file tree, rsync has no way to compare the two for changes. The only solution to that which I see is to maintain a local encrypted mirror of your file tree. So then you need twice as much space, since you're maintaining two local file trees, and you need a tool to update automatically sync the local file tree and the local encrypted version of the file tree. If you have that tool, then it may work or be hacked to work with a remote file tree, completely removing the need for rsync. Even supposing that you found a tool to do that which won't work with a remote file tree, you're nullifying the primary advantage of rsync.
rsync is designed to do incremental updates. If you have a text file and change one word, rsync doesn't transfer the whole file. It only sends enough info to correctly update the remote file so that it matches the new local file. (Or vice versa, of course.) But when you change a single word and reencrypt a text file, the whole file changes. So rsync will have to transfer the whole file. So will any other solution, of course, but it does mean that rsync loses much of the capability which makes it so valuable.
You could do something like unencrypt the local file tree mirror, rsync with the working file tree, reencrypt the file tree and then rsync the local encrypted tree with the remote encrypted tree mirror, but that's a lot of work and processing power and hardly matches the clean, integrated solution that the article is asking for. It's probably more cumbersome than whatever it is he's doing now.
The problem is FTP. It is an old deprecated protocol that is inherently insecure and even FTP w/ SSL is simply a work around to a broken problem.
Wow. It might be better to understand the problem before you make suggestions. FTP isn't the problem. FTP is just a way to move files from here to there. It's unsecured and untrusted but, in this case, SO IS THE REPOSITORY. Exactly what benefit do you get from using SSH to securely transfer files to an unsecure location? That's like using an armored truck to move your valuables to the QuickStorage down the road. What's wanted is an automated way to encrypt the files locally, then transfer the encrypted files to an untrusted site. If the files are encrypted, then it doesn't matter that FTP is unsecured.
Go ask Alice. I think she'll know.
Well, we are talking about QM, where logic and proportion do indeed fall sloppily dead...
I'm assuming that the point is to make sure that people who search for your name (from a perspective boss to a perspective boy/girlfriend) can find the truth. You can also add a note pointing out that a scummy site has falsely used your name.
In my case, I really don't need that much horsepower, although it's nice when I decide to recompile my kernel. :-) But these were about the cheapest rackmount servers I could find. If I could have picked up something with half the power for half the price, I'd have done it but there's nothing out there I could find.