Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Arantor
4591
Archived fixes / Re: Fixed SMF bugs
« on March 3rd, 2012, 11:57 AM »
Quote
Still, I just have a question... Why the hell does this option show up in an admin area that has *nothing* to do with attachments...?!
It should be moved!
What setting, exactly, are you changing?
Quote
Honestly, in this situation you know better than I do. I'm just saying we need to log this into the error log. In case it's not possible to log into the error log but not into the online log, then a new param should be added to specify that the online log should be skipped.
It's weird.

The code that logs a 404 is in QueryString.php, beginning with:
Code: [Select]
// Don't bother going further if we've come here from a *REAL* 404.

But yet it displays the standard content, indicating to me it isn't triggering. But all you should have to do is add a define of WEDGE_NO_LOG there.
4592
Archived fixes / Re: Fixed SMF bugs
« on March 2nd, 2012, 11:17 PM »
Yup, the r number indicate what revision in Wedge where the fix gets committed.
4593
Bug reports / Re: SMF bug 4954 (poll options can get mixed up when > 127 options)
« on March 2nd, 2012, 11:17 PM »
You wouldn't normally, but if you keep editing a poll, it might have 255+ different options in its life.
4594
Bug reports / Re: SMF bug 4953 (PS adds 'cellTextIsHtml' to JPGs causing them to fail checks)
« on March 2nd, 2012, 08:56 PM »
I have a feeling it already is, not sure, but I don't think that's enough.
4595
Bug reports / Re: SMF bug 4953 (PS adds 'cellTextIsHtml' to JPGs causing them to fail checks)
« on March 2nd, 2012, 06:50 PM »
Neither, directly, does SMF have the same vulnerability (because it isn't strictly a vulnerability), provided the same thing that SMF does (blocking PHP execution via htaccess for the entire media folders) is done.

But that's not to say that browsers don't have vulnerabilities to bad images, it has been known. How far do we go to protect users?
4596
Archived fixes / Re: Fixed SMF bugs
« on March 2nd, 2012, 06:46 PM »
Quote
But the thumbnail settings in Wedge.org are 1280x1024. Where does the 640 value come from, then..?
Maximum uploaded image size.
Quote
logging 404's and not logging them for checkSession use.
How do we know to log it? If we know to log it, we know to define WEDGE_NO_LOG so that it won't be logged in the online log.
4597
Archived fixes / Re: SMF bug 4763 - menu hook doesn't work properly when caching level >= 2
« on March 2nd, 2012, 06:39 PM »
That sort of defeats the point of caching, because other than Aeva's unread count (which is per user as opposed to the caching which is groups+language), it's all permissions tests which are pretty cheap and there are better places to worry about caching.
4598
Bug reports / Re: SMF bug 4953 (PS adds 'cellTextIsHtml' to JPGs causing them to fail checks)
« on March 2nd, 2012, 06:12 PM »
Ah, but we should - more than SMF does, in fact.

If there is any chance of a file being served to the user that we did not have a hand in (like attachments), we need to be confident that the file isn't malicious. And it's not enough to validate the image with getimagesize() because it's possible to hide even shell scripts inside legitimate images...
4599
Archived fixes / Re: Fixed SMF bugs
« on March 2nd, 2012, 06:07 PM »
Quote
It's not full size here, it's at 640x480... Which is precisely the setting I'd like to modify. Having to use the media gallery when you just want to post a quick attachment isn't so cool.
Nope. http://wedge.org/pub/plugins/7122/a-project-i-started-a-while-back/ disagrees with you: the original image was larger than 640 wide, so it was rescaled to cap at 640px, but there's no thumbnail for it - that image shown under the post is 640x501, and downloading it also gives you a 640x501 image.
Quote
I don't think so?
Well, I know that Weaving reports 3 missing images on the page for me, which fouls it up.
Quote
Well, they need to be if you want the admin to be able to fix the 404 in the first place...?
I have no issue with the htaccess pushing 404s to index.php, but they must not be logged in writeLog(), because that pushes it into the online log, which is where the referrer is tracked as far as checkSession('post', 'admin') is concerned (which is what's causing the problem)
4600
Bug reports / SMF bug 4953 (PS adds 'cellTextIsHtml' to JPGs causing them to fail checks)
« on March 2nd, 2012, 02:21 PM »
There are a surprising number of ways to get false positives in images, and I'm not sure how useful the current code is in stopping threats.
Posted: March 2nd, 2012, 10:55 AM

I remember discussing this issue with several people at SMF when this originally blew up way back.

The problem that isn't really being solved here is that you have legitimate images (and other files) being uploaded and checked for common things that could be malicious - but not nearly all of the things that could be, and unfortunately blocking others in the process like this one. The problem is that you can't realistically blacklist certain constructions and then provide exceptions, unless you're making very specific exceptions - and even then it's not reliable.

What might be better to do is to do separate types of validation based on the file type (assuming it's an image that you're trying to validate) and attempt to make sense of the file itself, e.g. if it's a GIF, step through and validate the image contents vs its headers and if there's any extra content, dump it. (Being sure to validate for animated images, of course)

It doesn't help that GIF, PNG and JPEG all legitimately allow for extra non-image information to be embedded in less than pleasant ways.
4601
Bug reports / Re: SMF bug 4954 (poll options can get mixed up when > 127 options)
« on March 2nd, 2012, 02:11 PM »
Well, you have another method that you can use - examine $_POST['options'] when it comes in. Pull the array_keys and iterate over them, looking for any values > 255, which can be relied upon to be accurate, as it were.
4602
Archived fixes / SMF bug 4880 (admin search members by date doesn't pass date through properly)
« on March 2nd, 2012, 01:59 PM »
The date parameter is not passed between pages properly, causing page 2+ not to filter by date.
Posted: March 2nd, 2012, 10:56 AM

I can reproduce this on SMF but I apparently can't reproduce this on Wedge even though the code hasn't apparently changed.
Posted: March 2nd, 2012, 01:26 PM

Eh, no, I can reproduce it. Just didn't see what I expected to see to start with. >_<
Posted: March 2nd, 2012, 01:32 PM

Fixed in r1419.
4603
Features / Re: New revs
« on March 2nd, 2012, 01:59 PM »
(1 file, 1KB)

Revision: 1419
Author: arantor
Date: 02 March 2012 12:58:33
Message:
! SMF bug 4880 (admin search members doesn't paginate because dates are passed in a different format to received; adjusted so that both int and date format will be accepted and processed) (ManageMembers.php)
----
Modified : /trunk/Sources/ManageMembers.php
4604
Bug reports / Re: SMF bug 4954 (poll options can get mixed up when > 127 options)
« on March 2nd, 2012, 01:49 PM »
Ah, that makes perfect sense, thanks :)

I note the commit note mentions fixing it for > 255, is the column a smallint in SMF 2.1, or is a suitable error thrown at the user? (A poll with 255 options, or lots and lots of editing, is probably going to be messy and probably should be recreated from scratch.)
4605
Archived fixes / Re: Fixed SMF bugs
« on March 2nd, 2012, 01:48 PM »
Quote
I thought thumbnails were what Wedge would show below posts -- i.e. what is capped to 640x480 on Wedge.org right now. I thought there was nothing else..?
They are - to a point. If the image size is smaller than the thumbnail size, it will display the image unresized. Now, if no thumbnail size is set, it will just show the image full size... (that's what's happening here)
Quote
Generally speaking, SMF never asked an admin to set a value of -1 to disable something or whatever -- always zero.
Makes sense, I guess...
Quote
"Unable to verify referring url. Please go back and try again."

Always says that...
Lemme guess, there's a broken image somewhere on the page? (I've noticed this before: where even 404s are pushed to Wedge for handling, it screws up the referer, 404s need to not be logged in writeLog())