June 29th, 2004

RSS ads

Without naming names, I've started to see ads in RSS feeds. (whole items that are just ads, not even discussing ads above/below real items)

I'm wondering if we should let there be a regexp configured per-feed to flag these entire-item-ads and either discard them, or let the user choose if they want them. (perhaps into journal categories)

Of course, then it's just an arms race. Will RSS eventually turn into the mess HTML is today?

email+PGP problems

[I started out with support on this, but I suspect it's actually a bug, rather than a support issue, exactly.]

I've had some problems with the email PGP posting which, as near as I can tell, hasn't been touched in months. There's some UTF-8 stuff and some image stuff that went in around it in livejournal/cgi-bin/ljemailgateway.pl, but none of that seems to be mangling the MIME::Entity in the case of my test messages.

I hacked ljemailgateway.pl (in ugly ways) so that I could play with this without installing all of lj locally. Unless there's a wrinkle hidden in the ljconfig stuff that I'm missing somehow (and I'm pretty sure there isn't) the code should validate the messages that post.livejournal.com has been rejecting.

Is it possible that someone doing maintenance on the lj servers updated MIME::Parser (less likely; if that weren't behaving many more people would be whining) or Mail::GnuPG without regression testing? Perhaps even gpg itself (there may have been some newly-paranoic changes in it that means my 1.2.4 behaves fine but whatever's on the server doesn't; like say refusing to have a homedir under /tmp).

If the callout to gpg returns undefined you get the not_signed output (at line 411 of ljemailgateway.pl)... but that'll happen for reasons other than the lack of a signature (the easiest example is that the permissions on gpg's homedir are more permissive than 0600). So there should maybe be some better error checking here (like, say, actually doing something with $err, defined on line 393; incidentally, closing it on line 398 would protect against a potential memory leak, though I'm pretty sure Perl will garbage collect anyway here).

I was hoping I'd be able to replicate the problem... but I can't. Nor can I use test for this, since PGP-signed emails are a paid-user-only feature. (Unless I'm confused and test is hacked so that one can create paid user accounts without actually paying, nor having to pass through SSL for CC information?) If someone wants to create me a "paid" account on test, I'd be glad to, erm, test this there.

Update: It's quite possible this is related to the stupid-git attacks and an overworked mail infrastructure.

Update 2.1: test.livejournal.com is now configured for PGP, but it lacks email post support,
so I still can't test this there, unfortunately. I'm reasonably sure that all that would happen is that the posting works, though, so I don't think this would help much.

Update 3: Here's a patch that will report the real error state in the case that Mail::GnuPG fails to fill $ret.
Collapse )I can't know what errors to check for unless this is run on the production lj servers, but it's also not code that should be run on production servers for long (because it's just spewing what would have been die messages from inside Mail::GnuPG to the world). Should I email mahlon at this point?
amused, happy
  • mart

Global Locks

I notice that ddlockd is currently considered to be not ready for production, so I assume that it's not currently used. In this case, then, how should a maint task ensure that its processing does not get into a race condition with another server running the same maint task simultaneously? Is there currently any mechanism for aquiring a global lock, or do I just have to make sure that only one server runs my maint task right now?