Slashdot Mirror

Dan is the man in DNS. He pretty much explains why they don't have implementation here:

http://cr.yp.to/djbdns/forgery.html

You might not like Dan, but he doesn't get things wrong very often.

I will tell you why I don't register, I can't think of a good nickname, as I don't have a good nickname, I don't have a name (domain name) for a domain name, as I don't have a domain name, I don't have a place from my email. And registering needs an email address, and before anyone suggestions my real name some morons took it and has been holding onto it for a few years already.

Also I have another problem with email, by email they normally mean the SMTP protocol, well sorry to tell you there are other better mail protocols such as Internet Mail 2000, which happen to handle mail a bit smarter, this is a real solution to finish off phishing emails, as the wont be possible, not to say it will mean a real slow down in the amount of spam.

"You'd still wind up dealing with typo squatters like this guy. The Usenet example is a good point though and I tip my hat to you on that one.

In any case, I wish people would wait and see what happens rather then using it as an issue to further divide the World over. If DoC or the US Government actually blocks it then you'll have a point. Right now it looks like are they doing is slowing it down to allow more time for comment."

I'm not willing to throw the baby out with the bathwater; theres always be people that have, uh, a different vision of what a domain name is for. In general terms I think having lots of tlds and lots of domains will lessen then to it's boring and not a big deal. Not my idea, that was Postel's, but I think he's right about this.

As for allowing time for comments, that's ICANN-ese for "we have no other optins so we'll form a committee to look at it". The Bush administration bitch-slapped them and they're trying to get other governments to put pressure on the US.

Cause, you know, that works so well.

Morons. The thing has been slowed down for 10 years. The ICANNauts always bragged thge DoC rubber stamps anything they pass up to them.

Now perhaps they get it. It's not like this wasn't pointed out them a decade ago.

Once more with feeling:

      http://cr.yp.to/dnsroot.html

"Who said the US was attempting to do any such thing? Because the US Commence Department asked for more time to hear objections?"

Let's look at what actually happened:

A religous organization that had the ear of George Bush walked into Carl Rove's office. They had a shopping list of three things, 1) stem cell research, 2) same-sex marriages 3) .XXX

Rove went "Uh, about that third one, lemme make a phone call" and .xxx was shitcanned. Note the DOC has a new administrator. I would not expect .xxx to be in the lagacy root under a Bush administration.

And that, ladies and germs is what's wrong with the technical adminstration of names and numbers in the TCP/IP protocol suite. We've hit the seventh layer of the protocol stack - the political layer - and the ooze, scum and congealed evil is dribbling down into the lower layers and making a mess.

