I'd say it's pretty hard to get an angle that lets you aim easily. There are other problems I forgot to mention. Suppose you shine a nice green laser. While lasers are normally not visible as a beam, over that distance and with that power it could very well trace a nice green line right to you. The pilot could also get a very good idea of your location.
The other option is to use an invisible laser, in which case you need equipment that lets you see it, and it makes thing even more difficult. A weak visible laser could be enough to scare the pilot. An infrared one will have to pretty much fry the retina, and you'll have to point that right into the eye for it to work.
And in any case, if the objective is terrorism I don't really see why would somebody go with such a complicated plan. IIRC, the kind of thing ETA does here in Spain is to plant a bomb in front of a big commercial center, then *call the police* and I suppose then (expeletive deleted) safely sit in front of the TV and watch the evacuation of several thousand people. Stolen car, some explosives from their reserve, tried strategy, guaranteed panic even if nobody gets hurt.
A 747 flies at 565 mph or 909 km/h. This is 252 meters *per second*. And as you said, from the ground you barely see it move. You can't just point to it, since a second later your aim will be 252 meters off if you were right under it. Of course really it'd be slower for you due to the angle, but we can assume that the plane isn't at your altitude flying right at you, which is about the only thing that would make cheap aiming possible. The pilot will probably not even notice the laser even if you managed to shine it right into the eye for the tiny fraction of a second it'd be pointing at it.
You need one heck of a system that can to two things. The first one is to aim precisely. That alone would be quite difficult, since it'll need to be capable of making really tiny and precise adjustments. The second one is that it needs some kind of very precise system that would keep it pointing to a moving target. The minimum would be some kind of very good motorized telescope mount, controlled by a computer.
Now, the beam spreading. If your beam spreads noticeably, then it will lose a lot of power by the time it gets to the plane. First of all you have the atmosphere, with all the air and crap floating in it. Second, as the beam spreads it will become a lot less powerful. If the radius of the laser beam doubles, the area becomes 4 times larger. Either your laser has to be insanely powerful to overcome this, or you have to have an insanely good mount and tracking system. And neither of those things looks cheap, easy to get, or move around.
Finally, if did somehow managed to do all of this, wouldn't it be a lot easier to pay some dumb islamic terrorist to shoot it with a rocket? Surely that would be a lot cheaper, less trouble, and less dangerous for you.
Well, duh, what do you think an electric kettle is? A container with a resistor inside. Also see lava lamps, which use a light bulb as the heating element.
All you need is to take one of those, and wire them to the car. You need the heck of a laser to get the same power, and if you get one like that it will make holes in the asphalt besides of melting snow. Besides giving little useful result, I'm sure that the relevant authority would be rather unhappy about the holes in the roads.
Of course I could have used callbacks, but that wasn't the point. Callbacks run in the same address space. The experiment was to try to write a server that would absolutely as stable as possible. The plan involved:
A tiny core that's so simple it can nearly be assumed bug free, or at least never crashes. All functionality implemented externally. All functionality is optional. Functionality can be addded and removed at runtime. The server is so simple and stupid it doesn't know anything about moderation. The moderation service simply traps commands and says "yay" or "nay" to the main server.
For example, the authentication server would be a separate process that talks to the server, kind of a privileged client. Suppose that the mysql database goes down, and there happens to be no error handling at that particular point in the auth service. It tries to use an object that doesn't exist and crashes.
Server sees the login server went down, and takes note. Everything continues to work, but nobody can login while the auth server is down. A cron job/monitor/admin restarts the auth server, it reconnects, and the server's back to full capacity again. The idea is that the server could resist an almost complete failure without fully going down. It should even be possible to actively develop and upgrade the server while running. Services would specify what to do if they crash. Say, the server might revert to a very basic chat if everything crashes, or deny messages completely if the moderation service is gone. Somebody called this thing the HURD of chat servers.
Now, in practice this stuff meant lots and lots of message passing. A moderation service would imply almost every command would wait for the moderation service to reply, then the command would be processed by the service that provides it, then finally the client would get a reply. Some of that can be optimized, say, a logging service doesn't need to make the server wait.
But anyway. In theory all this stuff was very cool and very nice. In practice, it meant several thousand lines of code for the management of all this stuff, debugging interactions between services and coming up with ways of making all of this have an acceptable performance. And all that before it would archieve the functionality of "talk". With this kind of mess in something as simple as a chat server I'm pretty sure bigger problems happen with kernels.
Currently this project is stopped in favour of more interesting and practical stuff, although I suppose some day I will finish it and see what happens. If I do finish it, I'm fairly sure it could be very cool, but performance will suck compared to any decent ircd.
BeOS is dead, and last time I heard about it, OS X runs all of Darwin as one big process. Now, this area of my knowledge is very fuzzy, but if true then it's not much of a microkernel, when if I understand correctly, the original idea was to have lots of little components.
NT might have been somewhat of a microkernel in NT 3.51, but it's not anymore. Win2K is a NT system, and I haven't seen it resist driver failures. In fact, any serious kernel failure results in a BSOD, followed by a reboot. Heck, even Linux seems to stand kernel oopses better, because quite often it does manage to continue despite a failure.
I think you misunderstood the part about pipes. I was meaning to use it as an agreement with Linus' quote - that a kernel that does message passing accomplishes absolutely nothing by itself, and that writing a server the "microkernel way" was resulting in a lot of code that did nothing useful at all.
Why the microkernel part? Although I don't have much experience in this, I'd say it should be quite simple, relatively speaking. Look at Linux, most of the kernel tree is drivers. The kernel itself is pretty small.
From reading stuff and watching discussions what I got is that the problem with microkernels is that they're hard to properly implement and still have fairly bad performance. In fact, I hit those same problems when trying to code an extremely modular application, that I tried to write as an experiment.
My experiment consisted in writing a small chat server in the most modular way possible, that is, the core does almost nothing, and everything is implemented externally, with "services". Soon it became clear that if you go at it this way, there's lots and lots of latency. For example, a service could trap events. The theory is that I let people just login without a password, then a module overrides that, requiring whatever authentication method was desired. It would be modular to the point that it could do completely different things depending on the services running.
In practice this meant that a login would arrive to the server, get parsed, be forwarded to the service which would do its own processing, get sent back to the server, which would finally reply to the client. Now imagine this happens almost during every request.
Now, of course I'm not a programming genius, perhaps somebody can pull this stuff off with good performance and make it look good, but the point is that I finally realized that I could write a very basic chat with shell script and named pipes, while this thing would need thousands of lines of code before starting to do anything at all. Linus' quote about message passing and masturbation seems to fit here quite well.
Would definitely melt some, although I'm quite certain you wouldn't get any real results from it, as it'd melt very little. At most it'd make a hole in the form of a very thin line in the snow.
If you really want that, wouldn't it be easier to just wire resistors or light bulbs and use that instead? That will generate a lot more heat than the laser can.
Imagine the more exact calculations told us instead that it's certain that it will hit the Earth. Then doing all these calculations would have been a very good thing. With the speed at which technology is advancing, I'm pretty sure we could figure out some way of blasting that thing if it was proved it was really needed, given enough time. If we found that we had only two years that would be really bad.
Now, I'm not really qualified to say this, but I'd say we have much better chances of guessing an asteroid impact than when an earthquake will happen, since there are less variables influencing where an asteroid will go.
First of all, comparing MD5 sums provides absolutely no security. No matter how many are there, they could all be wrong, or altered in transit, etc. The secure way is this: You have file.txt. You md5sum it and get file.txt.sum, which contains the filename and hash. Then you sign both with PGP, getting a signed original file, and a signed md5sum file. The first signature ensures the data is not tampered with. You can check the signed md5sum file to verify the file hasn't been renamed, becuase renaming would require changing the name of the original file, and correcting the filename stored in the md5sum file.
Why generate the md5 file in a secure environment? Well, if you're signing something you want to make sure you're signing the right thing, and not something a hacker planted there moments before.
Second, you seem to misunderstand how PGP signatures work. They can have collisions just the same as MD5, because that's how they're generated! When PGP makes a signature it's actually signing the hash of the message, and all hashes have collisions. Hashes detect alteration just fine, that's what they're made for after all. A hash is a one way function that produces output such that you can't reverse it, or find a second input with the same hash by anything but brute force.
Now, anybody can generate a hash, so it provides no security. PGP provides it by making sure that nobody but the one who has the private key can generate a good signature for the corresponding public key.
Well, the problem here would be that GPG doesn't really care about filenames and just signs the data. This could be fairly easily worked around by signing the filename, just like when gpg didn't support photos in GPG keys you could just sign a JPG and place it on your website.
Now, MD5 sums add absolutely nothing to PGP signatures. The signature itself is already just as good as a MD5 sum even in the worst case of a completely untrusted key. You can combine them of course, by signing both the file and md5sum. Then the signature on the md5sum makes sure the filename hasn't been changed. I suppose this is what you meant.
However, in this case what you said about compromised MD5 sums doesn't make sense. Both the MD5 and the GPG signatures would be generated in a secure environment. If we do things this way, the MD5 would be signed, which makes any tampering trivially detectable.
Indeed. However, you were implying that a signature somehow lets me identify that it's indeed Firefox before I install it, when it doesn't. In fact, signatures can let one thing slip by: Renamed executables.
I can take a perfectly well signed, but ancient version of Firefox, break into a mirror and replace the current version with the old one. Here's an example:
You need a passphrase to unlock the secret key for user: "Vadim Trochinsky (HP Laptop Key) <me@vadim.ws>" 1024-bit DSA key, ID B95CD181, created 2004-09-19
vadim@gadget vadim $ gpg --verify 50_exim4-config_clamav.gpg gpg: NOTE: old default options file `/home/vadim/.gnupg/options' ignored gpg: Signature made Tue Dec 21 12:00:32 2004 CET using DSA key ID B95CD181 gpg: Good signature from "Vadim Trochinsky (HP Laptop Key) <me@vadim.ws>" vadim@gadget vadim $ cp 50_exim4-config_clamav foo vadim@gadget vadim $ cp 50_exim4-config_clamav.gpg foo.gpg vadim@gadget vadim $ gpg --verify foo.gpg gpg: NOTE: old default options file `/home/vadim/.gnupg/options' ignored gpg: Signature made Tue Dec 21 12:00:32 2004 CET using DSA key ID B95CD181 gpg: Good signature from "Vadim Trochinsky (HP Laptop Key) <me@vadim.ws>" vadim@gadget vadim $
You wouldn't know that even if it was signed. I can think of two possibilities:
Verisign says this has been signed by the Mozilla Foundation. Verisign says this because Mozilla paid them for a key and presented some documents. And I trust Verisign because their certs come with IE, which I trust... not really sure why. This doesn't mean it's harmless, or that the program was made by the Mozilla team. Just that the Mozilla Foundation paid $$$ to Verisign, and made a signature on this particular executable.
It's signed by the Mozilla PGP key, which I trust because I trust Alice who trusts Bob who trusts Dave who trusts the Mozilla team. This may be a bit better, but still doesn't mean it is really Firefox.
And all this stuff still doesn't mean it's Firefox. It identifies the signer, but the signer's free to sign anything they want.
For the 2^128th time, a hash like MD5 or SHA1 provides no security. They are used to verify data integrity, that is, that nothing got corrupted while you were downloading it, or that it was read correctly from the media it's stored on. It says nothing at all about if it can be trusted or not, the attacker will simply replace the hash.
Now PGP signatures made with proper keys are something quite different. They're harder to verify too as I explained in another comment here, but they provide some real security.
Somewhat complicated, but can be done. First of all you go to a PGP key signing party. The more the better, but just one gives quite good chances already. Then you use the PGP key path finder and it tries to find a path from your key to the Mozilla one.
Does it sound messy? Yes, it is. It's not as automatic as going to a site and have the browser pop up a window saying it's been blessed by Verisign and so it should be okay? Indeed.
However, it's definitely a lot safer if you can verify it. Unlike with Verisign, with PGP/GPG you know that the key can be trusted because you signed Alice's key, and Alice signed Bob's and Bob signed the Mozilla one. GPG can be told to only trust if there are several signatures on the key that can be verified if you're feeling paranoid, too.
Maybe it's supposed to be a kitsune, which would be a japanese red fox (which does exist) which has cool powers (some fire related) and multiple tails in the mythology. Although the logo seems to have too many tails for that, they're supposed to have up to 9.
Sure, viruses for Linux can be written. The problem's getting them to run, and then do anything useful.
Let's say I receive a virus attached to an email, which I open with kmail.
First of all, I've got to save it to disk, mark it as executable, and run it. This alone makes it quite improbable.
Second, the virus has actually to start up, and Linux binaries don't necessarily work on other systems, unless statically linked.
Assuming it's statically linked, Linux systems are rather less standard than Windows ones. How does it send mail? Well, kmail has a dcop interface, but I don't see a function for sending. The virus could compose it of course, but the user would need to click send on it.
Next, it can perhaps try using the server at localhost. If there's one, that is, since normal people probably aren't going to be running one. Reading the user's kmail config would probably work though, as long as the password is there.
So, overall I'd say, yeah, it's possible. But all the obstacles above make it a lot harder to do than on Windows, especially the first one. To make it run you probably would need to find a buffer overrun in a mail client, and that's increasingly uncommon these days.
Despite the usual quality of Unix software, I didn't think it would be that hard to find a hole. After all, on Linux it's really easy to get source, and surely some automated way of finding possible exploits like grepping for the usual dangerous functions could be found. Now actually exploiting it sounds harder.
My strategy would have been to compile a list of executables that can be easily tested automatically, and run them under valgrind while piping data from/dev/urandom, or something similar. I'd also try feeding normal input with randomly changed characters, and things like that. In my experience valgrind's really good at finding all kinds of subtle issues.
That's what it'll result in. Giant robots with backpacks full of antimatter using a nanolathe to build bases and turrets. Nobody will come out of that unharmed;-)
Seriously though, it'll probably be a big mess if this kind of thing is ever invented. There's enough trouble already with "intellectual property". Imagine if everything suddenly was like that. Would sure make life interesting.
Sounds perfectly fine to me. It looks like a decent way of figuring out if you were good enough or not, since initially all your changes had to go through the DBA. When the DBA understood that you knew what you were doing, s/he gave you the access.
This doesn't work (just checked), but since you can see/etc/shadow you can now run John the Ripper against it. And it's *very* effective. Unless the system has really good passwords it'll eventually get some of them, and from there you can potentially wreak havoc.
john's pretty fast, you can be almost certain to get something in an hour from a shadow file with many accounts, or at least something in a day.
There are other possibilities, like grepping log files and root's.bash_history for passwords typed in the wrong place. For example, if the admin types the password instead of the username you'd get it in the logs in clear text.
Here we managed to live with ETA, without making a mess in the Basque country:-P ETA has been dealt several pretty hard blows lately, too.
Things were better before Azanar decided that he had something to do in Iraq, even though 90% of the population was opposed to it. Fortunately this mistake got corrected too.
I came with a better way to solve that here. A Perl script.
Basically, it's a small script that talks to a mysql database, and a set of filters that convert log files to an universal (currently very ugly) format. You just run this from cron or whatever, and then can search the database. Comes quite handy when you have several computers with different IM services.
Right, but the thing here is that they're not shooting the satellite from a cannon. They're lifting it from a rocket, which can leave earth as fast or slowly as it wants.
Say, a helicopter ascends much slower than escape velocity, and still has no problem with doing because it has *propulsion*. Of course it can't leave Earth's gravitational field due to lack of air, but that's about the only thing that stops it from doing that.
Slashdot Mirror
Yup, won't be 252 metres per second. But let's see what we get with different angles. Hope I'm not screwing up anything, it's late here.
45 degrees: 252 * sin(pi/4) = 178.19
20 degrees: 86.18
10 degrees: 43.75
5 degrees: 21.96
I'd say it's pretty hard to get an angle that lets you aim easily. There are other problems I forgot to mention. Suppose you shine a nice green laser. While lasers are normally not visible as a beam, over that distance and with that power it could very well trace a nice green line right to you. The pilot could also get a very good idea of your location.
The other option is to use an invisible laser, in which case you need equipment that lets you see it, and it makes thing even more difficult. A weak visible laser could be enough to scare the pilot. An infrared one will have to pretty much fry the retina, and you'll have to point that right into the eye for it to work.
And in any case, if the objective is terrorism I don't really see why would somebody go with such a complicated plan. IIRC, the kind of thing ETA does here in Spain is to plant a bomb in front of a big commercial center, then *call the police* and I suppose then (expeletive deleted) safely sit in front of the TV and watch the evacuation of several thousand people. Stolen car, some explosives from their reserve, tried strategy, guaranteed panic even if nobody gets hurt.
Think of what you said for a little.
A 747 flies at 565 mph or 909 km/h. This is 252 meters *per second*. And as you said, from the ground you barely see it move. You can't just point to it, since a second later your aim will be 252 meters off if you were right under it. Of course really it'd be slower for you due to the angle, but we can assume that the plane isn't at your altitude flying right at you, which is about the only thing that would make cheap aiming possible. The pilot will probably not even notice the laser even if you managed to shine it right into the eye for the tiny fraction of a second it'd be pointing at it.
You need one heck of a system that can to two things. The first one is to aim precisely. That alone would be quite difficult, since it'll need to be capable of making really tiny and precise adjustments. The second one is that it needs some kind of very precise system that would keep it pointing to a moving target. The minimum would be some kind of very good motorized telescope mount, controlled by a computer.
Now, the beam spreading. If your beam spreads noticeably, then it will lose a lot of power by the time it gets to the plane. First of all you have the atmosphere, with all the air and crap floating in it. Second, as the beam spreads it will become a lot less powerful. If the radius of the laser beam doubles, the area becomes 4 times larger. Either your laser has to be insanely powerful to overcome this, or you have to have an insanely good mount and tracking system. And neither of those things looks cheap, easy to get, or move around.
Finally, if did somehow managed to do all of this, wouldn't it be a lot easier to pay some dumb islamic terrorist to shoot it with a rocket? Surely that would be a lot cheaper, less trouble, and less dangerous for you.
Well, duh, what do you think an electric kettle is? A container with a resistor inside. Also see lava lamps, which use a light bulb as the heating element.
All you need is to take one of those, and wire them to the car. You need the heck of a laser to get the same power, and if you get one like that it will make holes in the asphalt besides of melting snow. Besides giving little useful result, I'm sure that the relevant authority would be rather unhappy about the holes in the roads.
Of course I could have used callbacks, but that wasn't the point. Callbacks run in the same address space. The experiment was to try to write a server that would absolutely as stable as possible. The plan involved:
A tiny core that's so simple it can nearly be assumed bug free, or at least never crashes. All functionality implemented externally. All functionality is optional. Functionality can be addded and removed at runtime. The server is so simple and stupid it doesn't know anything about moderation. The moderation service simply traps commands and says "yay" or "nay" to the main server.
For example, the authentication server would be a separate process that talks to the server, kind of a privileged client. Suppose that the mysql database goes down, and there happens to be no error handling at that particular point in the auth service. It tries to use an object that doesn't exist and crashes.
Server sees the login server went down, and takes note. Everything continues to work, but nobody can login while the auth server is down. A cron job/monitor/admin restarts the auth server, it reconnects, and the server's back to full capacity again. The idea is that the server could resist an almost complete failure without fully going down. It should even be possible to actively develop and upgrade the server while running. Services would specify what to do if they crash. Say, the server might revert to a very basic chat if everything crashes, or deny messages completely if the moderation service is gone. Somebody called this thing the HURD of chat servers.
Now, in practice this stuff meant lots and lots of message passing. A moderation service would imply almost every command would wait for the moderation service to reply, then the command would be processed by the service that provides it, then finally the client would get a reply. Some of that can be optimized, say, a logging service doesn't need to make the server wait.
But anyway. In theory all this stuff was very cool and very nice. In practice, it meant several thousand lines of code for the management of all this stuff, debugging interactions between services and coming up with ways of making all of this have an acceptable performance. And all that before it would archieve the functionality of "talk". With this kind of mess in something as simple as a chat server I'm pretty sure bigger problems happen with kernels.
Currently this project is stopped in favour of more interesting and practical stuff, although I suppose some day I will finish it and see what happens. If I do finish it, I'm fairly sure it could be very cool, but performance will suck compared to any decent ircd.
BeOS is dead, and last time I heard about it, OS X runs all of Darwin as one big process. Now, this area of my knowledge is very fuzzy, but if true then it's not much of a microkernel, when if I understand correctly, the original idea was to have lots of little components.
NT might have been somewhat of a microkernel in NT 3.51, but it's not anymore. Win2K is a NT system, and I haven't seen it resist driver failures. In fact, any serious kernel failure results in a BSOD, followed by a reboot. Heck, even Linux seems to stand kernel oopses better, because quite often it does manage to continue despite a failure.
I think you misunderstood the part about pipes. I was meaning to use it as an agreement with Linus' quote - that a kernel that does message passing accomplishes absolutely nothing by itself, and that writing a server the "microkernel way" was resulting in a lot of code that did nothing useful at all.
Why the microkernel part? Although I don't have much experience in this, I'd say it should be quite simple, relatively speaking. Look at Linux, most of the kernel tree is drivers. The kernel itself is pretty small.
From reading stuff and watching discussions what I got is that the problem with microkernels is that they're hard to properly implement and still have fairly bad performance. In fact, I hit those same problems when trying to code an extremely modular application, that I tried to write as an experiment.
My experiment consisted in writing a small chat server in the most modular way possible, that is, the core does almost nothing, and everything is implemented externally, with "services". Soon it became clear that if you go at it this way, there's lots and lots of latency. For example, a service could trap events. The theory is that I let people just login without a password, then a module overrides that, requiring whatever authentication method was desired. It would be modular to the point that it could do completely different things depending on the services running.
In practice this meant that a login would arrive to the server, get parsed, be forwarded to the service which would do its own processing, get sent back to the server, which would finally reply to the client. Now imagine this happens almost during every request.
Now, of course I'm not a programming genius, perhaps somebody can pull this stuff off with good performance and make it look good, but the point is that I finally realized that I could write a very basic chat with shell script and named pipes, while this thing would need thousands of lines of code before starting to do anything at all. Linus' quote about message passing and masturbation seems to fit here quite well.
Would definitely melt some, although I'm quite certain you wouldn't get any real results from it, as it'd melt very little. At most it'd make a hole in the form of a very thin line in the snow.
If you really want that, wouldn't it be easier to just wire resistors or light bulbs and use that instead? That will generate a lot more heat than the laser can.
Well, I look at it this way.
Imagine the more exact calculations told us instead that it's certain that it will hit the Earth. Then doing all these calculations would have been a very good thing. With the speed at which technology is advancing, I'm pretty sure we could figure out some way of blasting that thing if it was proved it was really needed, given enough time. If we found that we had only two years that would be really bad.
Now, I'm not really qualified to say this, but I'd say we have much better chances of guessing an asteroid impact than when an earthquake will happen, since there are less variables influencing where an asteroid will go.
Ah, we have a slight misunderstanding here.
First of all, comparing MD5 sums provides absolutely no security. No matter how many are there, they could all be wrong, or altered in transit, etc. The secure way is this: You have file.txt. You md5sum it and get file.txt.sum, which contains the filename and hash. Then you sign both with PGP, getting a signed original file, and a signed md5sum file. The first signature ensures the data is not tampered with. You can check the signed md5sum file to verify the file hasn't been renamed, becuase renaming would require changing the name of the original file, and correcting the filename stored in the md5sum file.
Why generate the md5 file in a secure environment? Well, if you're signing something you want to make sure you're signing the right thing, and not something a hacker planted there moments before.
Second, you seem to misunderstand how PGP signatures work. They can have collisions just the same as MD5, because that's how they're generated! When PGP makes a signature it's actually signing the hash of the message, and all hashes have collisions. Hashes detect alteration just fine, that's what they're made for after all. A hash is a one way function that produces output such that you can't reverse it, or find a second input with the same hash by anything but brute force.
Now, anybody can generate a hash, so it provides no security. PGP provides it by making sure that nobody but the one who has the private key can generate a good signature for the corresponding public key.
Well, the problem here would be that GPG doesn't really care about filenames and just signs the data. This could be fairly easily worked around by signing the filename, just like when gpg didn't support photos in GPG keys you could just sign a JPG and place it on your website.
Now, MD5 sums add absolutely nothing to PGP signatures. The signature itself is already just as good as a MD5 sum even in the worst case of a completely untrusted key. You can combine them of course, by signing both the file and md5sum. Then the signature on the md5sum makes sure the filename hasn't been changed. I suppose this is what you meant.
However, in this case what you said about compromised MD5 sums doesn't make sense. Both the MD5 and the GPG signatures would be generated in a secure environment. If we do things this way, the MD5 would be signed, which makes any tampering trivially detectable.
I can take a perfectly well signed, but ancient version of Firefox, break into a mirror and replace the current version with the old one. Here's an example:
You wouldn't know that even if it was signed. I can think of two possibilities:
Verisign says this has been signed by the Mozilla Foundation. Verisign says this because Mozilla paid them for a key and presented some documents. And I trust Verisign because their certs come with IE, which I trust... not really sure why. This doesn't mean it's harmless, or that the program was made by the Mozilla team. Just that the Mozilla Foundation paid $$$ to Verisign, and made a signature on this particular executable.
It's signed by the Mozilla PGP key, which I trust because I trust Alice who trusts Bob who trusts Dave who trusts the Mozilla team. This may be a bit better, but still doesn't mean it is really Firefox.
And all this stuff still doesn't mean it's Firefox. It identifies the signer, but the signer's free to sign anything they want.
For the 2^128th time, a hash like MD5 or SHA1 provides no security. They are used to verify data integrity, that is, that nothing got corrupted while you were downloading it, or that it was read correctly from the media it's stored on. It says nothing at all about if it can be trusted or not, the attacker will simply replace the hash.
Now PGP signatures made with proper keys are something quite different. They're harder to verify too as I explained in another comment here, but they provide some real security.
Somewhat complicated, but can be done. First of all you go to a PGP key signing party. The more the better, but just one gives quite good chances already. Then you use the PGP key path finder and it tries to find a path from your key to the Mozilla one.
Does it sound messy? Yes, it is. It's not as automatic as going to a site and have the browser pop up a window saying it's been blessed by Verisign and so it should be okay? Indeed.
However, it's definitely a lot safer if you can verify it. Unlike with Verisign, with PGP/GPG you know that the key can be trusted because you signed Alice's key, and Alice signed Bob's and Bob signed the Mozilla one. GPG can be told to only trust if there are several signatures on the key that can be verified if you're feeling paranoid, too.
Maybe it's supposed to be a kitsune, which would be a japanese red fox (which does exist) which has cool powers (some fire related) and multiple tails in the mythology. Although the logo seems to have too many tails for that, they're supposed to have up to 9.
That's a way yeah, but it should eventually disappear, with things like gcc -fstack-protector, grsecurity kernel patches and CPU features like NX
Sure, viruses for Linux can be written. The problem's getting them to run, and then do anything useful.
Let's say I receive a virus attached to an email, which I open with kmail.
First of all, I've got to save it to disk, mark it as executable, and run it. This alone makes it quite improbable.
Second, the virus has actually to start up, and Linux binaries don't necessarily work on other systems, unless statically linked.
Assuming it's statically linked, Linux systems are rather less standard than Windows ones. How does it send mail? Well, kmail has a dcop interface, but I don't see a function for sending. The virus could compose it of course, but the user would need to click send on it.
Next, it can perhaps try using the server at localhost. If there's one, that is, since normal people probably aren't going to be running one. Reading the user's kmail config would probably work though, as long as the password is there.
So, overall I'd say, yeah, it's possible. But all the obstacles above make it a lot harder to do than on Windows, especially the first one. To make it run you probably would need to find a buffer overrun in a mail client, and that's increasingly uncommon these days.
Despite the usual quality of Unix software, I didn't think it would be that hard to find a hole. After all, on Linux it's really easy to get source, and surely some automated way of finding possible exploits like grepping for the usual dangerous functions could be found. Now actually exploiting it sounds harder.
/dev/urandom, or something similar. I'd also try feeding normal input with randomly changed characters, and things like that. In my experience valgrind's really good at finding all kinds of subtle issues.
My strategy would have been to compile a list of executables that can be easily tested automatically, and run them under valgrind while piping data from
That's what it'll result in. Giant robots with backpacks full of antimatter using a nanolathe to build bases and turrets. Nobody will come out of that unharmed ;-)
Seriously though, it'll probably be a big mess if this kind of thing is ever invented. There's enough trouble already with "intellectual property". Imagine if everything suddenly was like that. Would sure make life interesting.
Sounds perfectly fine to me. It looks like a decent way of figuring out if you were good enough or not, since initially all your changes had to go through the DBA. When the DBA understood that you knew what you were doing, s/he gave you the access.
This doesn't work (just checked), but since you can see /etc/shadow you can now run John the Ripper against it. And it's *very* effective. Unless the system has really good passwords it'll eventually get some of them, and from there you can potentially wreak havoc.
.bash_history for passwords typed in the wrong place. For example, if the admin types the password instead of the username you'd get it in the logs in clear text.
john's pretty fast, you can be almost certain to get something in an hour from a shadow file with many accounts, or at least something in a day.
There are other possibilities, like grepping log files and root's
Indeed it should.
:-P ETA has been dealt several pretty hard blows lately, too.
Here we managed to live with ETA, without making a mess in the Basque country
Things were better before Azanar decided that he had something to do in Iraq, even though 90% of the population was opposed to it. Fortunately this mistake got corrected too.
I came with a better way to solve that here. A Perl script.
Basically, it's a small script that talks to a mysql database, and a set of filters that convert log files to an universal (currently very ugly) format. You just run this from cron or whatever, and then can search the database. Comes quite handy when you have several computers with different IM services.
Currently Psi, Kopete, kvirc and mbox/maildir.
Right, but the thing here is that they're not shooting the satellite from a cannon. They're lifting it from a rocket, which can leave earth as fast or slowly as it wants.
Say, a helicopter ascends much slower than escape velocity, and still has no problem with doing because it has *propulsion*. Of course it can't leave Earth's gravitational field due to lack of air, but that's about the only thing that stops it from doing that.