Bug 143472 - FILEOPEN: pdf fails to open in draw (because sdext.pdfimport does not accept encryption algorithm version > 3 and revision > 3)
Summary: FILEOPEN: pdf fails to open in draw (because sdext.pdfimport does not accept ...
Status: RESOLVED DUPLICATE of bug 55425
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
7.1.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: PDF-Import-Draw
  Show dependency treegraph
 
Reported: 2021-07-21 12:42 UTC by johnks
Modified: 2022-07-06 12:19 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
class notes (317.92 KB, application/pdf)
2021-07-21 12:42 UTC, johnks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description johnks 2021-07-21 12:42:17 UTC
Description:
i was sent a pdf that someone tried to open in libreoffice draw and failed to. the pdf opens cleanly in evnice or okular so the problem is in libreoffice.
while opening it says, "version incompatibility. incorrect file version." then second dialog box that says "general error. general input/output error" and draw closes. i tried to use safe mode but same thing
FILEOPEN

Steps to Reproduce:
1. open file in okular or evince or any pdf reader
2. open file in draw
3.

Actual Results:
draw crashes always

Expected Results:
pdf should open in draw


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 7.1.4.2 / LibreOffice Community
Build ID: a529a4fab45b75fefc5b6226684193eb000654f6
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-IN (en_IN); UI: en-US
Flatpak
Calc: threaded
Comment 1 johnks 2021-07-21 12:42:51 UTC
Created attachment 173735 [details]
class notes
Comment 2 V Stuart Foote 2021-07-21 15:29:08 UTC
Confirmed on Version: 7.2.0.1 (x64) / LibreOffice Community
Build ID: 32efc3b7f3a71cfa6a7fa3f6c208333df48656cc
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

Get the indicated error:

'Version Incompatibility. Incorrect file version'

And, when opened in Adobe Acrobat, PDF properties show:

PDF producer: OpenOffice.org3.1
PDF Version: 1.6(Acrobat 7.x)

Which of course is bogus, and kind of makes makes this NOTOURBUG (would need more detail about the producer of the PDF to take it further).

Otherwise the pdfium based Insert -> Image filter works just fine, a page at a time. Perhaps split the PDF and just use that.
Comment 3 johnks 2021-07-21 17:49:41 UTC
(In reply to V Stuart Foote from comment #2)
> Confirmed on Version: 7.2.0.1 (x64) / LibreOffice Community
> Build ID: 32efc3b7f3a71cfa6a7fa3f6c208333df48656cc
> CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL:
> win
> Locale: en-US (en_US); UI: en-US
> Calc: CL
> 
> Get the indicated error:
> 
> 'Version Incompatibility. Incorrect file version'
> 
> And, when opened in Adobe Acrobat, PDF properties show:
> 
> PDF producer: OpenOffice.org3.1
> PDF Version: 1.6(Acrobat 7.x)
> 
> Which of course is bogus, and kind of makes makes this NOTOURBUG (would need
> more detail about the producer of the PDF to take it further).
> 
> Otherwise the pdfium based Insert -> Image filter works just fine, a page at
> a time. Perhaps split the PDF and just use that.

i don't mind that. i tried a few online pdf manipulators and the file worked fine there. i used smallpdf.com to "compress" the file and downloaded with "basic" setting they show on the website. that compressed pdf file worked just fine in draw so if this file can open on smallpdf.com or in a regular pdf reader, isn't it a problem of draw that isnt opening it? i am saying this pdf should open in draw and currently it isnt because of something in draw itself. how is it NOTOURBUG?
Comment 4 johnks 2021-07-21 18:04:00 UTC
(In reply to V Stuart Foote from comment #2)
> Confirmed on Version: 7.2.0.1 (x64) / LibreOffice Community
> Build ID: 32efc3b7f3a71cfa6a7fa3f6c208333df48656cc
> CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL:
> win
> Locale: en-US (en_US); UI: en-US
> Calc: CL
> 
> Get the indicated error:
> 
> 'Version Incompatibility. Incorrect file version'
> 
> And, when opened in Adobe Acrobat, PDF properties show:
> 
> PDF producer: OpenOffice.org3.1
> PDF Version: 1.6(Acrobat 7.x)
> 
> Which of course is bogus, and kind of makes makes this NOTOURBUG (would need
> more detail about the producer of the PDF to take it further).
> 
> Otherwise the pdfium based Insert -> Image filter works just fine, a page at
> a time. Perhaps split the PDF and just use that.



you probably would be surprised to know i got this from a friend who found this in his backup somewhere. this file really is old like his records indicate he got the file back in 2015 which was old even at the time so openoffice  must have been used to make this file. same for the other few bugs i have raised today. all came from the backup of these old files
Comment 5 David P. 2021-10-16 01:48:51 UTC
I can confirm this issue with the latest Arch Linux compilations of LO (libreoffice-fresh and libreoffice-still affected). Opening PDF files with Draw fails with a general input/output error.
Comment 6 himajin100000 2021-10-16 17:46:14 UTC
504 0 obj
<<
/Filter /Standard
/V 4
/R 4
/Length 128
/StrF /StdCF
/StmF /StdCF
/CF <<
/StdCF <<
/AuthEvent /DocOpen
/Length 16
/CFM /AESV2
>>
>>

(snip)

<<
/Size 505
/Root 199 0 R
/Info 200 0 R
/ID [ <CF45F72AB728764BB00FDAC0DE12B30F> <CF45F72AB728764BB00FDAC0DE12B30F> ]
/DocChecksum /F5A9B059D948568B44B739E345CFE935
/Encrypt 504 0 R
>>

https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/pdfparse/pdfentries.cxx?r=776a1b9b#1311

https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/pdfparse/pdfentries.cxx?r=776a1b9b#1212

I'm not so familiar with PDF stuffs, and I don't know whether LibreOffice is doing things correctly.
Comment 7 Kevin Suo 2021-10-27 07:26:59 UTC
sdext/source/pdfimport/wrapper/wrapper.cxx:1023: xpdf_ImportFromFile(...) calls 
sdext/source/pdfimport/wrapper/wrapper.cxx:894 checkEncryption(...)

which further checks encryption in line 913:
if( pPDFFile->usesSupportedEncryptionFormat() )
and fails.

PDFFile::usesSupportedEncryptionFormat() is in:

https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/pdfparse/pdfentries.cxx?r=776a1b9b#1212

bool PDFFile::usesSupportedEncryptionFormat() const
{
    return m_pData->m_bStandardHandler &&
        m_pData->m_nAlgoVersion >= 1 &&
        m_pData->m_nAlgoVersion <= 2 &&
        m_pData->m_nStandardRevision >= 2 &&
        m_pData->m_nStandardRevision <= 3;
}

For this PDF document:

(gdb) p m_pData->m_bStandardHandler
$5 = true
(gdb) p m_pData->m_nAlgoVersion
$6 = 4
(gdb) p m_pData->m_nStandardRevision
$7 = 4

So m_nAlgoVersion is not <=2 and m_nStandardRevision is not <= 3, thus does not "usesSupportedEncryptionFormat".

m_pData is of struct type PDFFileImplData in https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/pdfparse/pdfentries.cxx?r=776a1b9b#1015

It's m_nAlgoVersion, m_nStandardRevsion etc are set in PDFFileImplData* PDFFile::impl_getData() in https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/pdfparse/pdfentries.cxx?r=776a1b9b#1015.

Based on comment 6 the version numbers m_nAlgoVersion (4) and m_nStandardRevision(4) seems correct. So the problem would be the newer (?) decyption algorithm are "not supported" (?) by our sdext.pdfimport. 

However, a quick search in poppler (i.e. the upstream lib used by libreoffice to parse the pdf into xpdfimport tokens and then further assembled into an ODF draw document), it already added support for "version 5 + revision 6 documents" in year 2016:
https://cgit.freedesktop.org/poppler/poppler/commit/?id=69ffeb71a79b686d5c79d20832c4666c498098e8

So it seems the code in sdext/source/pdfimport/pdfparse/pdfentries.cxx need to be updated. Actually I see in line 1345 that it seems to accept m_nAlgoVersion >= 3:
if( m_pData->m_nAlgoVersion >= 3 )

Actually the version limitation there has not been touched since the very beginning in year 2008:
https://cgit.freedesktop.org/libreoffice/core/commit/sdext/source/pdfimport/pdfparse/pdfentries.cxx?id=a00669b8cb4843acaea59dedc68a4dac8e016fc7

======
Poppler `pdfinfo` output of this file:
======
Author:          Studynama.com
Creator:         Writer
Producer:        OpenOffice.org 3.1
CreationDate:    Wed Aug 17 21:23:43 2011 CST
ModDate:         Tue Sep 29 08:11:35 2015 CST
Custom Metadata: no
Metadata Stream: no
Tagged:          no
UserProperties:  no
Suspects:        no
Form:            none
JavaScript:      no
Pages:           60
Encrypted:       yes (print:yes copy:yes change:no addNotes:no algorithm:AES)
Page size:       612 x 792 pts (letter)
Page rot:        0
File size:       325547 bytes
Optimized:       no
PDF version:     1.6
Comment 8 Kevin Suo 2021-10-27 07:27:47 UTC
And I suspect the other bugs related to draw not opening encrypted PDF file may be the same cause.
Comment 9 Kevin Suo 2021-11-22 11:24:13 UTC
back to new as the patch was abandoned due to license issue.
Comment 10 Timur 2022-07-06 12:19:02 UTC

*** This bug has been marked as a duplicate of bug 55425 ***