A large and well funded ICANN makes noise. .xxx could have been deployed years ago (modulo some testicular augmention the ICANN board lacks, they could use them on the rare occasions they're awake)

Is this the 3 or 4 guys operating in the light that used to do the very job icann does now? And for $15,000/yr as a part time task, not as a $15+M boondoggle? No. Instead there's physical meetings, bars, 5 star hotels, hookers and enough booze to fill a football stadium. Oh, and it's never 4:20 at an ICANN meeting, these boys are old school. A map of ICANN meeting locations reads like a book of the great beers of the world.

So no, this is not the online sythesis of ideas among the worlds brightest technologists to solve technical problems associated with adinistration of names and numbers. It's a slow moving government sponsored toga party parody of itself. It's face to face, real world, behind closed doors where people who know nothing, do nothing modulo the occasional very expensive press release.

Ironically ICANN was created to give legal personality to IANA - that had none, it couldn't sign anything. Imagine if Jon Postel were alive today: he would get nothing done with ICANN in the picture.

If you primary the root for yourself you're immune to this nonsense and other minor annoyences like the legacy root servers dropping packets.

http://cr.yp.to/dnsroot.html

Actually, using CDB is probably a better idea, and why programs like DJB's tinydns are so fast and reliable. You built a flat file with your data, compile it to a database atomically and depend on the OS' read cache to optimize performance when reading indexed records back.

Light-weight and extremely fast for read-only operations.

You can't do semi-complex queries against it mind you.

As someone else has mentioned, the ars system guides are excellent. They build several different types of system and explain the trade-offs they make very nicely.

I also happen to really like Dan Bernstein's advice, especially for a good *BSD desktop box. Like Ars, Dan does an excellent job explaining why he chose what he did.

The ars guides are usually almost current. DJB's is not as current. But look at them for the explanations, even if you want newer components. You can apply their advice to the in depth discussions of particular components you'll find at places like Tom's, HardOCP, AnandTech, etc.

Yes just say it Linux sucks, computers suck, da intraweb sucks....

Time for an exokernel already! Linux is not as good as everyone thinks it is... but its sure better than anything else we have right now that is usable... and if you want my opinion GNU sucks. I really wished someone that could do things correctly like djb would start their own OS.

There are only a dozen people in this generation that can do things correctly in the computer world, and djb happens to be one of them.

Prof. D. J. Bernstein has an excellent summary of why he is
not changing his programs to use IPv6.

      http://cr.yp.to/djbdns/ipv6mess.html

Basically, IPv6 is *not* compatible with IPv4, it requires a
whole new parallel system *everywhere* so it will never happen.

The IPv6 mess (according to D J Bernstein).

In 1998 I was in the office of the CTO of the company than ran the A-root. At the time they were not getting along with ICANN. They wanted to sell domain names in any tld they could and didn't see anybody else being able to handle running a 30+ M name com zone file. Other than that they didn't care what happens.

The goverment, IBM and ICANN were exerting pressure on them to sign an agreement with ICANN which placed them under ICANN's aegis. Up to this point they had nothing to do with them.

It was feared NSI would "go rouge" and I guess it's ok to say now that there were root servers at NSI that did not carry just the legacy root. Only a handfull of people knew about these but they were a beautiful thing to run dig or dnsq against.

If there was no accord reached with ICANN and NSI was effectivly out of the business it built then one scanario was they'd just keep going and ignore the USG and ICANN and expand the root zone. They owned the IP's the root servers ran on in more than enough cases.

I asked what would happen if they did this before a fallout with ICANN occurred and was told the a.root would be declared a national security resource and the Army would simply come in and run it so don't even think that. Since this CTO used to be in Army intel. I figured he had a good understanding of this. IBM coerced NSI to sign with ICANN (at the famous secret meeting nobody can talk about because of an IBM NDA) and this stuff was all dropped very quickly.

But the lesson is there: the DNS is whatever the US wants it to be, period.

If you rely on somebody else to tell you where the .com nameservers are then you are vulnerbale to games like this. Administration of a net of network numbers so we can find computers on the network is not supposed to leak into the political layers of the TCP/IP stack. Mercifully there's a software patch for this.

Primary the root instead http://cr.yp.to/dnsroot.html

IPv6 is great, but what we have deployed in the internet is IPv4 and we cannot magically switch to v6. What is needed is a transition plan. But we have no good plan now.

I wholeheartedly agree with that. It's trying to solve too many things at once. Revolution instead of evolution always costs you. At first the new thing may seem to do everything the old could, but you later find out it doesn't.

It completely breaks the whole IP philosophy and moves to a bastard child of IPSec (the who-needs-routing-tables protocol, and the blatant layering violation brought by IKE) and IPX. If IPX seems good, you simply don't understand the beauty of IPv4.

For a different take on it, see DJB's piece at http://cr.yp.to/djbdns/ipv6mess.html

Cheers,

Emile

IPv6 fans ought to read D.J. Bernstein's excellent article on the subject. In short, the main problem is that the two protocols aren't easily interoperable, so investment in IPv6 infrastructure is without short-term return.

This was pointed out by DJB a while back:

http://cr.yp.to/djbdns/ipv6mess.html

People don't seem to understand that IPV6 isn't the Internet. It's something else that nobody is on and nobody wants on because nobody is there.

http://cr.yp.to/djbdns/ipv6mess.html

IPV6 is being led by fools that are convinced that IPV6 is solely "a matter of time". Fact is, they have no transition plan, and until they do, they're going to continue to get laughed at.

I have recommended on numerous occasions that the simplest solution is to freeze the IANA and require TCP and UDP services publish their ports in DNS, and while we're at it, deprecate every record but NS, PTR, SRV and A. Make it a requirement right now.

Existing installations have it easy- they simply publish SRV records that contain the port numbers they already are using. New installations get to contact one less central authority about addressing, and at the rate that primary Internet vehicles (web browsers and email clients) are being deprecated for bugs, client deployment could be had in as little as 6 months.

You wouldn't need to add new configuration to your clients, and you wouldn't need to change anywhere near as much software as needs changing for IPV6. Best part: you'd increase the public internet address space by almost 16 bits- giving us almost 68,719,476,736 addresses or room for each person on the planet to publish 10 uniquely and immediately addressable services each - and that's without reallocating existing blocks- you do that and the number skyrockets to nearly 281,474,976,710,656 - which is enough addresses for everyone ON THE PLANET to publish 46,912 similarly immediately addressable services right now.

In contrast, IPV6 not only has to do all the work I suggest, but it has to replace every client and every server- regardless of whether or not they are going to benefit from the increased address space and complexity and they'll need to change the configuration files and configuration databases of those programs as well to accommodate the larger addresses.

But this will never happen: IPV6 is being run by people who think A6/DNAME records are a good idea.

That's ridiculous. Let's say you're taken to court by the author of a piece of software that was released as "public domain". You argue that it was clearly the intention of the author to allow any use, as if it were truly in the public domain due to an expired license. What judge or jury wouldn't accept that argument? (Assume there are no non-copyright issues involved in this case.) So while there may not be any way to truly place something in the public domain, merely making it clear that that is your intention will have the same effect.

Now, where things get sticky is if the author releases something without a clear intention of relinquishing all his rights.

That's ridiculous. Let's say you're taken to court by the author of a piece of software that was released as "public domain". You argue that it was clearly the intention of the author to allow any use, as if it were truly in the public domain due to an expired license. What judge or jury wouldn't accept that argument? (Assume there are no non-copyright issues involved in this case.) So while there may not be any way to truly place something in the public domain, merely making it clear that that is your intention will have the same effect.

Now, where things get sticky is if the author releases something without a clear intention of relinquishing all his rights.

That's ridiculous. Let's say you're taken to court by the author of a piece of software that was released as "public domain". You argue that it was clearly the intention of the author to allow any use, as if it were truly in the public domain due to an expired license. What judge or jury wouldn't accept that argument? (Assume there are no non-copyright issues involved in this case.) So while there may not be any way to truly place something in the public domain, merely making it clear that that is your intention will have the same effect.

Now, where things get sticky is if the author releases something without a clear intention of relinquishing all his rights.

I've heard similar stories about UIC. Mostly with the University stealing grant money (and charging grant expenses to the wrong accounts). Daniel Bernstein has one account here, and I've heard similar accounts from other professors.

Working for the state is a great way to get free money. And a great waste of taxpayer resources. (Apparently you have to give all employees a 1-year notice before you can stop paying them. That's a year of free salary unless you commit a felony. Greaaat.)

I have read the article and I found no explaination at all about how the clock can calculate the local time including the leap second. Ok, the clock have a synchronization of the earth rotation using the sunlight, but this in no way synchronized to the local time. First current local time is an offset of UTC and UTC is an offet to TAI and TAI is a averge of many atomic clocks, so the basic of our local time is not astronomic, but atomic (http://cr.yp.to/proto/utctai.html). This clock can be a impressive model of the astronomic motion, but this is the wrong way to tel the local time. Second, even for the astronomic motion I have doubts, since I never see a paper telling that the earth axis motion can be know for 10'000 year. But you can find papers that tel exactly the opposite: this motion is largely unpredictable as now for a such long time. See this URL about how complexe is the earth rotation axis http://mb-soft.com/public/precess.html and this URL about why this is impossible to predict at full precision this movement http://www.cv.nrao.edu/~rfisher/Ephemerides/earth_ rot.html. Did you know that such bulltins exists ftp://maia.usno.navy.mil/ser7/iersexp.sup ? Last, did you realiste that the local time is an human concept that have radicaly changed in less than one century ? How can someone assert that this will not change in 10'000 year ? Juste an exemple: the Asian earthquake end last year did have an observable impact on the earth roation, see http://www.nasa.gov/home/hqnews/2005/jan/HQ_05011_ earthquake.html. So keep in mind this basic facts: 1) astronomic motion is unpredictable in full precision for long time; 2) local time in based on atomic observation plus offset to keep it compatible with astronomic observation, not the opposit!

Anyone who watched the PC platform when Windows 95 came out knows better than to say that MS stifled development.

Agreed. I think it's more appropriate to say they set it back twenty years.

By creating a platform for developers,

Actually, that was GNU: By developers and for developers. Windows is probably the most unpleseant platform to develop for still in active use.

they allowed the lowly PC platform to catch up greatly to the Mac in usability

You'll end up shot if you tell a Mac person that.

Windows never came close to MacOS in terms of usability. Not to mention your leading about developers- MacOS was and still is extremely pleseant to develop for.

and bring capabilities to buyers of low-cost hardware that might never have come to them otherwise.

You mean like how almost half of a reasonable system goes into Microsoft's pocket?

My kernel takes a little while to boot, with 6 drives in my PC (2 SATA, 4 IDE) to initialize on 2(3) controllers and other fun hardware.

That said, my bootup after that is near instant since I long ago moved away from the init.d style startup toward a daemontools parallel startup system.

How about one developer producing an MTA for free?
It's possible.

DJB is an asshat. From his guarantee page:

In May 2005, Georgi Guninski claimed that some potential 64-bit portability problems allowed a ``remote exploit in qmail-smtpd.'' This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits.

In other words, "as long as you don't use this software in ways I didn't envision, it is secure." Well, no kidding! By that standard, Windows is mostly secure too, because nobody would ever try to run a .exe file from Outlook Express - that would be silly!

DJB's guarantee is worth the paper it's printed on (note: applies only to electronic formats; real paper may have value) since he will never, ever admit that a bug actually exists. It's much more fun to posture and claim that your competitors old releases were buggy than to fix your own problems.

So what are they supported by? If the use of a work is not an exclusive right (which it is not according to 17 USC 106) then why does anyone pay any heed to EULAs at all?

In fact, DJB has a Software user's right's page that goes into this issue. However the most recent case it references is 1992... does any one know of a similar page with more up to date information?

Security is a process and a state. Evidence: qmail versus sendmail.

How about an application whose sole job is to pull data from untrusted sources as root and pass it to other programs which either send it to other hosts, recieving back untrusted data, run programs on that data, or write that data to disk as a user? Gotta have security problems, right?

http://cr.yp.to/qmail.html

Daniel Bernstein: http://export.cr.yp.to/

> postfix as an example of a program that was designed from the outset to be secure

Uhh... except that postfix has had a number of severe security problems over the years!

Postfix Disasters

And to solve the security problems, the postfix developers denyed them for quite a while! Not good security at all! Postfix is pretty much a failure.

You are not encouraged to withhold information. Programmers who create security holes will suffer if those security holes are disclosed; good! They obviously need more incentive to check their work. The security holes are their fault, not yours. If you're worried about them shooting the messenger, post anonymously.

1) It's a bitch to install. Won't even compile on modern Linux distributions. You have to patch it to compile it and the patch isn't even hosted on qmail's site.

Yes, it's not for newbies like you. It's for people who know what they're doing. On which "modern distro" did it "not even compile", anyways?

2) It's a bitch to configure. Rather than parsing a single configuration file, qmail relies heavily on the presence of individual files in a directory.

Guess what, many admins prefer that approach over
lengthy, nested config files.

3) Not not not not scalable! That's a myth. Doesn't properly batch jobs together. Hell! qmail was originally designed to be run from inetd!

