Closed
Bug 91664
Opened 23 years ago
Closed 23 years ago
Bugzilla does not enforce a maximum patch/attachment size.
Categories
(Bugzilla :: Attachments & Requests, defect, P1)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.16
People
(Reporter: myk, Assigned: myk)
References
Details
Attachments
(1 file)
5.78 KB,
patch
|
Details | Diff | Splinter Review |
Bugzilla does not enforce a maximum patch/attachment size, even though it stores attachments in a LONGBLOB column with a theoretical limit of (2^32 - 1) characters, a practical limit of 16MB based on the maximum value of mysqld's max_allowed_packet, and an actual limit equivalent to the value of that variable. More significantly, the lack of any size enforcement leads to reckless and wanton uses of space, for example the posting of unnecessary and/or non-compressed attachments (like highest-quality JPEG screen-shots). Bugzilla should enforce a maximum patch/attachment size.
Assignee | ||
Comment 1•23 years ago
|
||
Assignee | ||
Comment 2•23 years ago
|
||
This patch fixes the bug by defining two parameters: maxpatchsize and maxattachmentsize, that installations can configure to restrict the size of patches and non-patch attachments, respectively. The parameters are set to 1048576 bytes (1 megabyte) by default. If set to zero, Bugzilla will not impose a size restriction on patches/attachments (but one will be imposed by other server software, f.e. mysql). Otherwise Bugzilla will warn users on the "Create Attachment" page about the size restrictions and will display an error if they try to upload patches/attachments whose sizes exceed the limits. The patch does some incidental clean-up of Perl and HTML code formatting.
Comment 3•23 years ago
|
||
I'll call this a P1 because apparently moz.org had some problems without this. It's not a 2.14 blocker but Dave says if the patch is ready it will go in.
Priority: -- → P1
Target Milestone: --- → Bugzilla 2.16
Assignee | ||
Comment 4•23 years ago
|
||
From MattyT via email: Desirable fixes in the area: <ssdbot> MattyT: Bug http://bugzilla.mozilla.org/show_bug.cgi?id=87770 tri, --, All, tara@tequilarista.org, NEW, createattachment should work with no parameters. <ssdbot> MattyT: Bug http://bugzilla.mozilla.org/show_bug.cgi?id=87420 tri, --, All, tara@tequilarista.org, NEW, Pressing back on "create attachment". Apparent duplicate: <ssdbot> MattyT: Bug http://bugzilla.mozilla.org/show_bug.cgi?id=59390 nor, P3, All, tara@tequilarista.org, NEW, Abort large (>1MB) attachments before uploading and with a r This bug has a comment suggesting size detection before upload is possible.
Updated•23 years ago
|
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: Bugzilla 2.13 → 2.10
Comment 7•23 years ago
|
||
The only reason to have two params is if either: a) you'd want the max patch size to be smaller than the max attachment size (Why on earth?) or, b) you'd want the max attachment size to be smaller than the max patch size. Would you ever have an installation where the max. attachment size was so small that patches exceeded it? I've never seen a patch bigger than 500k. And they can always be split in two. I'd say one param is fine. I think this patch has rotted because of templatisation. Myk - any interest in reviving it? Gerv
Assignee | ||
Comment 8•23 years ago
|
||
>I've never seen a patch bigger than 500k. I have. Hyatt posted a 900k patch once, and others have also been posted. The reason for two settings is, as you mentioned, to allow for bigger patches. The fix for this went in as part of bug 98602, so resolving fixed. File bug called "remove maxpatchsize parameter" if you think this is wrong.
Component: Creating/Changing Bugs → attachment and request management
Comment 9•22 years ago
|
||
*** Bug 185828 has been marked as a duplicate of this bug. ***
Comment 10•21 years ago
|
||
I'm seeing this on a 2.17.6-based installation: [Mon Dec 29 10:01:36 2003] [error] [client 192.168.10.200] malformed header from script. Bad header=<F1><E2><EF><F1><E2><EF><F1><E2><EF><F1><E2><EF><F1><E2><EF><F1> <E2><EF><F1><E2><EF><F1><E2><EF><F1><E2><EF><F1><E2><EF>: /var/www/bugzilla-tip/attachment.cgi [Mon Dec 29 10:01:36 2003] attachment.cgi: DBD::mysql::st execute failed: MySQL server has gone away [for Statement "INSERT INTO attachments (bug_id, creation_ts, filename, description, mimetype, ispatch, isprivate, submitter_id, thedata) [Mon Dec 29 10:01:36 2003] attachment.cgi: VALUES (585, now(), 'Gia 0730 DOS.doc', 'Orienta<E7><F5>es para altera<E7><E3>o do Lay Out Gia 0730', 'application/msword', 0, 0, 4, '<D0><CF>^Q<E0><A1><B1>\Z<E1>\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0> I had maxattachsize set to 50MB, but I hadn't changed the max_packet_size variable in my.cnf. Is this something I "should have known"? Shouldn't this be mentioned next to the maxattachsize description in the params page at least?
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•