Why would you limit yourself to ssh, when there's so many useful unpatched exploits for so many other server applications? Among other things, you're missing out on all the easily exploitable Windows ME boxen out there.
ssh defaults to port 22. Port 23 is usually telnet.
1) Clock drift in excess of a minute per day is not unheard-of.
I don't think I have ever seen numbers that high myself, but if needed, the time_diff could be recalculated more often. If the page notice a large clock drift between two calculations of the diff, it could schedule the next recalculation to occur sooner.
2) If the AJAX request fails, what do you do?
For the first calculation of the diff, you don't really need to use AJAX since the page already includes the server time in the "clock"-element. If a later AJAX-request fails, you could simply reuse the old diff and schedule a new calculation at a much sooner time that otherwise.
3) If the AJAX request hits a high asymmetric delay (not unheard-of), you'll be off by a good fraction of a minute.
You're right, I don't have a good solution for that problem. Maybe take a look at how NTP deals with it.
4) If the user can't set their computer's clock, what makes you think they can set the computer's timezone?
I don't think I said anything about the user setting the timezone anywhere, so I fail to see your point.
I did mention the "Europe/London"-timezone, but that timezone would be set by the BBC site, not the user.
5) Related to 4, what happens during a daylight savings time shift? You can't count on the local clock changing by an hour, but you also can't count on it *not* changing.
What daylight savings time? There's a reason why I'm using milliseconds since Epoch.
If you know the time in milliseconds since Epoch and you know when the transition between standard time and daylight savings occur (or any other change of offset from UTC), you can calculate the local time. You can find the transition times and offsets in the tzdatabase and do the calculation yourself or you can use the tzdata-javascript library I mentioned.
What the BBC said was that they would find it difficult and expensive to accurately show the time at the user's location, when the user's time settings were wrong.
This is roughly how I would do it:
Make sure the server is running NTP or something similar, so the server time is correct.
When the page is requested, include the current server time: <span id="clock">Thu Jun 6 11:29:04 BST 2013</span>.
If JavaScript is off, we can't update the time and all we can do is display that static time.
If JavaScript is on, we:
Find the HTML-element: var clock=document.getElementById("clock");
Get the current local time as milliseconds since Epoch: var local_time_1=new Date().valueOf();
Use AJAX to get the current server time as milliseconds since Epoch, server_time.
Get the current local time as milliseconds since Epoch, local_time_2.
Assuming that the delay from the client to the server is the same as the delay from the server to the client, calculate the difference between server time (correct time) and local time: var time_diff=server_time - (local_time_1+local_time_2)/2;
Every second, minute, whatever...
Get the current local time as milliseconds since Epoch, local_time.
Calculate the assumed server time: var assumed_time=local_time + time_diff;
Update the HTML-element to display the assumed_time in some "pretty" format.
If you don't want to display the time in either UTC or "whatever timezone the user has configured", use something like (shameless plug) tzdata-javascript to convert it "Europe/London".
Maybe recalculate time_diff every hour to avoid time drifting. I highly doubt this is needed.
Who the American Idol winner is has no real effect on my life, whereas my local city council does when they decide whether to put money into repairing nearby streets or changing the zoning to accommodate a CVS in my neighborhood.
Your local council decides that? Weird...
When I wanted to have a version control system, I just installed one. I didn't have to get permission from anyone.
The patient link is static and can never change, so a QR is appropriate.
Yes, cause there's no such thing as areas without coverage, network errors, database failures,...
And in case of large scale emergencies, the cellular network would never fail. NEVER!
The common::sense people claim it uses less memory than the combo, I'm currently using (mainly use strict; use warnings;), so I'm considering switching.
If anyone has any input about use common::sense; vs. use strict; use warnings;, I would like to hear it.
TFA says the pictures take ~30 minutes each, so that's the only thing that makes sense to me.
TFA says...
The satellite takes a full image of Earth from its stationary point over 35,000 kilometers above the Indian Ocean every 30 minutes, providing the material for the video below.
It doesn't say anything about shutter speed/exposure time or how long it takes to transfer a single image back to Earth.
It only says "wait 30 minutes between taking a picture".
Let me demonstrate the difference with some examples.
First a normal ssh connection to a new host. Without VerifyHostKeyDNS it doesn't matter if your SSHFP records are up-to-date, since they won't be checked.
$ ssh login@example.com
The authenticity of host 'example.com (127.0.0.1)' can't be established.
RSA key fingerprint is 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
Are you sure you want to continue connecting (yes/no)?
With "VerifyHostKeyDNS yes" and up-to-date SSHFP records, it looks like this instead. Note the extra line of output.
$ ssh -o "VerifyHostKeyDNS yes" login@example.com
The authenticity of host 'example.com (127.0.0.1)' can't be established.
RSA key fingerprint is 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
And this is what you get, if the SSHFP record ain't up-to-date:
$ ssh -o "VerifyHostKeyDNS yes" login@example.com
[Cut long line of @'s. Too many 'junk' characters for/.]
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
[Cut long line of @'s]
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
Please contact your system administrator.
Update the SSHFP RR in DNS with the new host key to get rid of this message.
The authenticity of host 'example.com (127.0.0.1)' can't be established.
RSA key fingerprint is 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
Compare that with the first case where you had absolutely no idea if the fingerprint was correct or not.
I'm not saying, you should just trust all SSHFP records, if you're paranoid. But even if you ain't paranoid, the warning about the mismatching SSHFP record should be enough to make you stop and think instead of just saying yes.
Slashdot Mirror
To me "Internet" means "freedom of information"
To me "The Internet" is a series of tubes... Or a dump truck.
Why would you limit yourself to ssh, when there's so many useful unpatched exploits for so many other server applications? Among other things, you're missing out on all the easily exploitable Windows ME boxen out there.
ssh defaults to port 22. Port 23 is usually telnet.
For those who missed the reference and didn't click the links, this is a reference to Fahrenheit 451.
Anyone who didn't get the references need to: Go back to highschool chemistry, and read more books.
We can't!
1) Clock drift in excess of a minute per day is not unheard-of.
I don't think I have ever seen numbers that high myself, but if needed, the time_diff could be recalculated more often. If the page notice a large clock drift between two calculations of the diff, it could schedule the next recalculation to occur sooner.
2) If the AJAX request fails, what do you do?
For the first calculation of the diff, you don't really need to use AJAX since the page already includes the server time in the "clock"-element. If a later AJAX-request fails, you could simply reuse the old diff and schedule a new calculation at a much sooner time that otherwise.
3) If the AJAX request hits a high asymmetric delay (not unheard-of), you'll be off by a good fraction of a minute.
You're right, I don't have a good solution for that problem. Maybe take a look at how NTP deals with it.
4) If the user can't set their computer's clock, what makes you think they can set the computer's timezone?
I don't think I said anything about the user setting the timezone anywhere, so I fail to see your point.
I did mention the "Europe/London"-timezone, but that timezone would be set by the BBC site, not the user.
5) Related to 4, what happens during a daylight savings time shift? You can't count on the local clock changing by an hour, but you also can't count on it *not* changing.
What daylight savings time? There's a reason why I'm using milliseconds since Epoch.
If you know the time in milliseconds since Epoch and you know when the transition between standard time and daylight savings occur (or any other change of offset from UTC), you can calculate the local time. You can find the transition times and offsets in the tzdatabase and do the calculation yourself or you can use the tzdata-javascript library I mentioned.
You can use local time as an estimate of the time zone, since time zones are only in 30 minute or an hour increments.
Or 15 minutes...
$ date -u ; TZ=Pacific/Chatham date
Thu Jun 6 22:54:10 UTC 2013
Fri Jun 7 11:39:10 CHAST 2013
What the BBC said was that they would find it difficult and expensive to accurately show the time at the user's location, when the user's time settings were wrong.
This is roughly how I would do it:
Wouldn't that work?
Who the American Idol winner is has no real effect on my life, whereas my local city council does when they decide whether to put money into repairing nearby streets or changing the zoning to accommodate a CVS in my neighborhood.
Your local council decides that? Weird...
When I wanted to have a version control system, I just installed one. I didn't have to get permission from anyone.
What can perl do that newer languages such as python and ruby can't do, and do more readably/maintainably?
use common::sense;
Well, this guy MAY actually have something.
Or maybe the page has a hidden image loaded from a webserver running on localhost. The webserver is configured to start putty when someone connects...
I did something like that 15+ years ago, so it's nothing new at all.
...coming back? Just my luck that the first year I entered it, it died... :P
You killed it! Damn you and your underhanded C code!
No, it's finally P.
Is that the same as NP?
If only we had them operational 776 years ago.
I think, you mean 775 AD, 1237 years ago.
plus he doesn't want the remote copy deleted if the local copy is, and unison and rsync both do that by default.
Remote deletion of files is NOT default in rsync. You have to use --delete if you want that.
...time to grab my towel.
You're late. Towel Day was last Friday.
The patient link is static and can never change, so a QR is appropriate.
Yes, cause there's no such thing as areas without coverage, network errors, database failures, ...
And in case of large scale emergencies, the cellular network would never fail. NEVER!
I'll take plain text, thank you very much!
The common::sense people claim it uses less memory than the combo, I'm currently using (mainly use strict; use warnings;), so I'm considering switching.
If anyone has any input about use common::sense; vs. use strict; use warnings;, I would like to hear it.
What's *really scary* is a perl script with '#use strict;'. Meaning they tried to use strict; but gave up on it.
Did they use common::sense; instead?
and it looks like Parrot was dropped.
Nah, he's only resting...
TFA says the pictures take ~30 minutes each, so that's the only thing that makes sense to me.
TFA says...
The satellite takes a full image of Earth from its stationary point over 35,000 kilometers above the Indian Ocean every 30 minutes, providing the material for the video below.
It doesn't say anything about shutter speed/exposure time or how long it takes to transfer a single image back to Earth.
It only says "wait 30 minutes between taking a picture".
Back in my day hashtags had to do with IRC!
You must be new here.
# clearly has to do with the C preprocessor.
Or it indicates that you're logged in as root.
Or that you're about to start a nice game of Tic-Tac-Toe to stop the game of Global Thermonuclear War on the WOPR.
Or all of the above...
just use port 4000 twice. It's all binary.
4000 ain't binary. It's at least base 5.
That's not the only bad math. This is RIDDLED with bat math.
Holy hole in the doughnut, Batman! The Riddler is at it again!
Indeed. It's 1MB of RAM, in fact.
Actually, it's 1Mb.
65536 * 16 bits = 1Mbit = 128KByte
Let me demonstrate the difference with some examples.
First a normal ssh connection to a new host. Without VerifyHostKeyDNS it doesn't matter if your SSHFP records are up-to-date, since they won't be checked.
$ ssh login@example.com
The authenticity of host 'example.com (127.0.0.1)' can't be established.
RSA key fingerprint is 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
Are you sure you want to continue connecting (yes/no)?
With "VerifyHostKeyDNS yes" and up-to-date SSHFP records, it looks like this instead. Note the extra line of output.
$ ssh -o "VerifyHostKeyDNS yes" login@example.com
The authenticity of host 'example.com (127.0.0.1)' can't be established.
RSA key fingerprint is 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
And this is what you get, if the SSHFP record ain't up-to-date:
$ ssh -o "VerifyHostKeyDNS yes" login@example.com /.]
[Cut long line of @'s. Too many 'junk' characters for
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
[Cut long line of @'s]
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
Please contact your system administrator.
Update the SSHFP RR in DNS with the new host key to get rid of this message.
The authenticity of host 'example.com (127.0.0.1)' can't be established.
RSA key fingerprint is 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
Compare that with the first case where you had absolutely no idea if the fingerprint was correct or not.
I'm not saying, you should just trust all SSHFP records, if you're paranoid. But even if you ain't paranoid, the warning about the mismatching SSHFP record should be enough to make you stop and think instead of just saying yes.
Add the output to your DNS and set VerifyHostKeyDNS to "yes" or "ask" in your ssh_config.
Remember to update your DNS if/when your machine gets a new SSH hostkey.