qmail was designed to run from daemontools.
Where do you take all that bullshit from that you're spilling here?
Oh, and it scales quite well, quote from qmail.org:
USA.net's outgoing email, Address.com, Rediffmail.com, Colonize.com, Yahoo! mail, Network Solutions, Verio, MessageLabs (searching 100M emails/week for malware), listserv.acsu.buffalo.edu (a big listserv hub, using qmail since 1996), Ohio State (biggest US University), Yahoo! Groups, Listbot, USWest.net (Western US ISP), Telenordia, gmx.de (German ISP), NetZero (free ISP), Critical Path (email outsourcing service w/ 15M mailboxes), PayPal/Confinity, Hypermart.net, Casema, Pair Networks, Topica, MyNet.com.tr, FSmail.net, Mycom.com, and vuurwerk.nl.

4) Heavy reliance on other daemontools.

Yes, because

1. it's UNIX
2. all other tcpserver implementations were broken at the time (and afaik are still broken)

What are you gonna criticize next, qmails low memory footprint?

5) Breaks well-known and understood UNIX standards.

Which "well-known and understood UNIX standards" are you referring to? Do you have *any* clue what you're talking about? NO.

6) Security through lack-of-functionality.

Actually it's secure by design.
If you had the slightest clue about software architecture you'd have realized that on first glance.

