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

Reply via email to