[Printing-architecture] pdftopdf

[Printing-architecture] pdftopdf

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

Hi,

Looking at the source code to pdftopdf, it seems like it is *another*
fork of xpdf.

Is there a reason it can't use the poppler library to do what it needs
to do?

Has it been security audited, or at least have the recent xpdf
vulnerabilities from the last few years been verified not to be present
in pdftopdf?

Thanks,
Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: [Printing-architecture] pdftopdf

[Till Kamppeter]

Tim, I did not know that. At least it links against libpoppler.

Otani-san, is there still code-duplication of XPDF or Poppler in the 
pdftopdf filter? Can this be avoided?

Tim, which version of pdftopdf are you looking at?

    Till

On 03/01/2012 12:18 PM, Tim Waugh wrote:
> Hi,
>
> Looking at the source code to pdftopdf, it seems like it is *another*
> fork of xpdf.
>
> Is there a reason it can't use the poppler library to do what it needs
> to do?
>
> Has it been security audited, or at least have the recent xpdf
> vulnerabilities from the last few years been verified not to be present
> in pdftopdf?
>
> Thanks,
> Tim.
> */
>

Re: [Printing-architecture] pdftopdf

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Thu, 2012-03-01 at 13:36 +0100, Till Kamppeter wrote:
> Tim, I did not know that. At least it links against libpoppler.
> 
> Otani-san, is there still code-duplication of XPDF or Poppler in the 
> pdftopdf filter? Can this be avoided?
> 
> Tim, which version of pdftopdf are you looking at?

I'm looking at the pdftopdf from cups-filters-1.0.2.

$ grep -l 'Glyph & Cog' *
P2PCharCodeToUnicode.cxx
P2PCharCodeToUnicode.h
P2PCMap.cxx
P2PCMap.h
P2PGfx.cxx
P2PGfx.h
parseargs.cxx
parseargs.h

These are from xpdf aren't they?  Or copied from poppler?

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: [Printing-architecture] pdftopdf

[Koji Otani]

From: Tim Waugh <twaugh@redhat.com>
Subject: Re: pdftopdf
Date: Thu, 01 Mar 2012 13:55:12 +0000
Message-ID: <1330610112.28173.5.camel@rubik>

twaugh> On Thu, 2012-03-01 at 13:36 +0100, Till Kamppeter wrote:
twaugh> > Tim, I did not know that. At least it links against libpoppler.
twaugh> > 
twaugh> > Otani-san, is there still code-duplication of XPDF or Poppler in the 
twaugh> > pdftopdf filter? Can this be avoided?
twaugh> > 
twaugh> > Tim, which version of pdftopdf are you looking at?
twaugh> 
twaugh> I'm looking at the pdftopdf from cups-filters-1.0.2.
twaugh> 
twaugh> $ grep -l 'Glyph & Cog' *
twaugh> P2PCharCodeToUnicode.cxx
twaugh> P2PCharCodeToUnicode.h
twaugh> P2PCMap.cxx
twaugh> P2PCMap.h
twaugh> P2PGfx.cxx
twaugh> P2PGfx.h
twaugh> parseargs.cxx
twaugh> parseargs.h
twaugh> 
twaugh> These are from xpdf aren't they?  Or copied from poppler?
twaugh> 

Yes, these files have codes copied from poppler.
pdftopdf uses poppler for what poppler can do.
Some of these files are copied from poppler to compiles it without
 poppler sourcecode files.

----
Koji Otani

Re: [Printing-architecture] pdftopdf

[Richard Hughes]

On 2 March 2012 04:03, Koji Otani <sho@bbr.jp> wrote:
> Yes, these files have codes copied from poppler.
> pdftopdf uses poppler for what poppler can do.
> Some of these files are copied from poppler to compiles it without
>  poppler sourcecode files.

Shouldn't we just link to libpoppler? Or are the source files in some
way modified?

Richard.

Re: [Printing-architecture] pdftopdf

[Koji Otani]

From: Richard Hughes <hughsient@gmail.com>
Subject: Re: [Printing-architecture] pdftopdf
Date: Fri, 2 Mar 2012 09:39:13 +0000
Message-ID: <CAD2FfiGa5qyHQ9q-CT6RcDzQU4Yyov2kxq-nB6cSB21CeivdqA@mail.gmail.com>

hughsient> On 2 March 2012 04:03, Koji Otani <sho@bbr.jp> wrote:
hughsient> > Yes, these files have codes copied from poppler.
hughsient> > pdftopdf uses poppler for what poppler can do.
hughsient> > Some of these files are copied from poppler to compiles it without
hughsient> >  poppler sourcecode files.
hughsient> 
hughsient> Shouldn't we just link to libpoppler? Or are the source files in some
hughsient> way modified?
hughsient> 

