ARGH ARGH ARGH!

[branchandroot]

OMG, LJ YOU UTTER FUCKERS!

Not ONLY do they fuck up the latest release so it allows random people access to random other people's journals and HAVEN'T ROLLED THE RELEASE BACK, but NOW LJ-SEC CAN'T LOG IN. Because those remote log-in pathways that just changed?

AFFECT THE ONLY APPLICATION THAT CAN DO BULK DELETION OF LJ ENTRIES.

RAGE.

*breathing heavily* I can only hope that the lj-sec developer is a kind soul and releases an update soon. Because this is absolutely it, I'm not leaving my content on that service for another second than I have to. Nothing but public links to other sites!

ETA: It has been suggested by a party who wishes to remain unnamed, but who has some cause to know, that the reason a release like this will not be rolled back despite security failure is most usually that this release fixes some /other/ security bug that was being actively exploited. Additional recommendation: try logging out of LJ and not logging back in until it's fixed. This would kill one possible cause of the mad account access swapping. If it's another cause, apparently we're fucked until LJ's worker bees can scramble a fix. *sighs*

Comments

[synecdochic]

Additional recommendation: try logging out of LJ (ideally restarting your browser) and logging back in. This would fix one possible cause of the mad account access swapping. If it's another cause, apparently we're fucked until LJ's worker bees can scramble a fix.

actually, in *most* cases the problem could be (and please note that I have no idea what the problem is or whether it's something other than the Varnish misconfigs they mention in http://lj-maintenance.livejournal.com/131843.html and claim to have fixed), logging out of LJ entirely, expiring all sessions, and staying logged out until the problem is no longer being reported, would most likely do it. If it's cache/Varnish problems the way they say, that would prevent you from loading a page logged in and thus having your logged-in account cached for someone else to see; if it's something more serious like a fucked up master cookie->login session table or something, it would prevent your master cookie or login session from existing (and thus from being confused with someone else's).

[branchandroot]

Ooooo. *grimaces* Yeah, sounds like a good day to put my invite codes up on codesharing.

[synecdochic]

Yeah. I feel so horrible for my old team; they're probably on the phone shouting at the tops of their lungs right now :(

[branchandroot]

I can only imagine. Talk about a nightmare.

[synecdochic]

Even if it really was the Varnish caching problem they mentioned (which I'm not convinced of, given that the reports kept going for ~24h or so after the supposed fix), that post was nobody's idea of a good explanation :(

[dragonwolf]

So...um....why is Varnish even set up to cache the pages that should be encrypted and pretty much by security definition not cached, even if everything else is cached and not encrypted? Hell, if only the "sensitive" pages (ie - payment, login, etc) are the only ones that are encrypted (the issues with things like Firesheep notwithstanding), it should make it easier to filter out such stuff, because it will be on a different port. In fact, I'm fairly certain Varnish ignores port 443 by default, at least on the standard installs.

Yeah...their explanation seems fishy to me.

/end rant of fellow developer/sysadmin

[synecdochic]

I am pretty sure the answer involves a firm bit of Dunning-Krueger.