27 Sep, 2007, David Haley wrote in the 1st comment:
Votes: 0
Samson said:
And we did it with code that's rock solid secure.

How do you back that claim up? I'm not disputing or agreeing with it; I'm just curious what basis you have for saying your code is that secure. Not having found security holes doesn't mean there aren't any; it's one of the benefits of having a (relatively) small user base. Web applications are notoriously hard to make fool proof, so I'd be a little skeptical of anybody saying they were completely rock-solid when the development hasn't undergone some kind of (semi-)formal security analysis.
27 Sep, 2007, Guest wrote in the 2nd comment:
Votes: 0
Sadly I don't have loads of money to pay for a team of professional code auditors to provide verifiable evidence. I can only go by my experiences in using the code, and by our attention to security concerns while developing it.

All of the sites I run using QSF and QSFP have weathered numerous obvious attacks and during our run on the project we only had one confirmed exploitable breech which got plugged up within hours of being reported. So I'm sorry we don't have lab coats examining our code, but I hardly think that invalidates making the statement. The code is rock solid, and unless you have evidence otherwise….
27 Sep, 2007, Conner wrote in the 3rd comment:
Votes: 0
Personally, I'd solidly recommend QSFP myself. I use it for both my mud's forums and for my family blog site which also doubles as a few other group forums for me privately and have had very few problems with it, none of which Samson couldn't help me solve in very short order. I have used other forum software and I thuoght invision was pretty nice, but it's very expensive and invisionfree becomes anything but free should you decide to transition away from it.

David: Note that he said it was secure, not fool-proof, I know that I've manged to fool my way into setting things wrong before and having to track down why members couldn't reach this or do that before and even the opposite trying to figure out what I'd done wrong that was allowing so-and-so to do/access such-and-such, but I can not blame the software for that, it was because I set something wrong for my needs. As to how he can claim rock solid security, I can't directly address that, but it does certainly from an end-user and site adminstration stand point feel pretty secure.
27 Sep, 2007, David Haley wrote in the 4th comment:
Votes: 0
Samson said:
So I'm sorry we don't have lab coats examining our code, but I hardly think that invalidates making the statement. The code is rock solid, and unless you have evidence otherwise….

Like I said, I wasn't trying to dispute the truth of the claim; I was just pointing out that a lack of evidence of flaws is not proof that no flaws exist. (It does give credence to the claim that no obvious flaws exist.) Efforts to make the product safe/secure aren't proof either; we've seen that go wrong time and time again throughout the entire history of engineering.

This isn't a criticism of your code, Samson; I was just asking if you had anything to defend your claim other than the fact that you don't know of any bugs. That said, of course it is better to have something with no known flaws than to have something with known flaws.

Conner said:
David: Note that he said it was secure, not fool-proof,

Fool-proof wasn't the best word; I should have said something like "attack-proof". :smile:

Conner said:
but it does certainly from an end-user and site adminstration stand point feel pretty secure.

I'm sure that lots of things "feel" secure, until somebody comes out with a zero-day exploit. :wink:
27 Sep, 2007, Conner wrote in the 5th comment:
Votes: 0
Well, I believe Samson did invite you to prove his claim otherwise.. :tongue:
27 Sep, 2007, Guest wrote in the 6th comment:
Votes: 0
Quote
Like I said, I wasn't trying to dispute the truth of the claim; I was just pointing out that a lack of evidence of flaws is not proof that no flaws exist. Efforts to make the product safe/secure aren't proof either; we've seen that go wrong time and time again throughout the entire history of engineering.


I can't give you the kind of proof you seek. I think you know this. I'm not sure why you chose to make such an issue out of this. A lack of evidence of flaws may not be proof that none in fact exist, but at the same time you certainly have nothing to suggest that some do and whether you intended for it to or not, your statement comes off as accusing ignorance of the issue. I can only assure you ( and everyone else reading ) that we're not oblivious to security concerns and we do keep that in mind while writing code.

I never said our code was fool-proof, attack-proof, bomb-proof, idiot-proof, or anything of the sort. I said it was "rock solid" which I continue to defend as a perfectly valid statement in the absence of any evidence that there are gaping holes needing to be plugged.
27 Sep, 2007, David Haley wrote in the 7th comment:
Votes: 0
Samson said:
A lack of evidence of flaws may not be proof that none in fact exist, but at the same time you certainly have nothing to suggest that some do

I already said that there is something to suggest it: the entire history of engineering, traditional and computer, is fraught with people who, despite their best intentions, sometimes made mistakes. What is so characteristic and nasty of security mistakes is that they're very, very hard to predict ahead of time. (Who would have guessed that input x1234161@$"!@$%! would cause an error that let the attacker gain control of the system?)

Samson said:
I'm not sure why you chose to make such an issue out of this.

