I totally agree with this comment. I don't know whether Diaspora is architecturally secure or not. I strongly suspect that it isn't, but am unqualified (and insufficiently interested) to constructively prove that.
The things I found were mostly tactical insecurities, springing from a combination of Rails Security 101 errors and "web application programming is hard." They're pervasive tactical insecurities. Maybe they'll all get fixed if a lot of people pick over every line of that codebase for the remaining one month before release. But that won't help address the part of the iceberg below the waterline. (I can't see it, but the amount of ice above the waterline strongly suggests it is there.)
I haven't read the code or the design, but I'll say:
* To the extent that Diaspora's security depends on Rails, their problem is tenable; Rails (when properly configured, which this project isn't) does a really nice job of making CRUD secure.
* To the extent that Diaspora's security depends on cryptography, we needn't worry about the security of their current design at all, because they have no current design; what they have instead is a "hello world" of cryptography; someone professional (or in academia) will need to design something for them, and then write a paper on it.
I'm worried about their federation strategy: even assuming users A@provider1 and B@provider2 don't have their communications compromised, I have a feeling that Here There Be Dragons around this area, in every fashion I can imagine and many that I can't. At the moment, though, their crypto is academic in that it is like a bank vault door securing a vault where one wall is actually open air and passerby on the street could walk in and take the money. It may or may not be a good door, I don't know, but it is not a good vault.
The Rails bits, yeah, those should be solvable if anyone wants to solve them. I really like Rails for a lot of reasons, and my experience has been that I do less damage with it than I used to do with Java.