D16498: [KFileMetaData] Add extractor for DSC conforming (Encapsulated) Postscript

[Stefan Brüns]

bruns added a comment.


  In D16498#350460 <https://phabricator.kde.org/D16498#350460>, @pino wrote:
  
  > In D16498#350426 <https://phabricator.kde.org/D16498#350426>, @bruns wrote:
  >
  > > In D16498#350422 <https://phabricator.kde.org/D16498#350422>, @pino wrote:
  > >
  > > > In D16498#350289 <https://phabricator.kde.org/D16498#350289>, @bruns wrote:
  > > >
  > > > > In D16498#350286 <https://phabricator.kde.org/D16498#350286>, @pino wrote:
  > > > >
  > > > > > Ugh no manual parsing of PS files -- please use libspectre.
  > > > >
  > > > >
  > > > > This is not Postscript parsing, but DSC parsing - read the specification to understand the difference!
  > > > >
  > > > > http://www.lprng.com/RESOURCES/ADOBE/5001.DSC_Spec.pdf
  > > >
  > > >
  > > > An EPS file //is// also a PostScript file, and indeed ghostscript opens it perfectly
  > >
  > >
  > >
  > >
  > > - also **
  >
  >
  > Sure: that is a reason more to handle it like that.
  >
  > >> Because of the above, libspectre perfectly handles EPS files, and the API already provides all the information that the current DscExtractor provides as well.
  > > 
  > > Its an additional dependency (libpectre and libgs),
  >
  >
  >
  > - libspectre is a C library, and uses only libgs
  > - the rest of the ghostscript dependencies are already used in one way or another in an average KDE installation
  > - okular & cantor already use libspectre for a very long time (okular a decade)
  
  
  It //may// be an option to use libspectre as basis for an additional extractor, but this should not be the default, see below.
  
  This is meant to be as simple as possible - the extractor itself is hardly more than 30 lines of code. There is definitely a use case for this extractor.
  
  >> and also imposes a security risk - see e.g. https://nvd.nist.gov/vuln/detail/CVE-2018-11645
  > 
  > There are way worse CVEs in lower components of a modern Linux stack (say in the Linux kernel).
  >  Also, according to that, should we drop the support in okular for PostScript files, and the support in cantor for EPS images?
  
  There is a difference between opening a file consciously and letting it happen by chance. The extractor is run when a file is hovered by the mouse cursor or by baloo. It will be executed without the user being aware of it.
  
  IMHO the ghostscript support should be disabled (runtime) by default in Okular, until it is run completely sandboxed.
  
  >>> In D16498#350325 <https://phabricator.kde.org/D16498#350325>, @bruns wrote:
  >>> 
  >>>> @pino - please remove your change request, if you have not read the code at all ...
  >>> 
  >>> 
  >>> Please tone down your attitude to something more respectful, thanks.
  >> 
  >> You started with "Ugh ..." - you comment lacks any respect ...
  > 
  > Certainly this was not the case, sorry if it was not intended. But even then, that was geared towards //the code//, and that does not remotely justify attacking //the person// with "you did not read the code" (which is wrong).
  
  The code clearly states it targets (E)PS **DSC**. A full blown PS interpreter //may// be able to extract more info from the file, but not without the mentioned drawbacks. Blankly stating using libspectre is better and should be used, without weighting pros and cons, does not give the impression (//to me//) you have evaluated it carefully.
  
  Apology accepted.

REPOSITORY
  R286 KFileMetaData

REVISION DETAIL
  https://phabricator.kde.org/D16498

To: bruns, #frameworks, #baloo, astippich, ngraham, poboiko, pino
Cc: pino, kde-frameworks-devel, ashaposhnikov, michaelh, astippich, spoorun, ngraham, bruns, abrahams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20181029/fe9cc480/attachment-0001.html>