Potential issue with pdf files and git repos

[Thomas De Schampheleire]

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 ?

Thanks,
Thomas