7) Not really secure despite the claims.

So, you have found a vulnerability and collected the $500 USD from djb? Oh, you didn't?
Then shut the fuck up.
Your FUD is not appreciated, kiddy.

8) No longer maintained.

Says who? You? haha!

9) No features. Adding them requires patching, and patching, and more patching.

Yes, which you do *once* and then roll it into a nice package for future deploys.
Last time I had to change something in my qmail-tarball was over a year ago.
That tarball is all I need to pull up new installations with all the patches that I need.
Deploy takes exactly one line:

tar zxf qm.tgz && cd qmaili && make && make setup check

And, guess what, the Makefile even sets up the config for the box at hand which is easy because all it takes is stuff like echo `hostname -f` >/var/qmail/control/me etc.
With postfix I'd have to replace tokens in a config-file-template (which will ofcourse change syntax in newer versions) and other shit.

But from your statements I can tell that all this is way beyond your little head already. So next time you see the adults talking about stuff you don't grok you'd better shut up and listen instead of humiliating yourself like you just did.

And if you still didn't get it:
All your points are either outright *wrong* or display an embarrassing lack of clue. Go figure.

That's in the QMTP server, not the SMTP server. That's the protocol described here, not the one described here.

Could you be a bit more specific on the following items?

5) Breaks well-known and understood UNIX standards.

