If PTR and A have to match, why aren't they just collapsed to one field?
Which requirement are you thinking about? I know of at least two completely different requirements that people have made, each of which could match the description you gave.
Make a reverse lookup of an IP, and then do a forward lookup of the resulting name to see that you get the original IP. Doing that actually makes sense. If you just did a reverse lookup of the IP, then the provided hostname could be spoofed. Anybody who control reverse lookups can give you an arbitrary domain name. However, if a forward lookup of the domain name give you the original IP, you can have more confidence, that they actually control the domain name.
Require that the name given in an SMTP HELO command match the domainname you get from a reverse lookup of the IP. That requirement doesn't make the slightest sense to me - heeeelloooo if they were supposed to match, why would there even be a HELO command in the protocol? You could just do the DNS lookup and be donw with it. OTOH, requiring that a forward lookup of the name provided in the HELO command actually match the IP the connection originate from would make a bit of sense. But even that may not always be feasible.
For the SELinux thing against null pointer attacks, won't that break DOSemu?
It would if enabled. But the protection is not enabled by default, and if you decide to enable it, you can always create a policy allowing DOSemu to mmap on a low address. Anyway if you are moving to a 64 bit architecture, DOSemu is going to break anyway. So I guess in a few years, it won't matter.
Whether kernel developers take requirements directly from users, or via application software programmers, the end result is the same
No it is not. The typical end user doesn't understand the system well enough to even say what features are needed from the kernel in order to produce a system working in the desired way. And in fact a kernel change alone is hardly ever going to improve the user expierience. And what requests are the kernel developers going to get, if they come from end users not knowing anything about software development themselves? The ones I have seen have always been something along the lines of either stop working on the kernel and start working on this userinterface instead, or make the system work exactly like Windows.
but "usability is a problem for the desktop maintainers ( the KDE or GNOME guys ), not the kernel hackers" is plain false.
Jeez. Most of the usability improvements that people wants are things that doesn't require any kernel changes at all. Why should kernel developers be bothered with requests like, I want this button to be moved to the right and do something else. If a user wants KDE to behave differently, it would be much better for the KDE developers to look on the request and decide how it can be done. And if it requires a kernel change, that developer can explain what he needs from the kernel. Very few end users will ever understand how that kernel feature relates to the user interface change.
If you set FD_CLOEXEC prior to calling other socket routines, the worst that happens is the child gets a fresh socket that's not connected to anything.
If the child already got a file descriptor for the socket, it doesn't matter what state it was in at that exact time. The file descriptor does not go away, the child will still have the file descriptor by the time you are doing something sensitive on that socket. Looking back I think it was a design mistake to make file descriptors inherited across exec by default. Close on exec should have been the default, and you should disable that flag yourself on those few file descriptors you want to keep open across exec.
Of course it is easy to look back and point out mistakes. It is much more tricky to fix design mistakes later. I think it is great when some people insist on at least trying to fix design mistakes rather than keeping them around forever just for compatibility. Of course in this case it is not trivial because the design mistake is probably not implementation specific, but rather in the standard that multiple implementations follow.
As an extreme example, you can have a well-documented single-tasking kernel, and it would be a royal pain
He didn't say that documentation is the only requirement. But it definitely is very important. Undocumented functionality might as well be nonexistent. you need of course both powerfull functionality and documentation of it. But now let's get back to what that comment is really about. Kernel developers shouldn't deal directly with end users' needs. Kernel developers should just give the application developers, what they need. Then it is up to the developers of KDE, Gnome, etc. to make a good user experience. If they need additional kernel support to achieve that, then those application developers can tell the kernel developers, what they need. Users who do not understand the difference between a kernel and a user interface is certainly not in a position to make any qualified statements about what the interface between those two software components should look like.
Coming from an environment with IRIX and Solaris, I must say that I found Linux hell of a lot eaiser to learn than for example Windows. After having used Linux for a few months, I had already learned enough that I was able to hack the kernel on my own. After having used Windows for a few months, I still couldn't get the GUI to behave how I wanted it to, and just wanted to scream.
The ones that don't do either can be assumed to opt-in until such time as they complain.
Wrong, you'd have to assume they did not accept the license change, since they didn't. What you can do is to require all new contributions to be dual licensed until there is so little GPLv2 only code left, that it feels reasonable to remove it. If the license permits it, you could have a tree with some pieces being GPLv2 only and other pieces being GPLv3 only. But either approach will make it a lot more problematic to move code between forks. And yes, forks do exist, though they tend not to diverge a lot from each other, because code is frequently moved between them.
Just cut that part out of the image, and use some algorithm to fill in the blank space without depending on the original data in that area. Hey, if you are blocking out a license plate in that way, the algorithm could even fill in something that looks like a license plate but with some random characters instead of the original ones. It doesn't matter what the algorithm does, since the information you wanted to hide was completely removed before using that algorithm.
> I'm having a hard time understanding how 6 feet of free fall ends in 900g of force
It's not the fall that kills you; it's the sudden stop at the end.
Exactly. So the 900g figure simply means it took 900 times as long time to accelrate during the fall than it took to slow down when it hit the floor. Let's assume a fall from that height took 9 seconds (I could have computed the exact value if the height had been given in standard units), then it means it must stop in just 0.01 seconds when it hits the floor to have a 900g force. (Not completley accurate since the force during those 0.01 seconds is probably not constant, but you get the idea.)
I will almost guarantee that most people here do NOT want an "all-in-one" board.
There may be some on board features, that I would rather be without. But there are definitely some I like to have, such as ethernet interfaces. You can never get too many onboard ethernet interfaces. The last computer I bought had too few onboard ethernet interfaces for my needs, so I ended up having to use all the expansion slots for additional ethernet interfaces. Why do motherboards still come with less than 4x1Gbit/s?
When I was a kid I used to think that ROM meant "Read Only Memory".
When I was a kid new computers had "Electrically erasable programmable read only memory", which made it quite obvious, that it was not as read only as "read only" would imply.
I can't find any consumer drives that can beat 50-60MB/sec
Many new SATA disks can do 70-80MB/s. Still if somebody can tell me where I can find those 4GB/s drives, I'm going to order a lot of those. (I wonder if that guy was thinking about 60 drives in a RAID-0 configuration).
I don't think it counts as "heavy editing" if I can do it in 2 minutes with almost any basic image editing program.
I agree with all your points. However there is another difference, which nobody else mentioned. The logo on the cap was removed, probably because it wouldn't have done well together with the caption. I wonder if there are other details, which we have not spotted yet.
Why have that not been blocked yet? I think the operators should be required by law to block any calls with forged caller ID. And if they don't, they should be held liable for the calls they let through.
My boss once worked for a startup that was getting low on funds, so they asked all the employees to sign a waiver agreeing not to be paid for the most recent month (or whatever). The people who didn't sign got their pay--and got laid off.
I have a very hard time imagining the circumstances where I'd be willing to sign that. What is the probability one is ever going to see that money? Sure, one could work for another month and maybe get a payment then, and then another month, and then the company might again not be able to pay. And at that point you'd have wasted two months and got no more money than you would have if you had just taken your money and left. There are many better ways to spend two months than to be working hard and unpaid for a company in trouble.
I wouldn't be surprised if there are countries in which signing such a waiver couldn't be legally binding. If you were sure it wouldn't be legally binding, you could sign it and sue them when you don't get your money. But still the effort may be better spend looking for another job.
But I guess you could theoretically use hash collisions by designing random data for a piece that has the same checksum?
A collision attack is not sufficient for that, because it is just going to give you two pieces of data with identical checksum. What you need is a second preimage attack, which will allow you to produce another piece of data matching the same checksum as the one you have already got. A second preimage is significantly more difficult to generate than a collision. For brute force attacks, you need O(2^n) for a second preimage and only O(sqrt(2^n)) for a collision. Could be faster if you find a weakness in the hash. A collision in md5 was demonstrated a few years ago, I don't think a second preimage will be feasible anytime soon.
I'm not sure how easy this is for SHA1 though.
More difficult than for md5. For sha1 there haven't even been demonstrated a collision yet. I think there was found a weakness, which would do it faster than brute force, but still not fast enough for anybody to bother demonstrating it.
Be liberal in what you accept, and conservative in what you send.
A long time ago I actually believed in that. But not anymore. Being conservative in what you send is the only part of that statement, which I believe is always good. Being liberal in what you accept is good in some situations, in other situations it is just going to hurt. The place where it is going to hurt the most is if you need to pass the data on to some other party. If you just accepted something which was out of specs and need to pass it on, you will either have to mange the data or pass on something out of specs. Neither of those is a good idea. In fact that kind of situation have lead to some security problems, where something out of spec ends up being interpreted differently by different parties.
Another reason why being forgiving in what you accept is bad, is when it may be ambigious. You just accepted something from the client which was out of spec, and you may have interpreted it differently from what the client intended. Any further communication is just going to be misunderstandings because the two communicating parties are no longer on the same page. If a client sends something that is so much out of spec, that it could be misinterpreted, it is better to just break the connection, and optionally write a message to your log file.
Yet another reason for not being forgiving is, that if everybody are forgiving in what they accept, new implementations are more likely to get away with sending bad data. And consequently they are forcing everybody to be able to interpret all sorts of crap. Being forgiving in what you accept may be a convenient short term solution. But to make a protocol robust on a long term, I think it is better if there are as few ways as possible to format the packets you send. And then of course an unambigious document describing the standard. Extensibility is still possible, it just have to be formalized in the initial standard, such as fields which must have a specific value in the current implementation, and must be ignored by the recipient.
There are two cases where I think it is good to be forgiving in what you accept. Some standards have some pretty arbitrary limits (such as a maximum line length of 1000 characters). Making an implementation that accepts data larger than required by the standard, is probably fairly safe, as long as it is properly formatted. The other case is when you are receiving input from a user rather than a program. It is ok to be forgiving in what you accept, as long as you can inform the user how you interpreted it. For example there is more than one way to enter a date, if there is no immediate harm in misunderstanding such a date, I think it is best to be forgiving in what you accept and immediately inform the user how you are going to interpret the date. So if you are just doing some kind of query, worst case is that you don't get the information you were looking for, and you will know why. And if you are actually performing a transaction, there could be another step allowing the user to confirm that the interpretation was correct.
But unless you somehow pass that trust forward somehow you haven't done a thing for any mail host other than your own.
If everybody would just take proper care of their own mail server, the problem would be solved.
Remote systems may still need to bounce the message, and they have no way to validate the sender.
Actually validating the domain would be sufficient. There have been attempts at this, but none that will work in every situation.
But any legitimate email will only travel through mail servers that are either affiliated with the sender or with the recipient. So as long as mail servers affiliated with the sender verify that the sender address is correct, and any mail server affiliated with the recipient verify that the recipient is valid before accepting responsibility for the email, you will get no spurious bounces. In fact all bounces would be going to a local recipient which you had already validated was correct.
The reason why most applications want to access the/etc/passwd file is to get your home directory.
That would be a bug. The application is supposed to use the HOME environment variable. If you get different directories by looking in/etc/passwd and using the HOME environment variable, then the environment variable is the one containing the correct directory.
Strace relies on a kernel interface which cannot be disabled by Joe Average Luser.
And ltrace relies on the exact same interface, just tries to figure out some other things using it. The first of a few things to notice is, that strace is not completely transparent. There are bugs in at least some kernel versions, that causes system calls to sometimes return wrong return values when strace is being used. And for some system calls such as vm86 strace will actually show incorrect information about which system calls are being made. ltrace is even more tricky to get right. With static linking and very agressive optimization, it could become impossible to do what ltrace wants to do. Not seing getpwuid or related library calls is no definitive proof, that they are not being made. To make matters worse, even if/etc/passwd was only accessed through ordinary getpwuid calls to glibc, it might still be possible to get the entire contents of/etc/passwd. Once glibc have read it, pieces of it could be left around in memory from where it could trivially be read without making any system calls. The good news is, that/etc/passwd normally doesn't contain very sensitive information.
Whether that approach gives false positives depends on the size and complexity of the piece of code they had to write. As a teaching assistent I have seen assignments that looked even more like copying than what you described, but even in that case they were eventually accepted. One time the students had to add some functionality to an assembler. All groups were given the same code to start with and just had to add one clearly defined piece of functionality. There is really not many ways to do that, so having two assignments looking suspiciously similar might not trigger any red flags. But when they also had accidentially added some whitespace in a piece of the code that they didn't even have to change, it looked a lot more suspicious. In a later assignment, they were asked to change the scheduler in Linux 2.2 to give each user the same share of CPU time. All groups came up with different solutions, except from two, which were identical except from variable names and white spacing. And that was the same two groups that had handed in something suspiciously similar in an earlier assignment.
You do have some valid points, but there are solutions for such problems. For example the ISP case you mention can validate the sender, once you have validated the sender the problem is solved.
In the case of a relay, it can almost be done in the way you describe. Actually you forgot to mention one problem. Relay sends message to first recipient domain and gets OK, next relay sends message to second recipient domain and get a temporary error condition. When I was implementing such a system myself, the only solution I could think of for that problem was to disallow recipients in different domains in a single transaction. There is a response code in SMTP to indicate that the maximum number of recipients for a single transaction has been reached. If you use that it is the senders responsibility to do another transaction with the remaining recipients.
Using that response code before you have accepted 100 recipients could be considered a violation of the RFC. But I feel a lot better about violating that limit than silently losing data. Besides I have never seen a server actually sending messages for different domains in the same transaction. What they do is, that they group the recipients by domain, and then does one session per recipient domain. It would be more complicated to actually detect when messages for two different domains can be sent to the same IP address.
In my case I had some additional requirements, that DynDNS does not have. I wanted my relay to be completely stateless, and sometimes I wanted to change the destination address in ways that caused me to use the 452 code when the previous hop saw two recipient addresses in the same domain. So I checked my log and found that my mail server have used that code five times during those 1½ years I have logs from. And all five times the previous hop correctly did another transaction for the remaining recipients - it did wait for half an hour before doing so though. But a half hour delay in a situation that is probably never going to happen to a legitimate email is IMHO better than silently losing data.
But since DynDNS is not really trying to avoid keeping state on their relays, they can do better than what I did. For eaxmple they can cache information about valid recipients. If a recipient was valid at some point within the last week, but it is not currently possible to validate it, I'd say it is OK to accept the mail. You may have to bounce a few mails that way, but still you have made a significant cut in the number. Caching can also help a bit on the multiple recipient domains problem - if they are ever going to experience that at all.
Why in the would would you bounce a message that you _already_ know to be invalid?
If you knew, you wouldn't. But you don't know. The only thing you know is, that you have a message with a valid recipient, which you are not going to deliver. This is the kind of thing that causes the mail system to be less reliable today. If you silently drop it, you are going to make the system even less reliable. It is bullshit when they say the mail system is more reliable today, the wide presence of spam filters make it less reliable.
Generating a bounce when you do not deliver an email is not a problem, as long as you do it right. Yes there will be generated some spurious bounces, but those are almost trivial to identify and reject. A bounce can be identified by the empty envelope sender. And once you have identified the mail as a bounce, you can verify validity by looking for the message-id of something you have sent. So if you are able to keep track of the message-id of everything you send yourself, then you don't ever have to be bothered with spurious bounces.
The only problem is those systems that violate the RFC by putting a sender address on their bounces. Whenever I see such a mail I wish the server would fall over from a bounce loop.
Silently dropping mail to valid recipients is causing more harm than a correct bounce - which means empty envelope sender and include full headers of the message you are bouncing. But of course it is even better if you just refuse to receive the email and let somebody else have the hassle of generating the bounce. The earlier you can identify that a message is not going to be delivered, the more reliable you can make the system.
A huge part of security is having sane defaults. If you support 'secure' and 'insecure' you should default to 'secure,' and let users who know what they are doing, and need 'insecure' behaviour opt into it.
So when I type a domain name into my browser, it should default to https instead of http like all the browsers I have seen so far?
Slashdot Mirror
Jeez. Most of the usability improvements that people wants are things that doesn't require any kernel changes at all. Why should kernel developers be bothered with requests like, I want this button to be moved to the right and do something else. If a user wants KDE to behave differently, it would be much better for the KDE developers to look on the request and decide how it can be done. And if it requires a kernel change, that developer can explain what he needs from the kernel. Very few end users will ever understand how that kernel feature relates to the user interface change.
Of course it is easy to look back and point out mistakes. It is much more tricky to fix design mistakes later. I think it is great when some people insist on at least trying to fix design mistakes rather than keeping them around forever just for compatibility. Of course in this case it is not trivial because the design mistake is probably not implementation specific, but rather in the standard that multiple implementations follow.
Just cut that part out of the image, and use some algorithm to fill in the blank space without depending on the original data in that area. Hey, if you are blocking out a license plate in that way, the algorithm could even fill in something that looks like a license plate but with some random characters instead of the original ones. It doesn't matter what the algorithm does, since the information you wanted to hide was completely removed before using that algorithm.
Exactly. So the 900g figure simply means it took 900 times as long time to accelrate during the fall than it took to slow down when it hit the floor. Let's assume a fall from that height took 9 seconds (I could have computed the exact value if the height had been given in standard units), then it means it must stop in just 0.01 seconds when it hits the floor to have a 900g force. (Not completley accurate since the force during those 0.01 seconds is probably not constant, but you get the idea.)
I wouldn't be surprised if there are countries in which signing such a waiver couldn't be legally binding. If you were sure it wouldn't be legally binding, you could sign it and sue them when you don't get your money. But still the effort may be better spend looking for another job.
More difficult than for md5. For sha1 there haven't even been demonstrated a collision yet. I think there was found a weakness, which would do it faster than brute force, but still not fast enough for anybody to bother demonstrating it.
Another reason why being forgiving in what you accept is bad, is when it may be ambigious. You just accepted something from the client which was out of spec, and you may have interpreted it differently from what the client intended. Any further communication is just going to be misunderstandings because the two communicating parties are no longer on the same page. If a client sends something that is so much out of spec, that it could be misinterpreted, it is better to just break the connection, and optionally write a message to your log file.
Yet another reason for not being forgiving is, that if everybody are forgiving in what they accept, new implementations are more likely to get away with sending bad data. And consequently they are forcing everybody to be able to interpret all sorts of crap. Being forgiving in what you accept may be a convenient short term solution. But to make a protocol robust on a long term, I think it is better if there are as few ways as possible to format the packets you send. And then of course an unambigious document describing the standard. Extensibility is still possible, it just have to be formalized in the initial standard, such as fields which must have a specific value in the current implementation, and must be ignored by the recipient.
There are two cases where I think it is good to be forgiving in what you accept. Some standards have some pretty arbitrary limits (such as a maximum line length of 1000 characters). Making an implementation that accepts data larger than required by the standard, is probably fairly safe, as long as it is properly formatted. The other case is when you are receiving input from a user rather than a program. It is ok to be forgiving in what you accept, as long as you can inform the user how you interpreted it. For example there is more than one way to enter a date, if there is no immediate harm in misunderstanding such a date, I think it is best to be forgiving in what you accept and immediately inform the user how you are going to interpret the date. So if you are just doing some kind of query, worst case is that you don't get the information you were looking for, and you will know why. And if you are actually performing a transaction, there could be another step allowing the user to confirm that the interpretation was correct.
Actually validating the domain would be sufficient. There have been attempts at this, but none that will work in every situation.
But any legitimate email will only travel through mail servers that are either affiliated with the sender or with the recipient. So as long as mail servers affiliated with the sender verify that the sender address is correct, and any mail server affiliated with the recipient verify that the recipient is valid before accepting responsibility for the email, you will get no spurious bounces. In fact all bounces would be going to a local recipient which you had already validated was correct.
Whether that approach gives false positives depends on the size and complexity of the piece of code they had to write. As a teaching assistent I have seen assignments that looked even more like copying than what you described, but even in that case they were eventually accepted. One time the students had to add some functionality to an assembler. All groups were given the same code to start with and just had to add one clearly defined piece of functionality. There is really not many ways to do that, so having two assignments looking suspiciously similar might not trigger any red flags. But when they also had accidentially added some whitespace in a piece of the code that they didn't even have to change, it looked a lot more suspicious. In a later assignment, they were asked to change the scheduler in Linux 2.2 to give each user the same share of CPU time. All groups came up with different solutions, except from two, which were identical except from variable names and white spacing. And that was the same two groups that had handed in something suspiciously similar in an earlier assignment.
You do have some valid points, but there are solutions for such problems. For example the ISP case you mention can validate the sender, once you have validated the sender the problem is solved.
In the case of a relay, it can almost be done in the way you describe. Actually you forgot to mention one problem. Relay sends message to first recipient domain and gets OK, next relay sends message to second recipient domain and get a temporary error condition. When I was implementing such a system myself, the only solution I could think of for that problem was to disallow recipients in different domains in a single transaction. There is a response code in SMTP to indicate that the maximum number of recipients for a single transaction has been reached. If you use that it is the senders responsibility to do another transaction with the remaining recipients.
Using that response code before you have accepted 100 recipients could be considered a violation of the RFC. But I feel a lot better about violating that limit than silently losing data. Besides I have never seen a server actually sending messages for different domains in the same transaction. What they do is, that they group the recipients by domain, and then does one session per recipient domain. It would be more complicated to actually detect when messages for two different domains can be sent to the same IP address.
In my case I had some additional requirements, that DynDNS does not have. I wanted my relay to be completely stateless, and sometimes I wanted to change the destination address in ways that caused me to use the 452 code when the previous hop saw two recipient addresses in the same domain. So I checked my log and found that my mail server have used that code five times during those 1½ years I have logs from. And all five times the previous hop correctly did another transaction for the remaining recipients - it did wait for half an hour before doing so though. But a half hour delay in a situation that is probably never going to happen to a legitimate email is IMHO better than silently losing data.
But since DynDNS is not really trying to avoid keeping state on their relays, they can do better than what I did. For eaxmple they can cache information about valid recipients. If a recipient was valid at some point within the last week, but it is not currently possible to validate it, I'd say it is OK to accept the mail. You may have to bounce a few mails that way, but still you have made a significant cut in the number. Caching can also help a bit on the multiple recipient domains problem - if they are ever going to experience that at all.
Generating a bounce when you do not deliver an email is not a problem, as long as you do it right. Yes there will be generated some spurious bounces, but those are almost trivial to identify and reject. A bounce can be identified by the empty envelope sender. And once you have identified the mail as a bounce, you can verify validity by looking for the message-id of something you have sent. So if you are able to keep track of the message-id of everything you send yourself, then you don't ever have to be bothered with spurious bounces.
The only problem is those systems that violate the RFC by putting a sender address on their bounces. Whenever I see such a mail I wish the server would fall over from a bounce loop.
Silently dropping mail to valid recipients is causing more harm than a correct bounce - which means empty envelope sender and include full headers of the message you are bouncing. But of course it is even better if you just refuse to receive the email and let somebody else have the hassle of generating the bounce. The earlier you can identify that a message is not going to be delivered, the more reliable you can make the system.