Huh? Python is still on version 2, that's only one incompatible rewrite. Sure, 3 is coming with changes, and they will disrupt things, but they're for the better, and 2 may well still be maintained if you want to stick with that.
I wrote scripts for python 2.1, which is IIRC a few years old, and have no problems with them today (on 2.4)
Yes, that's exactly what the OP is saying and it's a stupid idea. By double MD5 I meant a double-length MD5 (twice as many bits in the hash), which although still a stupid idea is nowhere near as stupid as using MD5 and SHA1 together and expecting it to increase security.
RPM uses both MD5 and SHA1, the chances of finding a collision that satisfies both hashes is small, even if both MD5 and SHA1 are compromised since the hash the data differently.
Not true, firstly the two come from the same "family" and are related, and secondly most of this type of attacks allow you to generate arbitrarily many files matching the hash almost as easily as two. So you use your MD5 attack to generate a large set (2^60 or however many you need) of RPMs matching the MD5, then you use your SHA1 attack to find one among them which matches the SHA1 too, or vice versa.
Fortunately there is no practical attack against SHA1 yet, but when there is RPM will be completely insecure.
No, it wouldn't, *sigh*. Stop posting this, I'm tired of correcting it.
As another reply said, however, doubling the bit count would improve security. But, a simple double-MD5 would have exactly the same problems. Therefore, the solution is to use a longer and more secure hash, like, for example, SHA-256.
Considering this is such a "well known" result, you would think that MD5 should have been abandoned long ago. Is this true for other popular hash functions?
It's a useful property because it means you can MD5 data piece by piece. I don't want to think about how long it would take to MD5 a 700MB.iso if you had to use the file as a whole, it takes long enough as it is. It shouldn't allow you to break a hash function without other flaws, and I'd expect it to be the case for many hashes.
I thought that the known attacks would not work agains compressed content, because you had to add some "random" data to the content and while decompressing the decompressor would give an error. I know it isn't exact, but I thought that md5's of compressed content was safe.
I see "gzip: trailing garbage ignored" messages all the time when unpacking tarballs, should I be worrying about them? I know most users won't.
Anyway, if it's zip compression then by design arbitrary content can be added to the start without resulting in an error. (This is done to make self-extracting programs possible). Make no mistake, this is a very serious break.
As for md5... with only 32bits, it should've came up with repetitive hashes in end anyways?
Yes, but the point of a hash is that it's computationally infeasible to find them. If you're distributing a binary with a certain MD5 there's sure to be a file somewhere with the same sum, maybe it's a car manufacturer's specification PDF, but I can't write a trojan and get it to MD5 to the same thing *and* do what I want. Now you can.
Attacks only get better, a theoretical vulnerability is one to worry about as they are almost always followed by a practical exploit like this. Move away from SHA1 before the same thing happens.
both X libraries and the GNU tools are already ported. Thus, the whole glory goes to the portability of GNU tools,
KDE deserves some credit for not depending on other aspects of its environment. Even when using a crossplatform API it's very easy to make non-portable assumptions about the underlying environment.
I'm a coder and have used stricter languages than C/C++ and have difficulty with XHTML. Partly it's just that I learnt HTML 3, but I think it is unnecessarily restrictive.
Yes, lynx is very secure, exactly because it places a lot more emphasis on security than features. But it's too far in that direction on the tradeoff for many users - You can't log in here with it AFAIK (no image support), it has no javascript support to speak of, and of course no java or flash. A balance needs to be struck, and I don't think lynx is where it is for most users.
Bear in mind that although security implies a certain lack of features the reverse is not true. W3m has a horrible number of unfixed security problems.
While Windows 9x/NT/Linux can kill these ads, good luck getting hold of a time-slice to perform the command.
That's where having a shell running at -10 on another terminal comes in handy. And while you're right, I can see a good reason to execute plugins at fairly high priority even when they're taking 100% CPU - if you're using the gxine plugin to watch a high-res video, on a slower system it may well take 100% CPU and still be dropping frames. It's a features/security tradeoff where they've gone for the features.
Or do they have wiggle room and claim that its produced offshore and therefore isn't exported from the US, even though its now owned by a US company? I doubt that will go down well with the powers-that-be, because (among other things) that will just encourage US companies to offshore all their products-with-crypto work to get around the regulations.
That's been happening already, lots of multinational companies do their crypto work in Europe and then send the finished product to the US division, because once it's in the US you can't get it out again.
What I'd LOVE to see is someone porting the full KDE system to run natively on Windows, then write a layer that'll handle Windows GUI calls and DirectX through KDE. A screenshot of that would freak out so many people...
Considering how horrible-looking and slow gtk-qt-engine is, I don't think such a layer would be very useful.
Ummm... If I wanted to run KDE, why would I buy a Mac? I mean I love my Powerbook, but I know the Pentium M systems are faster, cheaper, and (if my experiences are the rule not the exception) more reliable.
If you look at any Apple thread (at least prior to the x86-switching keynote) where it comes up, you'll see 500 apple zealots saying Mac hardware is the same price, faster, and far more reliable than x86 systems, and anyone who replies denying it getting modded down as troll.
RTFA, the programs are running locally. True, all it basically shows is a) OSX can get a working X and GNU tools and b) KDE really is independent of the underlying OS and only relies on X and some GNU tools, as has always been its aim, but it's impressive and useful. Since it's still using X it's not really any better technically than the port of KDE to Solaris, but I think this will mean more to more people.
It's good for making things more OS-independent and helping migrations. KDE runs on most unicies and now OSX, a windows port should happen with Qt4. Once that happens you have a complete suite of applications you can train your users with and then migrate them to whichever OS you like with hardly any noticable differences.
Qt/Mac was made available under the GPL fairly recently, so this is an encouraging sign for the porting of KDE to windows (though that has to wait for the porting of KDE to Qt4). I also presume that they've managed to remove the dependencies on X, which should not only speed up windows ports but also makes it more feasible to run KDE apps on Qt/Embedded. Anyone with a Zaurus like to comment?
A lot of the patches had to be rewritten and others could only be merged after apple opened up its VCS (which it only did after the row provoked by those patches), it wasn't just a question of dropping in the Apple patches. It was quite a flamewar if you remember.
It's a target for 4.0, since Qt wasn't free on windows before V4. However, there's already a working cygwin version and partial pure native port at http://kde-cygwin.sf.net/
It's not OSNews, it's KDE Dot, the summary is identical. This happened with the Qt 4 release too, even though I'd submitted a better version. I think the way to get stories approved is to bribe the/. editors.
firefox extensions are only a huge security threat because they aren't sandboxed. As someone else mentioned Java implemented a sandbox years ago (presumably because SUN new a little bit about networks and security).
There have still been more than enough Java exploits, either by breaking out of the sandbox or signed code being able to bypass it. Sandboxed execution of remote code is better than running it freely but still far from optimal, it's a step in the right direction but removing the extensions altogether would be better.
I would guess that IE and Firefox aren't secure because neither of the development teams were practiced in networks or security, mainly because Windows is Windows and didn't like anything else and Firefox is mainly developed by people with more time on their hands than the average security / network expert.
There's probably truth in all of that, but I think the principal problem is that with finite resources there's always a tradeoff between features and security, and both have decided the former is more important.
Slashdot Mirror
I wrote scripts for python 2.1, which is IIRC a few years old, and have no problems with them today (on 2.4)
Yes, that's exactly what the OP is saying and it's a stupid idea. By double MD5 I meant a double-length MD5 (twice as many bits in the hash), which although still a stupid idea is nowhere near as stupid as using MD5 and SHA1 together and expecting it to increase security.
Not true, firstly the two come from the same "family" and are related, and secondly most of this type of attacks allow you to generate arbitrarily many files matching the hash almost as easily as two. So you use your MD5 attack to generate a large set (2^60 or however many you need) of RPMs matching the MD5, then you use your SHA1 attack to find one among them which matches the SHA1 too, or vice versa.
Fortunately there is no practical attack against SHA1 yet, but when there is RPM will be completely insecure.
Already been done, as has "Djikstra considered harmful", shortly after the original one.
As another reply said, however, doubling the bit count would improve security. But, a simple double-MD5 would have exactly the same problems. Therefore, the solution is to use a longer and more secure hash, like, for example, SHA-256.
It's a useful property because it means you can MD5 data piece by piece. I don't want to think about how long it would take to MD5 a 700MB .iso if you had to use the file as a whole, it takes long enough as it is. It shouldn't allow you to break a hash function without other flaws, and I'd expect it to be the case for many hashes.
I see "gzip: trailing garbage ignored" messages all the time when unpacking tarballs, should I be worrying about them? I know most users won't.
Anyway, if it's zip compression then by design arbitrary content can be added to the start without resulting in an error. (This is done to make self-extracting programs possible). Make no mistake, this is a very serious break.
Yes, but the point of a hash is that it's computationally infeasible to find them. If you're distributing a binary with a certain MD5 there's sure to be a file somewhere with the same sum, maybe it's a car manufacturer's specification PDF, but I can't write a trojan and get it to MD5 to the same thing *and* do what I want. Now you can.
Attacks only get better, a theoretical vulnerability is one to worry about as they are almost always followed by a practical exploit like this. Move away from SHA1 before the same thing happens.
KDE deserves some credit for not depending on other aspects of its environment. Even when using a crossplatform API it's very easy to make non-portable assumptions about the underlying environment.
I'm a coder and have used stricter languages than C/C++ and have difficulty with XHTML. Partly it's just that I learnt HTML 3, but I think it is unnecessarily restrictive.
Bear in mind that although security implies a certain lack of features the reverse is not true. W3m has a horrible number of unfixed security problems.
That's where having a shell running at -10 on another terminal comes in handy. And while you're right, I can see a good reason to execute plugins at fairly high priority even when they're taking 100% CPU - if you're using the gxine plugin to watch a high-res video, on a slower system it may well take 100% CPU and still be dropping frames. It's a features/security tradeoff where they've gone for the features.
Isn't Kopete adding skype protocol support? That would allow you to check it was encrypting properly.
That's been happening already, lots of multinational companies do their crypto work in Europe and then send the finished product to the US division, because once it's in the US you can't get it out again.
Considering how horrible-looking and slow gtk-qt-engine is, I don't think such a layer would be very useful.
Why is this funny? Not only is he right as far as I can tell, that's actually a true port rather than just using fink and X.
If you look at any Apple thread (at least prior to the x86-switching keynote) where it comes up, you'll see 500 apple zealots saying Mac hardware is the same price, faster, and far more reliable than x86 systems, and anyone who replies denying it getting modded down as troll.
RTFA, the programs are running locally. True, all it basically shows is a) OSX can get a working X and GNU tools and b) KDE really is independent of the underlying OS and only relies on X and some GNU tools, as has always been its aim, but it's impressive and useful. Since it's still using X it's not really any better technically than the port of KDE to Solaris, but I think this will mean more to more people.
It's good for making things more OS-independent and helping migrations. KDE runs on most unicies and now OSX, a windows port should happen with Qt4. Once that happens you have a complete suite of applications you can train your users with and then migrate them to whichever OS you like with hardly any noticable differences.
Qt/Mac was made available under the GPL fairly recently, so this is an encouraging sign for the porting of KDE to windows (though that has to wait for the porting of KDE to Qt4). I also presume that they've managed to remove the dependencies on X, which should not only speed up windows ports but also makes it more feasible to run KDE apps on Qt/Embedded. Anyone with a Zaurus like to comment?
A lot of the patches had to be rewritten and others could only be merged after apple opened up its VCS (which it only did after the row provoked by those patches), it wasn't just a question of dropping in the Apple patches. It was quite a flamewar if you remember.
It's a target for 4.0, since Qt wasn't free on windows before V4. However, there's already a working cygwin version and partial pure native port at http://kde-cygwin.sf.net/
It's not OSNews, it's KDE Dot, the summary is identical. This happened with the Qt 4 release too, even though I'd submitted a better version. I think the way to get stories approved is to bribe the /. editors.
There have still been more than enough Java exploits, either by breaking out of the sandbox or signed code being able to bypass it. Sandboxed execution of remote code is better than running it freely but still far from optimal, it's a step in the right direction but removing the extensions altogether would be better.
I would guess that IE and Firefox aren't secure because neither of the development teams were practiced in networks or security, mainly because Windows is Windows and didn't like anything else and Firefox is mainly developed by people with more time on their hands than the average security / network expert.
There's probably truth in all of that, but I think the principal problem is that with finite resources there's always a tradeoff between features and security, and both have decided the former is more important.