Which standards are these? Are you talking about the errno fiasco?

6) Security through lack-of-functionality.

What sort of functionality is provided by, say, postfix, that qmail simply won't do?

7) Not really secure despite the claims.

How's that? Do you have $500? If not, what's the security vulnerability that the author refuses to acknowledge?

Which of these problems that you enumerate are not addressed by netqmail?

--grendel drago

I'll bet the one that's 500% better cost 500% less, too. I've never understood textbooks -- I've paid $150 for some absolutely worthless ones and gotten some excellent ones online for free. This semester I am only taking 13 hours, and 3 of those have an online textbook (Discrete Math, info at http://cr.yp.to/2005-261.html) but I still ended up with $500+ of textbooks! What really hit the wallet this semester were music theory textbooks. $60 for the text. $50 for a workbook. $70 for this tiny little song book for ear training class. $100 for the piano book. I didn't even bother to get the $125 CDs for the piano book. $125!?

(As a sidenote, the most I ever paid for a math textbook in Japan was 1300 yen -- about $10. Then you go over to the English section and the books are $200. I don't get it.)

One thing I have noticed in the recent year is the upsurge in Ralink (RA) WiFi devices. Taiwanese motherboards manufacturers are bundling 802.11 cards by the thousands with high end motherboards with RA cards. ASUS, MSI and Gigabyte all bundle RA cards with their "deluxe" motherboards.

Since RA is a very Taiwanese component, and motherboards are - of course - *very* Taiwanese components, it would be excellent if FreeBSD took advantage of the opportunity to embrace RA in the same manner that Linux has. For bonus points, PLEASE backport to 5.x and 4.x since many of us (particularly DJB and myself) refuse to move off 4.x unless it is absolutely needed.

HJ

The fact that clockspeed hasn't been updated since October 1998 makes absolutely no difference to me. DJB got the design right -- it accounts for leap seconds, it syncs the clock, and if I lose my internet connection for a month I'm still within a second of the atomic clock.

NTP is based on UTC and doesn't handle leap seconds as gracefully as TAI. Further discussion:

http://cr.yp.to/proto/utctai.html
http://cr.yp.to/proto/taiclock.txt

The fact that clockspeed hasn't been updated since October 1998 makes absolutely no difference to me. DJB got the design right -- it accounts for leap seconds, it syncs the clock, and if I lose my internet connection for a month I'm still within a second of the atomic clock.

NTP is based on UTC and doesn't handle leap seconds as gracefully as TAI. Further discussion:

http://cr.yp.to/proto/utctai.html
http://cr.yp.to/proto/taiclock.txt

DJB's clockspeed package:

http://cr.yp.to/clockspeed.html

Includes an SNTP client, TAI client, TAI server, and clock correction program. It's very simple and it keeps my entire cluster to within a very small amount of drift of the atomic clock, with the sync interval doubling at every sync.

I use SNTP to get Stratum-1 time from NIST, then TAI to serve Stratum-2 time to my cluster.

TFA mentions using AES, TDES, or RSA as alternatives to DES. He also says, "...the final AES standard is estimated to require a current cryptanalysis system 149 trillion years to decrypt." That may be true for direct-channel cryptanalysis, but side-channel attacks such as cache timings against most implementations of AES can guess the key given known plaintext, known ciphertext, and at least estimated timings for encryption.

Read more: http://cr.yp.to/antiforgery/cachetiming-20050414.p df

The answer lies in authentication - who is sending the email.

• 
  "This paper reports successful extraction of a complete AES key from a network server on another computer. The targeted server used its key solely to encrypt data using the OpenSSL AES implementation on a Pentium III.
  
  The successful attack was a very simple timing attack. Presumably the same technique can extract complete AES keys from the more complicated servers actually used to handle Internet data, although the attacks will often require extra timings to average out the effects of variable network delays.
  

• gets queried for www.badguy.com by target.com
• delegates authority for HIS nameservers to ns.yahoo.com, for example; so he says:
  • www.badguy.com NS ns1.yahoo.com
  • www.badguy.com NS ns2.yahoo.com
  • ...
• ALSO includes fake mappings of the form:
  • ns1.yahoo.com A 1.2.3.4
  • ns2.yahoo.com A 1.2.3.4
  • ...
• so target.com contacts "ns1.yahoo.com" at 1.2.3.4 and asks to resolve "www.badguy.com"
• since ns1.yahoo.com is *actually* a name server under bad guy's control (bad guy controls 1.2.3.4), ns1.yahoo.com returns how to get to www.badguy.com
• then in future queries for www.yahoo.com, the name server will ask 1.2.3.4 for the IP for www.yahoo.com and send that reply to the requestor

Imagine agreeing to do something at a certain future time, and then setting up a piece of hardware to do it.

If not for leap seconds, your hardware could be a simple down counter programmed with the difference between the agreed-upon future time and the current time.

It doesn't seem reasonable to me. You'd need to require to-the-second accuracy to a point many months in the future, and you'd need that point in time to be declared in a way recognizable to the rest of the world. You'd need an atomic clock in the computer, not just "a simple down counter", and even then you might not even wind up with something perfectly synchronous - time is relative. To get true TAI you'd have to synchronize with 200 other atomic clocks, since TAI is just an average. The simplest solution here would be to just attach a radio clock, GPS, or some external device.

But I still don't understand *why* you'd want to do such a thing. I guess if you're trying to make the perfect bomb which didn't rely on any radio signals and was set to go off at midnight 7/7/2007 at 7:17:07 or something. So the adoption of UTC has foiled a terrorist. :)

NORAD epoch times are UTC, and that creates a trap if you're not careful about leap seconds.

Oh boy, so you have to be careful. So what? Be careful.

Obviously that epoch date could not move around arbitrarily as a result of leap seconds, so it's based on "terrestrial time", another standard time scale related to TAI that doesn't follow leap seconds.

Leap seconds aren't arbitrary. They're based on the spin of the Earth.

Anyway, I don't see what this has to do with computing the number of "seconds" until a UTC date in the future. Obviously some people are going to use different methods of time. And remember, UTC is a hybrid system between GMT/UT1 and TAI. GMT would be a better system for human purposes, and in fact it's a modern version of the system we had back in Babalonian times, back before scientists decided to redefine the meaning of a second. The problem is that GMT isn't easily adapted to accurate clocks, such as atomic clocks, and you don't want to have to constantly send update information such as would be necessary with UT1. So you save up a whole second worth of updates and send them all at one time.

So I think we completely agree on the main point: UNIX's internal representation of time is fundamentally broken.

Yeah, the UNIX time system is broken in its design. You have no argument with me there.

It ought to be based on a count of seconds from some epoch on a timescale that does not use leap seconds, and conversion to or from UTC should be done only when needed for human consumption or input.

That'd be one way to do it. Of course, using UT1 would work too, and then you wouldn't need a table of historical leap seconds unless you wanted to convert to TAI. You'd just need to store the current offset between UT1 and UTC.

One could even argue that UNIX already does this, and it's the conversion routines that are broken. As you point out, a time_t value is supposed to be the number of seconds since January 1, 1970 00:00:00 UTC. Well, that count for a given event is not going to change just because leap seconds were subsequently declared!

Without specifying a frame of reference, that definition is rather meaningless :).

