Fink was asked what he thought about SCO's allegation... [that HP's actions reinforced SCO's position.] He called SCO's words, "An interesting spin," and carefully pointed out that HP has no official position on the validity of SCO's claims. "That's up to the courts to decide," he said.
Timothy:
HP's Martin Fink roundly denies SCO's backhanded interpretation.
sammy baby:
C'mon, man. At least make an effort.
No, I think Timothy's interpretation is correct. There are two SCO assertions being discussed here:
That Linux users are violated SCO's intellectual property (what roblimo referred to as "SCO's claims")
That HP's statement affirms these original arguments (what timothy referred to as "SCO's backhanded interpretation").
HP said they have no official position on the former. The latter says otherwise, so HP denied the latter. Timothy was right.
Or instead of ditching make altogether, perhaps they'd just generate the Makefile from some other format.
Why? Then you've written your own parser and generator. The generator is barely simpler than the topological sort and parallelized execution code and requires make, which normally lives dynamically linked in the/usr partition. I'm all for reuse, but at some point you have to realize that (A) the fraction of it you're using is not saving you code and (B) the extra functionality you don't need will probably still drag you down in some way.
> > Most surprising to me is the use of 'make' to handle dependencies between services."
> Really? That's an odd statement. How surprising that they choose to use an open-source software application that is designed to compactly represent dependencies for representing dependencies.
Actually, I also found it surprising, and I think I know "make" pretty well. The thing about make is that in 95% of cases almost all of the rules correspond to an actual target file that should be generated or not based on presence and timestamp. There are exceptions, like the usual "all" rule that's called a phony rule since it generates no file. (And make sure you have a ".PHONY: all" line right before it or "touch all" will break your build.) It's usually just there for the dependencies on a bunch of real targets, so you don't have to type "make this && make that && make...".
Parts of make that they're not using here:
logic for checking if a real target is up-to-date
rules for creating specific targets from generic ones, like the.c.o target
variable substitutions
a lot of other things...look at the man/info pages; modern versions of make have a lot of functionality that makes no sense here
And they are using:
topological sort (easy algorithm!)
stuff for following the partial order in parallel (also surprisingly easy)
the parser, but it's for a widely-disliked syntax that doesn't make a lot of sense here
When I say the syntax doesn't make sense here, I mean (in addition to the usual make complaints) that it's all in one file. Distributors (notably RedHat in particular) have been very serious about separating out stuff into.d directories so that packages don't need to touch each others' files.
So, I think make is the wrong tool for the job here, at least in the long term. A simple tool with separate files for each service would be a win. I don't think the author of the article really cares about that (it's just a little tip for intermediate users), but if a distribution wanted to implement this idea and maintain it, they wouldn't use make.
Re:We really need a different language
on
Secure Programming
·
· Score: 1
Buffer overruns are only a security hole if the buffer is on the stack, where an overrun can overwrite the function's return address.
That's not true. Google for security "heap overflow" and you'll see a lot of advisories and exploits for bugs of this nature.
If it's on the heap, overwriting the stack in a controlled way becomes immensely difficult at best, maybe even impossible depending on the architecture.
"Immensely difficult" isn't good enough; there are people who live for this stuff, as shown by the link above. Even impossible isn't good enough, because there's still a denial of service attack. The only even remotely secure thing is to not have a buffer overflow. There are dozens of languages in which this just isn't a concern.
Re:We really need a different language
on
Secure Programming
·
· Score: 5, Informative
qmail and djbdns do not have security holes.
Bah. That they do not have security holes is implausible, if not actually impossible, to prove. It's hard to even define what a security hole is; a changing threat model has "caused" many security holes. (Is an open relay a security hole? I say yes. Twenty years ago, everyone said no.) I doubt your statement. I can't point at a hole right now, but I have confidence that at least one security hole will eventually be discovered in those programs.
They were written using secure coding techniques that make them immune to things like buffer overflows. You can't "overlook" a buffer overflow with stralloc.
No, they make it easier to avoid buffer overflows. They don't prevent them: I quote from your hyperlink:
A stralloc structure has three components: sa.s is a pointer to the first byte of the string, or 0 if space is not allocated; sa.len is the number of bytes in the string, or undefined if space is not allocated; sa.a is the number of bytes allocated for the string, or undefined if space is not allocated. A stralloc variable should be initialized to {0}, meaning unallocated.
Applications are expected to use sa.s and sa.len directly.
If they use sa.s and sa.len directly, they can screw up and increase len inappropriately. The API seems good in that it makes it much harder to do things wrong, but it is hubris to say it makes you invulnerable. Besides, buffer overflows are possible for things other than strings, so this solves only (the most common) part of the problem. And there's still the legacy code that people can use without porting to stralloc.
It does seem like a good library if you're stuck using C. Another alternative is APR, which makes managing all sorts of memory allocations much easier. Pools are handy things when dealing with a language that primitive.
But there are languages in which it actually is impossible to have a buffer overflow. Please don't confuse the issue by saying that this (which makes it somewhat easier to avoid this error) makes the error impossible.
That's a really cool article. I have a bit of skepticism for one part of it, though: the woman with no sense of balance. The summary: she lost her sense of balance because an antibiotic killed the hairs lining her inner ear. She couldn't walk. When she strapped this thing on to her tongue (essentially an array of electrodes connected to an accelerometer), she could. But then:
Schiltz later took the experiment even further. After 20 minutes spent centering the circle, she took off the hat, pulled out the electrodes, and kept her balance for a full hour without any apparatus. "I ran through the building in my socks," she says. "I danced with Paul and climbed up and down chairs and tables. I felt cured, literally cured."
They give no explanation for this (it's the last paragraph). So obviously she has learned to compensate for not having that sense, since she can function without being strapped to the accelerometer. I can see two explanations here:
she had been developing the ability to function without it slowly, and the hour with the sense "back" was enough to reinforce this ability. She could then function without it.
it was the placebo effect. Whether or not the accelerometer was even connected wouldn't have mattered. She believed she had her sense of balance back and functioned without it. Then when it was taken away she still functioned without it.
I'm kind of leaning toward #2. Now, what is quite impressive is when the reporter managed to see the outline of large letters. Assuming they didn't give him too much feedback, there's no other real explanation than that the device worked.
Even if you only get a recorded message, they pay toll fees for every incoming call. Once you start hearing a busy signal, their cost is zero.
They've called my cell phone before, and that cost me money. When I warned them, they did not do it again, but they should have checked more thoroughly to begin with. So I don't have much sympathy for them when they whine that we are costing them money.
BerntB said: From ISR's FAQ on space elevators, it is: 7.5 kg/km
Oops. Noted.
(-: I haven't studied physics since high school, but don't have a headache -- and had the energy to check the FAQ. The moral of this is left for the reader to think out, but probably has something to do about how students should limit alcohol intake.:-)
I don't drink, actually. I got this headache all on my own merits.
It's not like we're talking about a high tension cable here.
Actually, yes, we are. That's why advances in materials science were necessary before they could even think about building this thing. I quote from the article:
The biggest technical obstacle is finding a material strong but light enough to make the cable; this is where the carbon nanotubes come in. These are microscopically thin tubes of carbon that are as strong as diamonds but flexible enough to turn into fibre. In theory, a nanotube ribbon about one metre wide and as thin as paper could support a space elevator.
The cable's structure will be balanced by gravity -- the center of gravity will rest at the geosynchronous point, meaning that the bottom half will be falling toward Earth while the top half will be moving away at an equal rate.
Being "balanced by gravity" means there's a huge amount of tension here. In fact, that basically says that the top half (by mass - by distance probably a very small proportion of the thing) holds up everything below the center of mass at the geosync point. (Or from the other perspective: the bottom half holds down the top half, which would fly off into space otherwise.) It does that with tension in the cable, and we're talking about a lot of tension in the cable.
Let's put concrete numbers on it: carbon nanotubes are pretty light, but we're still talking about 35,785 kilometers in the bottom half (by mass) of the elevator - that's geosynchronous orbit around the earth. Say the elevator is 1 kg / m (very conservative, I think), which we'll call lamba (normal for linear density). Now gravity changes along the length of the cable (that's sort of the point), so we need an integral to calculate the force of gravity pulling the thing down:
F = \int GM dm/r^2 = \int GM \lambda dr / r^2
(where dm = \lamba dr). From my Physics I book, r_e (the mean radius of the Earth, which is a bit higher than sea level but not too bad) is 6.37 * 10^6 m. M (the mass of the earth) is 5.98 * 10^24 kg. And G is 6.67 * 10^-11 N*m^2 / kg^2. So the integral becomes:
F = \int_{6.37 * 10^6 m}^{6.37 * 10^6 m + 3.58 * 10^7 m} (6.67 * 10^-11 N*m^2/kg^2) (5.98 * 10^24 kg) (1 kg / m) dr / r^2 = 5.3 * 10^7 N = 53 MN (mega-Newtons)
...which I think is the require tension right above that point. I can't think off-hand exactly how geosync works, but essentially the stuff above that is being sped up and the stuff below (and the Earth itself, though not significantly) is being slowed down by that tension.
Disclaimer: I'm an undergrad physics student with a headache. I very well may have made a mistake above, but I guarantee it's closer than the parent post.
So, by your logic, if a woman gets gang raped and beaten to death, its her fault because she should've worn her burka and not gone out of the house unaccompanied by a male relative. Red-blooded, honest men cannot control themselves from the intoxicating effects of nearby females, and she should've known that!
Wow, what a straw man. Here's a closer analogy: you own a gun, which you keep loaded with the safety off. Your kid has a friend over. He finds it and accidentally shoots his friend. There are a range of crimes you could be charged with, up to involuntary manslaughter, I believe.
There are two key things here that make this a better analogy: (1) the precautions you should have taken are quite reasonable and (2) you are not the only victim; your negligence impacts other people. [*] It's not perfect - there was a willful crime being penetrated in the original case. But that's what happens when you go with analogies instead of talking about the thing itself.
[*] - Even ones who are not infected. The rest of us still have to pay for bandwidth and sort through our email. I received so many copies of not only the worm, but responses to worms forged as being sent from me.
Sounds like you had a horrible experience with one. But the problems you saw were bugs in the software, not fundamental problems with the concept. One by one...
I worked at a local ISP who managed to get a demo for a cache server a while back. (I don't anymore.) The machine arrived. We plugged it in, and started to take tech calls.
Sounds like this was your mistake. You "managed to get a demo" speaks volumes. Sounds like an expensive proprietary product from a small company. If you had just downloaded Squid, I don't think you would have encountered all these problems.
The server had a difficult time with virtual hosting of any kind. About 4 out of 5 requests to a virtual host would go through. About 20% of the time, there was some critical piece of information that the cache server would mangle so that the vhost mechanism would be unable to serve the right data. This was a couple years ago, so bugfixes might have happened. Maybe.
Sounds like it only supported IP-based virtual hosting. Back in the day, most sites would have had separate IPs for everything they hosted, so that percentage sounds right. The 20% that failed needed a "Host: www.virtual.com" header.
The server definitely had a hard time with dynamic content that wasn't built with a GET url (thus triggering the pass-thru proxy). If the request was posted, encrypted, hashed, or referenced a server side directive of some kind (server-side redirects were a nasty) the cache would fail. A server side link equating something like "http://www.server.net/redirect/" to a generated URL or dynamic content of some kind was the most frequent case we rean into with this. The server simply couldn't parse each and every http request or every variety and try to decide if it should pass-thru or not. I can't think of a logical way around this that wouldn't break any given implimentation. Can you?
First, I think you mean a POST query would trigger the pass-through. GET is the normal method.
Second, there are pretty simple ways for triggering a cache or not. The full rules are here, but very roughly a page should be cached if and only if:
There is an "Expires", "Last-modified", or "E-tag" header set
There is no "Cache-control: no-cache" header set
There was no authorization domain required (HTTP authorization; this doesn't catch forms of course)
If one is in the cache other than the Expires (which doesn't even need to be checked), it will query the server and check if the content is the same as before (with a special header that instructs the server not to send anything if it's unchanged).
This is a nice rule because webservers tend to automatically set the Last-modified: date on plain files and never do on dynamic stuff, so you have to explicitly add it in your dynamic code after considering it. So it gets most of the static stuff automatically (and that's generally the big stuff - images) but is cautious with anything dynamic. That's the correct approach.
This scheme really only breaks down when clock used by the requester (cache server in this case, browser also) or by the content generator (possibly the webserver, but also maybe the desktop used to generate stuff and then upload to the webserver) is skewed. And even then, it just gives stale data; not one person logged in as someone else. And this problem occurs even without a caching server, since browsers implement caching by themselves. Really, having a correct time is important to lots of things on computers. For example, don't ever try to do development without your clock being correct; build tools will be completely unable to tell what's up-to-date and what's not. Ticket-based network authentication systems (like Kerberos implementations, including Microsoft's shiny new ActiveDirectory) will refuse to log you on. etc, etc.
We used dynamically assigned IPs at the time, so proxy requests made
Many software programs that dynamically allocate ports likely will use some ports you block, and users applications will just fail "randomly".
What software programs? I'm aware of no applications that accept connections on a dynamically-allocated secure (<1024) port.
There are a few that initiate connections from a dynamically-allocated secure port. I believe the r* applications (rsh, rlogin, rcp) do. The goal is to prove the code is being run as root, so the username field can be trusted. But many people would argue that these applications are broken and s* should be used instead, since IP addresses can be spoofed. Even if you consider them important, you could avoid breaking them by only blocking incoming connections (either by SYN packets or, better yet, stateful filtering).
I could see this being a problem in blocking a >=1024 port. Then the behavior you describe could happen with some applications, as some do accept connections on dynamically-allocated ports. Active FTP comes to mind. Many people (myself included) would say active FTP is broken, but few users would know to switch to passive and their only hint shouldn't be random failures. I think there may be some peer-to-peer applications that do this, also. But they tend to just try a different port when it doesn't work, so that's not such a big deal.
I think that this is the perfect environment for an anti-worm. If the spread of such a worm was limited to the college's netblock, it could be easily controlled (luckily computer viruses don't spontaneously mutate) and it could be set to download all needed patches from a campus server, and destroy itself on command from the same server
A worm has a bunch of properties that aren't desirable here:
every machine probes all the others - this slows down the network, as we've all seen. Centralized machines with more coordination and such probing machines systematically would be more friendly to the network. (Worms do this to catch people when they cross network boundaries with a laptop and such (unnecessary), to catch stuff unreachable from earlier machines (unnecessary), and to make it hard to see where the attack came from (unnecessary).
it lingers around on the machines (so that it can do the above) - undesirable. Once a machine is patched, it should go back to doing whatever it's doing rather than running worm code.
opens the machines to new security flaws - downloading stuff from a centralized server? Do you check a cryptographic signature of the downloaded code? How do you keep the key secure? What if you screw up the logic?
Now, you might say that those problems are only temporary, but what if your screw up the code to make the worm destroy itself? Then you have no way to control the outbreak - you've already patched your only sure way to get in.
A better way would be for your machines (ones you control without having to infect) to scan machines and send code that exploits the vulnerability and patches it. Nothing else. But even this would never fly; see below.
Why haven't antivirus companies caught on to this? They could sell customized anti-worms to small-to-medium size network owners. The problems of releasing an anti-worm on the Internet at large don't apply to smaller networks. You can get the permission of all the network admins before releasing the worm, and a central server can be used to control the infection, keeping track of which computers are patched and shutting down the worm when it has done its job.
Trust. They may be able to get the permission of all the network admins, but they'd never get the permission of all the owners of the machines. If someone were trying to break into my machine, I'd throw a fit, even if I believed their intent. They could screw up, opening my machine to new vulnerabilities. The correct thing to do when you notice someone else's machine is vulnerable is to TELL THEM they have a problem and TEACH THEM how to fix it.
I run a College network, and the thought of any Tom, Dick or Harry being able to wander in and use my network for pretty much anything would be enough to give me nightmares for a month. Can you imagine the potential security issues there, or virus outbreaks? Cold shower time...
But they can already, most likely. Where are your Ethernet ports? If someone just plugs a laptop into one, what will happen? (On most networks, the DHCP server will issue the laptop an address and the "intruder" can go about his/her business merrily. To actually prevent random people from using the network, you'd have to actually authenticate the people whenever they use it, probably with a VPN. Remember, MAC addresses can be spoofed easily.) How is this different with a wireless network, aside from not needing to find an Ethernet port?
To really achieve security, you need a segmented network with firewalls between that don't trust anyone more than necessary for them to do their work. And if you're worried about traffic being captured, encryption. (Either a VPN or application-level encryption like SSH and SSL.) I don't really understand how wired or wireless changes that.
Apparently coming soon, these rules will be created automatically for non-ambiguous views. The great thing is that you will still be able to modify these rules, to make any logic happen as the result of a view update.
I'll be looking forward to that. I saw a little bit of discussion about it, but missed the final result. Will it work just single-table queries, or will it be able to handle stuff like this?
create view employee_formview as select employee.*, supervisor.lname as supervisor_lname, supervisor.fname as supervisor_fname, department.name as department_name from employee natural join department left join supervisor on (employee.supervisor_id = supervisor.employee_id);
(ugh, slashdot butchered the indenting, sorry. it doesn't seem to to preserve spaces either with or in a <ecode> block.)
Oracle's behavior is to allow inserts, updates, and deletes. You can only set the columns in the first table mentioned ().
This works well for Oracle Forms-based stuff; I just set the other columns to "Query Only" and have LOVs (Lists of Values; a fancy drop-down sort of thing) that set them and the ID fields at the same time. Both changes appear on the screen and only the ID fields are sent to the database.
You don't have to do that much work, you just need the one rule.
Sure, if you are only wanting to support UPDATE. But I think that UPDATE, INSERT, and DELETE require separate logic. And most people want to support updating more than the one field.
One of my favorite ways to do this is with a table that consists only of a primary key and a "dirty bit". [...] When you select data of of your database, you just make sure that you don't pull any data that's dirty.
So when data are in the process of changing, they just don't show up in queries? That's horrible. And what happens if the system goes down in the process of changing? You can't roll back; the old data are lost. And you have to manually go in and clear the dirty bit for the broken, half-new data to be even remotely accessible. Or code logic checking for this everywhere, which would be a nightmare of duplicated, unnecessary code.
With this method, you will eventually run into a case where you will have to pull an old backup because a transient failure caused your stupid method to corrupt a lot of data. Transactions are pretty much essential to ensure correctness; you'd have to reimplement the transaction system to get its guarantees, and it's much smarter to use the one that's already there and tested.
And what about procedures that need a consistent view of the database? There's more in ACID than the "A". Transation isolation is necessary for a lot of applications. They can ensure that multiple queries were run on the same set of data.
If people aren't thinking about their data and doing stupid things, that's entirely separate from their using transactions. There are methods for rigorously proving that your transaction use is correct. I strongly recommend to you that you study them. You sound like you care a lot about correctness. You're not achieving it at all now. If you used transactions, you could.
InnoDB transactions don't include the DDL so your create table/index etc... WON'T roll back when you cancel a transaction - so really mysql transactions are for inserts, updates and deletes ONLY. Don't give me this crap about innodb being the be all and end all..
That's also true for Oracle. DDL statements just aren't transactional, and that's not a problem. (Some might be in PostgreSQL...I seem to recall something weird about that. But I don't consider it an advantage.) If you are care about DDL statements in transactions, you're doing something seriously wrong. It's something that you do manually (not from an application!). You don't have simultaneous DDL statements going on. And you should be able to figure out the opposite statement yourself.
As for the rest, that's pretty bad. I design my databases with data types for a reason, so when the database doesn't enforce it...ugh. And inserting anything other than what I say (-99.99 instead of -100) is no good, even if I told it to do something impossible (it should throw an error instead).
This from a proud user of PostgreSQL (and Oracle at work).
I don't know, but one critical missing for me is writeable views.
It already has them. You have to write the rule yourself, so it's not nearly as convenient as in Oracle, but it's possible. It's something like:
create rule foo_ins as on insert to bar_v do instead ( insert into bar (...) values (...); )
create trigger foo_up as on update to bar_v do instead ( ... )
Now, I could see why you'd really want these to be automatic, as updating the definition of these rules manually is a maintenance headache. But you can do it.
For those with this problem, there is a wiki with a set of helpful SpamAssassin rules to filter out the worst offenders. Culley Harrelson was kind enough to point me at the rules.
> > Email needs to be reliable communication medium. If a message can not be delivered, it has to be returned to the sender.
> The thing is, the sender was forged. Since the virus scanner knows the message was a virus and correctly identifies it as such, shouldn't it know that the virus uses forged headers? And since it should know the header was forged, it should NOT return the message.
Sure, if the virus scanner is 100% sure that it has identified a virus email. But a lot of times, these things aren't 100%:
Many people are just blocking all Win32 executables, which could stop a legitimate attempt to send a program. In that case, it would be helpful to say "if this is deliberate, put it in a.ZIP file" or something. Silently discarding the message is right out. (I do this with a 5XX rejection response after the DATA command.)
Also, many people are discarding the messages by subject. I'm also doing this, because sometimes I get virus emails without the actual attachment payload. (I'm not sure if the virus just doesn't always send it or if it was stripped out en route.) I have gotten legitimate emails with the subject "Thank you!" before. It's acceptable for me for these in the future to be rejected with a "Please change the subject line if this isn't a virus" sort of message. It's not acceptable to me for these to be silently discarded.
signature-based virus scanners sometimes fail, too. Some software has notes like "disable antivirus software before installing" because they've had trouble with false positives.
I have gotten a lot of fallout myself (over 1000 messages, including bounces, majordomo responses, out of office auto-replies, support tickets, etc.) so I'm sensitive to this problem. After a postfix-users discussion, I decided that my solution of sending 5XX responses is adequate to reduce the amount of fallout for others. See my other post in this topic.
Unless you want to open yourself to the rumplestiltskin attack, you must accept every message for delivery, and THEN decide on the action.
No, there are other ways around this attack. (He's talking about an attacker guessing the names of your users by trying a lot of combinations.) You can simply enforce a delay before sending a 5xx response, as Postfix does. This slows down the attack, as accepting and then bouncing would.
In fact, returning a 5XX is a bounce. It's not blocking them from sending it. You have still received the data, and nothing is going to undo that.
It is not a bounce. Sending a 5XX after the DATA command does mean you've already received the data, but that's not what defines a bounce. A bounce means your email server accepting the message and then sending a message saying it failed. Refusing delivery may cause their SMTP server to bounce it, but not necessarily. If a virus is directly connecting to your SMTP server, no bounce will be generated by a 5XX response. This is the usual case with Sobig, though sometimes it does seem to go through an intermediary. So sending a 5XX response instead of bouncing is adequate to dramatically reduce the amount of worm fallout.
Furthermore, sending a 5XX response requires much less upstream bandwidth than accepting and then sending a bounce message (which typically includes the entire source message). For some people, this is significant, particularly for people with assymetric connections.
Hello. I'm a moderator. I see it, and I have chosen not to moderate it down. It's still relevant because apparently people didn't read it the first time.
You know, you were doing pretty well there. You had some compelling, concise reasons why the Anonymous Coward was incorrect - the Word format is a poor choice for exchanging documents. But then:
So, Anonymous Astroturfer, you should go back to your cube and rethink your strategy for spreading lies into the public consciousness.
See, you might as well have said "I'm an asshole who will assume the worst of people - that they're malicious instead of just misinformed." This is why I hate slashdot sometimes. Is basic civility so hard?
Rares Marian> Cameras in classrooms that follow every thing in detail. Excuse me? How is that necessary for studying a child's behavior? Nevermind that we're talking about classrooms. Cameras on the kids every damn minute of the day.
Ooh, now you're attempting to debate the study's ability to achieve its intended goal. That's better. But I still don't think you read the article, because they attempted to answer that question there. For example:
"With the microphones we can tell, for instance, when the students will switch from using English to Spanish or vice versa," he said.
Try again...maybe you'll agree with their points, maybe not, but you will be closer to having an intelligent conversation either way.
Slashdot Mirror
Timothy:
sammy baby:
No, I think Timothy's interpretation is correct. There are two SCO assertions being discussed here:
HP said they have no official position on the former. The latter says otherwise, so HP denied the latter. Timothy was right.
Why? Then you've written your own parser and generator. The generator is barely simpler than the topological sort and parallelized execution code and requires make, which normally lives dynamically linked in the /usr partition. I'm all for reuse, but at some point you have to realize that (A) the fraction of it you're using is not saving you code and (B) the extra functionality you don't need will probably still drag you down in some way.
> Really? That's an odd statement. How surprising that they choose to use an open-source software application that is designed to compactly represent dependencies for representing dependencies.
Actually, I also found it surprising, and I think I know "make" pretty well. The thing about make is that in 95% of cases almost all of the rules correspond to an actual target file that should be generated or not based on presence and timestamp. There are exceptions, like the usual "all" rule that's called a phony rule since it generates no file. (And make sure you have a ".PHONY: all" line right before it or "touch all" will break your build.) It's usually just there for the dependencies on a bunch of real targets, so you don't have to type "make this && make that && make ...".
Parts of make that they're not using here:
- logic for checking if a real target is up-to-date
- rules for creating specific targets from generic ones, like the
.c.o target
- variable substitutions
- a lot of other things...look at the man/info pages; modern versions of make have a lot of functionality that makes no sense here
And they are using:When I say the syntax doesn't make sense here, I mean (in addition to the usual make complaints) that it's all in one file. Distributors (notably RedHat in particular) have been very serious about separating out stuff into .d directories so that packages don't need to touch each others' files.
So, I think make is the wrong tool for the job here, at least in the long term. A simple tool with separate files for each service would be a win. I don't think the author of the article really cares about that (it's just a little tip for intermediate users), but if a distribution wanted to implement this idea and maintain it, they wouldn't use make.
That's not true. Google for security "heap overflow" and you'll see a lot of advisories and exploits for bugs of this nature.
If it's on the heap, overwriting the stack in a controlled way becomes immensely difficult at best, maybe even impossible depending on the architecture.
"Immensely difficult" isn't good enough; there are people who live for this stuff, as shown by the link above. Even impossible isn't good enough, because there's still a denial of service attack. The only even remotely secure thing is to not have a buffer overflow. There are dozens of languages in which this just isn't a concern.
Bah. That they do not have security holes is implausible, if not actually impossible, to prove. It's hard to even define what a security hole is; a changing threat model has "caused" many security holes. (Is an open relay a security hole? I say yes. Twenty years ago, everyone said no.) I doubt your statement. I can't point at a hole right now, but I have confidence that at least one security hole will eventually be discovered in those programs.
They were written using secure coding techniques that make them immune to things like buffer overflows. You can't "overlook" a buffer overflow with stralloc.
No, they make it easier to avoid buffer overflows. They don't prevent them: I quote from your hyperlink:
If they use sa.s and sa.len directly, they can screw up and increase len inappropriately. The API seems good in that it makes it much harder to do things wrong, but it is hubris to say it makes you invulnerable. Besides, buffer overflows are possible for things other than strings, so this solves only (the most common) part of the problem. And there's still the legacy code that people can use without porting to stralloc.
It does seem like a good library if you're stuck using C. Another alternative is APR, which makes managing all sorts of memory allocations much easier. Pools are handy things when dealing with a language that primitive.
But there are languages in which it actually is impossible to have a buffer overflow. Please don't confuse the issue by saying that this (which makes it somewhat easier to avoid this error) makes the error impossible.
They give no explanation for this (it's the last paragraph). So obviously she has learned to compensate for not having that sense, since she can function without being strapped to the accelerometer. I can see two explanations here:
I'm kind of leaning toward #2. Now, what is quite impressive is when the reporter managed to see the outline of large letters. Assuming they didn't give him too much feedback, there's no other real explanation than that the device worked.
They've called my cell phone before, and that cost me money. When I warned them, they did not do it again, but they should have checked more thoroughly to begin with. So I don't have much sympathy for them when they whine that we are costing them money.
BerntB said: From ISR's FAQ on space elevators, it is: 7.5 kg/km
Oops. Noted.
(-: I haven't studied physics since high school, but don't have a headache -- and had the energy to check the FAQ. The moral of this is left for the reader to think out, but probably has something to do about how students should limit alcohol intake. :-)
I don't drink, actually. I got this headache all on my own merits.
Actually, yes, we are. That's why advances in materials science were necessary before they could even think about building this thing. I quote from the article:
The cable's structure will be balanced by gravity -- the center of gravity will rest at the geosynchronous point, meaning that the bottom half will be falling toward Earth while the top half will be moving away at an equal rate.
Being "balanced by gravity" means there's a huge amount of tension here. In fact, that basically says that the top half (by mass - by distance probably a very small proportion of the thing) holds up everything below the center of mass at the geosync point. (Or from the other perspective: the bottom half holds down the top half, which would fly off into space otherwise.) It does that with tension in the cable, and we're talking about a lot of tension in the cable.
Let's put concrete numbers on it: carbon nanotubes are pretty light, but we're still talking about 35,785 kilometers in the bottom half (by mass) of the elevator - that's geosynchronous orbit around the earth. Say the elevator is 1 kg / m (very conservative, I think), which we'll call lamba (normal for linear density). Now gravity changes along the length of the cable (that's sort of the point), so we need an integral to calculate the force of gravity pulling the thing down:
F = \int GM dm/r^2 = \int GM \lambda dr / r^2
(where dm = \lamba dr). From my Physics I book, r_e (the mean radius of the Earth, which is a bit higher than sea level but not too bad) is 6.37 * 10^6 m. M (the mass of the earth) is 5.98 * 10^24 kg. And G is 6.67 * 10^-11 N*m^2 / kg^2. So the integral becomes:
F = \int_{6.37 * 10^6 m}^{6.37 * 10^6 m + 3.58 * 10^7 m} (6.67 * 10^-11 N*m^2/kg^2) (5.98 * 10^24 kg) (1 kg / m) dr / r^2 = 5.3 * 10^7 N = 53 MN (mega-Newtons)
...which I think is the require tension right above that point. I can't think off-hand exactly how geosync works, but essentially the stuff above that is being sped up and the stuff below (and the Earth itself, though not significantly) is being slowed down by that tension.
Disclaimer: I'm an undergrad physics student with a headache. I very well may have made a mistake above, but I guarantee it's closer than the parent post.
Wow, what a straw man. Here's a closer analogy: you own a gun, which you keep loaded with the safety off. Your kid has a friend over. He finds it and accidentally shoots his friend. There are a range of crimes you could be charged with, up to involuntary manslaughter, I believe.
There are two key things here that make this a better analogy: (1) the precautions you should have taken are quite reasonable and (2) you are not the only victim; your negligence impacts other people. [*] It's not perfect - there was a willful crime being penetrated in the original case. But that's what happens when you go with analogies instead of talking about the thing itself.
[*] - Even ones who are not infected. The rest of us still have to pay for bandwidth and sort through our email. I received so many copies of not only the worm, but responses to worms forged as being sent from me.
I worked at a local ISP who managed to get a demo for a cache server a while back. (I don't anymore.) The machine arrived. We plugged it in, and started to take tech calls.
Sounds like this was your mistake. You "managed to get a demo" speaks volumes. Sounds like an expensive proprietary product from a small company. If you had just downloaded Squid, I don't think you would have encountered all these problems.
The server had a difficult time with virtual hosting of any kind. About 4 out of 5 requests to a virtual host would go through. About 20% of the time, there was some critical piece of information that the cache server would mangle so that the vhost mechanism would be unable to serve the right data. This was a couple years ago, so bugfixes might have happened. Maybe.
Sounds like it only supported IP-based virtual hosting. Back in the day, most sites would have had separate IPs for everything they hosted, so that percentage sounds right. The 20% that failed needed a "Host: www.virtual.com" header.
The server definitely had a hard time with dynamic content that wasn't built with a GET url (thus triggering the pass-thru proxy). If the request was posted, encrypted, hashed, or referenced a server side directive of some kind (server-side redirects were a nasty) the cache would fail. A server side link equating something like "http://www.server.net/redirect/" to a generated URL or dynamic content of some kind was the most frequent case we rean into with this. The server simply couldn't parse each and every http request or every variety and try to decide if it should pass-thru or not. I can't think of a logical way around this that wouldn't break any given implimentation. Can you?
First, I think you mean a POST query would trigger the pass-through. GET is the normal method.
Second, there are pretty simple ways for triggering a cache or not. The full rules are here, but very roughly a page should be cached if and only if:
If one is in the cache other than the Expires (which doesn't even need to be checked), it will query the server and check if the content is the same as before (with a special header that instructs the server not to send anything if it's unchanged).
This is a nice rule because webservers tend to automatically set the Last-modified: date on plain files and never do on dynamic stuff, so you have to explicitly add it in your dynamic code after considering it. So it gets most of the static stuff automatically (and that's generally the big stuff - images) but is cautious with anything dynamic. That's the correct approach.
This scheme really only breaks down when clock used by the requester (cache server in this case, browser also) or by the content generator (possibly the webserver, but also maybe the desktop used to generate stuff and then upload to the webserver) is skewed. And even then, it just gives stale data; not one person logged in as someone else. And this problem occurs even without a caching server, since browsers implement caching by themselves. Really, having a correct time is important to lots of things on computers. For example, don't ever try to do development without your clock being correct; build tools will be completely unable to tell what's up-to-date and what's not. Ticket-based network authentication systems (like Kerberos implementations, including Microsoft's shiny new ActiveDirectory) will refuse to log you on. etc, etc.
We used dynamically assigned IPs at the time, so proxy requests made
What software programs? I'm aware of no applications that accept connections on a dynamically-allocated secure (<1024) port.
There are a few that initiate connections from a dynamically-allocated secure port. I believe the r* applications (rsh, rlogin, rcp) do. The goal is to prove the code is being run as root, so the username field can be trusted. But many people would argue that these applications are broken and s* should be used instead, since IP addresses can be spoofed. Even if you consider them important, you could avoid breaking them by only blocking incoming connections (either by SYN packets or, better yet, stateful filtering).
I could see this being a problem in blocking a >=1024 port. Then the behavior you describe could happen with some applications, as some do accept connections on dynamically-allocated ports. Active FTP comes to mind. Many people (myself included) would say active FTP is broken, but few users would know to switch to passive and their only hint shouldn't be random failures. I think there may be some peer-to-peer applications that do this, also. But they tend to just try a different port when it doesn't work, so that's not such a big deal.
A worm has a bunch of properties that aren't desirable here:
Now, you might say that those problems are only temporary, but what if your screw up the code to make the worm destroy itself? Then you have no way to control the outbreak - you've already patched your only sure way to get in.
A better way would be for your machines (ones you control without having to infect) to scan machines and send code that exploits the vulnerability and patches it. Nothing else. But even this would never fly; see below.
Why haven't antivirus companies caught on to this? They could sell customized anti-worms to small-to-medium size network owners. The problems of releasing an anti-worm on the Internet at large don't apply to smaller networks. You can get the permission of all the network admins before releasing the worm, and a central server can be used to control the infection, keeping track of which computers are patched and shutting down the worm when it has done its job.
Trust. They may be able to get the permission of all the network admins, but they'd never get the permission of all the owners of the machines. If someone were trying to break into my machine, I'd throw a fit, even if I believed their intent. They could screw up, opening my machine to new vulnerabilities. The correct thing to do when you notice someone else's machine is vulnerable is to TELL THEM they have a problem and TEACH THEM how to fix it.
But they can already, most likely. Where are your Ethernet ports? If someone just plugs a laptop into one, what will happen? (On most networks, the DHCP server will issue the laptop an address and the "intruder" can go about his/her business merrily. To actually prevent random people from using the network, you'd have to actually authenticate the people whenever they use it, probably with a VPN. Remember, MAC addresses can be spoofed easily.) How is this different with a wireless network, aside from not needing to find an Ethernet port?
To really achieve security, you need a segmented network with firewalls between that don't trust anyone more than necessary for them to do their work. And if you're worried about traffic being captured, encryption. (Either a VPN or application-level encryption like SSH and SSL.) I don't really understand how wired or wireless changes that.
I'll be looking forward to that. I saw a little bit of discussion about it, but missed the final result. Will it work just single-table queries, or will it be able to handle stuff like this?
(ugh, slashdot butchered the indenting, sorry. it doesn't seem to to preserve spaces either with or in a <ecode> block.)
Oracle's behavior is to allow inserts, updates, and deletes. You can only set the columns in the first table mentioned ().
This works well for Oracle Forms-based stuff; I just set the other columns to "Query Only" and have LOVs (Lists of Values; a fancy drop-down sort of thing) that set them and the ID fields at the same time. Both changes appear on the screen and only the ID fields are sent to the database.
Sure, if you are only wanting to support UPDATE. But I think that UPDATE, INSERT, and DELETE require separate logic. And most people want to support updating more than the one field.
So when data are in the process of changing, they just don't show up in queries? That's horrible. And what happens if the system goes down in the process of changing? You can't roll back; the old data are lost. And you have to manually go in and clear the dirty bit for the broken, half-new data to be even remotely accessible. Or code logic checking for this everywhere, which would be a nightmare of duplicated, unnecessary code.
With this method, you will eventually run into a case where you will have to pull an old backup because a transient failure caused your stupid method to corrupt a lot of data. Transactions are pretty much essential to ensure correctness; you'd have to reimplement the transaction system to get its guarantees, and it's much smarter to use the one that's already there and tested.
And what about procedures that need a consistent view of the database? There's more in ACID than the "A". Transation isolation is necessary for a lot of applications. They can ensure that multiple queries were run on the same set of data.
If people aren't thinking about their data and doing stupid things, that's entirely separate from their using transactions. There are methods for rigorously proving that your transaction use is correct. I strongly recommend to you that you study them. You sound like you care a lot about correctness. You're not achieving it at all now. If you used transactions, you could.
That's also true for Oracle. DDL statements just aren't transactional, and that's not a problem. (Some might be in PostgreSQL...I seem to recall something weird about that. But I don't consider it an advantage.) If you are care about DDL statements in transactions, you're doing something seriously wrong. It's something that you do manually (not from an application!). You don't have simultaneous DDL statements going on. And you should be able to figure out the opposite statement yourself.
As for the rest, that's pretty bad. I design my databases with data types for a reason, so when the database doesn't enforce it...ugh. And inserting anything other than what I say (-99.99 instead of -100) is no good, even if I told it to do something impossible (it should throw an error instead).
This from a proud user of PostgreSQL (and Oracle at work).
It already has them. You have to write the rule yourself, so it's not nearly as convenient as in Oracle, but it's possible. It's something like:
Now, I could see why you'd really want these to be automatic, as updating the definition of these rules manually is a maintenance headache. But you can do it.
For those with this problem, there is a wiki with a set of helpful SpamAssassin rules to filter out the worst offenders. Culley Harrelson was kind enough to point me at the rules.
> The thing is, the sender was forged. Since the virus scanner knows the message was a virus and correctly identifies it as such, shouldn't it know that the virus uses forged headers? And since it should know the header was forged, it should NOT return the message.
Sure, if the virus scanner is 100% sure that it has identified a virus email. But a lot of times, these things aren't 100%:
I have gotten a lot of fallout myself (over 1000 messages, including bounces, majordomo responses, out of office auto-replies, support tickets, etc.) so I'm sensitive to this problem. After a postfix-users discussion, I decided that my solution of sending 5XX responses is adequate to reduce the amount of fallout for others. See my other post in this topic.
No, there are other ways around this attack. (He's talking about an attacker guessing the names of your users by trying a lot of combinations.) You can simply enforce a delay before sending a 5xx response, as Postfix does. This slows down the attack, as accepting and then bouncing would.
In fact, returning a 5XX is a bounce. It's not blocking them from sending it. You have still received the data, and nothing is going to undo that.
It is not a bounce. Sending a 5XX after the DATA command does mean you've already received the data, but that's not what defines a bounce. A bounce means your email server accepting the message and then sending a message saying it failed. Refusing delivery may cause their SMTP server to bounce it, but not necessarily. If a virus is directly connecting to your SMTP server, no bounce will be generated by a 5XX response. This is the usual case with Sobig, though sometimes it does seem to go through an intermediary. So sending a 5XX response instead of bouncing is adequate to dramatically reduce the amount of worm fallout.
Furthermore, sending a 5XX response requires much less upstream bandwidth than accepting and then sending a bounce message (which typically includes the entire source message). For some people, this is significant, particularly for people with assymetric connections.
Hello. I'm a moderator. I see it, and I have chosen not to moderate it down. It's still relevant because apparently people didn't read it the first time.
So, Anonymous Astroturfer, you should go back to your cube and rethink your strategy for spreading lies into the public consciousness.
See, you might as well have said "I'm an asshole who will assume the worst of people - that they're malicious instead of just misinformed." This is why I hate slashdot sometimes. Is basic civility so hard?
Ooh, now you're attempting to debate the study's ability to achieve its intended goal. That's better. But I still don't think you read the article, because they attempted to answer that question there. For example:
Try again...maybe you'll agree with their points, maybe not, but you will be closer to having an intelligent conversation either way.