Potential issue with pdf files and git repos

[Thomas De Schampheleire]

On Wed, Jun 13, 2018, 22:29 Thomas De Schampheleire <
patrickdepinguin at gmail.com> wrote:

> 2018-06-13 20:39 GMT+02:00 Matey Chopov <matey.chopov at ca.abb.com>:
> > Hi,
> >
> > It looks like it happens with a specific .pdf manual, I tested it with
> another .pdf file and the exception didn't occur, the file got pushed
> correctly.
> >
> > Here's the line in the trace I think is the most interesting:
> >
> > DatabaseError: (DatabaseError) file is encrypted or is not a database
> u'SELECT ui.ui_id AS ui_ui_id, ui.ui_section AS ui_ui_section, ui.ui_key AS
> ui_ui_key, ui.ui_value AS ui_ui_value, ui.ui_active AS ui_ui_active \nFROM
> ui \nWHERE ui.ui_key = ?' ('push_ssl',)
> > 2018-06-13 11:07:04.946 ERROR [waitress] Exception when servicing
> <waitress.channel.HTTPChannel connected 0.0.0.0:12756 at 0x7f06c5923e90>
> >
> > I have uploaded the surrounding log on pastebin:
> https://pastebin.com/n9fY4xae
> >
> > So the problematic pdf that I though wasn't encrypted, was actually
> encrypted with RC4, the weird thing is that in Git Extensions you can still
> see the file contents in the "diff" section.
> >
> > Apparently, pdf readers automatically decrypt such files if there is no
> password (which is the current case).
> >
> > I used qpdf to decrypt the file (with no password) which gave another
> valid .pdf file with no encryption (at least that's what I get when I
> analyze the file with pdfinfo).
> >
> > Tried pushing that file too, but it still failed.
> >
> > I played with the pdf headers, changed the Creator and Producer values
> to the ones of a .pdf file I know could be uploaded. Same error.
> >
> > I tried converting the file from pdf1.3 to pdf1.4, same issue.
> >
> > So, what finally worked for me was converting from pdf to ps, then to
> text, then from the text file, to ps, and then to pdf. The indexing table
> got screwed, but that doesn't really bother me. Finally, pushed the new pdf
> file to the git repo with success.
> >
> > Commands:
> >
> > pdftops test.pdf test.ps
> > ps2txt test.ps test.txt
> >
> > enscript -B --margins=10:10 -o test.ps -f Courier at 7.3/1 test.txt
> > ps2pdf test.ps test_last.pdf
> >
>
> Your log also shows:
>
> Traceback (most recent call last):
>   File "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/task.py",
> line 74, in handler_thread
>     task.service()
>   File
> "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/channel.py",
> line 368, in service
>     request._close()
>   File
> "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/parser.py",
> line 249, in _close
>     body_rcv.getbuf()._close()
>   File
> "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/buffers.py",
> line 303, in _close
>     buf._close()
>   File
> "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/buffers.py",
> line 110, in _close
>     self.file.close()
> IOError: [Errno 9] Bad file descriptor
>
>
> which reminds me of following two open issues:
>
>
> https://bitbucket.org/conservancy/kallithea/issues/219/waitress-exception-when-serving-file
> https://bitbucket.org/conservancy/kallithea/issues/229/bad-file-descriptor
>
>
>
> Is the PDF on which you see the issue something you could share?
> Or could you create another PDF with dummy data that also exhibits the
> issue?
>
> If at all it would be possible, could you test with the default branch
> of Kallithea, instead of 0.3.5 ?
>

Note that it doesn't make sense to me that the contents of the file would
matter. I think it is more likely about the file size. Could you check the
file sizes of the different files you tested with?

Also, the reporter of issue #219 reported back that his issue was gone when
switching away from waitress to another web server, in his case uwsgi.
Could you try that too ?

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20180613/8f9e922b/attachment-0001.html>