Code tour: 2020 Q1 edition!
Continuing on from the last code tour!
Hi all, some changes coming your way -- figured I'd make the noise!
Fix Summertime horizontal growth (pull request 2613) by
roadrunnertwice
Fix an issue in the
Summertime
style, where sometimes it would grow sideways in an infinite and disgusting fashion. Fixed.Fix cut tags sometimes going backwards (pull request 2614) by
roadrunnertwice
Fix an issue that, in rare circumstances, caused cut tags to expand backwards. And by that I mean that you would click the cut and suddenly be looking at the end of the story, wondering how you got there. Wat.
Fix Crossposter formatting to be less wild (pull request 2616) by
roadrunnertwice
As part of the improvements we've made to Markdown in the last few months (see the previous code tour!), we took a backwards step in terms of the Crossposter and accidentally made it spit out some ... less than good ... output.
This PR not only fixes that, but improves the flow of the system so that the Crossposter behaves in a much more sane fashion when it comes to formatting the post being sent out. The result of this is that even if we add new formatting and fun stuff to Dreamwidth, it should always work wherever the post ends up! Nice!
Remove MD5 password hashing hack (pull request 2619) by
momijizukamori
MD5 has not been hot technology in a good decade, but at one point in our long, storied existence we couldn't rely on browsers and servers being capable of secure connections (HTTPS). Since we had to (gasp!) sometimes send traffic in an unencrypted fashion, we had this ancient hack that would use MD5 to hash your password locally before sending it over the wire.
That was cool in 2001, but in 2020, not only has MD5 been so laughably broken for so long that you might as well not even use it, but every browser and all pages on Dreamwidth force you to use encryption. We never send anything unencrypted, so this hack is no longer necessary.
Deleted with passion by the fearless
momijizukamori.
Modernize password storage (pull request 2621) by
momijizukamori and
mark (and h/t
me_and
kaberett)
As part of modernizing our systems to be vaguely with the times, this change updates how we store your authentication information in the database. Once this is deployed, passwords will no longer be stored -- instead, we will use bcrypt (with random salts) as is considered best-in-class for storing authentication credentials.
We need to do some testing on this to ensure we don't break any of the authentication flows on Dreamwidth (there are so many!), but once that's done we can finally say we comply with modern best practices for how to securely store user credentials.
Also a big hat tip to
me_and for writing the original proposal (which I can't find now... argh) and
kaberett for pushing on this :)
Support development with TaskQueue (pull request 2622) by
mark
Recently we moved off of using MogileFS in many places, which was one of the old systems we used back before... there were better things. Recently we moved over to SQS, a queueing service. That's cool, but there wasn't a way to run the new system "locally" (i.e., in development) unless you were willing to set up an SQS account.
That's not ideal, so this change makes it so developers can interact with our task queue system without doing that. It will magically just work using your local disk and butter your bread.
Cool beans, that's what I've got for now! Bye bye!
no subject
*waves pom-poms of encouragement*
no subject
no subject
(And omg, the cut tag thing, it happens to me ALL THE TIME and DRIVES ME MAD! So happy to see this gone.)
no subject
no subject
no subject
I take it the password changes will require corresponding changes in clients. The ones I've seen (including the one I'm using!) also use an MD5-based challenge-response system for XML-RPC -- is that affected, or just login?
no subject
From conversation in the dev chat, it sounds like DW’s XML-RPC supports both challenge/response AND plain password auth. So for clients that still have their source code available, it should be very feasible to switch to password auth... but there’ll likely be some breakage in the meantime. No one’s thrilled about that, but also this wasn’t a change that could be avoided. 😬
no subject
We don't have very many people accessing the site using clients for a lot of reasons, including the fact that the API clients use to interact with the site is basically 20-year-old technology at this point and needs to be completely replaced. (Which has been started!) Usually we'd still try to avoid breaking that option for the people who still use it, but these particular changes are part of some very important security work that we're doing, so we can't keep supporting the insecure version. I'm very sorry if it breaks things!
no subject
curl
. (I'm presently abusing the one client I could find that could post from a command line, and driving it from a shell script. Anything would be an improvement.)no subject
no subject
no subject
Once you see it, you can't unsee it!
no subject
passwords