> On Oct 25, 2018, at 10:11 AM, Sam Ruby <[email protected]> wrote: > > Short summary: > > It looks like a security fix for ImageMagick broke us, and the suggested > workaround is to re-enable PDF conversions in the configuration file. This > will affect any drag/drop of non-PDF types.
Looks like it affects anything to do with non-pdf files. I cannot do anything at all with non-pdf types. Drag/drop doesn't work. Pdf-ize doesn't work. > > Longer version: > > From /var/log/apache2/error.log: > >> App 25289 stderr: convert: not authorized >> `/tmp/ICLA_YuriGor_2.png20181025-30073-dc4pz.pdf' @ >> error/constitute.c/WriteImage/1028. >> App 25289 stderr: convert: not authorized >> `/tmp/ICLA_YuriGor_1.png20181025-30073-7ert84.pdf' @ >> error/constitute.c/WriteImage/1028. > > Google search turns up: > > https://stackoverflow.com/questions/42928765/convertnot-authorized-aaaa-error-constitute-c-readimage-453 > > This, in turn points to CVE-2016-3714. > > A number of people have suggested as a "fix" to change: > >> policy domain="coder" rights="none" pattern="PDF" > > to > >> policy domain="coder" rights="read|write" pattern="PDF" > > I don't know what the downside of making this change would be. This seems to affect the ability of ImageMagick to write pdf files. I understand that there are security implications for some systems but reading the stackoverflow article I don't think they apply. Can we try to enable read|write of pdf files and see if that helps? Craig > > - Sam Ruby > > > > On 10/25/2018 11:29 AM, Craig Russell wrote: >> Hi Sebb, >>> On Oct 24, 2018, at 9:26 AM, sebb <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On Wed, 24 Oct 2018 at 13:01, Craig Russell <[email protected] >>> <mailto:[email protected]>> wrote: >>>> >>>> tldr; drag/drop of .png files and .gif files does not corrupt the files >>>> but doesn't work either; pdfize .png files and .gif files does not corrupt >>>> but doesn't work either. >>> >>> png and gif both work for me. >> What does this mean? Can you process the png versions of the pending ICLA >> from 10/24/2018, 4:46:44 AM >> <https://whimsy.apache.org/secretary/workbench/201810/86a077e57e/> in the >> Secretary workbench? >> This still fails for me. I am stuck trying to get this ICLA processed. >>>> Should I ask for .jpg files? Anything else to try? >>> >>> We should try updating to latest version of ImageMagick. >> I assume that ImageMagick is done at the whimsy host site not locally, so >> there is nothing I can do here. >> Craig >>> >>>> Details: I forwarded the original large .png files message and tried to >>>> directly drag/drop 2 onto 1: >>>> This resulted in the same error Exception: #<RuntimeError: Failed to >>>> concatenate ICLA-YuriGor-2.png and ICLA-YuriGor-1.png> >>>> The headers now are: >>>> >>>> :attachments: >>>> - :name: ICLA-YuriGor-2.png >>>> :length: 478565 >>>> :mime: image/png >>>> Content-Type: image/png; name=ICLA-YuriGor-2.png >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-2.png >>>> Content-ID: "<f_jn5ogdb41>" >>>> - :name: ICLA-YuriGor-1.png >>>> :length: 464289 >>>> :mime: image/png >>>> Content-Type: image/png; name=ICLA-YuriGor-1.png >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-1.png >>>> Content-ID: "<f_jn5ogdau0>" >>>> :source: '201810' >>>> >>>> Pdf-izing 1.png which still looks fine: >>>> Exception: #<RuntimeError: Failed to pdf-ize ICLA-YuriGor-1.png in >>>> /secretary/workbench/201810/86a077e57e/> >>>> Headers are now: >>>> >>>> :attachments: >>>> - :name: ICLA-YuriGor-2.png >>>> :length: 478565 >>>> :mime: image/png >>>> Content-Type: image/png; name=ICLA-YuriGor-2.png >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-2.png >>>> Content-ID: "<f_jn5ogdb41>" >>>> - :name: ICLA-YuriGor-1.png >>>> :length: 464289 >>>> :mime: image/png >>>> Content-Type: image/png; name=ICLA-YuriGor-1.png >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-1.png >>>> Content-ID: "<f_jn5ogdau0>" >>>> :source: '201810' >>>> >>>> >>>> Now trying with the .gif versions: >>>> >>>> :attachments: >>>> - :name: ICLA-YuriGor-1.gif >>>> :length: 48572 >>>> :mime: image/gif >>>> Content-Type: image/gif; name=ICLA-YuriGor-1.gif >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-1.gif >>>> Content-ID: "<f_jnlykun50>" >>>> - :name: ICLA-YuriGor-2.gif >>>> :length: 53557 >>>> :mime: image/gif >>>> Content-Type: image/gif; name=ICLA-YuriGor-2.gif >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-2.gif >>>> Content-ID: "<f_jnlykun91>" >>>> :source: '201810' >>>> >>>> Directly drag/drop 2.gif onto 1.gif fails: Exception: #<RuntimeError: >>>> Failed to concatenate ICLA-YuriGor-1.gif and ICLA-YuriGor-2.gif> >>>> >>>> Pdfize 1.gif: Exception: #<RuntimeError: Failed to pdf-ize >>>> ICLA-YuriGor-1.gif in /secretary/workbench/201810/4f1be03a74/> >>>> Headers: unchanged. >>>> >>>> On Oct 24, 2018, at 2:50 AM, sebb <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> On Wed, 24 Oct 2018 at 09:53, sebb <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> On Wed, 24 Oct 2018 at 03:14, Sam Ruby <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> Trace can be obtained by looking at the javascript console in your browser. >>>> >>>> >>>> Also worth checking the server logs under: >>>> https://whimsy.apache.org/members/log/ >>>> >>>> Generally errors are posted to: >>>> error.log >>>> However it's now gzipped as: >>>> error.log-20181024.gz >>>> >>>> Look for YuriGor, you should find the following errors: >>>> >>>> App 26457 stderr: convert: not authorized >>>> `/tmp/ICLA_YuriGor_2.gif20181024-26883-12lhmlg.pdf' @ >>>> error/constitute.c/WriteImage/1028 >>>> App 26457 stderr: convert: not authorized >>>> `/tmp/ICLA_YuriGor_1.gif20181024-26883-qv55ls.pdf' @ >>>> error/constitute.c/WriteImage/1028 >>>> >>>> I think this means ImageMagick is not set up to convert .gif files. >>>> But I don't know how to fix this. >>>> >>>> I think I know what causes pdf-ise to corrupt the YAML. >>>> >>>> >>>> I should now have fixed the corruption on conversion failure. >>>> >>>> I cannot reproduce the conversion error; that may be because my >>>> version of ImageMagick is >>>> >>>> Version: ImageMagick 7.0.8-12 Q16 x86_64 2018-10-19 https://imagemagick.org >>>> >>>> whereas Whimsy has: >>>> >>>> Version: ImageMagick 6.8.9-9 Q16 x86_64 2018-09-28 >>>> http://www.imagemagick.org >>>> >>>> >>>> >>>> >>>> I've reproduced this locally, and sebb is right that the content >>>> length is zero (for both the source and target). Given that you >>>> (Craig) reforwarded the messages, it doesn't appear to be that a >>>> reparse would fix things. Looking at the raw content (from the >>>> workbench) there is data. >>>> >>>> I'll try to debug more in the morning. >>>> >>>> - Sam Ruby >>>> On Tue, Oct 23, 2018 at 8:49 PM Craig Russell <[email protected]> wrote: >>>> >>>> >>>> I've forwarded the original message (the big .png attachments), and the >>>> headers show: >>>> >>>> :attachments: >>>> - :name: ICLA-YuriGor-2.png >>>> :length: 478565 >>>> :mime: image/png >>>> Content-Type: image/png; name=ICLA-YuriGor-2.png >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-2.png >>>> Content-ID: "<f_jn5ogdb41>" >>>> - :name: ICLA-YuriGor-1.png >>>> :length: 464289 >>>> :mime: image/png >>>> Content-Type: image/png; name=ICLA-YuriGor-1.png >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-1.png >>>> Content-ID: "<f_jn5ogdau0>" >>>> :source: '201810' >>>> >>>> This fails to drag/drop, not sure exactly where since there is no trace: >>>> Exception: #<RuntimeError: Failed to concatenate ICLA-YuriGor-2.png and >>>> ICLA-YuriGor-1.png> >>>> >>>> The headers are now the same. >>>> >>>> When I select the second .png and pdf-ize it: >>>> >>>> :attachments: >>>> - :name: ICLA-YuriGor-2.pdf >>>> :length: 478565 >>>> :mime: application/pdf >>>> Content-Type: image/png; name=ICLA-YuriGor-2.png >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-2.png >>>> Content-ID: "<f_jn5ogdb41>" >>>> :content: '' >>>> - :name: ICLA-YuriGor-1.png >>>> :length: 464289 >>>> :mime: image/png >>>> Content-Type: image/png; name=ICLA-YuriGor-1.png >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-1.png >>>> Content-ID: "<f_jn5ogdau0>" >>>> :source: '201810' >>>> >>>> So it appears that the content is being corrupted during the pdf-izing of >>>> the png. >>>> >>>> Now, I try the smaller .gif version: >>>> >>>> :attachments: >>>> - :name: ICLA-YuriGor-1.gif >>>> :length: 48572 >>>> :mime: image/gif >>>> Content-Type: image/gif; name=ICLA-YuriGor-1.gif >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-1.gif >>>> Content-ID: "<f_jnlykun50>" >>>> - :name: ICLA-YuriGor-2.gif >>>> :length: 53557 >>>> :mime: image/gif >>>> Content-Type: image/gif; name=ICLA-YuriGor-2.gif >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-2.gif >>>> Content-ID: "<f_jnlykun91>" >>>> :source: '201810' >>>> >>>> drag/drop: Exception: #<RuntimeError: Failed to concatenate >>>> ICLA-YuriGor-1.gif and ICLA-YuriGor-2.gif> >>>> headers now are still the same. >>>> try to pdf-ize the first gif works, with headers now: >>>> >>>> :attachments: >>>> - :name: ICLA-YuriGor-1.pdf >>>> :length: 48572 >>>> :mime: application/pdf >>>> Content-Type: image/gif; name=ICLA-YuriGor-1.gif >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-1.gif >>>> Content-ID: "<f_jnlykun50>" >>>> :content: '' >>>> - :name: ICLA-YuriGor-2.gif >>>> :length: 53557 >>>> :mime: image/gif >>>> Content-Type: image/gif; name=ICLA-YuriGor-2.gif >>>> Content-Transfer-Encoding: base64 >>>> Content-Disposition: inline; filename=ICLA-YuriGor-2.gif >>>> Content-ID: "<f_jnlykun91>" >>>> :source: '201810' >>>> >>>> Does this make any sense? >>>> >>>> Craig >>>> >>>> On Oct 23, 2018, at 3:33 PM, sebb <[email protected]> wrote: >>>> >>>> I think the problem is that the YAML summary was previously corrupted >>>> by a failed conversion. >>>> I just checked and the :content: value is the empty string - use the >>>> headers link to see the current YAML contents for the message. >>>> >>>> Someone with sufficient karma needs to reparse the original message to >>>> reset the YAML entry; can then try again. >>>> >>>> Note: I have fixed some of the conversions (e.g. burst, rotate) so >>>> that a failed operation does not update the YAML summary, so this is >>>> less likely to happen again. >>>> On Tue, 23 Oct 2018 at 23:14, Craig Russell <[email protected]> wrote: >>>> >>>> >>>> At least the new error message works now. >>>> >>>> I'm trying to drag/drop a .jpg to another .jpg. Failed with Exception: >>>> #<RuntimeError: Failed to concatenate ICLA-YuriGor-1.jpg and >>>> ICLA-YuriGor-2.jpg> >>>> >>>> So I tried to pdf-size the two and that worked, but drag/drop of the .pdf >>>> files also failed: Exception: #<RuntimeError: Failed to concatenate >>>> ICLA-YuriGor-1.pdf and ICLA-YuriGor-2.pdf> >>>> >>>> So I think drag/drop is completely broken. >>>> >>>> Craig L Russell >>>> Secretary, Apache Software Foundation >>>> [email protected] http://db.apache.org/jdo >>>> >>>> >>>> Craig L Russell >>>> Secretary, Apache Software Foundation >>>> [email protected] http://db.apache.org/jdo >>>> >>>> >>>> Craig L Russell >>>> Secretary, Apache Software Foundation >>>> [email protected] http://db.apache.org/jdo >>>> >> Craig L Russell >> Secretary, Apache Software Foundation >> [email protected] <mailto:[email protected]> http://db.apache.org/jdo Craig L Russell Secretary, Apache Software Foundation [email protected] <mailto:[email protected]> http://db.apache.org/jdo <http://db.apache.org/jdo>