As I originally said, I was just curious if you had something to back it up beyond the fact that you have been very careful and that there are no known flaws. As I also said, I was not trying to criticize your package, in fact you might notice that I heartily recommended it as the first reply to this thread. And I recommend it in part because I believe its security is much better than that of phpBB's, which tends to grow in rather chaotic ways and which favors "cool features" over "good code". phpBB's security isn't even on the radar for me. (To be fair, their much larger user base also makes them a much larger target for attackers, and then, statistically speaking, if flaws exist in both phpBB and something else, the ones in phpBB are more likely to be found quickly.)

That said I'm not sure what difference you seek to establish between "attack-proof" and "rock solid". If something is rock solid, it is almost by definition safe against attacks and so forth.
27 Sep, 2007, Conner wrote in the 8th comment:
Votes: 0
David, I really think he was refering more to it's stability initially, but it's security thus far has proven pretty effective as far as we know too.
27 Sep, 2007, Guest wrote in the 9th comment:
Votes: 0
Being attack-proof implies a level of certainty you can't get without some kind of audit or other certification. Something can be rock solid and still have a chink, I'm not stupid enough to claim we're invulnerable. But from what I've experienced, a frontal assault isn't going to do much outside of potentially annoying me/us with some error messages. Like you and I, the hackers also have the source code handy and can scour it for flaws to exploit. It would be foolish to assume they're not testing things even as we speak. Our apache logs just for this site alone prove beyond all doubt that they ARE trying. It's just not getting them anywhere. Small userbase or not, they're making a grand effort just the same.

That's how I justify saying rock solid. But I don't have thousands of dollars to spend on a proper professional security audit to be able to declare it "attack-proof". I wouldn't waste that kind of money anyway. IPB did it, plugged all the holes the auditors found, and a week later someone attacked them with another exploit nobody knew was there. That sort of thing happens when you get arrogant and are maintaining a spaghetti code application.

QSF/QSFP isn't a spaghetti code application. I'm willing to bet that the clean code makes it far easier to spot potential pitfalls before they ever reach the public. There's also less code overall than most other packages, so there's less to have to scrutinize on a regular basis.
27 Sep, 2007, kiasyn wrote in the 10th comment:
Votes: 0
Samson said:
Our apache logs just for this site alone prove beyond all doubt that they ARE trying.


Oooh, really? *checks logs*
27 Sep, 2007, David Haley wrote in the 11th comment:
Votes: 0
kiasyn said:
Samson said:
Our apache logs just for this site alone prove beyond all doubt that they ARE trying.


Oooh, really? *checks logs*

Yes; check the logs for any application on the web, esp. e.g. Apache, and you will see tons upon tons of bad requests made, where people are trying to fool your system, break it, or just be annoying little, err, excrements.

Samson said:
That's how I justify saying rock solid.

Fair enough. I'm not sure I'd use the words the same way, but now I know what you mean.

Samson said:
That sort of thing happens when you get arrogant and are maintaining a spaghetti code application.

Arrogance about one's own security is in part responsible for most of the flaws around. It's why I'm skeptical of anybody who claims to have such good security. :smile:

Samson said:
I'm willing to bet that the clean code makes it far easier to spot potential pitfalls before they ever reach the public

I'm not sure this argument is a good one, because although what you say is true, it also makes it easier for attackers to spot said pitfalls. So it's score one for the good guys and score one for the bad guys. However, having clean code makes it easier to get things right (or close to right) from the get-go.
27 Sep, 2007, Guest wrote in the 12th comment:
Votes: 0
DavidHaley said:
Samson said:
I'm willing to bet that the clean code makes it far easier to spot potential pitfalls before they ever reach the public


I'm not sure this argument is a good one, because although what you say is true, it also makes it easier for attackers to spot said pitfalls. So it's score one for the good guys and score one for the bad guys. However, having clean code makes it easier to get things right (or close to right) from the get-go.


Well if the statement is true, then by virtue the argument is good. If we're able to spot the pitfalls before they go public, then I fail to see how that's a score for the dark side since those pitfalls are going to be addressed before a release.
27 Sep, 2007, David Haley wrote in the 13th comment:
Votes: 0
Samson said:
Well if the statement is true, then by virtue the argument is good. If we're able to spot the pitfalls before they go public, then I fail to see how that's a score for the dark side since those pitfalls are going to be addressed before a release.

Well, like I said, you are able to find the pitfalls quickly, but so are the bad guys. It is unlikely that the dev team will find all pitfalls every single time, and because the source is clean, it will be easier for the bad guys to spot them.

What I'm arguing is basically this:
Clean code –> easier for everybody (good and bad people) to spot problems
Clean code –> easier for the dev team to get things right from the get go
0.0/13