pdftopdf is linked to libpoppler.
And pdftopdf used some modified codes of poppler.
----------
Koji Otani

Re: [Printing-architecture] pdftopdf

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

On Fri, 2012-03-02 at 18:58 +0900, Koji Otani wrote:
> pdftopdf is linked to libpoppler.
> And pdftopdf used some modified codes of poppler.

So, the parts that are copied from poppler would need explicit security
maintenance outside of the poppler project.

Why do these files need to be copied?  Is there a way the poppler API
could be changed to avoid the need for this?

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: [Printing-architecture] pdftopdf

[Koji Otani]

From: Tim Waugh <twaugh@redhat.com>
Subject: Re: [Printing-architecture] pdftopdf
Date: Fri, 02 Mar 2012 11:22:02 +0000
Message-ID: <1330687322.32498.3.camel@rubik>

twaugh> On Fri, 2012-03-02 at 18:58 +0900, Koji Otani wrote:
twaugh> > pdftopdf is linked to libpoppler.
twaugh> > And pdftopdf used some modified codes of poppler.
twaugh> 
twaugh> So, the parts that are copied from poppler would need explicit security
twaugh> maintenance outside of the poppler project.
twaugh> 
twaugh> Why do these files need to be copied?  Is there a way the poppler API
twaugh> could be changed to avoid the need for this?
twaugh> 

Changes I made are needless for poppler and poppler can't use them.
I used only a frame of codes in some files.

Re: [Printing-architecture] pdftopdf

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

On Fri, 2012-03-02 at 21:08 +0900, Koji Otani wrote:
> Changes I made are needless for poppler and poppler can't use them.
> I used only a frame of codes in some files.

I don't understand.  Wasn't the whole idea of poppler to avoid having
bits of xpdf copied into every project that wants to do things to a PDF
file?  And doesn't pdftopdf want to do things to a PDF file?

Can you explain why it is that poppler "can't use" the extra bits you've
changed?  Can you describe what they are?  It seems to me that poppler
ought to provide sufficient insight into the structure of a PDF file so
that pdftopdf can do its job.  If it doesn't, that sounds like something
the poppler project would want to provide... no?

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: [Printing-architecture] pdftopdf

[Koji Otani]

Sorry, I'm not good at English.

It seemes that poppler provides parsing and rendering PDF.
pdftopdf needs modifying PDF such as number-up, duplicating pages ,
inserting empty pages, scaling pages, embedding fonts and producing PDF.
When I began to develop poppler, I considered about various things
such as limited time, cost, etc. And I decided that I developed pdftopdf
outside of poppler. (Developing pdftopdf was funded by a Japanese governmental 
organization)
It may be ok for poppler to include these features as you say.
I would appreciate it if you put these features into poppler.
----------
Koji Otani

From: Tim Waugh <twaugh@redhat.com>
Subject: Re: [Printing-architecture] pdftopdf
Date: Fri, 02 Mar 2012 12:13:38 +0000
Message-ID: <1330690418.32498.29.camel@rubik>

twaugh> On Fri, 2012-03-02 at 21:08 +0900, Koji Otani wrote:
twaugh> > Changes I made are needless for poppler and poppler can't use them.
twaugh> > I used only a frame of codes in some files.
twaugh> 
twaugh> I don't understand.  Wasn't the whole idea of poppler to avoid having
twaugh> bits of xpdf copied into every project that wants to do things to a PDF
twaugh> file?  And doesn't pdftopdf want to do things to a PDF file?
twaugh> 
twaugh> Can you explain why it is that poppler "can't use" the extra bits you've
twaugh> changed?  Can you describe what they are?  It seems to me that poppler
twaugh> ought to provide sufficient insight into the structure of a PDF file so
twaugh> that pdftopdf can do its job.  If it doesn't, that sounds like something
twaugh> the poppler project would want to provide... no?
twaugh> 
twaugh> Tim.
twaugh> */
twaugh> 

Re: [Printing-architecture] pdftopdf

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Sat, 2012-03-03 at 11:33 +0900, Koji Otani wrote:
> Sorry, I'm not good at English.

Your English is fine. :-)

> It seemes that poppler provides parsing and rendering PDF.
> pdftopdf needs modifying PDF such as number-up, duplicating pages ,
> inserting empty pages, scaling pages, embedding fonts and producing PDF.
> When I began to develop poppler, I considered about various things
> such as limited time, cost, etc. And I decided that I developed pdftopdf
> outside of poppler. (Developing pdftopdf was funded by a Japanese governmental 
> organization)
> It may be ok for poppler to include these features as you say.
> I would appreciate it if you put these features into poppler.

Thanks for explaining.  If poppler doesn't currently expose enough to
allow pdftopdf to do what it needs to then some work is needed to change
that, in order to avoid duplication of bugs.

