Hi.
working on a m2doc template, I had a stall of the generation process (progress bar said “Template processing”), which effectively blocked Capella to the point that it could not be even restarted. After resolving that, the following happened every time a m2doc generation has been attempted:
!ENTRY org.obeonetwork.m2doc.genconf.editor 4 4 2020-11-26 09:22:06.127
!MESSAGE M2Doc : technical error : An I/O problem occured while creating the output document.
!STACK 0
org.obeonetwork.m2doc.generator.DocumentGenerationException: An I/O problem occured while creating the output document.
at org.obeonetwork.m2doc.util.M2DocUtils.generate(M2DocUtils.java:831)
at org.obeonetwork.m2doc.genconf.GenconfUtils.generate(GenconfUtils.java:505)
at org.obeonetwork.m2doc.genconf.GenconfUtils.generate(GenconfUtils.java:432)
at org.obeonetwork.m2doc.genconf.editor.command.GenerateHandler$GenerateJob.runInWorkspace(GenerateHandler.java:87)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:42)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.io.IOException: Zip bomb detected! The file would exceed the max. ratio of compressed file size to the size of the expanded data.
This may indicate that the file is used to inflate memory usage and thus could pose a security risk.
You can adjust this limit via ZipSecureFile.setMinInflateRatio() if you need to work with files which exceed this limit.
Uncompressed size: 103735, Raw/compressed size: 989, ratio: 0.009534
Limits: MIN_INFLATE_RATIO: 0.010000, Entry: word/document.xml
at org.apache.poi.openxml4j.util.ZipArchiveThresholdInputStream.checkThreshold(ZipArchiveThresholdInputStream.java:131)
at org.apache.poi.openxml4j.util.ZipArchiveThresholdInputStream.read(ZipArchiveThresholdInputStream.java:81)
at org.apache.poi.util.IOUtils.toByteArray(IOUtils.java:152)
at org.apache.poi.util.IOUtils.toByteArray(IOUtils.java:121)
at org.apache.poi.util.IOUtils.toByteArray(IOUtils.java:108)
at org.apache.poi.openxml4j.util.ZipArchiveFakeEntry.(ZipArchiveFakeEntry.java:47)
at org.apache.poi.openxml4j.util.ZipInputStreamZipEntrySource.(ZipInputStreamZipEntrySource.java:53)
at org.apache.poi.openxml4j.opc.ZipPackage.(ZipPackage.java:106)
at org.apache.poi.openxml4j.opc.OPCPackage.open(OPCPackage.java:301)
at org.obeonetwork.m2doc.generator.UserContentManager.generateLostFiles(UserContentManager.java:315)
at org.obeonetwork.m2doc.util.M2DocUtils.generate(M2DocUtils.java:813)
… 5 more
The workaround is to delete the .generated.docx-Preserved area 1-lost.docx file before starting the generation. This file is created even if the template does not contain any
{m:userdoc AQL expression} …user block… {m:enduserdoc}
(If a user content exists in a previously generated document and the id is not re-generated, the user content will by removed from the generated document and saved in a «lost» file)
So this seems to be a bug sporadically effectively disabling m2doc generation. The suspected security thread is actually in the context of m2doc irrelevant, thus the min deflation ratio could and should be set to a value that prevents this ever to happen.
Is this issue corrected in the newest or pending version of m2doc? Is it known when this version will be released?
br, M.