So it's really the conversion routines that are broken...

I think I already linked to DJB's explanation, but in case I haven't, there it is. According to him it's a broken localtime(), combined with a broken xntpd which catered to the broken localtime().

But I also noticed that the original definition was in GMT. So really the error was in changing GMT to UTC instead of UT1, and in thinking that we meant TAI seconds instead of GMT seconds.

It actually does matter a lot in some applications. Take satellite tracking. A low earth orbit satellite moves about 7 km in one second. If you're off by one second because of confusion about a leap second, you've made a position error of 7 km. That's a lot.

No, I wasn't talking about calculating the current time. I'm talking about calculating the number of seconds between now and some time in the future. That's what you can't do, and I can't think of any reason why you'd ever need to do that.

There are many perfectly valid arguments against leap seconds. The difficulty in calculating the exact number of seconds between two events

That's impossible to do precisely anyway due to relativity, and as the time between the two events increases the precision goes down more and more. But it's not even that difficult to calculate within a system of leap seconds (within the limitations of the relative motions and gravitational effects of the two clocks and/or the distance between the locations of the events), you just need a table of historical leap seconds.

If you want to make things even easier on yourself, then don't record the times of things using UTC if what you care about is measuring the number of seconds between things. UTC isn't about that. It's about making it easy for humans to communicate times which can easily be converted to local times. And local times are, more than anything else, about measuring positions within a day.

