Hmmm, worked for me, after I clicked on the link at the bottom saying something in the line with "Linux compatible player". It then went ahead and asked if I wanted to install the Codec, which I did, and then it worked fine (watching it right now).
I tested this Perl module a while ago, and it has truly abysmal performance, giving a bad rep for Bloom Filters. I've been using an implementation written in C++, with a Perl XS API (thanks Tim!) and there's no comparison. Well, I guess there is a comparison, like this (for a set of 4.5M entries):
(first numbers are for Bloom::Filter, second number for "doctor" Sturge's C++ Bloom filter implementation).
I haven't spent a lot of time looking at the Perl code, but it's clearly doing some very suboptimal bitmap operations, and it's certainly not memory efficient at all (which is the main reason to use Bloom filters). Granted, this should be easy to fix.
I upgraded my RedHat9 to 2.6.1 kernel by simplying picking a few Fedora core 2 ("development" packages). Was really easy, I wrote a short note on it, at http://www.ogre.com/tiki-view_blog_post.php?blogId =3&postId=32
if people just set up their mail servers to force authentication before outgoing mail can be sent, there wouldn't be any problems. Sorry there will be some problems, but I bet it would eliminate a lot of spam.
Hmmm, what kind of spam would this prevent? Open SMTP relays? Forged From: addresses? Sure, we might get rid of some spam that way, but it will not fix the real problem IMO. It's just too easy to setup your own SMTP spamming server to "bypass" this, unless of course we start requiring SMTP auth in all SMTP traffic (not just from the MUA to MTA). But what a nightmare to maintain the global directory of servers and credentials...
Also, setting up SMTP auth to work with all possible clients turns out to be somewhat of a pain. I've done it with sendmail, and although it worked nicely "out of the box" for most clients, at least one had serious issues with the SASL and TLS protocols (see
this article for instance).
And yeah, unfortunately there will always be victims out there who will buy from spammers and telemarketers. And there will always be predators ready to take advantage of them, if they can do so. Spam works well because it's virtually free to do, so even with some incredible small "click through" rate, it's profitable.
Making spamming computational expensive, as has been talked about several times, seems like the best solution right now. I don't particular like this postage stamp solution, although, it certainly addresses the root of the problem, it's too easy/inexpensive to spam.
I watched the population size from Saturday 1/25 10am (PST) to Sunday 1pm (PST). It grew pretty steadily all day, from 5,349 to 8,662 users over a 24 hour period. Of course, by this time, the abuse on broadcast messages etc. was rampant.
Well, DHCP is inherently insecure, so this is definitely not a MacOSX specific "bug" (but I personally don't consider it a bug). This is all well documented in the DHCP RFCs and docs, e.g. from RFC 2131:
7. Security Considerations
DHCP is built directly on UDP and IP which are as yet inherently
insecure. Furthermore, DHCP is generally intended to make
maintenance of remote and/or diskless hosts easier. While perhaps
not impossible, configuring such hosts with passwords or keys may be
difficult and inconvenient. Therefore, DHCP in its current form is
quite insecure.
Unauthorized DHCP servers may be easily set up. Such servers can
then send false and potentially disruptive information to clients
such as incorrect or duplicate IP addresses, incorrect routing
information (including spoof routers, etc.), incorrect domain
nameserver addresses (such as spoof nameservers), and so on.
Clearly, once this seed information is in place, an attacker can
further compromise affected systems.
Malicious DHCP clients could masquerade as legitimate clients and
retrieve information intended for those legitimate clients. Where
dynamic allocation of resources is used, a malicious client could
claim all resources for itself, thereby denying resources to
legitimate clients.
I think what makes MacOSX "unique" is that they use services traditionally not provided by DHCP (in this case, LDAP server information). Just like with NIS/YP, we have a tradeoff between ease of deployment (automatic service discovery) vs strong security. I know for a fact that way back, many YP/NIS deployments got hacked (in open networks, most commonly Universities) by simply pretending to be an NIS server. NIS+ addressed this problem (and others), and made it close to impossible to deploy and maintain.:-)
I don't know what Apple will do to "secure" this, the natural solution seems to be to have the DHCP client limit which servers it will talk to (establish a trust relation). It could be done with something as simple as a DHCP server host list, or more likely using Kerberos tickets to verify the authenticity of the DHCP response (I'm no Kerberos expert, so don't quote me on that one). More than likely, it'll make deployment a bit harder that what it is now.
I still don't understand why this security "hole" got so much attention... Are people struggling to find problems with MacOSX? First of all, attacks like this is nothing new, just remember the old YP/NIS problems with broadcasting for the server, to mention just one example.
Secondly, when we wrote the DHCP LDAP option specs way back when, we explicitly documented this problem in the security section:
5. Security considerations
Security considerations discussed in [3], particularly with respect to the provision of authentication information, are directly applicable here. Additionally, it should be noted that providing LDAP server information by a broadcast protocol such as DHCP may allow unauthorized clients to learn the location of and authentication information for LDAP servers and hence pose as valid clients. This presents a security problem when sensitive information, such as user passwords, is published via LDAP servers.
The DHCP protocol provides no mechanisms for the client to verify the validity and correctness of the received information. The security considerations in [1] discuss several weaknesses, particularly the problem with unauthorized DHCP servers.
This was written in 1997, note the last paragraph above. These issues has been discusses and documented in several RFCs, many years ago...
I've tried this on two systems now. On one of them, the patched Metacity works great, no performance problems, thumbnails pop up very fast, and the Expose feature works well. On the other (similar hardware), it's dog slow, and many times the thumbnails are outright wrong... Both machines are running the same base distribution (RH9).
The difference on the systems are:
Machine A: Linux 2.4.20 kernel with latest, unstable Ximian gnome packages (bleeding edge release)
Machine B: Linux 2.6-test9, stable Ximian gnome (XD2)
Machine A is performing nicely with Expocity, machine B is pretty much useless (too slow, to unreliable). I'm not sure what is causing the problem, but it's either the 2.6 kernel or the old'ish Gnome installation.
In either case, there's something weird going on, and if you are experiencing performance issues with this patch, maybe look into these two things.
I tried this, and it actually works, quite well too. It replaces the "alt-TAB" feature, which seems like a questionable decision. I would rather have kept the old "windows" functionality (rotating between windows), and added Expose'ing as a new function entirely.
I downloaded the patch from the post, and got the CVS from gnome.org. Building it was easy, like:
# cvs -d:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome login # cvs -d:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co metacity
# patch -p0/tmp/expocity-11-24-03.diff
# cd metacity # CFLAGS='-O3 -march=pentium4'./autogen.sh --prefix=/usr # make # make install
Slashdot Mirror
Hmmm, worked for me, after I clicked on the link at the bottom saying something in the line with "Linux compatible player". It then went ahead and asked if I wanted to install the Codec, which I did, and then it worked fine (watching it right now).
It's fortunately not that simple, try it and you'll see. Y! clearly is not this stupid to let anyone mark anything as spam.
I tested this Perl module a while ago, and it has truly abysmal performance, giving a bad rep for Bloom Filters. I've been using an implementation written in C++, with a Perl XS API (thanks Tim!) and there's no comparison. Well, I guess there is a comparison, like this (for a set of 4.5M entries):
.vs. 172,000/sec .vs. 18MB
Inserts ("add"): 10/sec
Memory usage: 200MB
(first numbers are for Bloom::Filter, second number for "doctor" Sturge's C++ Bloom filter implementation).
I haven't spent a lot of time looking at the Perl code, but it's clearly doing some very suboptimal bitmap operations, and it's certainly not memory efficient at all (which is the main reason to use Bloom filters). Granted, this should be easy to fix.
-- Leif
I upgraded my RedHat9 to 2.6.1 kernel by simplying picking a few Fedora core 2 ("development" packages). Was really easy, I wrote a short note on it, at http://www.ogre.com/tiki-view_blog_post.php?blogId =3&postId=32
Hmmm, what kind of spam would this prevent? Open SMTP relays? Forged From: addresses? Sure, we might get rid of some spam that way, but it will not fix the real problem IMO. It's just too easy to setup your own SMTP spamming server to "bypass" this, unless of course we start requiring SMTP auth in all SMTP traffic (not just from the MUA to MTA). But what a nightmare to maintain the global directory of servers and credentials...
Also, setting up SMTP auth to work with all possible clients turns out to be somewhat of a pain. I've done it with sendmail, and although it worked nicely "out of the box" for most clients, at least one had serious issues with the SASL and TLS protocols (see this article for instance).
And yeah, unfortunately there will always be victims out there who will buy from spammers and telemarketers. And there will always be predators ready to take advantage of them, if they can do so. Spam works well because it's virtually free to do, so even with some incredible small "click through" rate, it's profitable.
Making spamming computational expensive, as has been talked about several times, seems like the best solution right now. I don't particular like this postage stamp solution, although, it certainly addresses the root of the problem, it's too easy/inexpensive to spam.
-- leif
I watched the population size from Saturday 1/25 10am (PST) to Sunday 1pm (PST). It grew pretty steadily all day, from 5,349 to 8,662 users over a 24 hour period. Of course, by this time, the abuse on broadcast messages etc. was rampant.
I think what makes MacOSX "unique" is that they use services traditionally not provided by DHCP (in this case, LDAP server information). Just like with NIS/YP, we have a tradeoff between ease of deployment (automatic service discovery) vs strong security. I know for a fact that way back, many YP/NIS deployments got hacked (in open networks, most commonly Universities) by simply pretending to be an NIS server. NIS+ addressed this problem (and others), and made it close to impossible to deploy and maintain.
I don't know what Apple will do to "secure" this, the natural solution seems to be to have the DHCP client limit which servers it will talk to (establish a trust relation). It could be done with something as simple as a DHCP server host list, or more likely using Kerberos tickets to verify the authenticity of the DHCP response (I'm no Kerberos expert, so don't quote me on that one). More than likely, it'll make deployment a bit harder that what it is now.
-- Leif
Secondly, when we wrote the DHCP LDAP option specs way back when, we explicitly documented this problem in the security section:
This was written in 1997, note the last paragraph above. These issues has been discusses and documented in several RFCs, many years ago...
-- Leif
I've tried this on two systems now. On one of them, the patched Metacity works great, no performance problems, thumbnails pop up very fast, and the Expose feature works well. On the other (similar hardware), it's dog slow, and many times the thumbnails are outright wrong... Both machines are running the same base distribution (RH9).
The difference on the systems are:
Machine A: Linux 2.4.20 kernel with latest, unstable Ximian gnome packages (bleeding edge release)
Machine B: Linux 2.6-test9, stable Ximian gnome (XD2)
Machine A is performing nicely with Expocity, machine B is pretty much useless (too slow, to unreliable). I'm not sure what is causing the problem, but it's either the 2.6 kernel or the old'ish Gnome installation.
In either case, there's something weird going on, and if you are experiencing performance issues with this patch, maybe look into these two things.
I tried this, and it actually works, quite well too. It replaces the "alt-TAB" feature, which seems like a questionable decision. I would rather have kept the old "windows" functionality (rotating between windows), and added Expose'ing as a new function entirely.
:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome login :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co metacity
/tmp/expocity-11-24-03.diff
./autogen.sh --prefix=/usr
I downloaded the patch from the post, and got the CVS from gnome.org. Building it was easy, like:
# cvs -d
# cvs -d
# patch -p0
# cd metacity
# CFLAGS='-O3 -march=pentium4'
# make
# make install
and then restart X11.