Gallery2 and Comment Spam BotNets

In his blog post about the m68k port he’s writing about the port being dead, because there’s simply no security support for it.

I have to admit that he might be right about it.

Although the m68k port is doing fine with keeping up, there are so many problems, that I doubt that m68k will be allowed to get back. My current list, of why m68k might be dead is:

  1. There’s no security support for m68k
  2. m68k has no glibc support in current versions (pthread thingie or so)
  3. m68k is not in stable
  4. packages are getting bigger and bigger and slower and slower all over the place
  5. there is basically no interest in supporting m68k in the majority of DDs
  6. some more minor reasons

I expect some of the above points to be taken against any possible re-inclusion of m68k, such as no security support and being not in stable, which is some sort of paradox because, you’ll guess it, m68k is not release with Etch and thus is not in stable. I guess this is difficult to understand when you’re not a m68k user, but from my point of view, this is forseeable because of past discussion about the status of m68k.
There had been spent so much energy on getting rid off m68k with the Vancouver Massacre, that it’s unlikely that a similar amount of energy will be spent to get m68k back in, because there wasn’t much energy spent for the time after Etch release. Ok, there was the introduction of etch-m68k on the mirrors, but as Joey already stated, that’s only part of the game.
There was a clear view of how to get rid off of m68k, but no vision of how m68k can exist outside of Etch. Now, the m68k support is basically gone, it’s even more problematic to keep up with other ports that are still considered for testing. The whole release infrastructure is based on the migration from unstable to testing. If a port doesn’t exist in testing, because it wasn’t released with the last stable, then it’s hard to get released with the next version of stable.

So, yes, I believe as well that m68k is pretty dead when no miracle happens soon…


11 thoughts on “Gallery2 and Comment Spam BotNets

  1. you can disable the right to comment from non-logged in users via the permissions of the top-level album (or individual albums). just remove the right to add comments from the everyone group and add it for the “logged in users” group (the names of the groups can be a bit off – i'm translating from german here)

  2. I've had great success in my personal blog by just discarding any comments that have a url in them. Seems as if this would be a better option than capcha, or useful in addition, but I'm not really up to digging into the Gallery2 code to do it.

  3. We have over 8000 porn-spam comments added in the last week. Despite capcha
    I set up permissions as below. Changes are applied to sub-items. But I can still comment as guest so it's not working. Any ideas?

    Registered Users [comment] Add comments
    Everybody [core] View all versions
    Everybody [comment] View comments
    Site Admins All access

  4. Hmmm, well, I think I've disabled commenting at all in my Gallery, because I experienced similar problems. Either that or because the captcha was solved by some spam bots…

  5. I have now disabled comments on all gallerys that are one level under the root. This seems to have stopped the spam.

    Do settings not ripple down if the lower level galleries' permisisons have already been customised.

  6. Also had a shed load of comment spam on my Gallery2. Endless postings of URLs. Captcha was installed but I don't think it went through. Suspect that there is another way of posting through the system.

    I ended up banning an IP range on my server. That stopped it – for now.

  7. I have been hit for a few days now from a bot net. Too many IPs to really put in blocks easily, and they rotate through what appears to be sets of about 200 IPs per attack. I have commenting totally disabled on my site, and they're still doing it via a forced push through some of the Gallery software it seems.

    Check your site access logs for the URL they're hitting and how they post the comment. I'm pretty sure there's a way to force the comment in via URL and thats how they're doing it.

  8. Well my site is getting completely hammered by spamming. Captcha on the comment system seems to be invisible with this new wave of attacks. I'm getting spammed to death from random IPs every few minutes. The comments are full of links about gambling and porn. I've turned the comment system off completely.

    Think I may have to get writing some code to enhance the captcha system.

    I've checked the server logs, and there are three access requests. It requests a page, then brings up the comment, and submits the comment. And goes away again .. just 3 accesses are made. Until a few minutes later when they choose a different image to have a go at. Grrrr .. any ideas very much appreciated.

  9. Beside turning off comments completely, the only solution I see is to allow comments just for registered users or specific user groups.

    Another way to handle the issue would be to block the spamming IP addresses and contacting the ISP via the abuse@ email address.

  10. Below is a listing of Gallery2 comment spammer ip addresses, gathered from my webserver log for the last 3 days – you may use them in your firewall or in deny statement in your webserver:

    {,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, }

Comments are closed.