the fact that calculations involving future times can give different results after leap seconds are declared

This is the part that I was talking about previously. I don't see why one would need to calculate the number of seconds until a time in the future (for practical purposes). If it's really necessary, then that time in the future shouldn't (can't, actually) be declared in UTC.

the difficulty of dating events that occur near or during leap seconds

What's difficult about it? I don't understand this point at all. There is a very clear and unambiguous way to date any event, regardless of whether or not it occurs near or during a leap second. "1998-12-31T23:59:59.00Z, 1998-12-31T23:59:60.00Z, 1999-01-01T00:00:00.00Z, 1999-01-01T00:00:01.00Z". You must be talking about UNIX time.

But these are not good arguments for removing leap seconds from UTC! Why do that when you can choose from two perfectly good standard time scales that don't have leap seconds?

I guess we're on the same page here. But I still don't understand the practical benefit of knowing the number of seconds between now and some date/time in the future.

It would have been really nice had the UNIX designers chosen the TAI timescale instead of UTC as the internal representation of time.

UNIX time, as declared by POSIX, is broken in design. They use an integer which is supposed to represent "the number of seconds elapsed since 00:00:00 on January 1, 1970" then they say it's in Coordinated Universal Time. But UTC is not an integer, and it doesn't measure the number of seconds elapsed since midnight 1/1/1970 (at least not under the UTC definition of the second which is equal to the SI definition).

