However, note that most people use DSA as their signing algorithm, and DSA can only use a 160-bit hash. So if you don't want SHA-1, you have to use RIPEMD-160. If you want to use SHA-256, you'll need to use RSA as your signing algorithm (which would mean creating a new key).
SHA-256 is not just SHA-1 with more bits; it's a different algorithm. So moving from SHA-1 to SHA-256 is not the same as moving from RSA-512 to RSA-1024. (However, moving from SHA-256 to SHA-512 would be.)
RSA was never broken in the same way that SHA-1 is now (allegedly -- since the paper is not yet published) broken, or that MD5 is broken. SHA-1 is broken in the sense that the researchers were able to find a collision in much less than the expected 2^80 calculations. This indicates that the algorithm is weaker than previously believed, and may soon result in much quicker attacks. RSA-512 is broken because computing power has caught up with it, and it's possibly economical to build a computer that can crack 512-bit RSA keys. Weaknesses that are solely due to key/hash size may be fixed by switching to a larger size. Weaknesses that are inherent in the algorithm may not be able to be fixed in this way.
All hash algorithms are vulnerable to this if you don't use a salt (or too small of a salt). UNIX-like OSes have been using salt for a very long time (if not forever). See, for example, the crypt(3) man page. If you use a large enough salt, precomputed hash databases are pretty much useless.
What you are describing is a different type of attack from what the Chinese researchers discovered. Their attack allows them to generate two messages that have the same hash; it doesn't allow them to generate a message that hashes to a fixed value. So password hashing is still safe -- AFAIK, there are no known attacks against it other than brute force (or rubber hose).
Actually, the summary says that the 22W LEDs produce twice the light of a 100W incandescent. So it's more that slightly better than compact fluorescent.
Anyway I am the kind of person who always gets electric/static shocks from everything, by this logic I should be a language genius.
Not really. For one thing, static shocks probably wouldn't go through your brain (unless you have the habit of ramming your head against metal objects). And even if it did, it would only mean that you should be smarter with language than if you had never received those shocks -- it says nothing about how smart you would be relative to the general population. The study also doesn't say anything about long-term effects of the shocks -- the shocks might only increase your verbal ability for a short period of time -- or about what happens when you continuously shock yourself -- if you shock yourself too much, it could have a negative effect, instead of an increasingly positive effect.
(And as proof that SmallFurryCreature is not a language genius, I present exhibit A: use of the incorrect "to" in the first sentence of the 4th paragraph, and exhibit B: misspelling of "itchy"...;-) )
I just started trying it out today, so I don't know much about it. I'm also using the Debian package, so I don't know how it is compiling from source. It seems to work as advertised, although it doesn't interact well with the GNOME panel (in that it tries to occupy the same space as where I have a panel, and the panel wants to stay on top, so it sometimes hides the menu), but that is to be expected. It also seems to have some problems drawing certain menus too, but other than that, it does exactly what it claims to do.
That's old news. That particular case of ReiserFS corruption is due to the fact that ReiserFS (until a little while ago) only did metadata jounalling and did not ensure that data is written before metadata. The problem could have been fixed by applying a well-known patch (at least well-known among the ReiserFS community), which has recently been merged into the mainline kernel (at least the 2.6 series, though I'm sure 2.4 has it too).
Reiser4 does not have such a problem, as it operates in data=ordered mode by default.
My understanding is that journalled means the FS can't get into an inconsistant state and so does not need fsck-ing. It does not mean your data is safe from having the power pulled halfway through a write. If you want a super-safe home area you want some sort of logging FS and these are all far slower than journalled (I think).
What you are talking about is journaled data (data=journal) mode, in which data -- not just metadata -- is journaled.
All you need, though, is data=ordered mode, which has for a long time been available for ReiserFS through a patch by Chris Mason, and has been merged into Linux as of 2.6.6. data=ordered is also now the default, so you just have to boot up into 2.6.6, and your data will be fine.
BTW, this is a common problem with all journaled filesystems (that I know of). If you want your data safe, you need to at least use data=ordered.
It should be fairly trivial to add email notification via a Jabber client. As long as they have good spam filtering -- I don't want to be bothered whenever new spam appears in my inbox.
DDs don't have to compile for all archs. Debian has autobuilders. All that the DD has to do is make sure that the package is compilable on all archs (which usually just means uploading the source package to the archive and waiting for the bug reports to roll in). Unfortunately, some of the autobuilders are slow and overloaded.
But fonts still suck ass and I can't seem to improve some of them (gdm, the gnome login splash screen, and the gnome logout dialog).
Do you have the ttf-bitstream-vera package (or some other nice fonts) installed? Try running "dpkg-reconfigure fontconfig" and toggling the autohinter. Sometimes the autohinter makes things better, sometimes worse.
Here are a few SpamAssassin rulesets that catch a lot of the new spammer tricks, including O.,b|f-u.s,c;a,t.e,d W,.o.r.d.s. It is working very well for me, and many others. Right now (after a bit of Bayes training, adding a bogus-X-Originating-IP check that I found on the SpamAssassin list, and using a whitelist), SpamAssassin is separating my spam perfectly -- no false positives, and no false negatives. (BTW, I'm currently getting over 100 spams a day -- it's probably fairly close to 200 a day.)
I thought Yahoo's new scheme was designed to authenticate the mail server that originated a transaction with a Yahoo mail server, not to authenticate the domain in the "From:" line.
That is correct. Yahoo's scheme is to provide authentication for the Received: headers, not the From: header. Currently, the Received: headers frequently get forged, so it is hard to tell where spam is coming from. A real person can usually tell fairly easily, but you can't reliably tell a computer how to do it. It would be much nicer to be able to feed your spam through a program that will send off complaints to the appropriate sysadmin, or that will blacklist the appropriate server, than having to analyze the headers by hand.
Re:Okay but
on
GTK+ TTY Port
·
· Score: 4, Informative
Widget alignments when whatever widgets you align don't fall exactly on their equivalent ascii places?
GTK uses a container model for widget placements (i.e. you put the widgets in containers, and everything gets auto-sized based on the contents). The placement of widgets isn't pixel-based. So this isn't an issue, at least in properly written GTK programs.
Alright, I'm off to recompile X-Chat.
Cursed GTK uses LD_PRELOAD, so there's no recompilation needed. Unless the program is statically linked, of course.
They are not distinguished. Reiser4 technically does not store extended attributes. They are merely files that can be treated, by convention, as extended attributes. (Of course, the "..uid", etc. files *are* attributes, and will prevent you from having a normal file called "..uid".) The ".." convention was chosen to avoid collisions, since nobody seems to be using a ".." prefix for their own files. This should not break anything.
One thing I would like to know about reiserfs is how attributes are attached to directories? If they are just small files in the "directory" bit of a file, what distinguishes them from children of the directory? Or are attributes just banned from dirs? Seems limiting.
Extended attributes will just be normal files. The ".." convention is just a convention. Storing the attributes is implemented by making it possible to use files as directories (and vice versa).
Now, in this article, I see the assertion that databases in general require transactions, and thus cannot be supported by a filesystem.
I don't know where that came from. Reiser4 will have support for transactions. (at the top of http://namesys.com/v4/v4.html) I think that Reiser4 will be ACID-compliant, but I'm not a database guy. Of course, using transactions requires the use of some new system calls.
1) AFAICT, cp/bin/prog/bin/prog will fail due to permissions. When you try to write to an existing filename, it will try to write to the layer in which the filename already exists. Since/bin/prog is read-only, you will get a permission error. At least that's how writes were explained in the ReiserFS list. (BTW, it is not yet determined that this feature will be in Reiser4. Hans basically told the guy who suggested it (who happens to be the same guy who wrote the article) to write a plugin.)
2) I would imagine that the Reiser4 way to do this would be to use a plugin. But seeing as you don't need root permissions for chown/chgrp/chmod, a user could just run his own version, so I don't really see how your system provides any security.
3) Reiser4 will allow you to view/etc/passwd both as a flat file (for compatability and efficiency reasons) and as a hierarchy.
Slashdot Mirror
However, note that most people use DSA as their signing algorithm, and DSA can only use a 160-bit hash. So if you don't want SHA-1, you have to use RIPEMD-160. If you want to use SHA-256, you'll need to use RSA as your signing algorithm (which would mean creating a new key).
All hash algorithms are vulnerable to this if you don't use a salt (or too small of a salt). UNIX-like OSes have been using salt for a very long time (if not forever). See, for example, the crypt(3) man page. If you use a large enough salt, precomputed hash databases are pretty much useless.
What you are describing is a different type of attack from what the Chinese researchers discovered. Their attack allows them to generate two messages that have the same hash; it doesn't allow them to generate a message that hashes to a fixed value. So password hashing is still safe -- AFAIK, there are no known attacks against it other than brute force (or rubber hose).
Actually, the summary says that the 22W LEDs produce twice the light of a 100W incandescent. So it's more that slightly better than compact fluorescent.
Not really. For one thing, static shocks probably wouldn't go through your brain (unless you have the habit of ramming your head against metal objects). And even if it did, it would only mean that you should be smarter with language than if you had never received those shocks -- it says nothing about how smart you would be relative to the general population. The study also doesn't say anything about long-term effects of the shocks -- the shocks might only increase your verbal ability for a short period of time -- or about what happens when you continuously shock yourself -- if you shock yourself too much, it could have a negative effect, instead of an increasingly positive effect.
(And as proof that SmallFurryCreature is not a language genius, I present exhibit A: use of the incorrect "to" in the first sentence of the 4th paragraph, and exhibit B: misspelling of "itchy"... ;-) )
I just started trying it out today, so I don't know much about it. I'm also using the Debian package, so I don't know how it is compiling from source. It seems to work as advertised, although it doesn't interact well with the GNOME panel (in that it tries to occupy the same space as where I have a panel, and the panel wants to stay on top, so it sometimes hides the menu), but that is to be expected. It also seems to have some problems drawing certain menus too, but other than that, it does exactly what it claims to do.
You can try WildMenus, which puts the menubar at the top of the screen, like on MacOS.
http://freshmeat.net/projects/wildmenus/
Reiser4 does not have such a problem, as it operates in data=ordered mode by default.
What you are talking about is journaled data (data=journal) mode, in which data -- not just metadata -- is journaled.
All you need, though, is data=ordered mode, which has for a long time been available for ReiserFS through a patch by Chris Mason, and has been merged into Linux as of 2.6.6. data=ordered is also now the default, so you just have to boot up into 2.6.6, and your data will be fine.
BTW, this is a common problem with all journaled filesystems (that I know of). If you want your data safe, you need to at least use data=ordered.
It is patent encumbered, but a license is granted for GPLed works. http://djvu.sourceforge.net/licensing.html
LiMac? Licintosh?
It should be fairly trivial to add email notification via a Jabber client. As long as they have good spam filtering -- I don't want to be bothered whenever new spam appears in my inbox.
DDs don't have to compile for all archs. Debian has autobuilders. All that the DD has to do is make sure that the package is compilable on all archs (which usually just means uploading the source package to the archive and waiting for the bug reports to roll in). Unfortunately, some of the autobuilders are slow and overloaded.
Here are a few SpamAssassin rulesets that catch a lot of the new spammer tricks, including O.,b|f-u.s,c;a,t.e,d W,.o.r.d.s. It is working very well for me, and many others. Right now (after a bit of Bayes training, adding a bogus-X-Originating-IP check that I found on the SpamAssassin list, and using a whitelist), SpamAssassin is separating my spam perfectly -- no false positives, and no false negatives. (BTW, I'm currently getting over 100 spams a day -- it's probably fairly close to 200 a day.)
That is correct. Yahoo's scheme is to provide authentication for the Received: headers, not the From: header. Currently, the Received: headers frequently get forged, so it is hard to tell where spam is coming from. A real person can usually tell fairly easily, but you can't reliably tell a computer how to do it. It would be much nicer to be able to feed your spam through a program that will send off complaints to the appropriate sysadmin, or that will blacklist the appropriate server, than having to analyze the headers by hand.
Let's all flood SCO with mail, telling them that we are Linux users, and inviting them to try and sue us.
They are not distinguished. Reiser4 technically does not store extended attributes. They are merely files that can be treated, by convention, as extended attributes. (Of course, the "..uid", etc. files *are* attributes, and will prevent you from having a normal file called "..uid".) The ".." convention was chosen to avoid collisions, since nobody seems to be using a ".." prefix for their own files. This should not break anything.
1) AFAICT, cp /bin/prog /bin/prog will fail due to permissions. When you try to write to an existing filename, it will try to write to the layer in which the filename already exists. Since /bin/prog is read-only, you will get a permission error. At least that's how writes were explained in the ReiserFS list. (BTW, it is not yet determined that this feature will be in Reiser4. Hans basically told the guy who suggested it (who happens to be the same guy who wrote the article) to write a plugin.)
2) I would imagine that the Reiser4 way to do this would be to use a plugin. But seeing as you don't need root permissions for chown/chgrp/chmod, a user could just run his own version, so I don't really see how your system provides any security.
3) Reiser4 will allow you to view /etc/passwd both as a flat file (for compatability and efficiency reasons) and as a hierarchy.