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

Pino Toscano noreply at phabricator.kde.org
Mon Oct 29 12:02:28 GMT 2018


pino added a comment.


  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)
  
  > 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?
  
  >> 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).

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/5525453f/attachment.html>


More information about the Kde-frameworks-devel mailing list