Who knows the pdftopdf/poppler code well enough to do this?

Do we know anyone on the poppler development team who could guide us as
to what sort of changes they will accept?

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: [Printing-architecture] pdftopdf

[Till Kamppeter]

Otani-san, for the time being until we succeed to get the Poppler 
developers to expose the additional APIs for implementing pdftopdf and 
pdftoopvp, can you update the duplictaed code to the newest file 
versions available, so that the known vulnerabilities are fixed? Thanks 
in advance.

    Till

On 03/05/2012 01:14 PM, Tim Waugh wrote:
> On Sat, 2012-03-03 at 11:33 +0900, Koji Otani wrote:
>> Sorry, I'm not good at English.
>
> Your English is fine. :-)
>
>> It seemes that poppler provides parsing and rendering PDF.
>> pdftopdf needs modifying PDF such as number-up, duplicating pages ,
>> inserting empty pages, scaling pages, embedding fonts and producing PDF.
>> When I began to develop poppler, I considered about various things
>> such as limited time, cost, etc. And I decided that I developed pdftopdf
>> outside of poppler. (Developing pdftopdf was funded by a Japanese governmental
>> organization)
>> It may be ok for poppler to include these features as you say.
>> I would appreciate it if you put these features into poppler.
>
> Thanks for explaining.  If poppler doesn't currently expose enough to
> allow pdftopdf to do what it needs to then some work is needed to change
> that, in order to avoid duplication of bugs.
>
> Who knows the pdftopdf/poppler code well enough to do this?
>
> Do we know anyone on the poppler development team who could guide us as
> to what sort of changes they will accept?
>
> Tim.
> */
>

Re: [Printing-architecture] pdftopdf

[Till Kamppeter]

On 03/05/2012 01:14 PM, Tim Waugh wrote:
> On Sat, 2012-03-03 at 11:33 +0900, Koji Otani wrote:
>> Sorry, I'm not good at English.
>
> Your English is fine. :-)
>
>> It seemes that poppler provides parsing and rendering PDF.
>> pdftopdf needs modifying PDF such as number-up, duplicating pages ,
>> inserting empty pages, scaling pages, embedding fonts and producing PDF.
>> When I began to develop poppler, I considered about various things
>> such as limited time, cost, etc. And I decided that I developed pdftopdf
>> outside of poppler. (Developing pdftopdf was funded by a Japanese governmental
>> organization)
>> It may be ok for poppler to include these features as you say.
>> I would appreciate it if you put these features into poppler.
>
> Thanks for explaining.  If poppler doesn't currently expose enough to
> allow pdftopdf to do what it needs to then some work is needed to change
> that, in order to avoid duplication of bugs.
>
> Who knows the pdftopdf/poppler code well enough to do this?
>
> Do we know anyone on the poppler development team who could guide us as
> to what sort of changes they will accept?
>

Otani-san, can you provide a list of features which need to get exposed 
in Poppler so that you can implement the pdftopdf and pdftoopvp filters 
without code duplication? Please CC Albert Astals Cid (CCed in this 
mail) when answering.

Albert, could you help us in making more secure and 
distribution-friendly PDF print filters by adding some APIs to Poppler?

    Till

Re: [Printing-architecture] pdftopdf

[Koji Otani]

From: Till Kamppeter <till.kamppeter@gmail.com>
Subject: Re: [Printing-architecture] pdftopdf
Date: Mon, 05 Mar 2012 16:15:10 +0100
Message-ID: <4F54D87E.6060801@gmail.com>

till.kamppeter> On 03/05/2012 01:14 PM, Tim Waugh wrote:
till.kamppeter> > On Sat, 2012-03-03 at 11:33 +0900, Koji Otani wrote:
till.kamppeter> >> Sorry, I'm not good at English.
till.kamppeter> >
till.kamppeter> > Your English is fine. :-)
till.kamppeter> >
till.kamppeter> >> It seemes that poppler provides parsing and rendering PDF.
till.kamppeter> >> pdftopdf needs modifying PDF such as number-up, duplicating pages ,
till.kamppeter> >> inserting empty pages, scaling pages, embedding fonts and producing
till.kamppeter> >> PDF.
till.kamppeter> >> When I began to develop poppler, I considered about various things
till.kamppeter> >> such as limited time, cost, etc. And I decided that I developed
till.kamppeter> >> pdftopdf
till.kamppeter> >> outside of poppler. (Developing pdftopdf was funded by a Japanese
till.kamppeter> >> governmental
till.kamppeter> >> organization)
till.kamppeter> >> It may be ok for poppler to include these features as you say.
till.kamppeter> >> I would appreciate it if you put these features into poppler.
till.kamppeter> >
till.kamppeter> > Thanks for explaining.  If poppler doesn't currently expose enough to
till.kamppeter> > allow pdftopdf to do what it needs to then some work is needed to
till.kamppeter> > change
till.kamppeter> > that, in order to avoid duplication of bugs.
till.kamppeter> >
till.kamppeter> > Who knows the pdftopdf/poppler code well enough to do this?
till.kamppeter> >
till.kamppeter> > Do we know anyone on the poppler development team who could guide us
till.kamppeter> > as
till.kamppeter> > to what sort of changes they will accept?
till.kamppeter> >
till.kamppeter> 
till.kamppeter> Otani-san, can you provide a list of features which need to get
till.kamppeter> exposed in Poppler so that you can implement the pdftopdf and
till.kamppeter> pdftoopvp filters without code duplication? Please CC Albert Astals
till.kamppeter> Cid (CCed in this mail) when answering.
till.kamppeter> 
till.kamppeter> Albert, could you help us in making more secure and
till.kamppeter> distribution-friendly PDF print filters by adding some APIs to
till.kamppeter> Poppler?
till.kamppeter> 