Since converting an integer into a date/time involves some calculation anyway, I agree with you it would have made much more sense to use TAI as the base. See http://cr.yp.to/proto/utctai.html for another argument.

Of course, this system would only be useful for timestamps since about 1955, when we started paying attention to leap seconds in the first place. Before that we can't accurately measure the number of seconds between two events, using the modern definition of the second. Depending how far back you go the systems become more and more convoluted.

I wonder if it's too late to make such a change...

Depends how much control you have over your system, and how much you're willing to break POSIX. For backward compatibility, we would probably need to come up with a new system call, though maybe a good hybrid solution would be to use UT1 internally. At least then the clock slews are spread out.

With our current system of leap seconds, does the Unix timestamp actually reflect the CORRECT number of seconds since Jan 1st, 1970?

The other answers to this were somewhat confusing, so I'll give one too: No, unix timestamps don't reflect the number of seconds since 1/1/1970, at least not if they follow the POSIX standards. Unix timestamps reflect the UTC time. Here's another link.

If you think this is bad, then you should plan on being very scared of IPv6 since that will have the ability to give every device a permanent non-NATted IP address that will uniquely identify you.

DJB's technique is to produce (imho) underfunctional software and deny security issues when they arise. (Witness the recent overrun in qmail's pop3 daemon, because the thing uses certain high bits for rather strange purposes.)

ISC mentioning it:
http://isc.sans.org/diary.php?date=2005-05-31

Wikipedia mentioning it:
http://en.wikipedia.org/wiki/Daniel_Bernstein

And his reply

http://cr.yp.to/qmail/guarantee.html " Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits"

I don't know about you, but that a program's author would make that kind of assumption makes me somewhat uncomfortable.

Anyway, the REAL flaw in this logic is that it's a probability thing - a competent programmer can produce an error free line of code (say) 95% of the time. But when you have ten lines, it's a matter of all ten being error free - (0.95) ^ (10) - which is only 60%. Heck, at 99% chance of being good each line, it's a 90% chance those ten lines are good.

Now what if there's 10,000 lines of code?

Bugs happen.

Of course, the fact that djb writes secure software using exactly that technique means *you* probably need to rethink your assumptions.

Personally, my goal is always perfection. I know it's difficult and I don't always achieve it, but I gotta wonder about people like you who "aim low".

Unfortunately, giving people lectures doesn't teach them how to do this. In an industry with about zero barrier to entry, most software is going to be crap. Most programmers simply don't know what they are doing. But don't let that cloud your thinking. It *is* possible to write secure software exactly like you describe.

And it's not just watching for buffer overflows, it's also partitioning parts of your programs from one another, setting resource limits, filtering input, all the layers of security.

If you think "writing secure software is impossible", you've already lost, please get out of the industry, or at least don't write software that deals with network data.

According to a link I just read, POSIX doesn't handle leap seconds. So yes, if you use NTP, like someone else suggested, your time will be correct, but any measurements of time crossing leap seconds won't.

The correct solution in my opinion would be to store leap seconds along with the timezone information. That's really what they are. Unix time could be stored in TAI instead of UTC, and thus subtracting two times from each other would still give the correct result.

Whenever a leap second was announced you'd have to download a new timezone file, and if you didn't download the file in time your displayed time would be off by a second. Alternatively, if you synced using NTP, which is in UTC, and you didn't update your timezone file, then your computer would incorrectly slow down the clock by one second. Once you installed the timezone file, and resynced with NTP, this would be corrected.

Eventually NTP should probably be switched over to TAI. I see a proposal for this in a mailing list in January 2004. Would have been nice to do it before the leap second, but that's probably too soon to expect many people to change at this point.

Here's a link to the essay that D.J. Bernstein wrote on the 'IPv6 Mess'. He makes some good points that I think are really significant. The fact that IPv6 has not been widely deployed yet is a silent acceptance of the migration nightmare that it would cause.