Closed
Bug 91664
Opened 24 years ago
Closed 24 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•24 years ago
|
||
Assignee | ||
Comment 2•24 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•24 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•24 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•24 years ago
|
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: Bugzilla 2.13 → 2.10
Comment 7•24 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•24 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•23 years ago
|
||
*** Bug 185828 has been marked as a duplicate of this bug. ***
Comment 10•22 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•13 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
•