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