I've spent a lot of time in the Baltimore area, and I can tell you that it is suzzy as hell with some of the worst crime rates in the country. See?
Yeah, except the Inner Harbor is not where those crimes are commited. The Inner Harbor is where stupid tourists go. Much of the crime you refer to is in eastern Baltimore.
No. Clusters are only good for doing tasks that "parallelize". Compiling is too linear.
Compiling a single file is. But most software has more than one file, and you can compile different files on different machines. Check out distcc.
Of course, even using distcc, a single low-end Athlon will be 10x faster than all of those boxes combined, and use up a lot less electricity as well. So it's not exactly a useful excercise. Interesting, perhaps.
Except Qt was not an open source project turned commercial, it was a commercial project that they decided to give away under the GPL for those who want it. I'll admit that I don't know for sure (not exactly checking up on Trolltech's finances), but I would suspect that most of their revenue comes from licensing the code to people who want to write non-GPL Qt code (similiarly to MySQL in that respect).
The team capabilities were about equal across the board. After they crunched the data down, they discovered that Ada was giving them twice the programmer productivity and 1/4 the defect density.
AAAAAHHHH! Look at the list I provided. You'll note that Ada95 was in there. I am not saying anything bad about Ada (still haven't learned it, but I should). What we're talking about is SPARK, which is basically an Ada subset. Do you really think that a language without recursion, dynamic memory allocation, or function side-effects is going to be as productive as a language that does? Of course languages built for programming with side-effects (O'Caml, Lisp, etc) that's not a restriction, but in an imperative language it's not going to be very fun.
A comparison of Ada and C/C++ is very interesting, but not terribly applicable when the language under discussion is a language which looks rather like Ada but with many language features removed. Most of those features were not removed because they are inherently insecure, but because nobody has figured out how to write a correctness prover for a program which uses those features.
Actually, I've seen a bunch of safety-critical systems that were written in Pascal or some godawful assembler
My Dad hand-patches microcode on 60s-era safety systems in a chemical plant for a living. It's pretty intense.:)
Perl is pretty far from a B&D language, but I'd sure hate to see an autopilot written in perl, no matter how productive or satisfied it made the coder.
The happiness of the coder is not really the issue. If we could get safe, secure, reliable software by coding them in restrictive languages (or beating the programmers with sticks, whatever), then by all means we should, if it's worth what it will cost.
The first problem is that nobody has any really convincing evidence that, all other things being equal (testing, design methods, skill of people involved, time/money available), SPARK or similiarly restricted languages actually gets you any meaningful improvment in security as compared to, say, Pascal, Ada95, C++, Java, O'Caml, or a similiarly "full of pointy bits" language.
Secondly, the languages restrictions mean the programmers/designers have to spend more time (ie, money) working around the limitations of said language. It's economics. If a particular application (Word or Photoshop or your firewall or what have you), *never* crashed or failed in any way, would you be willing to pay 1000 times as much for it? 100x? 10x? Twice as much, even? For an autopilot, it might make sense. For 99% of the stuff that's out there, it doesn't (read Ross Anderson's papers on the economics of security for some good details on this area), because the cost of a failure (for the people writing/selling the code) is between zero and tiny, and the cost of making it not fail is high. It's cheaper to write crappy software, unless your legal/political liability is so fscking high that you *have* to make in safe.
One thing I note that the review does not mention is the fact that SPARK is, while Turing-complete, not very much fun to program in. Starting with Ada, a pretty B&D langauge to start with, SPARK removes all the remaining pointy bits, including: "the goto statement, aliasing, default parameters for subprograms (i.e. procedures and functions), side-effects in functions, recursion, tasks, user-defined exceptions, exception handlers and generics" (list taken from here, emphasis mine), plus dynamic allocation, which is mentioned in the review.
Basically the only excuse you could possibly have for writing something in SPARK is extremely critical code (ie, if it fails, many people die). Even then I'd be skeptical it would provide much benefit, but at least it would provide some ass-covering ability.:)
For a alternatve view of the practicality of correctness proofs, see chapter 4 of Peter Guttman's thesis. IIRC there was a book review of it on/. a while back (which I didn't read). Even if you did read it, read it again.
"No programming language can save you from yourself."
- Me
I'm still waiting for the day that one of these things wipes out the infected host after X hours/days.
Actually there was one like this recently, that attacked some Windows personal firewall (the name escapes me). It would try to spread itself for a short while (some hours), and then killed the host.
Ebola spreads fast and kills the host, why not a virus/worm?
Ebola also burns itself out pretty fast. Too fast and you limit how well it can spread. Probably you'd want to maximize the total number of machines destroyed, which is a tradeoff between how many hosts it can infect (ie, how long it tries to infect other hosts before it kills it's host), and how long it has before the AV people/IT staff/etc notice + fix it. I would guess around 16-24 hours would be right; more if you released at some really bad time like Christmas Eve when 90% of staff will be on vacation in many countries.
This piece of software will erase absolutely all of your data completely and irreperably. Or at least anything you don't want getting out.
Hello overkill. Keep any really personal/your-eyes-only stuff encrypted with GPG/PGP. Keep all of your random personal junk (mail, etc) on an encrypted disk partition. If it doesn't get the "I'm still alive" email, then check if the drive is still mounted; if it is, unmount it. And encrypt your backups.
a) The system will recover from the inevitable failure that will at some point happen. You just have to wait till you get back (or can ssh in, whatever), and remount the drive.
b) It's probably safer. First, deleting a few hundred megs of stuff will take awhile, especially if you're scrubbing it with random bits. Unmounting an encrypted partition would only take a few seconds. Secondly, shredding doesn't work well on journaled filesystems (reiserfs, JFS, XFS, and to some extent ext3). You can shred the whole partition and take out the journal files, metadata, etc, but again, quite slow. Also, nothing stopping someone who really wants your precious bits from checking/tmp, swap, etc for bits of your files, you'd have to shred those as well.
But I don't see what that would achieve either: two strings of gibberish that happen to have the same MD5 sum. Find a way to produce two documents which both have meaning (perhaps two pieces of source code, or two different school reports) and have the same signature, and that would be impressive.
MD4 is considered totally broken. Nobody has ever been able to generate 'arbitary' collisions for that hash either, just semi-random ones. But still, nobody uses it.
The definition of collision-resistent is that you cannot find ANY inputs x,y st x!=y and H(x) == H(y). None. No exceptions. Lets say I could easily generate MD5 collisions on 'random-looking' 128-bit strings, but not on Word.docs (or whatever). Would MD5 be safe? Sure, if you used it only on Word files. Would MD5 be considerd broken? Hell yes.
Does the amd 64 use a 64 bit pid_t, time_t, uid_t, etc?
Short answer: no
Long answer: Depends on the kernel. On Linux, uid_t is always 32 bits (you really have more than 4 billion users?!?) pid_t/time_t: I forget. You can find out the size of pid_t in the kernel headers (types.h or posix_types.h or something like that). Again: you need more than 4 billion processes? Opteron is a nice CPU, but doesn't scale *that* well. Actually, I think right now on x86 at least pid_t is 32 bits, but only the low 16 are used (though I may be thinking of 2.2 behavior, and this in fact changed in 2.4 or 2.6).
time_t: I think this depends almost entirely on libc. Mostly, anyway: all the kernel has to do is not wrap when 2038 hits (not hard). libc has to actually know what to do with time values greater than that. One would hope glibc's time handling has already been tested, but I really don't know.
size_t/off_t are (or, at least, damn well should be, I actually haven't looked yet) 64 bits. So support for >2gb files is automatic. This is one that I would consider important.
Anyway, of the three you mention, the most important to move to 64 bits is time_t, and that isn't really a problem until at least 2020 (and that gives 18 years to upgrade).
will still have a tougher time getting a job than a C.S. student with no experience.
Don't worry, having a degree doesn't help you get a job either. Apparently, having a degree and a couple of years work experience and several years working on foss projects doesn't either.
BTW, define "lots of open source exp.": hacking on GCC and Linux, or writing lots and lots of 10 line Perl scripts. Nothing wrong with either, of course, except for that a 10 line Perl script could have been written in just 3 using half as many alphanumeric characters.
Cube, Pi, ExiZtenZ, and sneakers are a few movie I can think of that I've seen, but I doubt any non-geek has (unless made so by their SO)...
I've actually known several very-nongeek* people who really liked Pi (at least 4 I can think of off the top of my head). Sneakers, though, I think you may be right.
* In this case, that means people who majored in art, history, writing, etc and now do things not remotely related to math, science, or engineering.
1.2 forces people to use that windows activation thing
Actually, I view that as a good thing. I figure, the day that MS figures out a reasonably crack-resistant registration scheme is the day that they will actually have to compete with Linux and OS X in terms of quality. Tons of people use pirated copies of 2K/XP (5 people in my family alone, that I know of). The day that people actually have to pay the $100-300?/copy, they're going to be a lot pickier about what they're getting.
security. no more patches for win98. this means that the small group of people with win98 are always going to be vulnerable to internet viruses. Upgrade you say?
In addition to the people I know who are using unbought copies of 2K/XP, I also know a few running 95 or 98 w/o updates, as unpatched as the day the box was shipped. Most of the people who are going to migrate off 95/98 to something else, have. The remainder, it's likely, will keep using 95/98 until their machine commits suicide. They will not update the system. If you find a 98 system somewhere, odds have got to be high some worm or virus is on it already. It's mere existence (today) screams "I don't update my software. I don't care about security or stability." 2000 or even NT4, sure, why not. But 98... nuh uh.
Informed. Thanks. Article VI doesn't mention anything about it being binding to the public, though... while it does make sense that it be binding for the states, I can't see how I could be bound by the Constitution, simply because the rules made there don't apply to the public, they apply to the government. Wouldn't the rules for the people be the criminal and civil codes?
But how on earth could the GPL "violate the United States Constitution". Isn't the Consitution only binding to the Federal govt? ie, even if there was a clause in there saying "RMS is a kook and the GPL == evil and bad, use SCO Unixware instead", that wouldn't prevent anyone but the Feds from using/dealing with the GPL. Right? Have I been smoking too much crack?
(Yes, I know, it's Darl, I shouldn't assume it makes even the slightest bit of sense.)
After that, if your company server isn't able to send mail to anyone, you will update fast, I bet.
That's the thing. It won't happen, becuase nobody wants to take the first step. Just like IPv6, where the first major provider that changes gets to deal with every IPv6 bug in every piece of network equipment that is around. Thus, it's easier to keep using IPv4. Similiarly, nobody would change the mail servers because then they get to deal with all the problems inherent with doing this (when they would rather wait for someone else to deal with it).
Updating server software. Thats what admins are for. Should be possible to do in a year or so.
Just getting this through the IETF would take a year, assuming it wasn't insane. You are discussing a mandatory change to a widely used Internet standard. I don't know if you're aware of how this works, but it's not just "Hey! Let's do X" and it magically happens.
If you don't believe me, then go here, sign up to the SMTP WG list, and get SMTP changed. Then, if you like, you can come back and laugh at me and remind me how wrong I was.
1) Make a law (if your country doesn't have one already) which makes it illegal to send emails with forged FROM fields (= email addresses you don't own)
And when people violate it, you track them down how, exactly? Please explain.
Slightly improve RFC2821 (smtp)
What you term "slightly improve", I would call "change EVERY mail server and client in the world". Oh, wonderful solution. Even if this was pushed through today, it would take years (at best) to happen. As a much smaller-scale example, all new X.509 CAs that comply with PKIX (the IETF X.509 profile) are supposed to start issuing all their certs with UTF-8 on 1/1/04. This is been a requirement of PKIX since at least 1998. Not one single CA is going the change on the cutoff date. Not one. SMTP is thousands of times more widely used than X.509. You are insane if you think this is technically or politically feasible.
Yes, I know this prevents everybody from having his own pretty little smtp server. No, I'm perfectly well with that. Use a provider.
I am very glad you have no ability to carry out any of these actions.
Are crypt() secret keys limited to certain characters?
Yup (this is described in the paper). You get (at most) 8 characters of 7-bit ASCII, cause DES has a 56-bit key (plus 8 parity bits which are completely ignored). Of course it's hard to type \001 into a keyboard, so it's actually a bit less than 2^56. Anyway, changing the upper limit doesn't help that much, even if you modified it (somehow) to use 8-bit characters, the basic algorithm (25 iterations of DES) is just too quick to compute on a modern machine. The MD5 crypt() [common on Linux and *BSD] uses 1000 iterations, which is not bad, but is less than ideal. The OpenBSD Blowfish-based crypt() is very good, because it's very slow. Especially good as it uses up lots (~4K) of memory, which makes a custom hardware cracker quite expensive, which was actually one of the goals of the old crypt() as well (it's just that hardware has caught up with it, and then some).
Re:Symmetric vs. public-key cyphers...
on
RSA-576 Factored
·
· Score: 3, Interesting
There are no known ways to break currently acceptable symmetric cyphers (such as 3-DES and AES) faster than brute force
Just a quibble: you can actually break both 3DES and AES faster than brute force. In the cast of 3DES, there is a time/memory tradeoff, and AES has some key schedule weaknesses (though in the case of AES, you need to collect nearly the entire codebook before you can proceed with the attack (at least the one I'm thinking of)). Basically, you're right in practice, just not in theory; none of the (publicly known) attacks on 3DES or AES are remotely close to being practical in any sense of the word.
In any case, as the hardware makes it easier for the attackers, it makes it practical to go with longer encryption keys, so faster hardware is neither a help nor hindrance to attackers.
Actually, the win is probably for the defenders. Double the length of an RSA key, the encryptor has to do 3-4 times as much work, but the person trying to factor it faces an increase that is much, much larger.
F&OSS justifies its existence by claiming to give users freedom; to drop support for a platform for non-technical reasons would be a violation of its own guiding principles.
That is the counter-argument made in the GCC README.SCO file.
8. Urge Free Software and Open Source developers to drop support for SCO Unixware across all softwares being developed. GNU Software (GCC, Emacs, libraries, autotools, base utils), Samba, Apache, OpenSSL, OpenOffice, XFree86, Gnome, KDE, etc.
The GCC 3.4 snapshots have a note in the root directory (README.SCO), which basically says "SCO is a bunch of jerks, and we're considering dropping support for SCO Unix".
While I've never used Unixware, by all reports it's so totally broken that I figure a) it might simplify the build magic quite a bit to drop the bitch anyway, and b) who the hell uses Unixware? Makes much more sense to support something like QNX than Unixware (I would add that a lot of GNU stuff *doesn't* support QNX). Of course that would be up to the developers of each project. But if, say, GNU tommorow said "All GNU projects will from now on explicitly not support Unixware"... well, I would be amused.
I agree with you on that. My primary one is circa 1985, and is holding up like a champ. The later models weren't as nice in terms of the feel of the keys, either (though still better than most IMO).
Slashdot Mirror
I've spent a lot of time in the Baltimore area, and I can tell you that it is suzzy as hell with some of the worst crime rates in the country. See?
Yeah, except the Inner Harbor is not where those crimes are commited. The Inner Harbor is where stupid tourists go. Much of the crime you refer to is in eastern Baltimore.
And Baltimore fucking rocks, BTW.
No. Clusters are only good for doing tasks that "parallelize". Compiling is too linear.
Compiling a single file is. But most software has more than one file, and you can compile different files on different machines. Check out distcc.
Of course, even using distcc, a single low-end Athlon will be 10x faster than all of those boxes combined, and use up a lot less electricity as well. So it's not exactly a useful excercise. Interesting, perhaps.
Except Qt was not an open source project turned commercial, it was a commercial project that they decided to give away under the GPL for those who want it. I'll admit that I don't know for sure (not exactly checking up on Trolltech's finances), but I would suspect that most of their revenue comes from licensing the code to people who want to write non-GPL Qt code (similiarly to MySQL in that respect).
IPSO is based off Linux now, BTW.
The team capabilities were about equal across the board. After they crunched the data down, they discovered that Ada was giving them twice the programmer productivity and 1/4 the defect density.
AAAAAHHHH! Look at the list I provided. You'll note that Ada95 was in there. I am not saying anything bad about Ada (still haven't learned it, but I should). What we're talking about is SPARK, which is basically an Ada subset. Do you really think that a language without recursion, dynamic memory allocation, or function side-effects is going to be as productive as a language that does? Of course languages built for programming with side-effects (O'Caml, Lisp, etc) that's not a restriction, but in an imperative language it's not going to be very fun.
A comparison of Ada and C/C++ is very interesting, but not terribly applicable when the language under discussion is a language which looks rather like Ada but with many language features removed. Most of those features were not removed because they are inherently insecure, but because nobody has figured out how to write a correctness prover for a program which uses those features.
Actually, I've seen a bunch of safety-critical systems that were written in Pascal or some godawful assembler
:)
My Dad hand-patches microcode on 60s-era safety systems in a chemical plant for a living. It's pretty intense.
Perl is pretty far from a B&D language, but I'd sure hate to see an autopilot written in perl, no matter how productive or satisfied it made the coder.
The happiness of the coder is not really the issue. If we could get safe, secure, reliable software by coding them in restrictive languages (or beating the programmers with sticks, whatever), then by all means we should, if it's worth what it will cost.
The first problem is that nobody has any really convincing evidence that, all other things being equal (testing, design methods, skill of people involved, time/money available), SPARK or similiarly restricted languages actually gets you any meaningful improvment in security as compared to, say, Pascal, Ada95, C++, Java, O'Caml, or a similiarly "full of pointy bits" language.
Secondly, the languages restrictions mean the programmers/designers have to spend more time (ie, money) working around the limitations of said language. It's economics. If a particular application (Word or Photoshop or your firewall or what have you), *never* crashed or failed in any way, would you be willing to pay 1000 times as much for it? 100x? 10x? Twice as much, even? For an autopilot, it might make sense. For 99% of the stuff that's out there, it doesn't (read Ross Anderson's papers on the economics of security for some good details on this area), because the cost of a failure (for the people writing/selling the code) is between zero and tiny, and the cost of making it not fail is high. It's cheaper to write crappy software, unless your legal/political liability is so fscking high that you *have* to make in safe.
One thing I note that the review does not mention is the fact that SPARK is, while Turing-complete, not very much fun to program in. Starting with Ada, a pretty B&D langauge to start with, SPARK removes all the remaining pointy bits, including: "the goto statement, aliasing, default parameters for subprograms (i.e. procedures and functions), side-effects in functions, recursion, tasks, user-defined exceptions, exception handlers and generics" (list taken from here, emphasis mine), plus dynamic allocation, which is mentioned in the review.
:)
/. a while back (which I didn't read). Even if you did read it, read it again.
Basically the only excuse you could possibly have for writing something in SPARK is extremely critical code (ie, if it fails, many people die). Even then I'd be skeptical it would provide much benefit, but at least it would provide some ass-covering ability.
For a alternatve view of the practicality of correctness proofs, see chapter 4 of Peter Guttman's thesis. IIRC there was a book review of it on
"No programming language can save you from yourself."
- Me
I'm still waiting for the day that one of these things wipes out the infected host after X hours/days.
Actually there was one like this recently, that attacked some Windows personal firewall (the name escapes me). It would try to spread itself for a short while (some hours), and then killed the host.
Ebola spreads fast and kills the host, why not a virus/worm?
Ebola also burns itself out pretty fast. Too fast and you limit how well it can spread. Probably you'd want to maximize the total number of machines destroyed, which is a tradeoff between how many hosts it can infect (ie, how long it tries to infect other hosts before it kills it's host), and how long it has before the AV people/IT staff/etc notice + fix it. I would guess around 16-24 hours would be right; more if you released at some really bad time like Christmas Eve when 90% of staff will be on vacation in many countries.
This piece of software will erase absolutely all of your data completely and irreperably. Or at least anything you don't want getting out.
/tmp, swap, etc for bits of your files, you'd have to shred those as well.
Hello overkill. Keep any really personal/your-eyes-only stuff encrypted with GPG/PGP. Keep all of your random personal junk (mail, etc) on an encrypted disk partition. If it doesn't get the "I'm still alive" email, then check if the drive is still mounted; if it is, unmount it. And encrypt your backups.
a) The system will recover from the inevitable failure that will at some point happen. You just have to wait till you get back (or can ssh in, whatever), and remount the drive.
b) It's probably safer. First, deleting a few hundred megs of stuff will take awhile, especially if you're scrubbing it with random bits. Unmounting an encrypted partition would only take a few seconds. Secondly, shredding doesn't work well on journaled filesystems (reiserfs, JFS, XFS, and to some extent ext3). You can shred the whole partition and take out the journal files, metadata, etc, but again, quite slow. Also, nothing stopping someone who really wants your precious bits from checking
But I don't see what that would achieve either: two strings of gibberish that happen to have the same MD5 sum. Find a way to produce two documents which both have meaning (perhaps two pieces of source code, or two different school reports) and have the same signature, and that would be impressive.
.docs (or whatever). Would MD5 be safe? Sure, if you used it only on Word files. Would MD5 be considerd broken?
MD4 is considered totally broken. Nobody has ever been able to generate 'arbitary' collisions for that hash either, just semi-random ones. But still, nobody uses it.
The definition of collision-resistent is that you cannot find ANY inputs x,y st x!=y and H(x) == H(y). None. No exceptions. Lets say I could easily generate MD5 collisions on 'random-looking' 128-bit strings, but not on Word
Hell yes.
So he goes in to work each day, has his long term memory disabled, and gets his work persona plugged in.
Reminds me of the 'dolls' in Neuromancer (girls come in to work, unplug most of their brain, wake up 8 hours later somewhat sore and with a paycheck).
Does the amd 64 use a 64 bit pid_t, time_t, uid_t, etc?
Short answer: no
Long answer: Depends on the kernel. On Linux, uid_t is always 32 bits (you really have more than 4 billion users?!?) pid_t/time_t: I forget. You can find out the size of pid_t in the kernel headers (types.h or posix_types.h or something like that). Again: you need more than 4 billion processes? Opteron is a nice CPU, but doesn't scale *that* well. Actually, I think right now on x86 at least pid_t is 32 bits, but only the low 16 are used (though I may be thinking of 2.2 behavior, and this in fact changed in 2.4 or 2.6).
time_t: I think this depends almost entirely on libc. Mostly, anyway: all the kernel has to do is not wrap when 2038 hits (not hard). libc has to actually know what to do with time values greater than that. One would hope glibc's time handling has already been tested, but I really don't know.
size_t/off_t are (or, at least, damn well should be, I actually haven't looked yet) 64 bits. So support for >2gb files is automatic. This is one that I would consider important.
Anyway, of the three you mention, the most important to move to 64 bits is time_t, and that isn't really a problem until at least 2020 (and that gives 18 years to upgrade).
will still have a tougher time getting a job than a C.S. student with no experience.
Don't worry, having a degree doesn't help you get a job either. Apparently, having a degree and a couple of years work experience and several years working on foss projects doesn't either.
BTW, define "lots of open source exp.": hacking on GCC and Linux, or writing lots and lots of 10 line Perl scripts. Nothing wrong with either, of course, except for that a 10 line Perl script could have been written in just 3 using half as many alphanumeric characters.
Cube, Pi, ExiZtenZ, and sneakers are a few movie I can think of that I've seen, but I doubt any non-geek has (unless made so by their SO)...
I've actually known several very-nongeek* people who really liked Pi (at least 4 I can think of off the top of my head). Sneakers, though, I think you may be right.
* In this case, that means people who majored in art, history, writing, etc and now do things not remotely related to math, science, or engineering.
Any Win* that came later was definitely slower than Win98.
Possibly. XP is pretty usable on a P-II 300, which is definitely towards the low end these days.
1.2 forces people to use that windows activation thing
Actually, I view that as a good thing. I figure, the day that MS figures out a reasonably crack-resistant registration scheme is the day that they will actually have to compete with Linux and OS X in terms of quality. Tons of people use pirated copies of 2K/XP (5 people in my family alone, that I know of). The day that people actually have to pay the $100-300?/copy, they're going to be a lot pickier about what they're getting.
security. no more patches for win98. this means that the small group of people with win98 are always going to be vulnerable to internet viruses. Upgrade you say?
In addition to the people I know who are using unbought copies of 2K/XP, I also know a few running 95 or 98 w/o updates, as unpatched as the day the box was shipped. Most of the people who are going to migrate off 95/98 to something else, have. The remainder, it's likely, will keep using 95/98 until their machine commits suicide. They will not update the system. If you find a 98 system somewhere, odds have got to be high some worm or virus is on it already. It's mere existence (today) screams "I don't update my software. I don't care about security or stability." 2000 or even NT4, sure, why not. But 98... nuh uh.
Informed. Thanks. Article VI doesn't mention anything about it being binding to the public, though... while it does make sense that it be binding for the states, I can't see how I could be bound by the Constitution, simply because the rules made there don't apply to the public, they apply to the government. Wouldn't the rules for the people be the criminal and civil codes?
But how on earth could the GPL "violate the United States Constitution". Isn't the Consitution only binding to the Federal govt? ie, even if there was a clause in there saying "RMS is a kook and the GPL == evil and bad, use SCO Unixware instead", that wouldn't prevent anyone but the Feds from using/dealing with the GPL. Right? Have I been smoking too much crack?
(Yes, I know, it's Darl, I shouldn't assume it makes even the slightest bit of sense.)
After that, if your company server isn't able to send mail to anyone, you will update fast, I bet.
That's the thing. It won't happen, becuase nobody wants to take the first step. Just like IPv6, where the first major provider that changes gets to deal with every IPv6 bug in every piece of network equipment that is around. Thus, it's easier to keep using IPv4. Similiarly, nobody would change the mail servers because then they get to deal with all the problems inherent with doing this (when they would rather wait for someone else to deal with it).
Updating server software. Thats what admins are for. Should be possible to do in a year or so.
Just getting this through the IETF would take a year, assuming it wasn't insane. You are discussing a mandatory change to a widely used Internet standard. I don't know if you're aware of how this works, but it's not just "Hey! Let's do X" and it magically happens.
If you don't believe me, then go here, sign up to the SMTP WG list, and get SMTP changed. Then, if you like, you can come back and laugh at me and remind me how wrong I was.
1) Make a law (if your country doesn't have one already) which makes it illegal to send emails with forged FROM fields (= email addresses you don't own)
And when people violate it, you track them down how, exactly? Please explain.
Slightly improve RFC2821 (smtp)
What you term "slightly improve", I would call "change EVERY mail server and client in the world". Oh, wonderful solution. Even if this was pushed through today, it would take years (at best) to happen. As a much smaller-scale example, all new X.509 CAs that comply with PKIX (the IETF X.509 profile) are supposed to start issuing all their certs with UTF-8 on 1/1/04. This is been a requirement of PKIX since at least 1998. Not one single CA is going the change on the cutoff date. Not one. SMTP is thousands of times more widely used than X.509. You are insane if you think this is technically or politically feasible.
Yes, I know this prevents everybody from having his own pretty little smtp server. No, I'm perfectly well with that. Use a provider.
I am very glad you have no ability to carry out any of these actions.
A distributed.net-style project using typical home machines would win, IF you could get a thousand or so people to cooperate.
:) Much easier and faster, I would think.
OR build a crypt() cracker into the next Blaster.
Are crypt() secret keys limited to certain characters?
Yup (this is described in the paper). You get (at most) 8 characters of 7-bit ASCII, cause DES has a 56-bit key (plus 8 parity bits which are completely ignored). Of course it's hard to type \001 into a keyboard, so it's actually a bit less than 2^56. Anyway, changing the upper limit doesn't help that much, even if you modified it (somehow) to use 8-bit characters, the basic algorithm (25 iterations of DES) is just too quick to compute on a modern machine. The MD5 crypt() [common on Linux and *BSD] uses 1000 iterations, which is not bad, but is less than ideal. The OpenBSD Blowfish-based crypt() is very good, because it's very slow. Especially good as it uses up lots (~4K) of memory, which makes a custom hardware cracker quite expensive, which was actually one of the goals of the old crypt() as well (it's just that hardware has caught up with it, and then some).
There are no known ways to break currently acceptable symmetric cyphers (such as 3-DES and AES) faster than brute force
Just a quibble: you can actually break both 3DES and AES faster than brute force. In the cast of 3DES, there is a time/memory tradeoff, and AES has some key schedule weaknesses (though in the case of AES, you need to collect nearly the entire codebook before you can proceed with the attack (at least the one I'm thinking of)). Basically, you're right in practice, just not in theory; none of the (publicly known) attacks on 3DES or AES are remotely close to being practical in any sense of the word.
In any case, as the hardware makes it easier for the attackers, it makes it practical to go with longer encryption keys, so faster hardware is neither a help nor hindrance to attackers.
Actually, the win is probably for the defenders. Double the length of an RSA key, the encryptor has to do 3-4 times as much work, but the person trying to factor it faces an increase that is much, much larger.
F&OSS justifies its existence by claiming to give users freedom; to drop support for a platform for non-technical reasons would be a violation of its own guiding principles.
That is the counter-argument made in the GCC README.SCO file.
8. Urge Free Software and Open Source developers to drop support for SCO Unixware across all softwares being developed. GNU Software (GCC, Emacs, libraries, autotools, base utils), Samba, Apache, OpenSSL, OpenOffice, XFree86, Gnome, KDE, etc.
The GCC 3.4 snapshots have a note in the root directory (README.SCO), which basically says "SCO is a bunch of jerks, and we're considering dropping support for SCO Unix".
While I've never used Unixware, by all reports it's so totally broken that I figure a) it might simplify the build magic quite a bit to drop the bitch anyway, and b) who the hell uses Unixware? Makes much more sense to support something like QNX than Unixware (I would add that a lot of GNU stuff *doesn't* support QNX). Of course that would be up to the developers of each project. But if, say, GNU tommorow said "All GNU projects will from now on explicitly not support Unixware"... well, I would be amused.
The old one seems MUCH more durable.
I agree with you on that. My primary one is circa 1985, and is holding up like a champ. The later models weren't as nice in terms of the feel of the keys, either (though still better than most IMO).