We already asked Albert to expose some APIs for pdftoopvp, and he
exposed them for us.
Except a few codes, 
Essence of this issue is whether we add new features and codes to
poppler not exposing internal APIs, I think.

Re: [Printing-architecture] pdftopdf

[Jiri Popelka]

Otani-san, Till,

compiling cups-filters 1.0.18 I see
...
checking UGooString.h usability... no
checking UGooString.h presence... no
checking for UGooString.h... no
...

Trying to discover what's this UGooString and why it's not on my system
I found out that it used to be part of poppler but was definitelly 
removed [1] in version 0.6.0. pdftopdf still uses it and has it's own 
copy which it uses when there's no UGooString found on the system.

It seem's [2] that the last known version (before it was removed) was 
quite different than what's been in pdftopdf's UGooString.[h|cxx].
I have no idea which version is newer but it's worth checking whether
the [2] version doesn't fix any bugs.

Anyway, I think that the checking for system wide UGooString.h when
building pdftopdf could be removed because I don't think anybody uses
poppler < 0.6.0. It just confuses people (like me).


[1] 
http://cgit.freedesktop.org/poppler/poppler/commit/?id=bf7e0e980bf29994021cb1228f89f582adddf284

[2] 
http://cgit.freedesktop.org/poppler/poppler/tree/poppler/UGooString.cc?id=ba74bb3b0632593d1937911d73709fc870480efd


--
Jiri

On 03/05/2012 04:02 PM, Till Kamppeter wrote:
>
> Otani-san, for the time being until we succeed to get the Poppler
> developers to expose the additional APIs for implementing pdftopdf and
> pdftoopvp, can you update the duplictaed code to the newest file
> versions available, so that the known vulnerabilities are fixed? Thanks
> in advance.

Re: [Printing-architecture] pdftopdf

[Till Kamppeter]

The pdftopdf filter as it is currently in cups-filters is deprecated. 
Tobias Hoffmann is writing a new pdftopdf filter which does not copy 
Poppler code at all. Then the UGooString stuff will go away.

    Till

On 05/29/2012 06:06 PM, Jiri Popelka wrote:
> Otani-san, Till,
>
> compiling cups-filters 1.0.18 I see
> ...
> checking UGooString.h usability... no
> checking UGooString.h presence... no
> checking for UGooString.h... no
> ...
>
> Trying to discover what's this UGooString and why it's not on my system
> I found out that it used to be part of poppler but was definitelly
> removed [1] in version 0.6.0. pdftopdf still uses it and has it's own
> copy which it uses when there's no UGooString found on the system.
>
> It seem's [2] that the last known version (before it was removed) was
> quite different than what's been in pdftopdf's UGooString.[h|cxx].
> I have no idea which version is newer but it's worth checking whether
> the [2] version doesn't fix any bugs.
>
> Anyway, I think that the checking for system wide UGooString.h when
> building pdftopdf could be removed because I don't think anybody uses
> poppler < 0.6.0. It just confuses people (like me).
>
>
> [1]
> http://cgit.freedesktop.org/poppler/poppler/commit/?id=bf7e0e980bf29994021cb1228f89f582adddf284
>
>
> [2]
> http://cgit.freedesktop.org/poppler/poppler/tree/poppler/UGooString.cc?id=ba74bb3b0632593d1937911d73709fc870480efd
>
>
>
> --
> Jiri
>
> On 03/05/2012 04:02 PM, Till Kamppeter wrote:
>>
>> Otani-san, for the time being until we succeed to get the Poppler
>> developers to expose the additional APIs for implementing pdftopdf and
>> pdftoopvp, can you update the duplictaed code to the newest file
>> versions available, so that the known vulnerabilities are fixed? Thanks
>> in advance.
>