476

(14 replies, posted in Feature requests)

But since most web programmers aren't so savvy as to  consiously use it as a security feature, yet still do it, it's usually just Security By Fortunate Laziness.

haha big_smile

477

(3 replies, posted in General discussion)

Has been "fixed" in PunBB 1.3.

Yes, the automatic conversion will continue in 1.3. The only difference is that pun_hash() will always run sha1() (because PunBB 1.3 requires PHP 4.3.0 or later which has sha1 support)..

I would use SHA1 as well. PunBB 1.3 will use SHA1 only.

480

(9 replies, posted in PunBB 1.2 troubleshooting)

Solovey: PunBB 1.2.* does not support UTF-8. You can try to use it, but there's no "official" support. We need to make a bunch of changes to the codebase in order to support UTF-8.

481

(5 replies, posted in Feature requests)

http://dev.punbb.org/changeset/594

Thanks for the tip.

482

(13 replies, posted in PunBB 1.2 discussion)

Has the problem gone away?

483

(5 replies, posted in Archive)

That's the problem. People think of this as the official PunBB discussion forums in Russian and still, I have no idea what's going on in them. Another reason I want to move away from this is that any help and any solutions to problems that are posted in non-English languages are good only to the people who speak that particular language. If someone instead asks their question in English and gets an answer in English, that discussion can be of help to a greater audience.

484

(45 replies, posted in News)

The newsletter is going out as we speak.

485

(13 replies, posted in PunBB 1.2 discussion)

No, it's not a font. My friend "drew it" by hand in Illustrator.

486

(45 replies, posted in News)

grudon66: It is available in Norwegian. Just use the language pack from the download page.

487

(45 replies, posted in News)

Ludo wrote:

Hi,

What about the newsletter? I haven't received any notification for that release.

Ludo,

I'll try to get that out tonight. I can't send it from home anymore, so I'll have to write up some script to do it on the server.

488

(3 replies, posted in Archive)

Postar ett inlägg i den smile

489

(47 replies, posted in General discussion)

Now, if only they would fix this, I would be a happy camper. HttpOnly cookies are a great idea. In short, it means that if you set a HttpOnly cookie, you can't access the contents of that cookie via client side scripting. This essentially makes cross site scripting useless.

Dr.Jeckyl wrote:

Rickard need to update his extension...i can't handle copy, paste and go any more..... ERRRR!

I just did. They're just waiting on approval at addons.mozilla.org. pogenwurst, hurry big_smile

Edit: Just saw this in the e-mail I got reminding me to update my extension:

Firefox Product Team wrote:

As an extra incentive, we're planning on sending a limited edition "Bon Echo" ExtensionTeam shirt to each and every extension developer who validates their extensions for Firefox 2 with an update posted to addons.mozilla.org by midnight pacific time on Sunday, October 1st 2006.

How will they send it to me? They don't have my address?

490

(45 replies, posted in News)

Yesterday, I posted about the supposed "poison NULL byte vulnerability". I ranted on about how PunBB wasn't vulnerable and how I disliked the way vulnerability databases worked. Guess what? I was wrong! Through the help of a very nice editor at CVE, I was able to get in touch with the researcher behind the report and he clarified the issue for me. I had completely misunderstood what the vulnerability was about. Turns out I was wrong both on the vulnerability and in my generalization of how bad vulnerability databases work. I'm sorry for that.

So, today I have the pleasure of announcing PunBB 1.2.13. A release I've internally dubbed the "I'm a moron" release. PunBB 1.2.13 deals with the NULL byte injection vulnerability and adds support for HttpOnly cookies. The NULL byte injection is only exploitable by administrators so there's no need to rush. Nevertheless, I recommend that everyone upgrade.

Small note: If you have a look at the patch and the hdiff for this release, you'll notice there are what appears as non-existent changes in the unregister_globals() function. Nevermind these. It's just an update to get rid of some Windows style linebreaks.

Over and out.

Indeed it would. It would also involve a lot of cleaning to prevent people from embedding client side scripting into posts.

Moved.

493

(5 replies, posted in Archive)

Ok. It's just that I think there were two competing communities. I wanted to make sure I linked to the better one smile

494

(5 replies, posted in Archive)

It is my intention to keep every discussion here at punbb.org in English. For this reason, I will close the Russian and Swedish speaking forums in a few days.

If anyone can recommend a Russian PunBB community outside punbb.org, I will be glad to link to it as I've done with Spanish, German etc.

495

(0 replies, posted in Archive)

Det är min intention att hålla alla diskussioner här på punbb.org på engelska. Av denna anledning kommer jag snart stänga det svenska och det ryska forumet. Om någon är intresserad av att skapa en svensk PunBB-community får ni gärna göra det. I så fall kan jag länka dit istället.

496

(8 replies, posted in News)

sirena wrote:

In their defence, some of the more reputable security reporting sites do attempt to verify that bugs are real before they pass on any reports.

That is the responsible thing to do - otherwise they contribute to the severe noise pollution problem that security minded IT administrators have to deal with nowadays, as well as un-necessarily damaging the reputation of vendors and coders, and un-necessarily alarming users of the products concerned.

In this case, for example, I notice Secunia.com has not passed on news of this 'punBB vulnerability', presumably because they actually checked to see if the bug was real before registering it in their database.

True. In this case, the CVE is still "Under review". Both mitre.org and nvd.nist.gov have been prompt in their replies to my e-mails and seem focused on getting things right. We'll see how it turns out.

497

(8 replies, posted in News)

Edit: After you've read this, make sure to read my fantastic follow-up big_smile

About two weeks ago, a security advisory titled multiple PHP application poison NULL byte vulnerability popped up on BugTraq. The advisory claimed that various PHP applications, specifically phpBB and PunBB, were vulnerable. Now I can't speak for any other application, but I can assure you that PunBB is NOT. The original author of the report probably thought PunBB was a fork of phpBB and assumed PunBB was vulnerable as well. He sure as hell can't have looked at the source code, that's for sure.

Just for fun, I decided to check out the Wikipedia entry on BugTraq. Here's a quote from that article:

Wikipedia wrote:

Bugtraq was created on November 5, 1993 by Scott Chasin in response to the perceived failings of the existing Internet security infrastructure of the time, particularly CERT. Bugtraq's policy was to publish vulnerabilities, regardless of vendor response, as part of the full disclosure movement of vulnerability disclosure.

Elias Levy, aka Aleph One, noted in an interview that "the environment at that time was such that vendors weren't making any patches. So the focus was on how to fix software that companies weren't fixing."

That's great, but fast-forward 13 years and we end up with this: Anyone can write up a vulnerability report on a piece of software and that information will be assumed to be correct. Not only that, the information will spread like wildfire making it impossible to "repair the damage" in case the information turns out to be false. You see, once something appears on BugTraq, a million other security databases include the report on their websites and on their mailing lists.

Now I'm fine with the "guilty until proven innocent" approach when it comes to security, but come on! Isn't there some kind of review process involved in all of this? I think us "vendors" need to have a say in this before a bogus report ends up on every security website in the world. Sure, we can reply to the BugTraq posting and dispute the report, but that has virtually no impact.

Oh well, I guess I'll go e-mail a bunch of vulnerability databases.

It should work without any problems. My question is why? The only table one could consider converting to innodb is the topics table (because it gets quite a lot of updates).

The real mystery here is how the hell her phpbb installation supported avatar uploads smile

500

(3 replies, posted in PunBB 1.2 troubleshooting)

Is the database still locked or did the issue disappear after some time?