Re: [Podofo-users] Could someone tell me the encode type of HexString followed by Tj

[Matthew Brincke via Podofo-users]

On Tuesday, 12.04.2022 at 18:34 +0800 Alex wrote:
> Hi,
> 
>     When I opened a pdf file using podofobrowser.exe,if a pdfobject
> has a stream object,podofobrowser.exe will show the content of the
> stream as the following:
> 
> 
> BT
> /F2 10.56 Tf
> 1 0 0 1 136.46 758.28 Tm
> 0 g
> 0 G
> [(pdf)] TJ
> ET
> 
> BT
> /F1 10.56 Tf
> 1 0 0 1 154.94 758.28 Tm
> 0 g
> 0 G
> [<08CF372D>] TJ
> ET
> 
> 
> In the first BT object,I know easily the text string is “pdf “ by
> ([(pdf)] TJ),but it is difficult to understand [<08CF372D>] TJ in the
> second BT object,could someone tell me how to understand
> [<08CF372D>], what encode type is this.

Hi Alex,

the text is given as a HexString (correct), but the encoding of it
is given by the encoding of the font referenced as the name /F1 in
your PDF snippet (operator Tf). So if you'd like more information,
I'd need the content of the PDF object whose reference is given
after the name /F1 in the /Font property of your PDF's /ProcSet,
and also the contents of the objects whose references are given
after /Encoding and /FontDescriptor in that object (long arrays can 
be abbreviated). Thanks in advance. Pleased to read from you again.
                                                                     
>                              Thanks,
>                                                                      
>                                 Alex
> 

Best regards, mabri

___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo

[Matthew Brincke via Podofo-users]

On Friday, 08.04.2022 at 15:38 +0200 Dominik Seichter via Podofo-users
wrote:
> Hi Zyx, Hi Francesco,

Hi Dominik, hi zyx, hi Francesco,
> 
> I also wanted to continue this discussion. Sorry again for the long
> delay. If you prefer, we could also have a phone/video chat
> about these points (also whoever is interested could join in).

firstly, I'm sorry for not posting for so long, I had so much to do IRL
in the meantime. As there seem to be times of change ahead for PoDoFo,
I'd like to assume an active role in the project again.
> 
> From my point of view, the most important points/next steps are as
> follows (feel free to correct me if I am wrong):
> 
> 1) Decision on splitting PoDoFo and PoDoFo Tools: 
> I would prefer to keep them in the same repository to make sure they
> are in a buildable state all the time and can also be used as
> examples for working with PoDoFo.

Seconded.

> @Francesco Pretto : It would be great if you could take the
> additional effort and port them to pdfmm. The diff could also be a
> nice migration guideline for the future.
> 
> 2) Decision on license of PoDoFo Tools: 
> PoDoFo Tools are currently GPL whereas the library itself is LGPL.
> This e.g. makes it hard to copy from tools to the library. From my
> point of view, we should align the license so that the tools have the
> same license as the library (currently LGPL, for the future see
> separate discussion).

I always understood this difference as having a purpose
(in my view, warning people off taking PoDoFo tools and making
something non-free out of them).
> 
> 3) Merging back pdfmm in podofo / replacing podofo with pdfmm:
> I would agree to the proposal from Francesco here. We should do one
> last release of PoDoFo 0.9.8 based on the current svn trunk and then
> replace it. 
> @Zyx: When would be a good point of time for this? Can I just bundle
> a trunk, do quick tests and upload it? I am not sure about the
> current state.

Especially @Dominik: IIRC (I've lurked here in the meantime and looked
in the issue tracker on SourceForge a few times),
there are some patches still outstanding which I'd like to test (using
some "poor man's CI/test automation" locally most likely)
and then apply to SVN trunk, which fix security issues/crashers, so
that I'd be grateful for considering them
necessary for the next release. I'm not currently doing other work (a
day job), so I think I can do this quickly,
I hope starting tomorrow (Sunday). For the other issues labeled
"security" I'd also like to see what I can do
(I hope to produce patches and then handle them like the others, could
you please do too?).
> 
> 4) Move to Git: 
> Yes, let's move to Git* and keep website, mailing list on
> sourceforge.

Yes (after next release, I hope, if I'll succeed in committing with my
mabri SourceForge user account).
Issues which won't be copied to the new version control hosting (to
enable further work on them, after the move,
if the new issue tracker also has such features as e.g. issue states,
besides open/closed, the SourceForge one has)
should be closed at SourceForge, of course (IMHO at least).
> 
> 5) relicensing to MPL:
> I am in general open to that, but let's keep discussion in separate
> mail thread.

I think I'd like to think/discuss more about that (at least it's
copyleft?), in its mail thread.
> 
> 
> Best regards,
>  Dominik

Best regards, mabri
> 
> 
> 
> 
> On Tue, Feb 22, 2022 at 9:39 AM zyx  wrote:
> > On Mon, 2022-02-21 at 12:17 +0100, Francesco Pretto wrote:
> > > Please understand that after the port I would still need to
> > "recruit"
> > > people to ensure they actually work as intended. In short words:
> > they
> > > need a maintainer who cares about them.
> > 
> >         Hi,
> > sure, that's fine. As far as I can tell, it's no change from the
> > current state.
> >         Bye,
> >         zyx
> > 
> > 
> > ___
> > Podofo-users mailing list
> > Podofo-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/podofo-users
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users

___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Questions about Support Model Podofo A2308KMA3AM1EU

[Matthew Brincke via Podofo-users]

Hello Mr. Reuter,

this mailing list is of libpodofo, a software programming library and
associated software tools/examples for working with Portable Document
Format files/data (therefore its name from the first two characters of
each word written initial-capitalized) and has nothing to do with
hardware. Your inquiry/complaint is therefore sent to a venue where
questions about hardware (unless you can show it uses libpodofo) are
off-topic (it is not for those). Please continue your search for a
support forum or customer service venue elsewhere.

Best regards,

Matthew B.

On 05.03.22 at 12:33 wrote wolreu--- via Podofo-users:
>
>  
>
>  
>
> Gesendet von Mail  für
> Windows
>
> Greetings,
>
>  
>
> i bought this Podofo A2308KMA3AM1EU and by installing the device some
>
> things i missed or no function.
>
>  
>
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Releasing 0.9.7 ?

[Matthew Brincke]

> On 29 October 2019 at 13:24 Mattia Rizzolo  wrote:
> 
> Hello,

Hello Mattia, hello all,

> I believe it's high time for a new PoDoFo release.
> It has been slightly more than one year since the last one was done.
> Alright, there are still a few CVEs and other bugs opened, but many
> have been fixed in the same time, and it's getting slightly annoying to
> keep cherry-picking patches. Also, it's likely that more will appear
> the more we wait, so it doesn't make much sense to wait more.

I don't think a new release should contain any known security issues,
and if I recall correctly this was already deprioritised in 0.9.6, it'd
disappoint me if this happened again. Is it still called "cherry-picking"
when all the patches are taken into the packaging, or is there something
to exclude from the Debian package (if I'm informed right, 0.9.7 is to be
a bugfix-only release)?
> Are there any particular blockers for 0.9.7 at this time?

I would also like to work on a fix for CVE-2018-8002 if it's understood
that it would entail a technical limit for nesting as there are limits
given in an appendix of the PDF spec (free PDF32000_2008.pdf). For me,
getting acceptance on what should be in the special (documentation)
revision 2000 (see other ML post, please) would come first.

> --regards, Mattia Rizzolo

Best regards, mabri


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] Special revision 2000: Past, Present and future plans for PoDoFo

[Matthew Brincke]

Hello all,

I designate the special revision 2000 for documenting the past,
present and future plans for PoDoFo. Please commit anything to
svn until this has been discussed and a consensus reached.
Please make proposals for inclusion right away (just answer
this e-mail), I will be offline all the coming week (here is
still Sunday), maybe (I don't hope) including the weekend for
something really important and time-critical IRL, I'm sorry.

Best regards, mabri

P.S. I assume this OK because I was the only member of the
PoDoFo project actually contributing in the last quarter.


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Bug when drawing text using truetype font with difference encoding loaded from pdf

[Matthew Brincke]

Hello Michal, hello all,
> On 15 October 2019 at 19:00 Michal Sudolsky  wrote: 
> 
> Hi,
> How it looks with this bug?

I'm sorry I did only look cursorily at the issue (yet): I'm no expert for
fonts in PDF and for this reason, but also because other bugs caused crashes,
output data loss in the PoDoFo tool podofoimpose or memory leaking, prioritized
those, i.e. issues (in order of working on them) #49, #56, #57, #45 (only for
infinite recursion, excessive-but-finite recursion prevention outstanding), #58
and #64, #65, #66 and #67, recently also #61 (I've listed only those I think I
was successful in fixing on the platforms I regularly use), scheduled for the
future is #62 (after getting PdfRecursionGuard in its own file and using it on
fully fixing issue #45, this I'd like to get svn r2001 and svn r2002, after the
special revision 2000, which will be about the past, present and future plans
for the PoDoFo project).

Best regards, mabri

> On Sat, Jun 1, 2019 at 9:22 PM Michal Sudolsky < sudols...@gmail.com> wrote: 
> > I am sending test case:
> > ```
> > 
> > PdfMemDocument doc;
> > PdfPage *page = doc.CreatePage({0, 0, 500, 800});
> > PdfFont *font = doc.CreateFont("Verdana", false, false, false, 
> > PdfEncodingFactory::GlobalWin1250EncodingInstance());
> > PdfPainter p;
> > p.SetPage(page);
> > p.SetFont(font);
> > p.DrawText(10, 780, (const pdf_utf8*)"ČŘĎ");
> > p.FinishPage();
> > doc.Write("doc.pdf");
> > printf("Width of 'ČŘĎ' using newly created font is: %f\n", 
> > font->GetFontMetrics()->StringWidth((const pdf_utf8*)"ČŘĎ"));
> > 
> > PdfMemDocument doc2("doc.pdf");
> > PdfPage *page2 = doc2.GetPage(0);
> > PdfFont *font2 = doc2.GetFont(page2->GetFromResources("Font", 
> > font->GetIdentifier()));
> > PdfPainter p2;
> > p2.SetPage(page2);
> > p2.SetFont(font2);
> > p2.DrawText(10, 760, (const pdf_utf8*)"ČŘĎ");
> > p2.FinishPage();
> > doc2.Write("doc2.pdf");
> > printf("Width of 'ČŘĎ' using loaded font is: %f\n", 
> > font2->GetFontMetrics()->StringWidth((const pdf_utf8*)"ČŘĎ"));
> > 
> > 
> > ```
> > 
> > 
> > This gives incorrect width and also doc2.pdf does not contain second text.
> > 
> > Width of 'ČŘĎ' using newly created font is: 25.968750 
> > Width of 'ČŘĎ' using loaded font is: 36.00
> > On Tue, May 7, 2019 at 4:56 PM Matthias Brinke < ma...@mailbox.org> wrote: 
> > > [typos & wrapping fixed in quoted text] 
> > > Hello Michal, hello all, 
> > > 
> > > > On 09 December 2018 at 17:19 Michal Sudolsky < sudols...@gmail.com> 
> > > > wrote: 
> > > > 
> > > > Hi, 
> > > > Yes, it is usable rather with non-subset fonts. Whether a font is 
> > > > subset or 
> > > > not can be detected. Also it should be possible to check which 
> > > > characters are 
> > > > in a subset for example from weights (at worst from the embedded font 
> > > > file). 
> > > > 
> > > 
> > > I think this detection could be implemented later, i.e. I don't think 
> > > it's 
> > > necessary for acceptance of the patch. 
> > > 
> > > > One use case of this is to fill existing acroforms and construct 
> > > > appearance 
> > > > streams. It looks better and more uniform across viewers than to use 
> > > > "NeedAppearances". It would not be very reasonable to use a subset font 
> > > > for 
> > > > editable text fields. 
> > > > Also the StringWidth function will probably not work due to this bug. 
> > > > Let's 
> > > > say you want to extend the podofo text extraction utility to print also 
> > > > the 
> > > > bounding box of text elements in addition to position. You will get 
> > > > wrong 
> > > > string widths and bounding boxes due to this bug. This use case is 
> > > > reasonable 
> > > > also for subset fonts. 
> > > 
> > > This sounds very interesting, even though I don't think it'll be 
> > > implemented 
> > > in PoDoFo before next release (it's a new feature and there are still 
> > > bugs to 
> > > fix before). 
> > > 
> > > > All bug reports which I sent are based on some real use case. 
> > > 
> > > Could you please post such a test case, ideally minimal, as an attachment 
> > > to 
> > > answer this? 
> > > 
> > > > This is a bug and should be fixed. There is a function which lazily 
> > > > initialises the data structure which it uses and another function which 
> > > > does 
> > > > not. It can be fixed also by lazy initialisation in that other 
> > > > function. 
> > > > I just proposed a fix which I supposed is a better and simpler option. 
> > > 
> > > I also think that the simpler fix should be preferred and apologize for 
> > > only 
> > > coming around to this now. I'll test this and if all checks out, accept 
> > > it, 
> > > shortly after getting a (more or less) minimal test case. Thanks in 
> > > advance. 
> > > 
> > > Best regards, mabri 
> > > 
> > > > 
> > > > On Sat, Dec 8, 2018 at 7:13 AM zyx < z...@gmx.us> wrote: 
> > > > > On Mon, 2018-12-03 at 23:06 +0100, Michal Sudolsky wrote: 
> > > > > > The best is to initialise it during creation of 
> > > > > > PdfDifferenceEncoding. And 

Re: [Podofo-users] PoDoFo browser

[Matthew Brincke]

Hello Pietro, hello all,
> On 06 September 2019 at 19:33 Pietro Paolini 
>  wrote:
> 
> 
> Hi all,
> 
> I am following the instruction to compile the PoDoFo browser from the page:
> 
> http://podofo.sourceforge.net/download.html
>

the PoDoFoBrowser hasn't been changed/maintained for the whole decade (from 
2011,
of course) so it's "normal" that it can break on newer systems. 
> 
> However at the moment of the checkout I get an error with externals.
> 
>   U   trunk
> svn: warning: W205011: Error handling externals definition for 
> 'trunk/externals/required_libpodofo':
> svn: warning: W170013: Unable to connect to a repository at URL 
> 'http://podofo.svn.sourceforge.net/svnroot/podofo/podofo/tags/RELEASE_0_8_4'
> Checked out revision 1998.
> svn: E205011: Failure occurred processing one or more externals definitions

That URL is outdated, please use the svn checkout option --ignore-externals for
your "main" checkout and then manually checkout the tag using the current URL
https://svn.code.sf.net/p/podofo/code/podofo/tags/RELEASE_0_8_4 but note well
that it's very outdated and likely to be very broken compared to current PoDoFo.
PoDoFoBrowser also has probably never been tested since Qt 4.3 was released.

> 
> 
> Is there anything I am doing wrong ?

Except trying to get something long unmaintained, not really (please see above
for a workaround, but the whole browser thing hasn't been tested for long, so
it's very likely to break).
 
> 
> 
> Thanks,
> 
> Pietro
> 

Best regards, mabri


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Podofo rendering

[Matthew Brincke]

Hello zyx, hello all,
> On 14 August 2019 at 08:59 zyx  wrote:
> 
> 
> On Tue, 2019-08-13 at 14:11 +0200, Matthew Brincke wrote:
> > but Boost isn't searched for when configuring the podofo build (with
> > cmake) because it wasn't added as even an optional dependency to the
> > project.
> 
>   Hi,
> are you sure of that? See:
> 
> https://sourceforge.net/p/podofo/code/HEAD/tree/podofo/trunk/cmake/modules/FindBoost.cmake
> https://sourceforge.net/p/podofo/code/HEAD/tree/podofo/trunk/CMakeLists.txt#l461
> 
> and
> 
> https://sourceforge.net/p/podofo/code/HEAD/tree/podofo/trunk/README.html#l188
> 

I'm so sorry, I see my false description now, when I wrote what you quote I was 
so sure
of "optional dependencies" (by definition) only including packages checked for 
by default
that I only checked the output of my last cmake run for any mention of Boost 
before writing
that and sending it off. After checking CMakeLists.txt and README.html directly 
after I saw
your reply I now understand I was mistaken.
Please let me just make a suggestion: What do you think about calling such a 
package
a "hidden optional dependency"?

>   Bye,
>   zyx
> 

Best regards, mabri


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Podofo rendering

[Matthew Brincke]

Hello Pietro, hello all,
> On 13 August 2019 at 12:53 Pietro Paolini 
>  wrote:
> 
> 
> Hi Matthew,
> 
> I spoke too early and I have another question if you don't mind me 
> hammering.
> 

I received your first email as second (sorted up in my mail client)
and have already answered it. 

... snip ...
> 
> I get many errors, among them:
> 
> [..]/lib/libpodofo.a(PdfFiltersPrivate.cpp.o): In function 
> `PoDoFo::PdfDCTFilter::EndDecodeImpl()':
> PdfFiltersPrivate.cpp:(.text+0x2146): undefined reference to 
> `jpeg_read_header'
> PdfFiltersPrivate.cpp:(.text+0x215f): undefined reference to 
> `jpeg_destroy_decompress'
> PdfFiltersPrivate.cpp:(.text+0x21bd): undefined reference to 
> `jpeg_start_decompress'
> PdfFiltersPrivate.cpp:(.text+0x22b5): undefined reference to 
> `jpeg_read_scanlines'
> PdfFiltersPrivate.cpp:(.text+0x24fd): undefined reference to 
> `jpeg_destroy_decompress'
>

The mention of libpodofo.a tells me you're using a static build
of libpodofo (yes, I know, it's the default ... ;-( ). The solution
is to either link to all the dependencies of your libpodofo build
(should be mentioned as found in the cmake output when configuring
the build), or to switch to a shared library build with cmake option
-DPODOFO_BUILD_SHARED:BOOL=TRUE and check that "Building shared PoDoFo library"
is in the output of cmake.

> I think they are all coming from the same root problem, I do have the 
> libjpeg-dev (Debian system) installed locally though and I wonder what 
> the problem may be.

Then podofo was automatically configured with JPEG support and you'll need
to link to the libjpeg it found in your project too (when using a static
libpodofo build). When using a shared library build and not doing make install,
using LD_LIBRARY_PATH (on GNU/Linux) or changing the dynamic linker config
would be required to have your program find the libpodofo shared library. For
podofo-built programs this is required only when moving the library to a
non-standard location, or accessing it through a different non-standard path
(like in a sandbox) because the build process embeds a run-path in them.

> 
> This is the CMakeLists.txt for my microscopic project:
> 
> ADD_EXECUTABLE(main main.cpp)
> TARGET_LINK_LIBRARIES(main ${PODOFO_INSTALL_TOP}/lib/libpodofo.a)
> INCLUDE_DIRECTORIES(${PODOFO_INSTALL_TOP}/include)

Here the TARGET_LINK_LIBRARIES line is missing the dependencies of your
static libpodofo.

I hope this helps, please specify operating system if it isn't a (modern)
GNU/Linux "distro" (distribution).

> 
> 
> Best Regards,
> Pietro.

Best regards, Matthew

> On 13/08/2019 11:27, Pietro Paolini wrote:
> > Hi Matthew,
> > 
> > Thanks a lot for your answer, I am not bothered at all and I am  more 
> > than happy to stay on trunk - I just intended to flag this up.
> > I've also found that the example "pdfcontentsgraph" is not built as part 
> > of the main build.
> > 
> > Thanks,
> > P.
> > 
> > 
> > 
> > 
> > 
> > 
> > On 12/08/2019 23:36, Matthew Brincke wrote:
> >> Hello Pietro, hello all,
> >>> On 12 August 2019 at 23:24 Pietro Paolini 
> >>>  wrote:
> >>>
> >>>
> >>> Hi all,
> >>>
> >>> I've stumbled upon this library only a few days ago and I noticed that
> >>> the downloadable version from
> >>>
> >>> http://sourceforge.net/projects/podofo/files/podofo/0.9.6/podofo-0.9.6.tar.gz/download
> >>>  
> >>>
> >>>
> >>> Does not compile, at least on my system, while what I get right off
> >>> trunk does compile.
> >>
> >> in the meantime some issues were fixed which could have had made it 
> >> difficult
> >> to compile podofo, a number of security/crash issues were also fixed, 
> >> so it
> >> is definitely recommended to only use current svn trunk anymore. On 
> >> Tuesday,
> >> August 13, in the afternoon, I'll very probably commit (I'm a full 
> >> committer)
> >> a fix for issue #58 (plus some debug code to avoid such issues being 
> >> so difficult
> >> to debug as this was for me). I'd just like to run some further tests 
> >> with it,
> >> which are likely to pass, could you please hold out until then?
> >>>
> >>> I am exploring the possibility of using the library to inspect PDFs,
> >>> making some analysis on them and saving the PDF result of some
> >>> processing. A good example could be hidden text.
> >>>
> >>> It seems to be able to parse the input PDF and to "translate" in in

Re: [Podofo-users] Podofo rendering

[Matthew Brincke]

Hello Pietro, hello all,
> On 13 August 2019 at 12:27 Pietro Paolini 
>  wrote:
> 
> 
> Hi Matthew,
> 
> Thanks a lot for your answer, I am not bothered at all and I am  more 
> than happy to stay on trunk - I just intended to flag this up.
> I've also found that the example "pdfcontentsgraph" is not built as part 
> of the main build.

that is because "pdfcontentsgraph" requires Boost, but Boost isn't searched
for when configuring the podofo build (with cmake) because it wasn't added
as even an optional dependency to the project.

> 
> Thanks,
> P.

Best regards, Matthew

> 
> On 12/08/2019 23:36, Matthew Brincke wrote:
> > Hello Pietro, hello all,
> >> On 12 August 2019 at 23:24 Pietro Paolini 
> >>  wrote:
> >>
> >>
> >> Hi all,
> >>
> >> I've stumbled upon this library only a few days ago and I noticed that
> >> the downloadable version from
> >>
> >> http://sourceforge.net/projects/podofo/files/podofo/0.9.6/podofo-0.9.6.tar.gz/download
> >>
> >> Does not compile, at least on my system, while what I get right off
> >> trunk does compile.
> > 
> > in the meantime some issues were fixed which could have had made it 
> > difficult
> > to compile podofo, a number of security/crash issues were also fixed, so it
> > is definitely recommended to only use current svn trunk anymore. On Tuesday,
> > August 13, in the afternoon, I'll very probably commit (I'm a full 
> > committer)
> > a fix for issue #58 (plus some debug code to avoid such issues being so 
> > difficult
> > to debug as this was for me). I'd just like to run some further tests with 
> > it,
> > which are likely to pass, could you please hold out until then?
> >>
> >> I am exploring the possibility of using the library to inspect PDFs,
> >> making some analysis on them and saving the PDF result of some
> >> processing. A good example could be hidden text.
> >>
> >> It seems to be able to parse the input PDF and to "translate" in into an
> >> a "PdfVecObjects" but I have not found - within the time I had available
> >> for it, I should mention - a way to render the PDFs on screen.
> > 
> > PoDoFo is suitable for analyzing PDF documents, modify them (text editing
> > is still very limited, mostly adding is supported yet), and create them,
> > but what it doesn't do at all (because it's outside its scope) is rendering.
> > There are other libraries for that, a popular free (open source) one is
> > libpoppler (homepage URL https://poppler.freedesktop.org/ ), except for some
> > commenting functionality it does exclusively rendering (AFAIK), so IMHO it's
> > a good complement to PoDoFo which you'd use for the analysis and 
> > transformation
> > (sorry, colour space support is still rather limited, I hope that'll change
> > before 1.0 ;-) ).
> >   
> >>
> >> Is there an example somewhere for it ?
> > 
> > For rendering, please see the libpoppler homepage, for creation, there are
> > examples in that directory under podofo trunk, for analysis, please see
> > the tools directory's sub-directories there (podofopdfinfo could be a good 
> > start).
> >>
> >> Thanks,
> >> Pietro.
> >>
> > 
> > I hope this helps.
> > 
> > Best regards, Matthew
> >


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Podofo rendering

[Matthew Brincke]

Hello Pietro, hello all,
> On 12 August 2019 at 23:24 Pietro Paolini 
>  wrote:
> 
> 
> Hi all,
> 
> I've stumbled upon this library only a few days ago and I noticed that 
> the downloadable version from
> 
> http://sourceforge.net/projects/podofo/files/podofo/0.9.6/podofo-0.9.6.tar.gz/download
> 
> Does not compile, at least on my system, while what I get right off 
> trunk does compile.

in the meantime some issues were fixed which could have had made it difficult
to compile podofo, a number of security/crash issues were also fixed, so it
is definitely recommended to only use current svn trunk anymore. On Tuesday,
August 13, in the afternoon, I'll very probably commit (I'm a full committer)
a fix for issue #58 (plus some debug code to avoid such issues being so 
difficult
to debug as this was for me). I'd just like to run some further tests with it,
which are likely to pass, could you please hold out until then?
> 
> I am exploring the possibility of using the library to inspect PDFs, 
> making some analysis on them and saving the PDF result of some 
> processing. A good example could be hidden text.
> 
> It seems to be able to parse the input PDF and to "translate" in into an 
> a "PdfVecObjects" but I have not found - within the time I had available 
> for it, I should mention - a way to render the PDFs on screen.

PoDoFo is suitable for analyzing PDF documents, modify them (text editing
is still very limited, mostly adding is supported yet), and create them,
but what it doesn't do at all (because it's outside its scope) is rendering.
There are other libraries for that, a popular free (open source) one is
libpoppler (homepage URL https://poppler.freedesktop.org/ ), except for some
commenting functionality it does exclusively rendering (AFAIK), so IMHO it's
a good complement to PoDoFo which you'd use for the analysis and transformation
(sorry, colour space support is still rather limited, I hope that'll change
before 1.0 ;-) ).
 
> 
> Is there an example somewhere for it ?

For rendering, please see the libpoppler homepage, for creation, there are
examples in that directory under podofo trunk, for analysis, please see
the tools directory's sub-directories there (podofopdfinfo could be a good 
start).
> 
> Thanks,
> Pietro.
> 

I hope this helps.

Best regards, Matthew


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PdfPage::DeleteAnnotation does not delete the annotation object as it should (full mail)

[Matthew Brincke]

Hello F.E., hello all,
> On 03 April 2019 at 12:11 "F. E."  wrote: 
> 
> Hello again,
> I created two alternative patches for this issue, since the first one feels
> rather ugly. With patch v2, I switched the PdfReference parameter to
> call-by-value instead of call-by-reference.

I'd like to refrain from changing API before 0.9.7 unless it's really necessary
to fix a bug, here it isn't (see your first patch, which I'm going to accept
after some testing going OK, from reading it it's fine).  
> With patch v3, I kept the parameter as it is, but passed a local copy of the
> required PdfReference to the function.

That looks clean (and the comment I'd like to put into the first one) but 
there's
one problem: The method called is public so all users would need to change their
calls to fix the problem, so that's clearly impractical (+ docs'd need to 
change).

> With either of the three patches, the annotations are deleted without leftover
> objects, as it should be.

IIRC the object wasn't deleted to allow it to be reused, but I'm not sure if 
that
was really correct (the docs aren't clear about this).

Conclusion: Please wait for my acceptance of your first patch with some cosmetic
and comment changes (I first need to test it), I reject v2 and v3 herewith.

> Greetings, F.E. 
> 

Best regards, mabri


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [BRANCH] Moving source from root/src to root/src/podofo

[Matthew Brincke]

Hello Francesco, hello all,
> On 06 April 2019 at 00:42 Francesco Pretto  wrote:
> 
> 
> Also Matthew: any comment on the proposed re-layout of the source code?
>

before, I had dreamt of getting rid of the root/podofo/ directory, but
that was because of the wrapper headers in there. Because the (real)
headers are also in a podofo/ directory when installed, your proposal
is quite possibly the cleanest solution (maybe apart from separating
out the headers in an include/ directory, but that's probably, IMHO,
not so practical for development).

> Thank you,
> Francesco
> 

You're welcome.
Best regards, mabri


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [BRANCH] Moving source from root/src to root/src/podofo

[Matthew Brincke]

Hello zyx, hello Francesco, hello all,

> On 06 April 2019 at 00:06 Matthew Brincke  wrote:
> 
> 
> Hello zyx, hello all,
> 
> > On 05 April 2019 at 11:34 zyx  wrote:
> > 
> > 
> > On Fri, 2019-04-05 at 10:30 +0200, Francesco Pretto wrote:
> > > Ok. Now there are no other outstanding patches from my side and
> > > yesterday I merged a pending change from Michal Sudolsky.
> 
> what about the post "[Podofo-users] [PATCH 3/5] PdfArray: Removed
> inheritance from std::vector" from 2019-01-14 23:08 +0100 and the
> following ones? You haven't retracted or already committed them?
> 

I meant (and mean) to ask Francesco Pretto these questions, sorry
for not making that clear. zyx, you haven't committed them either
perchance, just curious?

I'm sorry for having forgot my sign-off in my previous mail.

Best regards, mabri


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [BRANCH] Moving source from root/src to root/src/podofo

[Matthew Brincke]

Hello zyx, hello all,

> On 05 April 2019 at 11:34 zyx  wrote:
> 
> 
> On Fri, 2019-04-05 at 10:30 +0200, Francesco Pretto wrote:
> > Ok. Now there are no other outstanding patches from my side and
> > yesterday I merged a pending change from Michal Sudolsky.

what about the post "[Podofo-users] [PATCH 3/5] PdfArray: Removed
inheritance from std::vector" from 2019-01-14 23:08 +0100 and the
following ones? You haven't retracted or already committed them?

> 
>   Hi,
> aha, it seems the svn change notifications are not working again (on
> the podofo-svn list). No big deal.
> 
> I guess it would be good to reply to respective messages with pending
> patches with a revision in which they've been merged into the sources,
> thus there is some evidence that someone took care of it. As examples
> (skipping those yours):
> https://sourceforge.net/p/podofo/mailman/message/36484599/

I  haven't tested that because I couldn't yet think of a document to test
it with, I otherwise think it's fine (the library user can decide if it's
sensible to use with some subset font AFAIK). It's not committed yet.

> https://sourceforge.net/p/podofo/mailman/message/36532908/

I haven't tested that because I don't know the relevant standards, and
I've had prioritized other things before asking about the ABI change
that patch causes, no API change because the extra parameter to the
constructor PdfSignatureField( PdfPage*, const PdfRect &, PdfDocument*,
EPdfSignFieldSubFilter eSubFilter = ePdfSignFieldSubFilter_pkcs7detached )
has a default value. What's your opinion on this (not committed yet)?

> These have no such response.
> 
> There are also some ongoing questions, which might be fixed too, but
> that's not the same as having pending patches.
> 
> > do you think now it could be a good moment to go for it
> 
> Sure, feel free to do it, I've no problem with that. My only concern
> was about pending patches, but if you believe you addressed that, then
> there's no other obstacle to do it, at least from my side.

Please see above.
>   Thanks and bye,
>   zyx


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Fwd: Better handling of xref entries shorter than 20 chars

[Matthew Brincke]

Hello F.E., hello all, 
> On 11 March 2019 at 09:52 "F. E."  wrote: 
> 
> > I think "\n\r" combination is unnecessary. 
> On principal I agree. But without the patch, Podofo loads PDFs
> with '\n\r' just fine and I don't want to change that without need. 
> Furthermore, the standard states 'if the marker is 2 characters
> (both a carriage return and a line feed)'. Imo there's no restriction
> to the order of CR+LF.
> 
> > This would be better: (e1 == '\r' && e2 == '\n') || (e1 == ' ' &&
> > (e2 == '\r' || e2 == '\n'))
> I added two patches with your simplification, one with check for '\n\r'
> and one without it.
> Greetings,F.E.

thanks for your patch (F.E.), I've committed your patch with the check for
LF+CR to trunk in svn r1973 [1] with the slight changes of making the
function CheckEOL() "static" to hide it to all outside its compilation unit
and re-wrapping comment lines to make them shorter, because I tested it with
four compilers: g++ 4.8, clang++ 3.8 and (on a newer system) g++ 7.3 and
clang++ 7.0, test/unit/podofo-test (both with and without --selftest) didn't
report any errors (no new warnings were reported by the compilers either),
and I also think that LF+CR xref line endings are legitimate.
I'm very sorry to have forgot the patch e-mail metadata in the commit message.

Best regards, mabri

[1] https://sourceforge.net/p/podofo/code/1973/

> Am So., 10. März 2019 um 10:02 Uhr schrieb Michal Sudolsky < 
> sudols...@gmail.com>: 
> > I think "\n\r" combination is unnecessary.
> > Also CheckEOL is too complicated there is unnecessary allocation and four 
> > string comparisons while it just had to compare two char values. This would 
> > be better:
> > 
> > 
> > (e1 == '\r' && e2 == '\n') || (e1 == ' ' && (e2 == '\r' || e2 == '\n'))
> > 
> > 
> > On Fri, Mar 8, 2019 at 8:16 PM F. E. < exler7...@gmail.com> wrote: 
> > > Hello again,
> > > I created another patch for checking the xref size. With this iteration, 
> > > '\r\n', '\n\r', ' \r' and ' \n' are considered valid as EOL, anythign 
> > > else will fail the parsing of the current subsection.
> > > I checked the patch with some of the researchers pdf files, it works 
> > > fine, but the error description from podofo could be a bit more clear, 
> > > though.
> > > I also checked the patch against the unit tests. The tests from the SVN, 
> > > although with fixes for MSCV compaired to the 0.9.6 tests, somehow 
> > > produced a "dereference out of range deque iterator" error. So I used the 
> > > tests form v0.9.6, had to fix some stuff, but tests were running through. 
> > > I had one failing test ('testDifferencesEncoding', last assert fails, 
> > > somehow the differences of the encoding are not applied), but thats 
> > > totally unrelated to my chances (I think).
> > > It would be nice if someone could check the patch again with a proper 
> > > test environment, mine feels very thrown together and quick-n-dirty (had 
> > > to dl and build cppunit as well and I'm not sure if I set everything up 
> > > correctly .. at least it built).
> > > GreetingsF.E. 
> > > 
> > > Am Do., 7. März 2019 um 13:13 Uhr schrieb F. E. < exler7...@gmail.com>: 
> > > > > > I disagree. To much leeway only creates more attack surface for 
> > > > > > malicious pdfs, since parsing is alwas a delicate procedure.> I do 
> > > > > > not think that allowing xref entries shorter than 20 chars is 
> > > > > > vulnerability. On the other side it could extend supported PDFs (if 
> > > > > > such PDFs really exists).My remark is more of a general advise. 
> > > > > > Parsers in general are often the weakest link and primary attack 
> > > > > > vector for attackers. Easy to exploit as well, just send a 
> > > > > > malicious input and a vulnerable parser will ultimately grant you 
> > > > > > RCE or what else. So the premise for writing a parser should always 
> > > > > > be, keep it as simple as possible and stick to the requirements.So 
> > > > > > i would say, if the pdf standard defines that xref entries have to 
> > > > > > be exactly 20 chacracters long, we should strictly stick to that. 
> > > > > > And if there are some PDFs with different-sized xref entries, they 
> > > > > > are to be rejected.Nevertheless, even if we would like to allow 
> > > > > > xref entries shorter than 20 chars, Podofos current parsing code 
> > > > > > still handles this wrong, so it has to be fixed regardless. And I 
> > > > > > think the easier solution right now is to just check for the 
> > > > > > correct size and fail consistantly otherwise. Changing the code to 
> > > > > > allow shorter xref entries requires a bigger change.
> > > > > Or there is hole in standard:  https://pdfsig-collision.florz.de
> > > > > In contracts with first two attacks seems SWA does not violate 
> > > > > standard, at least not with ByteRange key. From what I see in pdf 
> > > > > reference there is nothing what states that byte range must not 
> > > > > include only contents. And there is also not stated that 

Re: [Podofo-users] Issue with Encoding dictionary

[Matthew Brincke]

Hello Christophe, hello all,

> On 21 February 2019 at 22:03 BLANCHARD Christophe 
>  wrote: 
> 
> 
> Hello All, 
> 
> 
> I’ve managed to fix my issue. Please find my proposed patch as attachment. 

thank you for the patch, Christophe. I've changed it slightly but it looked
good before also, just a rename, replacing a deprecated type which you didn't
introduce, and a TODO about a called method from me (just to not forget about
an API change which I don't think should be done before the known security
issues are all fixed). I've committed it into svn r1970 [1] after testing it
on four compilers: GCC 4.8, clang 3.8 and (newer system) GCC 7.3 and clang 7.0
with your test document and test/unit/podofo-test (with only some xref parsing
test which provoke memory exhaustion/swapping disabled). I also used ASan with
them, at least the newer ones.

> 
> 
> Thank you 
> 
> 
> Cordialement/Best Regards,
> 
> 
> Christophe Blanchard

Best regards, mabri

[1] https://sourceforge.net/p/podofo/code/1970/

> 
> 
> De : BLANCHARD Christophe  
> Envoyé : vendredi 23 novembre 2018 23:50
> À : podofo-users@lists.sourceforge.net
> Objet : [Podofo-users] Issue with Encoding dictionary
> 
> 
> Hello all,
> 
> 
> I’ve encountered an issue when reading a PDF file containing an encoding 
> dictionary containing a “Differences” key: in attached file “doc1.pdf” 
> containing only “La création” text, PoDoFo, reads “La cr,ation”.
> 
> 
> Has anybody already encountered such a problem?
> 
> 
> Thank you in advance for your help.
> 
> 
> Cordialement/Best Regards,
> 
> 
> Christophe Blanchard
>


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] Test EncodingTest::testDifferencesEncoding() now properly fixed (was: Re: Bug when converting string to encoding with difference encoding)

[Matthew Brincke]

Hello Michal, hello all,

> On 29 November 2018 at 17:26 Michal Sudolsky  wrote: 
> 
> Function PdfEncodingDifference::ContainsUnicodeValue already gets its 
> unicodeValue parameter as big endian but it then treats it like machine 
> endian and swaps bytes then compares this against unicodeValues in 
> m_vecDifferences which are stored as big endian. 
> 
> Proposed patch attached.

thanks for the patch, Michal. It looks fine, tests more than fine (the test 
EncodingTest::testDifferencesEncoding()
is fixed properly by it, not like in svn r1906, reverted in svn r1927) also 
compiled with clang 3.8 (sorry for not
upgrading yet), therefore I've committed it into svn r1967 [1]. I'm very sorry 
for having overlooked it for that long
(nearly 12 weeks). Part of the reason might that I'm no expert in that area ;-).

Best regards, mabri

[1] https://sourceforge.net/p/podofo/code/1967/

P. S. the commit is within the 12 weeks ... ;-)


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] (Security) Issue #39: Opinions about attached patch for it?

[Matthew Brincke]

Hello all,

I'd like some opinions about the attached patch for solving
issue #39 [1] in which I have opted against throwing an
exception in order to avoid interrupting processing /Names
arrays in PdfNamesTree::AddToDictionary(PdfObject*, PDFDictionary&)
which would lose information. However, in podofopdfinfo,
against which the issue is reported, logging (which I used
instead of throwing) is disabled, so the log message isn't
output. Is it OK for you if I commit a change enabling that
logging first (before committing the attached patch, which
if there aren't objections, I plan to do tonight ca. 22:00 UTC),
should I alternatively commit both in one, or what do you think?

Best regards, mabri

[1] https://sourceforge.net/p/podofo/tickets/39/Index: src/doc/PdfNamesTree.cpp
===
--- src/doc/PdfNamesTree.cpp	(revision 1960)
+++ src/doc/PdfNamesTree.cpp	(working copy)
@@ -504,7 +504,17 @@
 // convert all strings into names 
 PdfName name( (*it).GetString().GetString() );
 ++it;
-rDict.AddKey( name, *(it) );
+if ( it == names.end() )
+{
+// logging needs to be enabled for this (e.g. in podofopdfinfo)
+PdfError::LogMessage( eLogSeverity_Warning,
+"No reference in /Names array last element in "
+"object %lu %lu, possible\nexploit attempt!\n",
+pObj->Reference().ObjectNumber(),
+pObj->Reference().GenerationNumber() );
+break;
+}
+rDict.AddKey( name, (*it) );
 ++it;
 }
 
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH] EncryptTest: Fix buffer overflow in decrypted out buffer in TestEncrypt()

[Matthew Brincke]

Hello Francesco, hello all,
> On 25 December 2018 at 21:04 Francesco Pretto  wrote: 
> 
> According to OpenSSL 1.1.0 documentation[1], "the decrypted data buffer out 
> passed 
> to the EVP_DecryptUpdate() should have sufficient room for (inl + 
> cipher_block_size) 
> bytes". In TestEncrypt(), pDecryptedBuffer has the exactly the size of the 
> known clear 
> text, which sounds correct but it's currently violating the contract of 
> EVP_DecryptUpdate() 
> used in PdfEncryptAESBase::BaseDecrypt() and causing a buffer overflow 
> detected by 
> MSVC when running the the test in Debug build. Fix TestEncrypt() so the out 
> data buffer 
> will end having exactly inl + cipher_block_size. 
> 
> [1] https://www.openssl.org/docs/man1.1.0/crypto/EVP_DecryptUpdate.html

thanks for your patch, I'm sorry to have overlooked it when no one else 
reviewed it,
I'm no expert in encryption. The quote about the contract of EVP_DecryptUpdate()
is also mentioned in the OpenSSL 1.0.2 documentation [2], and your patch adds as
much room in the output buffer for the decryption as the input got (padding to 
next
higher multiple of 16 bytes, and AES_IV_LENGTH = 16 bytes), so because inl, the 
length
of the encrypted data input to PdfEncrypt::Decrypt(), already includes the 
padding, your
patch adds AES_IV_LENGTH but the documentation calls for cipher_block_size. So 
it can
only work if both are the same number (or the IV length is larger, but that's 
unrealistic,
and also contradicts what you've written). The 1.0.2 documentation says: "The 
constant
EVP_MAX_IV_LENGTH is the maximum IV length for all ciphers.

EVP_CIPHER_block_size() and EVP_CIPHER_CTX_block_size() return the block size 
of a cipher
when passed an EVP_CIPHER or EVP_CIPHER_CTX structure. The constant 
EVP_MAX_IV_LENGTH is
also the maximum block length for all ciphers." The 1.1.0 documentation doesn't 
have this
last sentence anymore, but says instead EVP_MAX_BLOCK_LENGTH is the maximum 
block length.
Already in 1.0.2 (I don't have 1.1.* yet) the latter constant is 32, so if it 
is that in
1.1.* too, your patch could break with 32 extra bytes required instead of 16 
(what you're
giving). This is because I don't think AES-256 (32 bytes key length) would 
smaller-than-key
cipher blocks (I'm no expert in encryption, but could those who know more 
please speak up?).
So to decide on this issue, I need your (I mean the list) help: who thinks they 
can, please
do, because I'm not sure enough to reject the patch on my own, but also not to 
accept it.

Best regards, Matthew

[2] https://www.openssl.org/docs/man1.0.2/crypto/EVP_EncryptInit.html


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] PdfVariant: m_eDataType explained & Unknown sentinel value added

[Matthew Brincke]

Hi zyx, hello all,
> On 24 January 2019 at 18:55 zyx  wrote:
> 
> 
>   Hi,
... snip ...
> 
> > @zyx: Are you still vetoing that change of Francesco's (making
> > Unknown equal to 0xff in EPdfDataType)?
> 
> My complain from the past was about the compiler warnings (as Francesco
> pointed out in the archives). The two changes together (r1959 and the
> proposal) will make it work flawlessly, without the warnings, thus my
> original objection is gone. In other words, just do it.

Thank you very much :-). I'm so relieved because it didn't read so clearly
before.
> 
> > If not, I'll commit it after the fixes to the known security issues. 
> 
> Why to postpone? Why to split related commits by other commits?

Originally because I planned to prioritize the security fixes.
> Consider the r1959 caused this lengthy discussion. It would be more
> than logic to close the discussion in the next revision, in r1960, not
> to have some gap and only then finish something ongoing, while it's

You've persuaded me, I have done the commit and it has indeed landed in
svn r1960 [1] so that ends this discussion. 
> quite easy to forget of it. The changes I think of are: a) Unknown to
> be 0xff; b) add comment above the change in r1959 explaining why it is
> so. I would do a) and b) as one commit. The sooner you finish this

In general I'd have treated them as two commits, because they don't depend
on each other, but here, the elegance of "one finishing commit" swayed me.

> two-liner the better.

Now it's seven lines (with typo fixes and some reformatting as there is no
80-character limit followed in PdfVariant.h) ... Michal's assertion about
space for a 32-bit enum is for another time, IMO (in the other thread
originally about [PATCH 2/5]).

>   Bye,
>   zyx
> 

Best regards, mabri


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH 1/5] PdfVariant: m_eDataType is really a EPdfDataType

[Matthew Brincke]

Hi zyx, hello all,
> On 24 January 2019 at 12:13 zyx  wrote:
> 
> 
> On Wed, 2019-01-23 at 20:09 +0100, Michal Sudolsky wrote:
> > I am tempted to note that -1 is stored in 8-bit integer in exactly
> > same way as 0xFF.
> 

it seems to me (after reading the remainder of zyx' post) that I should
have replied to the above already, emphasizing that Michal's statement
(before your post, I've begun this before Michal's answer of 14:52 UTC)
only holds with 8-bit integers (not enum values, which are usually 32-bit
except when they are "typesafe enums" of C++11 and later and explicitly
given a different width) and it only says they're stored the same way,
not that they compare the same (or match in a switch statement the same,
I just didn't think of you, zyx, using one). 
>   Hi,
> I used the code below with gcc 8.1.1 with this result (the result will
> make sense when the code is read):
> 
>[0] is -1; same:0/1/0 as signed:-1/255 as unsigned:4294967295/255 switch 
> match: s:1 u:0
>[1] is 0; same:1/1/1 as signed:0/0 as unsigned:0/0 switch match: s:1 u:1
>[2] is 1; same:1/1/1 as signed:1/1 as unsigned:1/1 switch match: s:1 u:1
>[3] is 255; same:0/0/1 as signed:-1/255 as unsigned:4294967295/255 switch 
> match: s:0 u:1
> 
> what it should write is to have the 'same' triple all ones in at least
> one column, not any of them zeros. You can see that 0xff and -1 are not
> the same when it comes to comparison, either with a real enum value or
> with signed and unsigned integers. I believe (according to my

It isn't the case that Michal wrote they were the same, he only wrote they
are stored the same (AIUI, reinterpret_cast(pdf_int8(-1)) ==
pdf_uint8(0xff) with PoDoFo integral types, IIRC, this specific syntax
may require C++11 for the initializers).

> experience) that enums are like *signed* integers. Thus one might be
> careful what replacement type is used and which values will be assigned
> to it.

An enum is "like" a signed integer if there are negative enum values in it
[1] and only then, except in the following meaning: being convertible to int
(which is signed [2]), if there aren't values larger than int's maximum value
in the enum type [3]). 

> 
> The change mabri committed doesn't fix anything to upstream, it fixes a
> thing only to Francesco's private (and modified) checkout. The change
> also doesn't break anything upstream. Unless, some time later, someone

@zyx: Are you still vetoing that change of Francesco's (making Unknown
equal to 0xff in EPdfDataType)? If not, I'll commit it after the fixes
to the known security issues. This may help deciding: it's already
unspecified, and from C++17 undefined behaviour, to assign a value
outside its range to an enum (range means the set of values represent-
able by the smallest bitfield the existing enum values fit in) [4].

> decides to make Unknown -1 or anything like that. Then, hopefully, the
> compiler will claim something, thus it'll be noticed.

I certainly am opposed to negative values in enum types (because I don't
enumerate with negatives), especially that one (because it's free of them).
Therefore I'm upholding my -1 against such a change.

>   Bye,
>   zyx

Best regards, mabri

> 
> The used code follows. It generates compiler warnings with the switch-
> es, which is for good when looking for mistakes:
> 
> /* g++ test.cpp -o test && ./test */
> 
> #include 
> 
> typedef enum {
>   enMinusOne = -1,
>   enZero = 0,
>   enOne = 1,
>   enFF = 0xFF
> } EN;
> 
> int
> main (void)
> {
>   signed char n_int8;
>   unsigned char n_uint8;
>   bool smatch, umatch;
>   int ii;
>   EN ens[4] = { enMinusOne, enZero, enOne, enFF };
> 
>   for (ii = 0; ii < 4; ii++) {
>   n_int8 = ens[ii];
>   n_uint8 = ens[ii];
> 
>   #define test_switch(_val,_res) \
>   switch (_val) { \
>   case enMinusOne: _res = ii == 0; break; \
>   case enZero: _res = ii == 1; break; \
>   case enOne: _res = ii == 2; break; \
>   case enFF: _res = ii == 3; break; \
>   default: _res = false; break; \
>   }
> 
>   test_switch (n_int8, smatch);
>   test_switch (n_uint8, umatch);
> 
>   #undef test_switch
> 
>   printf ("[%d] is %d; same:%d/%d/%d as signed:%d/%d as 
> unsigned:%u/%u switch match: s:%d u:%d\n", ii, ens[ii],
>   n_int8 == n_uint8, n_int8 == ens[ii], n_uint8 == 
> ens[ii],
>   n_int8, n_uint8, n_int8, n_uint8,
>   smatch, umatch);
>   }
> 
>   return 0;
> }
> 

[1] https://en.cppreference.com/w/cpp/language/enum and there in the section
"Unscoped enumeration" under 1): "Declares an unscoped enumeration type
whose underlying type is not fixed (in this case, the underlying type is an

Re: [Podofo-users] [PATCH 1/5] PdfVariant: m_eDataType is really a EPdfDataType

[Matthew Brincke]

Hi zyx, hello all,
> On 23 January 2019 at 15:39 zyx  wrote:
> 
> 
>   Hi,
> 
> On Wed, 2019-01-23 at 13:35 +0100, Francesco Pretto wrote:
> > > weird, neither my checkout has it, nor the trunk:
> > 
> > I have ePdfDataType_Unknown = 0xff because I pushed for this change
> > some time ago[1].
> 
> I see, that's a long time ago.
> 
> > I ask you if we can move on with the change applied by Matthew, which
> > I think is wise and has the benefit of accommodating the change I was
> > aiming for.

@Francesco: Thank you.
> 
> I gave you a counter-example, where the committed change will break
> things (when the Unknown would be changed to -1 instead). For the

I wouldn't enumerate anything with a negative value, so IMO such a change
is to be -1'd (at least I would not accept non-"natural numbers" in it).
> consistency, the None is set to -1, the (other) Unknown-s to 0xff. Why
> not make them consistent in a way to declare Unknown/None as the first
> value of the enum with the value -1? Would that work for you? If not,

AFAIK, "None" and "Unknown" are different (e.g. for filters "None" means
it's known that no filter is applied whereas "Unknown" means it isn't
known which filter is applied (or the filter applied is unsupported in
PoDoFo, at least in the used revision). Therefore, where "None" makes
sense, I'm OK with (actually, would prefer) it being the first value,
but not -1 (or other negative) unless it'd be necessary to prevent zero-
initialization to yield "None" as valid value (on the contrary, I'd be
concerned if it'd yield some arbitrary, maybe unintended filter, even if
documented as the default filter, except in default construction PdfFilter()).

Another reason is that I wouldn't know, reading the source code, how many
1- (set) bits I'd get with an enum value -1, given the enum size can change
by compiler option (with 0xff any extra bits would be zeroed padding AFAICS).  

> why not? I kind of miss what you are aiming for. Is it anything else
> than having all Unknown being 0xff, which can eventually cause waste of
> memory in combination with -fshort-enums (while the switch is

In the reference Francesco mentioned in his first answer [1] to my first
post "[PATCH 1/5] is problematic" I couldn't find anything suggesting the
existence of less-than-8-bit enums, so 0xff (can be stored in 8 bit) does
waste clearly no memory, even with -fshort-enums (I didn't search all its
pages, just read the one about that option, but IIRC types shorter than 8
bit are only possible with bitfields).

> 
> > If you are reverting
> 
> I'm not going to revert anything. I just express my opinion on the
> change.
> 

@zyx: In light of what I've written above (and in pots before), would you
please allow the change making Unknown = 0xff go in?
> > I will not complain but I kindly ask you to comment the code with a
> > warning so nobody will attempt to change that underlying type anymore
> 
> Right, it makes sense to add the comment there. I'm not going to add it
> there myself though. Not yet at least.

I'm volunteering to add it, but only after the security fixes are all in,
and the Unknown has been added with positive value.

> 
>   Bye,
>   zyx

Best regards, Matthew

[1] Message-ID: 

Date: Tue, 22 Jan 2019 23:16:02 +0100
Archive URL: https://sourceforge.net/p/podofo/mailman/message/36524577/


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH 1/5] is problematic (was: Re: [PATCH 2/5] PdfDictionary: Removed 5 unneeded lookups in AddKey and RemoveKey methods)

[Matthew Brincke]

Hello Francesco, hello all,
> On 22 January 2019 at 23:16 Francesco Pretto  wrote:
> 
> 
> On Tue, 22 Jan 2019 at 22:27, Matthew Brincke  wrote:
> >
> > I retract my acceptance of [PATCH 1/5] because I've found some
> > posts [1] to the mailing list which show that it's problematic
> > (non-portable at least, but can lead to crashes). I'll instead
> > change the signed type pdf_int8 to pdf_uint8 because I don't
> > think casting a possibly-negative value to an enum makes sense
> > (though of course I can't give credit for that).
> >
> >
> 
> No problem, but it's worth mention that usage of enum as instance
> member is already spread in the library, for example
> PdfParser::m_ePdfVersion, PdfEncrypt::m_eAlgorithm,
> PdfEncrypt::m_eKeyLength. I think having enum as instance member
... snip ...
> library. I would rather aim to fix it setting a sentinel 0x
> value of the enum so it will be at least 32 bit, basing on the fact
> that no compiler on earth will ever allocate more than 32 bit for
> an enum unless required by actual enum values (we shouldn't care
> about stupid compilers, really). This could be done with all the
> enums in the library.

the size of that member PdfVariant::m_eDataType was reduced to
8 bits to save RAM space because PdfVariant objects are abundant
when using PoDoFo, not so much with the other ones you mention.
Therefore I don't agree with your proposal. The commit of my
change has made svn r1959 [1], btw. For the other enums this
could be discussed further, also with the other committers.

Best regards, mabri

[1] https://sourceforge.net/p/podofo/code/1959/

Best regards, mabri


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] [PATCH 1/5] is problematic (was: Re: [PATCH 2/5] PdfDictionary: Removed 5 unneeded lookups in AddKey and RemoveKey methods)

[Matthew Brincke]

Hello Francesco, hello all,

> On 18 January 2019 at 15:05 Matthew Brincke  wrote:
> patch and the fix because I'd like to accept the first two
> patches in this series today (commit them after testing with
> different compilers on GNU/Linux).

I retract my acceptance of [PATCH 1/5] because I've found some
posts [1] to the mailing list which show that it's problematic
(non-portable at least, but can lead to crashes). I'll instead 
change the signed type pdf_int8 to pdf_uint8 because I don't
think casting a possibly-negative value to an enum makes sense
(though of course I can't give credit for that).

The [PATCH 2/5] looks fine, but I'd like to put it on hold for
a bit because the location it's to be applied to is implicated
in issue #39 [2] and I plan to analyze and fix that first.

Best regards, mabri

[1] the post "Re: [Podofo-users] 0.9.5 regression,
pdfImage.GetObject()->GetDictionary() throws exception",
Message-ID <1487271019.6643.11.ca...@litepdf.cz>, archive
URL https://sourceforge.net/p/podofo/mailman/message/35670448/
shows a committer's acceptance of a bug report and his proposed
fix which is the opposite of yours. The bug analysis itself is
in Sandro Mani's post of 2017-02-11 02:12:33 UTC, archive URL
https://sourceforge.net/p/podofo/mailman/message/35659963/

[2] https://sourceforge.net/p/podofo/tickets/39/


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH 2/5] PdfDictionary: Removed 5 unneeded lookups in AddKey and RemoveKey methods

[Matthew Brincke]

Hello Francesco, hello all,

> On 18 January 2019 at 09:29 Francesco Pretto  wrote:
> 
> 
> On Fri, 18 Jan 2019 at 01:14, Matthew Brincke  wrote:
> >
> > Hello Francesco, hello all,
> >
> > > On 14 January 2019 at 23:08 Francesco Pretto  wrote:
> > >
> > >
> > > From: Francesco Pretto 
> > > ---src/base/PdfDictionary.cpp | 17 -
> > > 1 file changed, 8 insertions(+), 9 deletions(-)
> >
> > the lines your patch removes each contain an explicit or
> > implicit lookup, whereas your proposal only has one lookup
> > per method (class members are not called "functions" IIRC)
> > so it removes 5 look-ups (therefore I've changed the subject).
> 
> Thank you! Yes, it's 5 lookups removed, the code was very inefficient.
> 
> > More importantly, this patch seems to depend on [PATCH 4/5] in
> > this series for correctness (to avoid a memory leak) because
> > it removes a "delete" operator invocation without replacement
> > (IIRC: doesn't std::map::erase(), like std::vector::erase(),
> > only remove the item(s) from the container but doesn't free
> > their memory, for "reference" types, i.e. not primitives?).
> >
> 
> Are you talking about RemoveKey() method, right? I think the

yes, I mean that one.
> delete invocation is still missing, also in [PATCH 4/5], as
> map::erase() can't release memory for pointers.

I'm sorry I didn't yet review [PATCH 4/5], thank you for finding
the mistake yourself and mentioning it here.
> 
> Fixed method would be:
> 
> TKeyMap::iterator found = m_mapKeys.find( identifier );
> if( found != m_mapKeys.end() )
> {
> AssertMutable();
> delete found->second;
> m_mapKeys.erase( found );
> m_bDirty = true;
> return true;
> }

Thank you for providing the fix here, I'll credit you for the
patch and the fix because I'd like to accept the first two
patches in this series today (commit them after testing with
different compilers on GNU/Linux). 
> 
> I'm a bit in a stale situation now. Can I fix the change in
> a bigger merged patch 1-5?

I advise against that, because for accepting the two first
patches I'd need them separate, and I don't think you need
to provide a fixed version of the second patch as the fix
is already in the post I'm replying to and it's a simple one
so I can easily insert it into the code before testing.

I'm not sure I can accept the further patches because of the
(look-like at least for me) ABI changes, before the release
coming next, I think it'd be 0.9.7 and consist of fixes for
security vulnerabilities, crashes and exceptions avoidable
without changing the ABI or API (maybe supporting more uses).

Best regards, Matthew


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH 2/5] PdfDictionary: Removed 5 unneeded lookups in AddKey and RemoveKey methods

[Matthew Brincke]

Hello Francesco, hello all,

> On 14 January 2019 at 23:08 Francesco Pretto  wrote:
> 
> 
> From: Francesco Pretto 
> ---src/base/PdfDictionary.cpp | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)

the lines your patch removes each contain an explicit or
implicit lookup, whereas your proposal only has one lookup
per method (class members are not called "functions" IIRC)
so it removes 5 look-ups (therefore I've changed the subject).
More importantly, this patch seems to depend on [PATCH 4/5] in
this series for correctness (to avoid a memory leak) because
it removes a "delete" operator invocation without replacement
(IIRC: doesn't std::map::erase(), like std::vector::erase(),
only remove the item(s) from the container but doesn't free
their memory, for "reference" types, i.e. not primitives?).

Best regards,

mabri


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Help related to signing PDF document

[Matthew Brincke]

Hi Susheela, hello all,

> On 13 January 2019 at 19:08 Susheela S  wrote: 
> 
> Hi,
> I have tried to sign PDF document using latest version of PoDoFo
> 0.9.6 and openssl has been used for reading the certificate. I
> have attached the .cpp file which has the code. The PDF file gets
> created, but when [opened] it shows "invalid signature' on mouse
> over the signature field. "Error encountered while BER 
> decoding:Error during signature verification" is shown on
> clicking the signature in the PDF document.

please give which version of openssl did you use on which platform
(operating system), and which program (and version) gave the error
message? Which format is the certificate in?

> Can you please help me to fix this issue?
> I have also attached PDF created with signature from the attached
> code.

It's much easier to help (in general, I'm also speaking for the
people on this mailing list being more expert with PDF signing,
I hope) you with the answers to my questions.

> 
> Thanks, Susheela

Best regards, Matthew


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] Recursion guard against issues 15 (CVE-2018-8002) & 25

[Matthew Brincke]

Hello all,

what do you think about Dominik Seichter's suggestion [1]
to extract PdfRecursionGuard to its own file then to fix 
recursion issues in other places, namely CVE-2018-8002 [2]
(I'm of the opinion that fixing a CVE should take some
precedence over supporting everything that's, at least
theoretically, permissible according to the PDF spec)
and issue 25 [3] (in a PdfOutlineItem constructor)?

Especially @Committers: If you're OK with it, I'd do
both changes (extracting & then using it to do CVE fixes,
without changing the settings, I can only test with Linux).

Best regards, mabri

[1] https://sourceforge.net/p/podofo/tickets/7/#acda
[2] https://sourceforge.net/p/podofo/tickets/15
[3] https://sourceforge.net/p/podofo/tickets/25


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Patch to handle indirect ID in trailer

[Matthew Brincke]

Hello Clayton, hello zyx, hello all,

> On 30 October 2018 at 18:34 Clayton Wheeler  wrote: 
>  
... snip ...
> the typo in that comment, but I rewrote it after a closer reading of section
> 7.5.5 anyway; it implies the ID can be indirect when a PDF is unencrypted.
>

what the patch doesn't do is to insert a check for the document actually being
not encrypted. Should that that be added (as an extra commit), what do you 
think?
IHMO yes, because if it were encrypted, an indirect ID would be against the PDF
standard, right? I think that should be caught ...  

> Thanks,
> -- 
> 
> 
> Clayton Wheeler
> cwhee...@genomenon.com

Best regards, mabri


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] GetFilteredCopy throws exception with empty unencoded stream

[Matthew Brincke]

Hello Michal, hello zyx, hello all,

> On 29 October 2018 at 16:39 Michal Sudolsky  wrote: 
>  
> 
> I just meant there are other places where I can call function with NULL
> buffer and non-zero length to make crash for example "PdfImage::LoadFromData".

IMHO all these places should be fixed together in one commit. When you tell
me which places you mean, I could do the commit :-). What do you think?

Best regards, mabri

> 
> 
> On Mon, Oct 29, 2018 at 8:36 AM zyx < z...@gmx.us> wrote: 
> > On Sun, 2018-10-28 at 19:28 +0100, Michal Sudolsky wrote: 
> > > crash with null pointer and non-zero length as in other places in 
> > > podofo. 
> >  
> >          Hi, 
> >  crash is generally bad, that can lead to CVE issues at the least. 
> >  Better is when the code can handle broken inputs gracefully. If it's 
> >  the code's issue, then it should be fixed. 
> >  
> >  I mean, if you know of places which can crash instead of throw 
> >  exception, then feel free to share the reproducer and such, it'll be 
> >  highly appreciated. There are still opened some CVEs against PoDoFo, 
> >  maybe you face/mean one/some of them. 
> >          Bye, 
> >          zyx 
> > 
> > 
> >  ___ 
> >  Podofo-users mailing list 
> >  Podofo-users@lists.sourceforge.net 
> >  https://lists.sourceforge.net/lists/listinfo/podofo-users
> 
> 
> ___ 
> Podofo-users mailing list 
> Podofo-users@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/podofo-users


___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Password protected document

[Matthew Brincke]

Hello Christophe, hello all,
> On 03 September 2018 at 17:49 BLANCHARD Christophe 
>  wrote:
> Hello all,
> 
> I'm trying to read attached password-protected (password is 'password')

am I the only one to have *not* received any attachment with that email, or
has it been sent to the list with the attachment filtered away (without any
notice in the mail body), or did you (Christophe) just inadvertently forget
to attach it? (I'm sending to the list only to see whether I'm the only one
affected by this.)

Best regards,

Matthew

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] Untracked CVE issues now fixed (was: Re: CVE confusion, also in Debian (was: Re: Next PoDoFo Release 0.9.6))

[Matthew Brincke]

Hello all,

the CVE entries referenced below are now fixed in svn r1937.
These are CVE-2017-738[1-3].
URL: https://sourceforge.net/p/podofo/code/1937/

This means also: the Debian security tracker should be updated
(the "fixed versions" there didn't fix it AFAIK).

Best regards, mabri

> On 14 June 2018 at 01:37 Matthew Brincke  wrote:
> 
>
... snip ... 
> For the new info, please see my addition below (bad news).
> > On 12 June 2018 at 22:21 Matthew Brincke  wrote:
> > 
> > 
> > Hello Mattia, hello all,
> > > On 12 June 2018 at 16:25 Mattia Rizzolo  wrote:
> > > 
> > > 
> 
...snip...
> Upon detailed inspection, which I mostly did yesterday (Wednesday) like I
> promised, I found the claim in DLA-968-1's d/patches/CVE-2017-7380.patch
> that it also fixes CVE-2017-7381 to CVE-2017-7383 to be very suspect, if
> not outright mistaken.
> For CVE-2017-7381: If m_pResources in src/doc/PdfPage.cpp:609 is NULL,
> i.e. the page doesn't have resources, not even inherited ones (for those,
> cf. src/doc/PdfPage.cpp:63 to the end of the constructor), dereferencing
> it to call a method is undefined behaviour (likely crash/vulnerability).
> The patch doesn't change that, so it doesn't fix this CVE AFAICS.
> 
> For CVE-2017-7382: If the dictionary which is the value of/referred to
> by the /Font entry in the /Resources dictionary exists, the patch changes
> again nothing AFAICS (is the CVE ID bound to the specific reproducer?) so
> such a /Font dictionary without /Subtype entry (in the report, queried at
> src/doc/PdfFontFactory.cpp:200) can still trigger the bug (AFAICS, untested).
> 
> For CVE-2017-7383: The same except for /Type (in the report, queried at
> src/doc/PdfFontFactory.cpp:195) instead of /Subtype makes this unfixed.
> 
> > > 
> > > And if this is really going to reopen a CVE for stretch I'd need to
> > > check with the security team if they need/want to do something extra as
> > > well.
> > > 
> > Please do, thank you.
> > 
> > > -- 
> > > regards,
> > >  Mattia Rizzolo
> > > 
> > Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] 0.9.6 fails to link a test with -DPODOFO_HAVE_GCC_SYMBOL_VISIBILITY

[Matthew Brincke]

-1
I don't think any more classes should be publicized,
internals of PoDoFo should rather be protected from
users who might be tempted to rely on them.

Hello zyx, hello Mattia, hello all,
> On 30 July 2018 at 11:03 zyx  wrote:
> 
> 
> On Sun, 2018-07-29 at 19:45 +0200, Mattia Rizzolo wrote:
> > anybody? :)
> >...
> > > |-class PdfXRefStreamParserObject : public PdfParserObject {
> > > |+class PODOFO_API PdfXRefStreamParserObject : public PdfParserObject {
> > > | public:
> > > |
> > > | /** Parse the object data from the given file handle starting at
> > >
> > >
> > > But then I ask, is that class meant to be part of the public API?
IIRC it isn't meant as such, but as an internal part of the PdfParser API (so
the only class of all these is to be PdfParser itself, the other are of no
interest to application developers, aren't they?
> > > Otherwise, something else should be done to allow its linkage even with
> > > -fvisibility=hidden.
Yes, that's the solution I much prefer. I'm sorry to have not researched yet
which facility of ELF shared libs is to be used for that (or I don't exactly
remember, there was some paper of Ulrich Drepper about ELF internals and
security where I may have read such, I can hopefully read up on it in a few
days if nobody else is interested).
> 
>   Hi,
> I'm afraid nobody has a definite answer for your question, otherwise
> they'd already answer it, though, from my point of view, anything what
> is in public header(s) should be marked with either PODOFO_API or
> PODOFO_DOC_API, thus there are more "affected" classes, namely (from
> those I briefly grepped for): PdfHintStream, PdfFontType1Base14,
> PdfFontType1, PdfFontTrueType, PdfFontSimple, PdfXRefStream, PdfXRef,
> PdfObjectStreamParserObject, many in PdfEncrypt.h and that of yours,
> PdfXRefStreamParserObject.

IIRC there are some hints in the docs that PdfFont is meant as an
opaque supertype (meaning users aren't supposed to see any subclass,
if such info is really needed there could be a PdfFont::GetFontType()
returning an enum), so every subclass should be moved to an internal
header (to be created) that won't be installed.  Same for PdfEncrypt.
The XRef and ParserObject classes, internal to the PdfParser API
implementation, should also also be moved to an internal header.
PdfHintStream is part of the, still broken/deacivated, linearization
support in PoDoFo, so currently unused, but also internal.


> 
> Strictly speaking, (even I do not know why there is PODOFO_API and
> PODOFO_DOC_API, when both are defined to the same value) PdfTTFWriter

That class is another one currently unused IIRC, so also to be hidden.
> uses PODOFO_API, but it should use PODOFO_DOC_API instead, because it
> resides in src/doc/, not in src/base/.
> 
> I mean I'd be fine with the proposed change and if nobody has any
> objection (and I'll not lost track of this), I'll do the change within
> few days.
>   Bye,
>   zyx
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Fwd: Re: CVE confusion, also in Debian (was: Re: Next PoDoFo Release 0.9.6)

[Matthew Brincke]

Hello Mattia, hello Dominik, hello all,
> On 13 July 2018 at 14:30 Mattia Rizzolo  wrote:
> 
> 
> On Fri, Jul 13, 2018 at 08:17:31AM +0200, Dominik Seichter via Podofo-users 
> wrote:
> > I tagged the podofo-0.9.6 release already and also provided the tarball on
> > sourceforge. There was no official announcement though, yet.
> 
> Right, and I already stumbled on the first issue (that wasn't in the
> rc1): https://sourceforge.net/p/podofo/mailman/message/36363656/ :)
> > I still think we should release 0.9.6, as the status of 0.9.6 is not worse
> > than 0.9.5 (PLEASE CORRECT ME IF I AM WRONG HERE!).

PoDoFo 0.9.5 was released despite these 5 crashes:
https://sourceforge.net/p/podofo/mailman/message/35640936/ which then got CVE 
IDs
whereas in PoDoFo 0.9.6 there are 11 CVEs unfixed:
CVE-2018-5783 [1], CVE-2018-6253 [2], CVE-2018-8002 [3],
CVE-2018-11254 [4], CVE-2018-11255 [5], CVE-2018-11256 [6],
CVE-2018-12982 [7] whose description is IMO incorrect (the actual bug is 1-2 
levels
up the stack, please see PoDoFo issue #22), CVE-2018-12983 [8] and three ones
mistakenly declared fixed in the Debian libpodofo change log (see below).

> > Nonetheless, we should concentrate on fixing CVEs in a follow-up release. If
> > fixes are ready, I can provide another release 0.9.7 in short time.
That sounds good. A security-update release would usually use a four-component
version number, i.e. 0.9.6.1 here, no? On the other hand: I'd like to introduce
other crash/exception fixes too (for PdfOutlineItem and podofocolor) ...

> 
> I agree. I mean, it's a pity that there are known security
> vulnerability, but at this point several months (year+ really) passed
> and continue cherry-picking is not so great after a while.
> Not to mention, I fear the CVEs are going to keep coming...
> > On Thu, Jul 12, 2018 at 3:16 PM, Matthew Brincke  wrote:
> > > firstly I apologize (especially in case the delay in reaction
> > > on my part is the reason PoDoFo 0.9.6 was released with CVEs
> > > unfixed, for some of them see below in the original message)
> > > for having been busy with another project and not squeezing
> > > this in-between,
> 
> I don't think you should apologize for any of this.
Thank you.
> > > I also was unsure about you (Mattia) possibly being on vacation.
> 
> Alas, I'm not able to go on vacation long enough for anybody to notice…
> :(
I feel sorry for you (and tired ;-( ) ...

> > > (in the Debian changelog they had been
> > > mistakenly declared as fixed, and I didn't dare to send a 2nd
> > > e-mail or a bug report: I now fear this was wrong of me, so I
> > > apologize).
> 
> Apart from the situation in wheezy (which can't be changed anymore), I
> believe everything is fine now - at least in debian's git (pending the
> fix for the thing above). Please correct me if I'm wrong.

It's not just "the situation in wheezy": CVE-2017-738[123] are still
unfixed in 0.9.6 (upstream tag RELEASE_0_9_6) and therefore also in Debian
unstable (@Mattia: please don't upload until at least these 3 are fixed, I
can do that, possibly already this weekend, @Dominik: any objections?) and
experimental (the rc1).

In short: I'd like it more if 0.9.6 was the -rc2 for it ;-) ... because then
a future 0.9.6 (even last number) could be a stable/no known bugs release,
and the next one, 0.9.7 (odd last number) a development release like 0.9.5 ...
I'm sorry for having neglected to write that before so you (Dominik) couldn't
know I had hoped for that ... ;-)
I'm also rueful for having put off fixing bugs until you (Dominik) made sure
no further ones could go in 0.9.6 by tagging it, of course. I actually feel
punished by having been surprised by it (there was not even a warning by
private e-mail some days in advance, even if no public one was made). 

> 
> -- 
> regards,
>  Mattia Rizzolo
> 

Best regards, mabri

[1] https://security-tracker.debian.org/tracker/CVE-2018-5783
[2] https://security-tracker.debian.org/tracker/CVE-2018-6253
[3] https://security-tracker.debian.org/tracker/CVE-2018-8002
[4] https://security-tracker.debian.org/tracker/CVE-2018-11254
[5] https://security-tracker.debian.org/tracker/CVE-2018-11255
[6] https://security-tracker.debian.org/tracker/CVE-2018-11256
[7] https://security-tracker.debian.org/tracker/CVE-2018-12982
[8] https://security-tracker.debian.org/tracker/CVE-2018-12983

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Windows build on Podofo 0.9.5

[Matthew Brincke]

Hello Patrice, hello all,
> On 13 July 2018 at 10:48 Patrice Guérin  wrote: 
>  
>  Hello, 
>  
>  My name is Patrice and I'm new with Podofo. 
>  I was able to build Podofo 0.9.5 on Linux Debian 7 without problem but it's 
> a little bit more complicated on Windows with Visual Studio 2013. 
>  I've build the dependent libraries (jpeg9c, png1634, tiff 4.0.9, freetype 
> 2.9, zlib 1.2.11) without any major problem. 
>  The libraries includes and libs are all stored in a 'root' directory which 
> is accessed through an environment variable EXTERN_DEV ; the resulting 
> architecture is (I just show zlib 
> 
> > EXTERN_DEV (k:/extern_dev actually but can be changed) 
> >    |- zlib 
> >   |- 1.2.11 
> >      |- include 
> >      |- lib
> Podofo reside on a different disk and directory than dependent libraries. 
>  When creating the cmake project targetting Visual Studio 2013, I've  filled 
> the required paths to include and library in this way 
> 
> >  ZLIB_INCLUDE_DIR=$(EXTERN_DEV)/zlib/1.2.11/include 
> >  ZLIB_LIBRARY_DEBUG=$(EXTERN_DEV)/zlib/1.2.11/lib/zdll.lib 
> >  ZLIB_LIBRARY_RELEASE=$(EXTERN_DEV)/zlib/1.2.11/lib/zdll.lib 
> >  ...

I'm no expert in cmake, but IIRC environment variables are accessed as 
$ENV{NAME_OF_VARIABLE}, so in
your case $ENV{EXTERN_DEV}.
> The configuration process find all the dependencies expressed with 
> $(EXTERN_DEV) but the generation process prepends each include directories 
> with the Podofo source code path, so include files are not found : 
> 

It may also help to declare the cmake variables with their type FILEPATH: e.g. 
for the first one:
ZLIB_INCLUDE_DIR:FILEPATH=$ENV{EXTERN_DEV}

> > H:\Src\podofo-0.9.5\build\vs2013; 
> >  H:\Src\podofo-0.9.5; 
> >  H:\Src\podofo-0.9.5\$(EXTERN_DEV)\libjpeg\9c\include; 
> >  H:\Src\podofo-0.9.5\$(EXTERN_DEV)\libtiff\4.0.9\include; 
> >  H:\Src\podofo-0.9.5\$(EXTERN_DEV)\libpng\1.6.34\include; 
> >  H:\Src\podofo-0.9.5\$(EXTERN_DEV)\zlib\1.2.11\include; 
> >  H:\Src\podofo-0.9.5\src; 
> >  H:\Src\podofo-0.9.5\$(EXTERN_DEV)\freetype\2.9\include\config; 
> >  H:\Src\podofo-0.9.5\$(EXTERN_DEV)\freetype\2.9\include; 
> >  H:\Src\podofo-0.9.5\vcincludes; 
> >  %(AdditionalIncludeDirectories)
> The library files used for linking are expressed correctly.

It looks like as if the environment variable wasn't expanded in these paths.
If my guesses above don't help, I recommend looking for a CMake function
which explicitly resolves file paths to absolute path form (to call where
ZLIB_INCLUDE_DIR etc. are defined). Then even CMake functionality which
doesn't resolve environment variables should handle them correctly.
>  
>  Is there a way to correct this without modifying the VS solution by hand ? 

With my suggestions (I haven't tested them, I don't use Windows, sorry) it
should only be necessary to have CMake automatically generate the VS solution
again after a change of the environment variable.

>  
>  Thank you in advance 
>  Kind regards, 
>  Patrice.

I hope my suggestions help you.

Best regards, Matthew

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] Fwd: Re: CVE confusion, also in Debian (was: Re: Next PoDoFo Release 0.9.6)

[Matthew Brincke]

Hello Mattia, hello all,

firstly I apologize (especially in case the delay in reaction
on my part is the reason PoDoFo 0.9.6 was released with CVEs
unfixed, for some of them see below in the original message)
for having been busy with another project and not squeezing
this in-between, I also was unsure about you (Mattia) possibly
being on vacation.  
As it seems to me my original e-mail (see below) was missed,
I'm sending it again, but this time also to the podofo-users
list because I think now that version 0.9.6 has already been
released (IMNSHO prematurely, because of the CVEs and non-free
code in it) it's high time the project and its users get to
know them at last (in the Debian changelog they had been
mistakenly declared as fixed, and I didn't dare to send a 2nd
e-mail or a bug report: I now fear this was wrong of me, so I
apologize).
NB: Note that, contrary to what is in the "Original message"
below (I left it in so the reasoning for why I didn't send it
to the list stays intact), this has the earlier e-mail quotes
mostly snipped (as what was in them is now done), for reasons of
bandwidth economy, these paragraphs are already long enough ... 

Best regards, mabri

-- Original Message ------
From: Matthew Brincke 
To: mat...@mapreri.org
Date: 14 June 2018 at 01:37 CEST
Subject: Re: [Podofo-users] CVE confusion, also in Debian (was: Re: Next PoDoFo 
Release 0.9.6)
Hello Mattia,

I'm full-quoting my previous email because it was rejected by the
list server on account of an IP-address ban and I sent it to you
as a forward as you probably wouldn't like to get the same email
again so I'll avoid sending it to the list, instead you get this,
I hope this is OK. I've not pruned down this one because I don't
know if you are regularly reading your Debian address these days,
which I sent the the forward before (this Tuesday) to. In case of
that being a mistake, I'm sorry.
For the new info, please see my addition below (bad news).
> On 12 June 2018 at 22:21 Matthew Brincke  wrote:
> 
> 
> Hello Mattia, hello all,
> > On 12 June 2018 at 16:25 Mattia Rizzolo  wrote:
> > 
> > 
... snip ... 
> > Also, what about
> > https://security-tracker.debian.org/tracker/DLA-929-1
> > https://security-tracker.debian.org/tracker/DLA-968-1
> > Are they correct or they didn't fix some CVEs (like CVE-2017-5854)?
> 
> The DLA-929-1 did not fix the CVE-2017-5854 either (the patch supposedly
> doing that is the same change as in upstream svn r1836, so it can't).
> The DLA-968-1 doesn't look suspect to me, though I haven't checked in
> detail (having been busy with historical digital artifacts ;-) ).
... snip ...
> > The changes should be in
> > https://salsa.debian.org/debian/libpodofo/commits/wheezy - I would be
> > very happy if you could double check.
> I could probably do that tomorrow, now I'd like to get this e-mail sent.

Upon detailed inspection, which I mostly did yesterday (Wednesday) like I
promised, I found the claim in DLA-968-1's d/patches/CVE-2017-7380.patch
that it also fixes CVE-2017-7381 to CVE-2017-7383 to be very suspect, if
not outright mistaken.
For CVE-2017-7381: If m_pResources in src/doc/PdfPage.cpp:609 is NULL,
i.e. the page doesn't have resources, not even inherited ones (for those,
cf. src/doc/PdfPage.cpp:63 to the end of the constructor), dereferencing
it to call a method is undefined behaviour (likely crash/vulnerability).
The patch doesn't change that, so it doesn't fix this CVE AFAICS.

For CVE-2017-7382: If the dictionary which is the value of/referred to
by the /Font entry in the /Resources dictionary exists, the patch changes
again nothing AFAICS (is the CVE ID bound to the specific reproducer?) so
such a /Font dictionary without /Subtype entry (in the report, queried at
src/doc/PdfFontFactory.cpp:200) can still trigger the bug (AFAICS, untested).

For CVE-2017-7383: The same except for /Type (in the report, queried at
src/doc/PdfFontFactory.cpp:195) instead of /Subtype makes this unfixed.

> > 
> > And if this is really going to reopen a CVE for stretch I'd need to
> > check with the security team if they need/want to do something extra as
> > well.
> > 
> Please do, thank you.
> 
> > -- 
> > regards,
> >  Mattia Rizzolo
> > 
> Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Help needed for MinGw

[Matthew Brincke]

[ corrections in quoted text ]
Hello Gilles, hello all,
> On 04 July 2018 at 08:00 Gilles Maire  wrote:
> 
> 
> Hello,
> 
> I developped chordV on sourceforge 
> https://sourceforge.net/projects/chordV using libpodofo and Qt5
> 
> All is fine on Linux machine, and I try to install podofo on Mingw 
> provided by Qt5 on windows. I got a log of error messages. I don't know 
> if I can use different Mingw  version from the one provided by Qt.

What error messages did you get? It's difficult to help without them,
especially for people who don't have time/opportunity to install Qt on
Windows 10, who would otherwise well be able to help. So please attach
the log of error messages as a plain text file to your answer email.
> 
> I don't know a zlib mingw version I have to install on Windows10. I found 
> 2005 releases only

If your MinGW doesn't include it, it's probably best to compile it yourself
from its source code (as I understand Question 13's answer in the zlib DLL
FAQ from www.zlib.net/DLL_FAQ.txt which also has, in Question 1's answer,
requirements for using the name ZLIB1.DLL for a redistributed zlib DLL).
The current version available from its original web site https://www.zlib.net
is 1.2.11 from January 15, 2017.
> 
> Is there anyone who can help me ?

I don't know if there's anyone on this mailing list who has a sufficiently
similar installation to yours to be able to help you without you giving
the error log you got (not as an image, such was already seen on this list,
but as a plain text, preferably utf-8, attachment).
> 
> 
> Thanks
> 
> 
> Gilles
> 

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PdfPage DeleteAnnotation

[Matthew Brincke]

Hello Cory, hello all,
> On 14 June 2018 at 22:41 Cory Mickelson  wrote: 
>  
> 
> Please accept this patch to fix PdfPage DeleteAnnotation. I've added a

I have the following objections against accepting your new patch:
1. You have changed pItem from an address on the heap to a stack-allocated
   object. However, this breaks querying for any cached annotations: in
   your version, m_mapAnnotationsDirect is indexed with , which is
   an address on the stack (i.e. only valid within the same method call!),
   because pItem is a method-local (i.e. stack-allocated) object. This
   means, because m_mapAnnotationsDirect contains addresses valid for longer
   (IIRC all pointing into the heap), that the changed indexing will never
   work. Therefore, the memory the entries are pointing to will not be
   freed, leaking memory.

> test case to PageTest, you can verify the existence of this bug by running
> the test before applying the changes to PdfPage.cpp.

2. The test-case part of your patch contains very many unnecessary changes
   (you were warned against those by the committer zyx), namely to the
   formatting, which are IIRC also against project CodingStyle policy.
3. Your test-case declaration testDeleteAnnotation() can never be called
   because you didn't implement it (the definition is missing). Please don't
   add your test code to an existing test case, which you've done here with
   PageTest::testEmptyContentsStream().

For these reasons, I can't accept this patch. Please provide a corrected one.
Thank you in advance.
   
>  
> Thank you,
> Cory Mickelson
> 

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] CVE confusion, also in Debian (was: Re: Next PoDoFo Release 0.9.6)

[Matthew Brincke]

Hello Dominik, hello all,
> On 26 January 2018 at 23:35 Matthew Brincke  wrote:
> 
> 
> [ Left Dominik in To to help him follow this thread, fixed text typos ]
> 
> Hello Dominik, hello all,
> 
> > Dominik Seichter via Podofo-users has written on 26 January 2018 at 17:37: 
> > Hi Mattia,
> >  
> > Thanks for the good summary! Let me comment on the open issues.
> >  
> > Unfixed security issues: 
... snip ...
> >   
> > Plus this one without CVE that was reported in this ML:  
> > https://blogs.gentoo.org/ago/2017/02/01/podofo-null-pointer-dereference-in-pdfinfoguessformat-pdfinfo-cpp/
> 
> This is *not* fixed yet. I also don't understand why it didn't get
> a CVE entry.
> 
I erred here, I think, AFAICS it did get fixed in svn r1836 on 7 April 2017: 
https://sourceforge.net/p/podofo/code/1836/

The problem is that the commit message of that is incorrect (doesn't have
anything to do with the change): "Fix for CVE-2017-5854" which was only
fixed (AFAICS, untested) in svn r1870 on 21 January 2018 not mentioning it: 
https://sourceforge.net/p/podofo/code/1870/ 
Neither does it mention CVE-2018-5308 which is the same bug (AFAICS of course).
Fortunately this is fixed in Debian (I don't know about other distros, I don't 
use them): https://security-tracker.debian.org/tracker/CVE-2018-5308 
A related bug mentioned there was fixed in svn r1876.

@Mattia Rizzolo: Suggested action(s) to take: Correct the Debian security
tracker to say "vulnerable (no DSA)" instead of "fixed" in Debian stretch
(CVE-2017-5854). Fix the non-CVE'd bug too (in unstable, I'd think).

> > (CVE-2017-8054 had a tentative patch)
> > -> Seems same as above and seems fixed.
> 
> The CVE, yes, contrary to the other one without a CVE entry.

My error, I'm sorry (the latter is fixed upstream, just not in Debian, I
don't know about other distributions).

> > 
> > Best regards,
> >  Dominik
> > 
> 
> Best regards, mabri
>  

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH 13/13] PdfDictionary: Added support for range iteration

[Matthew Brincke]

Hello Francesco, hello all,
> On 22 February 2018 at 12:21 Francesco Pretto  wrote:
> 
> 
> Also added a convenience GetSize() method
> ---
>   src/base/PdfDictionary.cpp | 10 ++
>   src/base/PdfDictionary.h   | 16 +++-
>   2 files changed, 25 insertions(+), 1 deletion(-)
> 

your patch looks fine (except that it wouldn't apply without ignoring
white-space and some removals of that) and I've tested it OK in two
environments: a Debian sid chroot (with the Debian revision as a base,
GCC 7 compiler) and a sandbox with the current svn revision, but only
GCC 4.9.2). Therefore I've committed it as svn r1928:
https://sourceforge.net/p/podofo/code/1928/

I'm sorry for having taken my time (so much) with the testing (test
attached, committed version of patch also, first).

Best regards, mabriIndex: src/base/PdfDictionary.cpp
===
--- src/base/PdfDictionary.cpp	(revision 1927)
+++ src/base/PdfDictionary.cpp	(working copy)
@@ -357,4 +357,14 @@
 }
 }
 
+TCIKeyMap PdfDictionary::begin() const
+{
+return m_mapKeys.begin();
+}
+
+TCIKeyMap PdfDictionary::end() const
+{
+return m_mapKeys.end();
+}
+
 };
Index: src/base/PdfDictionary.h
===
--- src/base/PdfDictionary.h	(revision 1927)
+++ src/base/PdfDictionary.h	(working copy)
@@ -229,6 +229,11 @@
 void Write( PdfOutputDevice* pDevice, EPdfWriteMode eWriteMode, 
 const PdfEncrypt* pEncrypt, const PdfName & keyStop = PdfName::KeyNull ) const;
 
+/**
+*  \returns the size of the internal map
+*/
+inline size_t GetSize() const;
+
 /** Get access to the internal map of keys.
  *
  * \returns all keys of this dictionary
@@ -262,6 +267,10 @@
  */
 virtual void SetDirty( bool bDirty );
 
+ public:
+ TCIKeyMap begin() const;
+ TCIKeyMap end() const;
+
  private: 
 TKeyMap  m_mapKeys; 
 
@@ -272,6 +281,11 @@
 typedef	TVecDictionaries::iterator   TIVecDictionaries; 
 typedef	TVecDictionaries::const_iterator TCIVecDictionaries;
 
+size_t PdfDictionary::GetSize() const
+{
+return m_mapKeys.size();
+}
+
 // -
 // 
 // -
#include 
#include 

using namespace PoDoFo;

int main()
{
PdfError::EnableDebug(true);
PdfDictionary testDict;
testDict.AddKey(PdfName("Name"), PdfString("Test"));
testDict.AddKey(PdfName("F"), PdfString("test.txt"));
testDict.AddKey(PdfName("UF"), PdfString("Test.txt"));
for (const auto& testElem: testDict)
{
std::string objString;
PdfError::DebugMessage("Current element name: %s value: %s\n",
testElem.first.GetName().c_str(),
(testElem.second->ToString(objString), objString.c_str()));
}
PdfError::DebugMessage("Size of dictionary: %zu\n", testDict.GetSize());
return 0;
}

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] image extract

[Matthew Brincke]

Hello Joerg, hello all,
> On 22 May 2018 at 12:56 Joerg Sonnenberger  wrote:
> 
> 
> On Tue, May 22, 2018 at 12:48:50PM +0200, M. Froese wrote:
> > thank you joerg, so what might be wrong with my podofo build? the resulting
> > image is included in the attachment.
> 
> Windows problem. The file is not written as binary, so \n gets messed
> up.
> 
> Joerg

AFAICS in tools/pofofoimgextract/ImageExtractor.cpp (line 102 in current
svn r1926) the output file is opened as binary (on each call, and it's
the only place one is opened for writing in the program).
In PoDoFo in general, PdfOutputDevice forces opening files as binary in
its constructors taking a filename, see src/base/PdfOutputDevice.cpp
lines 59-63 and 93 in current svn. So the only one which could use a
file opened in text mode is PdfOutputDevice(const std::ostream*).

Where could the problem lie then, please? TIA.

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo PdfString::Write buffer overflow

[Matthew Brincke]

Hello Mark, hello all,
> On 02 May 2018 at 10:20 Mark Rogers  wrote:
> 
> 
> Hi
> 
> That sounds good. 
> 
>  > if( pEncrypt && m_buffer.GetSize() && IsValid() ) 
> > As IsValid() contains only a NULL check on the buffer in m_buffer,
>  > the size check needs to be > 2 if ...
> 
> At the moment buffer.GetSize()=1 produces buffer underflows so changing the 
> test to 
> buffer.GetSize()>1 or buffer.GetSize()>2 will prevent heap corruption

I'm sorry I didn't get to this until now: I think it's difficult to test because
I don't see when m_buffer.GetSize() could be less than 2 in PdfString ...

> 
> The harder question is when buffer.GetSize()=2 because this may work on some 
> systems 
> although it's relying on undefined behaviour.

My maxim is: "relying on undefined behaviour is always incorrect".
> 
> Best Regards
> Mark

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Getting Segmentation fault when trying to access PdfVecObjects

[Matthew Brincke]

Hello Georg, hello all,
> On 10 May 2018 at 19:28 Georg Funk  wrote:
> 
> 
> Hi Joerg,
> 
> thanks for this hint.
> 
> I thought maybe I'm misusing PdfObject::Reference() and
> PdfObject::GetReference() in my code This could explain the null
> pointer.
> 
that could also be a problem, however GetObject() returning NULL should
mean that no object with the reference numbers given to the method was
found in the PdfDocument or PdfVecObjects your PdfObject belongs to,
so please check if this is the case (no such object exists). Only if it 
isn't, you could have found a bug in PoDoFo.

> I want to get an object's Reference number by calling
> PdfObject::Reference() and get a pointer to a eventually existing
> indirect object by calling PdfObject::GetReference().
> 
> Is this the correct use case?
> 

Only the former is correct, whereas PdfObject::GetReference() is
inherited from PdfVariant and throws a PdfError exception if
IsReference() returns false, so it is only for "converting"
(de-capsulating) a reference in PdfObject form to PdfReference
(returns a C++ reference to a PdfReference object, no pointer).
 
> Thanks in advance!
> 
> Georg 
> 
> 

Hope this helps.

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Getting Segmentation fault when trying to access PdfVecObjects

[Matthew Brincke]

[typos fixed and code re-wrapped in quote]

Hello Georg, hello all,
> On 10 May 2018 at 16:14 Georg Funk  wrote:
> 
> 
> Dear developers,
> 
> I'm getting a segmentation fault in the following code snippet when
> resolving IsReference()):
> 
> if (objectVector.GetObject(currentReference)->IsReference()) {
> currentReference = objectVector
>  .GetObject(currentReference)->GetReference();
> }
> else {}
> 
> objectVector is a global variable here and currentReference holds a
> PdfReference to look up.

the method PdfVecObjects::GetObject() (your objectVector is of type
PdfVecObjects, right?) can return NULL (nullptr from C++11), this
means that the the reference passed (your currentReference) could
not be resolved (no object with those numbers was found in the vector).
Then IsReference() would be called with NULL this (undefined behaviour
AFAIK).

> 
> Error message from gdb:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x55ba2342486e in PoDoFo::PdfVariant::DelayedLoad (this=0x0) at
> /usr/local/include/podofo/base/PdfVariant.h:545
> 545   if( !m_bDelayedLoadDone)
> 

There it is, the "this" implicit argument with NULL value,
through some extra call(s).
> Have you any idea for me?

The return value of PdfVecObjects::GetObject() should be 
stored in a pointer variable which is then checked for
NULL (nullptr preferably for C++11 or newer) and used only
if it isn't equal to that.
> 
> Thank you!
> 

You're welcome.
> Best regards,
> Georg

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo PdfString::Write buffer overflow

[Matthew Brincke]

Hello all,
> On 01 May 2018 at 00:54 Matthew Brincke <ma...@mailbox.org> wrote:
> 
> 
> Hello Mark, hello all,
> > On 20 April 2018 at 00:09 Mark Rogers <mark.rog...@powermapper.com> wrote: 
> > 
> > 
> > Hi 
> > 
> > 
> > This code from PdfString::Write has a buffer overflow – it checks 
> > buffer.GetSize() > 0 then sets nInputBufferLen=GetSize()-2 which is passed 
> > to new[nInputBufferLen] and memcpy 
> 
> I'd like to contribute a fix for this (UTC tomorrow, I need to sleep soon):
> > if( pEncrypt && m_buffer.GetSize() && IsValid() ) 
> 

because I'm going to properly test the fix, I won't commit it yet, sorry, I
didn't have enough time for that.

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo PdfString::Write buffer overflow

[Matthew Brincke]

Hello Mark, hello all,
> On 20 April 2018 at 00:09 Mark Rogers  wrote: 
> 
> 
> Hi 
> 
> 
> This code from PdfString::Write has a buffer overflow – it checks 
> buffer.GetSize() > 0 then sets nInputBufferLen=GetSize()-2 which is passed 
> to new[nInputBufferLen] and memcpy 

I'd like to contribute a fix for this (UTC tomorrow, I need to sleep soon):
> if( pEncrypt && m_buffer.GetSize() && IsValid() ) 

As IsValid() contains only a NULL check on the buffer in m_buffer,
the size check needs to be > 2 if ...
> { 
>   pdf_long nInputBufferLen = m_buffer.GetSize() - 2; // Cut off the trailing 
> pair of zeros 
there is to be a trailing-zero pair at all ...
Otherwise only when there is such a pair expected: should be the Unicode case.
I mean IMHO only then should there be one, I'm going to make it so too.
In the non-Unicode case I'll check if zero-termination is needed altogether,
if it isn't the check wouldn't need to be changed, but the handling would.

>   pdf_long nUnicodeMarkerOffet = sizeof( PdfString::s_pszUnicodeMarker ); 
Of course I'd correct the typo also.

> 
> Best Regards 
>
> Mark 
> 

Best regards, mabri

P.S. Please still hold off with the rc2 for a bit (@Dominik), I'd like to 
commit Francesco Pretto's iterator API addition (13/13) and a PdfPage one 
of my own, still before the rc2 (and shouldn't the known vulnerabilities
be fixed in it also?).

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH 10/13] PdfVariant: Added SetString method

[Matthew Brincke]

Hello Francesco, hello all,
On 22 February 2018 at 12:21 Francesco Pretto wrote:
> ---
> src/base/PdfVariant.h | 25 +
> 1 file changed, 25 insertions(+)

the patch looks good except for the fact I had to
massage the white-space to get it to apply as a patch
(without fuzz), so please avoid sending patches in-line
in a post, please send all as attachments.
I've attached the final patch file here, as well as the
test program I used to test the change in a Debian sid
up-to-date sbuild chroot (against version 0.9.5-9 of
libpodofo0.9.5). I'm sorry that I had put off this test
for so long.
Thanks for your patch, I've committed it in the attached,
final form to svn r1922:
https://sourceforge.net/p/podofo/code/1922

Best regards, mabri---
src/base/PdfVariant.h | 25 +
1 file changed, 25 insertions(+)

diff --git a/src/base/PdfVariant.h b/src/base/PdfVariant.h
index f9217d8..fbd3c32 100644
--- a/src/base/PdfVariant.h
+++ b/src/base/PdfVariant.h
@@ -275,6 +275,14 @@ class PODOFO_API PdfVariant {
  *  \return the value of the number
  */
 inline double GetReal() const;
+
+/** Set the string value of this object.
+ * \param str the string value
+ *
+ * This will set the dirty flag of this object.
+ * \see IsDirty
+ */
+inline void SetString(const PdfString & str);

 /** \returns the value of the object as string.
  */
@@ -722,6 +730,23 @@ PdfData & PdfVariant::GetRawData()
 // We need a c-style casts here to avoid crashes
 // because a reinterpret_cast might point to a different position.
 return *((PdfData*)m_Data.pData);
+}
+
+// -
+//
+// -
+void PdfVariant::SetString(const PdfString )
+{
+DelayedLoad();
+
+if (!IsString())
+{
+PODOFO_RAISE_ERROR(ePdfError_InvalidDataType);
+}
+
+AssertMutable();
+*((PdfString*)m_Data.pData) = str;
+SetDirty(true);
 }
 
 // -

#include 
#include 

using namespace PoDoFo;

int main() {
  PdfVariant testVar(PdfString("Test string"));
  std::cerr << "Test: testVar contains " << testVar.GetString().GetStringUtf8()
<< std::endl;
  testVar.SetString("Another test");
  std::cerr << "Now in testVar (exp: Another test): "
<< testVar.GetString().GetStringUtf8() << std::endl;
  return 0;
}

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PDF CVE Security Research

[Matthew Brincke]

Hello Mark, hello all,
> On 19 April 2018 at 08:45 Mark Rogers  wrote: 
> Hi 
> This will be of interest to anyone testing PoDoFo or reviewing submitted 
> patches. It’s an analysis of 122 PDF CVEs found across a number of PDF 
> products presented at the Blackhat Security conference in March 2017. 
> Products with most CVEs found: 
> 
> 88 - Acrobat 88 
> 15 - Foxit 15 
> 8 – Adobe Digital Editions 
> 5 - Chrome 5 
> 3 - Apple Preview 3 
> 3 - Windows PDF Library 3 

these (in the left column) already add up to 122 so they're all of them,
not "most", and what I miss on the right are the version numbers ;-) ...
> 
> https://www.blackhat.com/docs/asia-17/materials/asia-17-Liu-Dig-Into-The-Attack-Surface-Of-PDF-And-Gain-100-CVEs-In-1-Year.pdf
>  
> 
> 
> The slides have links to the PDF CVE test repositories maintained by 
> Google and Mozilla (these are useful for testing PoDoFo) 
> 
> https://pdfium.googlesource.com/pdfium_tests/ 
> 
> https://github.com/mozilla/pdf.js/tree/master/test/pdfs 
> 

Thank you for the links, they could be very useful.

> And an analysis of the PDF modules most affected by CVEs: 
> 
> 34 – PDF Convertor 
> 24 – JPEG 2000 
> 24 – XFA 
> 21 – Rendering 
> 12 – Fonts 
> 4 – Others 
> 3 – JPEG (raw) 
> 
> 
> Does PoDoFo support JPEG 2000 or XFA? 

No, it does not support either yet.
Of course, rendering is outside its scope.
> 
> 
> Best Regards 
> Mark 

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH] PoFoFo: fix CVE-2018-5296 by reducing limit in s_nMaxObjects

[Matthew Brincke]

Hello Mark, hello all,

> On 15 April 2018 at 22:06 Mark Rogers  wrote: 
> 
> 
> Hi 
> 
> 
> Here’s a simple patch for CVE-2018-5296 – it reduces the limit returned 
> by GetMaxObjectCount from std::numeric_limits::max() to 8,388,607 which 
> is the limit for for the maximum number of indirect objects specified 
> in Table C.1 in Appendix C.2 Architectural Limits in PDF 32000-1:2008 
> 
the standard says there the limits are 32-bit systems whereas PoDoFo
uses 64-bit types in many places, therefore I'm feeling a bit uneasy
with the patch: Can anyone please shed some more light on this issue?

> 
> Best Regards 
> 
> 
> Mark 
> 
Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] CVE-2017-5855 and CVE-2017-6844

[Matthew Brincke]

Hello Mark, hello all,
> On 15 April 2018 at 18:32 Mark Rogers  wrote: 
> 
> 
> Hi 
> 
> 
> I’ve been trying to write unit tests for CVE-2017-5855 and CVE-2017-6844, and 
> now think both are false positives due to a bug in Address Sanitizer 
> triggered 
> by large values passed to std::vector::resize() 
> 
> 
> CVE-2017-6844  
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6844 
> 
> https://blogs.gentoo.org/ago/2017/03/02/podofo-global-buffer-overflow-in-podofopdfparserreadxrefsubsection-pdfparser-cpp/
>  
> 
> the stack trace shows the problem occurring in a call to 
> std::vector::resize(count) 
> 
> 
> CVE-2017-5855 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5855 
> 
> https://blogs.gentoo.org/ago/2017/02/01/podofo-null-pointer-dereference-in-podofopdfparserreadxrefsubsection-pdfparser-cpp/
>  
> 
> the stack trace shows the problem occurring in a call to 
> std::vector::resize(count) 
> 
> 
> Without ASAN enabled std::vector::resize with a large count will throw a 
> std::bad_alloc and be 
> caught by the catch( std::exception ) statement in ReadXRefSubsection 

that try/catch was introduced in svn r1843: 
https://sourceforge.net/p/podofo/code/1843 
so CVE-2017-5855 is unlikely to be entirely a false positive (although it could 
be a
DoS "only", a crash by std::bad_alloc not being caught), and AFAICS 
CVE-2017-6844 is
no false positive either because adding two numbers whose sum is too too large 
for 
their type can (NB: this is UB, Undefined Behaviour) make the result much 
smaller 
(when MSB carry is ignored) and the guard against this was introduced in svn 
r1840: 
https://sourceforge.net/p/podofo/code/1840

These commits were performed much later than the CVEs were assigned.

> 
> 
> Does this analysis make sense? 
> 

Summing up: No, at least your conclusion that the named CVEs are false positives
is wrong AFAICS.

> 
> Best Regards 
> 
> 
> Mark 

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo 0.9.6-rc1 ready for download

[Matthew Brincke]

Hello Francesco, hello all,

> On 08 April 2018 at 21:16 Francesco Pretto <cez...@gmail.com> wrote:
> 
> 
> On 8 April 2018 at 21:06, Matthew Brincke <ma...@mailbox.org> wrote:
> >
> > Could you please consider the following: I don't think the project should 
> > punish
> > Francesco Pretto by rejection of his not-yet-reviewed patches submitted on 
> > February 22,
> >
> 
> Matthew, don't worry: I think I got enough review for the patches I
> posted. Some were included but others won't be applied and on those I
> got enough explanation (I already know some were possibly
> controversial). If I think some of those patches still deserve to be
> included, I will post them updated at a later stage.

I mean the patches 04/13, 10/13 and 13/13 which I didn't review yet.
I think they are fine, I just would have liked to commit a fix to the
bug mentioned in the thread "[Podofo-users] BUG: Erase method from
PdfOutlineItem sometimes segfaults" first, which I'm still having
problems with ;-( (mainly with how I should test it and what should
be done in release vs. debug mode). 

I certainly didn't intend to exclude these patches from the upcoming
release by the passage of time until the release candidate comes out.
I'm very sorry for that if they don't get an exception from the "only
critical ones now" rule (as they're very simple I think).

> 
> Cheers,
> Francesco

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo 0.9.6-rc1 ready for download

[Matthew Brincke]

Hello Dominik, hello all,

> On 08 April 2018 at 14:12 Dominik Seichter via Podofo-users 
>  wrote: 
>  
> 
> Hi everybody,
>  
> The first release candidate for PoDoFo 0.9.6 can be downloaded from here:
> https://sourceforge.net/projects/podofo/files/podofo/0.9.6/podofo-0.9.6-rc1.tar.gz/download
>  
thank you, Dominik, for preparing and uploading the release candidate tarball.
>  
> Only critical patches will be integrated before release from now on.

Could you please consider the following: I don't think the project should punish
Francesco Pretto by rejection of his not-yet-reviewed patches submitted on 
February 22,
for the project's inaction (including mine, which I beg your pardon for) in not
reviewing and committing them (they're convenient API additions). I would commit
and review them today. Can patches be committed now which aren't for the 
release? 

Thanks in advance.

>  
> Best regards,
>  Dominik
> 
Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Justify text

[Matthew Brincke]

Hello Luis, hello all,
> On 13 March 2018 at 00:49 Luis Otavio  wrote: 
> 
> 
> Since PoDoFo seems to lack the ability to print multi line text into the 
> Justified format, and I am a newbie on PoDoFo 
> 
> Id like the help of you guys to get a few information 
> 
... snip ... 
> My questions are: 
> How do I get the length of a word in PDF units, or do i need to do it Glyph 
> by glyph? 
> Is there a better way to do that? 
as the PoDoFo method PdfPainter::DrawMultilineText() supports only left- and 
right-
aligned  as well as centered text drawing, PdfFontMetrics::StringWidth() can be
used (get the font metrics from a font by PdfFont::GetFontMetrics()) to have the
width of a string calculated (be wary of those overloads taking const char*, the
encoding they expect is undocumented). However, this method mostly just sums up
the widths of the characters, only processing spaces as special, so kerning of 
character pairs/triplets is not taken into account. I hope this helps you 
enough.

> 
> 
> -- 
> 
> Luis Otavio 

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Patch for GetFromResources to load colorspace

[Matthew Brincke]

Hello Christophe, hello all,
> On 10 February 2018 at 21:44 BLANCHARD Christophe 
>  wrote:
> 
> 
> Hello all,
> 
> This patch to make GetFromResources function supporting ColorSpace that can 
> be an array:
> 
> PdfObject* PdfPage::GetFromResources( const PdfName & rType, const PdfName & 
> rKey )
> {
> if( m_pResources->GetDictionary().HasKey( rType ) )
> {
> // OC 15.08.2010 BugFix: Ghostscript creates here sometimes 
> an indirect reference to a directory
> // PdfObject* pType = m_pResources->GetDictionary().GetKey( 
> rType );
> PdfObject* pType = m_pResources->GetIndirectKey( rType );
> if( pType->IsDictionary() && pType->GetDictionary().HasKey( 
> rKey ) )
> {
> PdfObject* pObj = pType->GetDictionary().GetKey( rKey 
> );// CB 08.12.2017 Can be an array
> if (pObj->IsReference()) {
> const PdfReference & ref = 
> pObj->GetReference();
> return 
> this->GetObject()->GetOwner()->GetObject( ref );
> }
> return pObj;  
>   // END
> }
> }
> 
> return NULL;
> }
> 

this patch looks fine, although it doesn't check for an entry being an array;
I don't think that's necessary at this time. I've received your email on Sun,
11 Feb 2018, 20:03 +0100 (CET), I'm sorry for answering it only an hour more
than a month later. As an aside: Patches submitted should be in attachments,
not in the mail body, except if extensive discussion of parts (which would
need to quoted) is foreseen.

I've committed your patch with minor (brace-style) alterations in svn r1910:
https://sourceforge.net/p/podofo/code/1910/

> Cordialement / Best Regards,
> Christophe BLANCHARD
> 

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Failed to build podofo on Manjaro Linux

[Matthew Brincke]

Hello,
> On 09 March 2018 at 16:04 張修銘  wrote: 
> 
> 
> Hello, 
> I downloaded snapshot of podofo from SourceForge and tried
> to build it on Manjaro Linux, but I encountered an error. Here
> is part of the error message: 
>  
> [ 66%] Linking CXX executable podofocolor
that your build got this far means that the podofo library
proper got built without (apparent) error. Have you tried to
use it in a program? 
> CMakeFiles/podofocolor.dir/luaconverter.cpp.o: In function 
> `LuaConverter::StartPage(PoDoFo::PdfPage*, int)': 
> luaconverter.cpp:(.text+0x280): undefined reference to `lua_getglobal' 
> luaconverter.cpp:(.text+0x2d4): undefined reference to `lua_callk' 
Please restart make with the VERBOSE=1 argument to get to know
the command line for this linking. Is the Lua library mentioned?
(I acknowledge that it being missing from the system should have
been detected during configuring: the cmake run on the top-level
CMakeLists.txt file. If you have it: Which version is it?)
... snip ... (because the error message have the same form, only
Lua symbols are reported missing, so the probable cause is the
Lua library not being mentioned: what is the cmake output on this?)

>  
> Does anyone knows how to solve it? 
You can try to give cmake an argument 
-DLUA_LIBRARIES=/path/to/liblua.so;/path/to/libm.so
(of course replace the path by the real one in your system)
or to check for a successful build of the library give the argument
-DPODOFO_BUILD_LIB_ONLY:BOOL=TRUE to cmake, this will deactivate
building the tools, tests and examples.

I hope this helps (untested, sorry). Please provide answers to
my questions above.

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] watermark

[Matthew Brincke]

Hello ChunHsia Tang, hello all,
> On 21 February 2018 at 10:16 chunhsia_t...@mazak.co.jp wrote: 
>  
>  hi, 

I'm sorry I'm replying only now, I just got your email from
the mailing list (approved there: Tue, 06 Mar 2018 01:07:23 +)
as there was an outage/reliability problem at SourceForge.net. 
> 
> 
>  a pdf page has some text and image 
>  
>  add watermark, watermark appear on top text and image 

I'm no expert on real (removal-protected) watermarks, sorry.
That said, when an image or some text is added to a PDF page
after other elements of the page, it appears on top of them.
That is because PoDoFo directly only supports appending to a
PDF page's content stream via the PdfPainter API, so to put
something in between, either lower-level PoDoFo APIs need to
be used or (only possible if the page is created with PoDoFo
of course) place the drawing call for it between the others.
>  
>  doc.Load("D:\\test.pdf"); 
>  PdfExtGState gstate(); 
>  pPage = doc.GetPage(0); 
>  painter.SetPage(pPage); 
>  painter.SetFont(pFont); 
>  gstate.SetFillOpacity(0.5); 
>  gstate.SetStrokeOpacity(0.5); 
>  painter.SetExtGState(); 
>  painter.Save(); 

The Save() call should bif youe put before SetExtGState() so that
the (not yet "extended") graphics state set before the latter
call can be restored further down in the code by Restore(). 
>  painter.DrawText(100, 100, "test test test test test test test test test"); 

Where do you add the image, please? I can't see it from this code. 
>  
>  how to add watermark appear at front text but behind image? 

To have the "watermark" (not a real one AFAIK) appear in front
of the text but behind the image, either draw it after the text
but before the image (if you're using PoDoFo for all that) or
use PdfContentsTokenizer to find where the text ends, copy the
part of the content stream (from PdfPainter::GetCanvas()) after
that offset in it to somewhere else, then truncate the original
there (FinishPage(), then use PdfStream methods for that, after
it's done call PdfPainter::SetPage() again) then draw to it:
Save() before SetExtGState(), see above, call Restore(), then
append the saved part of the content stream (just Append(), don't
call BeginAppend() or EndAppend() or any method which is to call
these, PdfPainter::SetPage() has already called the first one),
then call PdfPainter::FinishPage() (calls EndAppend() for you)
and it should work (I haven't tested it myself, though, or I
would still be busy with that for quite some time).
   
> 
> 
>  thanks 
You're welcome, I hope this helps you enough.

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] Resend: Re: Abolition of old-style casts, dynamic_cast intro request

[Matthew Brincke]

Hello all,

this is a resend because of a SourceForge.net mailing list
outage when it was originally (re)sent (I received an error
message for that in email yesterday, March 4, 09:21 CET).

-- Original Message --
From: Matthew Brincke <ma...@mailbox.org>
To: zyx <z...@gmx.us>, podofo-users@lists.sourceforge.net
Date: 28 February 2018 at 22:54
Subject: Re: [Podofo-users] Abolition of old-style casts, dynamic_cast intro 
request
Hello zyx, hello all,

> On 28 February 2018 at 09:06 zyx <z...@gmx.us> wrote:
> 
> 
> On Tue, 2018-02-27 at 22:22 +0100, Matthew Brincke wrote:
> > Thanks in advance for granting my request.
> 
>   Hi,
> from my point of view, and I confess I code in C more than in C++ these
> days/months/years, I do not care much as long as the code does what it
> is supposed to do. Of course, I prefer dynamic_cast when it comes to
> inheritance, thus the code can verify that the passed-in object is what
> it is supposed to be.
sounds good (as double-check, the enum about what kind it is, is checked).

> 
> Anyway, definitely do not do any such change just before the release.
> That's the worst idea one might have. There are plenty of patches to be
My intention was to make the code neat and tidy for the release, I read
in your answer fear of what shall be far from me: destabilization :-( ...

> reviewed and, as also Francesco said, more important work to be done
> first. You claimed you'll review patches during the last weekend (in
> message from Fri, 23 Feb 2018), but I didn't notice anything in this
I have committed and reviewed one patch just before the weekend's end (in
local time), I sent it to Francesco and the list, sourceforge.net lost it
(I configured my mailing list subscription to send my posts back to me
and didn't get it that time, I just suspected it might be delayed,
I wouldn't have put much faith in a resend). I'll resend it to you,
Francesco and the list right away.

> regard. Maybe stay on the safe side, do not promise things you might
> not accomplish for sure. :)

Yes, that's also my opinion, I hope I hadn't promised to review more than
one patch, I'm sorry that the one review email didn't reach you.

>   Bye,
>   zyx

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] Patch review/mailing list unreliability (was: Re: Abolition of old-style casts, dynamic_cast intro request)

[Matthew Brincke]

Hello zyx, hello all,
> On 01 March 2018 at 09:03 zyx <z...@gmx.us> wrote:
> 
> 
> On Wed, 2018-02-28 at 22:54 +0100, Matthew Brincke wrote:
> > I hope I hadn't promised to review more than one patch
> 
>   Hi,
> well, I understood (and hoped) your statement as more than one will be
> done, but if it was not meant like that, then my fault. I'm sorry.

I didn't know if I would manage to review more than one patch, so my
promise was intentionally worded such that the number of patches I'd
review was left open (so it could also mean just 1). For review of
further patches I'd have needed (and still do) you/Dom to answer this
question: How should I review patches which add public API? If the patch
is otherwise good, should I commit the API addition (after adding some
doxygen documentation if not already provided), before sending a review
email to the list with the revision web URL?
 
>   Bye,
>   zyx
> 
> P.S.: by the way, I'm on the list, I reply to message on the list, no
> need to "reply to all" in case of replies to my messages, better to use
> "reply to list". I know there are different opinions regarding "reply
> to all" and "reply to list", but in my case it's like this. Just a
> note, nothing serious :)
> 

When the list mail processing (mostly/for me) worked, I did that (remove
your/mostly everyone's) address from the mail's "To" field before sending),
only when the list proved unreliable, I left it in to make (more) sure you
would receive the email. I very much hope the sourceforge.net project
mailing lists and their archive web pages (hopefully with the thread view
fixed to show all emails, not missing some as it had been) return to proper
service very soon.

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] Fwd: Re: [PATCH 05/13] PdfPagesTree::InsertPage: Fix "atIndex" is really a 0-based index

[Matthew Brincke]

Hello zyx, hello Francesco, hello all,

this is a resend of the email content (with main headers) below.
I'm sorry that e-mail didn't reach (all of) you originally.

Best regards, mabri

-- Original Message --
From: Matthew Brincke <ma...@mailbox.org>
To: Francesco Pretto <cez...@gmail.com>
Cc: Dominik Seichter via Podofo-users <podofo-users@lists.sourceforge.net>
Date: 25 February 2018 at 23:59
Subject: Re: [Podofo-users] [PATCH 05/13] PdfPagesTree::InsertPage: Fix 
"atIndex" is really a 0-based index
Hello Francesco, hello all,
> On 23 February 2018 at 22:25 Francesco Pretto <cez...@gmail.com> wrote:
> 
> 
> On 23 February 2018 at 19:27, Francesco Pretto <cez...@gmail.com> wrote:
> > I tested it with following code:
> >
>

I'm sorry I couldn't make it yesterday, I was too tired because I couldn't
sleep well for long enough that night. Now I've done the review and test:
patch looks good, compiles without warnings, avoids a crash with your test
code below (with a minor change, please see there), so I've accepted and
committed it in svn r1898: https://sourceforge.net/p/podofo/code/1898/

> Oops...a missing fragment in the test code. Here it again complete:
> 
> PdfMemDocument document;
> PdfRect rect;
> 
> auto pageA = document.InsertPage(rect, 0);
> auto pageB = document.InsertPage(rect, 0);
> auto pageC = document.InsertPage(rect, 2);
> 
> // PageNumber is 1-based index
> assert(pageA->GetPageNumber() == 2);
> assert(pageB->GetPageNumber() == 1);
> assert(pageC->GetPageNumber() == 3);
> 
> // Insert ouf of bounds
> auto page = document.InsertPage(rect, -1);
> assert(page->GetPageNumber() == 1);
> int pageCount = document.GetPageCount();
This definition I've changed to "unsigned int" because ... 
> page = document.InsertPage(rect, pageCount + 1);
> assert(page->GetPageNumber() == pageCount + 1);
for this I received a warning from GCC about unsigned/signed comparison.
> 
> // Insert in the middle
> page = document.InsertPage(rect, 2);
> assert(page->GetPageNumber() == 3);

Without the patch, this had GCC Adress Sanitizer report a SEGV crash
by illegal memory access (at address 0, so a null pointer dereference),
with the patch all went well. Thanks for the patch and the test code!

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Accessing the images of one page?

[Matthew Brincke]

Hello Dmitry, hello Olivier, hello all,

> On 20 February 2018 at 19:50 Dmitry Salychev  wrote: 
>  
> 
> Hi, Olivier. 
>  
> First of all, you've to know what kind of image you're going to access. They 
> usually can be stored in a PDF file two ways: XObject image or inline one. 

IIRC if you don't want to tokenize page content yourself (e.g. helped by the
PdfContentsTokenizer class) the only way supported by PoDoFo is the XObject one.

> Does it make any sense? 
> 
> 
> Regards,
>  
> - Dmitry 
> 

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Abolition of old-style casts, dynamic_cast intro request

[Matthew Brincke]

Hello Francesco, hello all,
> On 27 February 2018 at 22:48 Francesco Pretto <cez...@gmail.com> wrote:
> 
> 
> On 27 February 2018 at 22:22, Matthew Brincke <ma...@mailbox.org> wrote:
> > I'd like
> > to make its code more C++-like by removing those
> > and replacing them with dynamic_cast.
> 
> My opinion: dynamic_cast has a runtime performance cost and should be
> done when it is desired to test the type hierarchy at runtime, for
> example when doing conditional code based on types. Most of the time,
AIUI many PdfVariant methods are doing just that: checking whether a
downcast, that is, to a more specific type, i.e. subtype, is safe, by
using a enum field in a struct, then if it isn't, throw an exception,
otherwise doing the cast.

> C/C++ developer are perfectly aware of the safeness of the casts they
> are doing, and they do C style casts or C++ static casts, getting a
> performance advantage over doing dynamic_cast everywhere. Since C/C++
> are languages where developers are supposed to be more aware of the
> consequences of their choices, I would rather prefer keeping C/C++
> static casts instead of blindly convert of all them to dynamic_cast.
I found a stackoverflow.com answer (very highly upvoted) [1] where it
says static_cast can be used "as long as it doesn't cast through virtual
inheritance", so I have to check if PdfVariant uses that.
> There are a lot of other places where I would invest time in improving
> the code, such as 32/64 bits API determinism (this was discussed
> today) or optimizations (removing double lookups from dictionaries).
Agreed.

Best regards, mabri

[1] 
https://stackoverflow.com/questions/332030/when-should-static-cast-dynamic-cast-and-reinterpret-cast-be-used

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH 06/13] PdfAnnotation: Removed duplicated set rect on constructor

[Matthew Brincke]

Hello Francesco, hello all,
> On 22 February 2018 at 12:20 Francesco Pretto  wrote:
> 
> 
> ---
>   src/doc/PdfAnnotation.cpp | 4 
>   1 file changed, 4 deletions(-)
> 
> diff --git a/src/doc/PdfAnnotation.cpp b/src/doc/PdfAnnotation.cpp
> index a02f05d..f95e82c 100644
> --- a/src/doc/PdfAnnotation.cpp
> +++ b/src/doc/PdfAnnotation.cpp
> @@ -92,10 +92,6 @@ PdfAnnotation::PdfAnnotation( PdfPage* pPage, 
> EPdfAnnotation eAnnot, const PdfRe
>   PODOFO_RAISE_ERROR( ePdfError_InvalidHandle );
>   }
>   
> -rRect.ToVariant( rect );
> -
> -this->GetObject()->GetDictionary().AddKey( PdfName::KeyRect, rect );
> -
>   rRect.ToVariant( rect );
>   date.ToString( sDate );
>   
> -- 
> 2.16.1.windows.1
> 

this patch looks good, builds without warnings (Debian sid chroot, GCC 7.3)
and tests out OK with test/unit/podofo-test (no specific test in it ;-(
only in ElementTest there are some similarly-named tests). Therefore:
Thanks for the patch, I accepted and committed it in svn r1894:
https://sourceforge.net/p/podofo/code/1894/

Further patch reviewing/testing will be done by me tomorrow, I need (some
more) sleep very soon.

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH 05/13] PdfPagesTree::InsertPage: Fix "atIndex" is really a 0-based index

[Matthew Brincke]

Hello Francesco, hello all,
> On 23 February 2018 at 01:05 Francesco Pretto <cez...@gmail.com> wrote:
> 
> 
> On 23 February 2018 at 00:13, Matthew Brincke <ma...@mailbox.org> wrote:
> > where did it crash? What kind of crash was it, please? I've looked in
> > the source code and couldn't find a reason for a crash, the index -1
> > for InsertPage(int, PdfPage*) just means "insert before the first page".
> >
> 
> Inserting page with index 0 in an empty document will crash. Following
ah, I see, I think I've found it: Do you mean that the GetKey() call in
src/doc/PdfPagesTree.cpp line 620 throws then? I'll fix that probably on
the coming weekend or before (if you haven't by then, I mean, if your
solution will be correct, I'll commit it, maybe with some doc clarifying).

> common zero based index convention, the following code should work,
> page count should be 3, and internal order of the pages should be
> page2, page1, page3.
> 
> PdfMemDocument document;
> PdfRect rect;
> auto page1 = document.InsertPage(rect, 0);
> auto page2  = document.InsertPage(rect, 0);
> auto page3 = document.InsertPage(rect, 2);
> int count = document.GetPageCount();
> 
> Having said this, my patch has **indeed** problems and doesn't really
> work in the previous example. I didn't quite get how it works the
> internal collection of pages. I will look at it tomorrow.
Ah, thanks. I'm looking forward to your next suggestion.
> 
> > - insertion before the first page through this wouldn't be possible [...]
> > - insertion after the last one wouldn't work either [...]
> 
> I don't understand if you disagree with the zero based index API or
> you just say that my patch doesn't work as intended (which is true).
> Inserting before the first page is inserting at zero. Inserting after
> last one is inserting at number of pages. Negative and out of range
> indices can still be supported by clamping (in other notable APIs they
> are usually treated as errors).

I didn't/don't want to change this API (including the special meaning of
the index -1, I don't really understand why there are more negative ones).
So it's currently "-1"-based as I see it, so my answer is "both".
I'm not sure whether clamping is the best idea, though ...

Best regards, mabri

P.S. I wish you a sound sleep this night if you're located in Europe ;-).

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH 03/13] PdfPainter: Removed unneed cast

[Matthew Brincke]

Hello Francesco, hello all,

> On 22 February 2018 at 12:20 Francesco Pretto  wrote:
> 
> 
> PdfImage is a PdfXObject
> ---
>   src/doc/PdfPainter.cpp | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/doc/PdfPainter.cpp b/src/doc/PdfPainter.cpp
> index 03a5d05..fc5c0de 100644
> --- a/src/doc/PdfPainter.cpp
> +++ b/src/doc/PdfPainter.cpp
> @@ -1320,7 +1320,7 @@ void PdfPainter::DrawGlyph( PdfMemDocument* pDocument, 
> double dX, double dY, con
>   
>   void PdfPainter::DrawImage( double dX, double dY, PdfImage* pObject, double 
> dScaleX, double dScaleY )
>   {
> -this->DrawXObject( dX, dY, reinterpret_cast(pObject),
> +this->DrawXObject( dX, dY, pObject,
>  dScaleX * pObject->GetPageSize().GetWidth(),
>  dScaleY * pObject->GetPageSize().GetHeight() );
>   }
> -- 
> 2.16.1.windows.1

I see it the same, even doubt the cast is correct, so:
Thanks for the patch, I've committed it in svn r1893: 
https://sourceforge.net/p/podofo/code/1893/

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH 05/13] PdfPagesTree::InsertPage: Fix "atIndex" is really a 0-based index

[Matthew Brincke]

Hello Francesco, hello all,
> On 22 February 2018 at 12:20 Francesco Pretto  wrote:
> 
> 
> This is also specified in the API documentation. Without the fix
> there was a crash trying to insert page at index 0

where did it crash? What kind of crash was it, please? I've looked in
the source code and couldn't find a reason for a crash, the index -1
for InsertPage(int, PdfPage*) just means "insert before the first page".

> ---
>   src/doc/PdfPagesTree.cpp | 8 
>   1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/src/doc/PdfPagesTree.cpp b/src/doc/PdfPagesTree.cpp
> index 2ee8ea2..9d851d3 100644
> --- a/src/doc/PdfPagesTree.cpp
> +++ b/src/doc/PdfPagesTree.cpp
> @@ -247,11 +247,11 @@ PdfPage* PdfPagesTree::InsertPage( const PdfRect & 
> rSize, int atIndex)
>   {
>   PdfPage* pPage = new PdfPage( rSize, GetRoot()->GetOwner() );
>   
> -  if (atIndex < 0 || atIndex >= this->GetTotalNumberOfPages()) {
> -  atIndex = this->GetTotalNumberOfPages() - 1;
> -  }
> + if (atIndex < 0 || atIndex > this->GetTotalNumberOfPages()) {
> +  atIndex = this->GetTotalNumberOfPages();
> + }
>   
> -  InsertPage( atIndex - 1, pPage );
> + InsertPage(atIndex, pPage );
>   m_cache.AddPageObject( atIndex, pPage );
>   
>   return pPage;
I'm sorry, I can't really recommend this your patch for acceptance and
wouldn't commit it myself because:
- insertion before the first page through this wouldn't be possible
- insertion after the last one (giving the correct, by its doc comment,
  index this->GetTotalNumberOfPages() wouldn't work either: in the
  method InsertPage(int, PdfObject*) the index is taken as the page index
  after which to insert, which isn't found, messages of critical severity
  are output, no insertion is done, then AddPageObject() can't work either
  (even if it would add, that wouldn't be correct, because the page wasn't
  inserted into the pages tree)
- I'd commit your changed if-clause together with doc-comment clarifying
  (and indentation fixes), acknowledging you gave me the idea

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Watermarks?

[Matthew Brincke]

Hello Olivier, hello all,
On 22 February 2018 at 17:54 Olivier Mascia  wrote:
> 
> 
> Dear all,
> 
> How about watermarking pages?
> Either with text, images or PDF pages?
>
I'm no expert for "watermarking", especially about securing/hardening
against removal of such a watermark (e.g. e-books marked with customer data).

> I mean, take two existing PDF files A and B.
> Update file A, placing content of page B.2 so it displays underneath
> (or over) page A.1 existing content?
> 
> Or given PDF file A, add text or images underneath (or over) page A.2?
Ah, that is meant: If there's any problem doing that with PoDoFo, it's the
latter's bug ;-). Just append the page's stream to the watermark's (what
comes later draws over the preceding content). In case graphics settings
could be changed in a page without reset: call PdfPainter::Save() first
(on an empty page, which has to be set first), then PdfPainter::GetCanvas(),
append the background's content's stream PdfPage::GetContents()->GetStream()
to the former's return object, call PdfPainter::Restore(), then append the
foreground likewise, call PdfPainter::FinishPage() (is automatically called
by SetPage()) and you should be set (sorry, I haven't tested this yet with
a current revision of PoDoFo, so please report any oddities you see).

> 
> Is there any known piece of code (even pseudo code of course or just some
> explanations) which would give pointers on how to achieve this using PoDoFo
> or building it around PoDoFo?

Please see above for an explanation/recipe. I hope this helps you.
> 
> Thanks,
> -- 
> Best Regards, Meilleures salutations, Met vriendelijke groeten,
> Olivier Mascia
> 
Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] BUG: Erase method from PdfOutlineItem sometimes segfaults

[Matthew Brincke]

[grammar fix in quoted text ]
> zyx has written on 28 April 2017 at 21:51:
> 
> 
> On Tue, 2017-04-25 at 00:47 +0200, Matthias Brinke wrote:
> > The patch and the sources for the test programs are attached here.
> 
>  Hi,
Hello zyx, hello Dominik, hello all,

> somewhat scare me. The part about "erase erases in both trees" is not
> the right thing.
> 
I understand that, the patch I've worked on this Sunday hasn't got that
(not attached because I still need some time on this Monday to test it).

> Imagine you want to copy subtree from another document and then free
> that other document, while still having the destination document there
> and making changes in it. This way you get lost the subtree which is
> copied, no? I forgot what we settled with, it's a long time ago. Can

No, with the last (IIRC) old patch the ownership was transferred to the
copy so the subtree could only be erased from the destination document.
Once you suggested only taking outline items without a tree they're in
(implement Copy() and Move() later), in my current patch it's similar,
the item gets stripped of its references (pointers) to other items
after copying but before it's inserted, that way there's no problem
with what Erase() should do (it changes some properties to what it needs,
in debug mode that is asserted, e.g. parent outline being set correctly). 

> there be different use-cases? Maybe not. If you want to copy part of
> the outlines from one document to another, then it should be truly
> copied, complete subtree. If you want to move subtree within the tree,
> then it's also clear what to do. That way Erase() is deterministic,
> erase the node and its subtree.
These tasks should be done by CopySubtree() and MoveSubtree() (or maybe
SetParentOutline() for the latter), I think. They can be implemented
later because I'd like to fix just the crashes with Erase() for now.
Copying is AFAIK possible to implement outside of PoDoFo for the time being. 

> 
> It also didn't fix a warning reported by clang's static analyzer, see
> below.

Now fixed, I hope I tests out well.
> 
> Feel free to correct me. As I said, this issue had been opened quite
> long ago.

See above.

>  Bye,
>  zyx
> 
Best regards, mabri

P. S. I wish you a good sleep, for sure I need one now.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Patch replaced: Wannabe-namespaced internal function converted to private method

[Matthew Brincke]

Hello Dominik,

may I commit the patch to be considered for the release candidate?
Until which time of day will changes/patches be accepted for the
latter? I'd like to provide a fix for the PdfOutlineItem crash also,
and for podofocolor passing through unsupported colours, instead of
throwing an exception and losing info about them from the input.
I'm thankfully looking forward to your answer in time.

Best regards, mabri
 
> Matthew Brincke <ma...@mailbox.org> wrote on 26 January 2018 at 18:08:
> 
> 
> Hello zyx, hello all,
> 
> > zyx <z...@gmx.us> has written on 14 January 2018 at 11:40:
> > 
> > 
> > On Thu, 2018-01-04 at 00:59 +0100, Matthew Brincke wrote:
> > > > the internal function name PODOFO_Base14FontDef_FindBuiltinData
> > > > looks like it should be in a namespace and a class IMHO, therefore
> > > > I've converted it to a private method with access only from
> > > > PdfFontFactory.
> > 
> > Hi,
> > I'm sorry, but what is the idea behind the change, please? If only the
> > above, then, well, from my point of view, it doesn't make much sense. I
> > see that it makes many things more complicated, defines classes inside
> 
> no, that was only my original idea, before I knew how to do it in C++.
> The reasons why I've made it so "complicated" are that IMHO it's important
> to isolate an internal "function" (static method, so "private" applies) as
> much as possible (a tenet of OOP AFAIK) and the C++ syntax rules. I've left
> off PODOFO_LOCAL only because that's (probably by far) not not the only
> location to insert it and that such a change would be advisable later anyway
> (by Mattia Rizzolo [1]).
> 
> > classes (while possible, I do not like it myself), requirement of
> > 'friend' classes, which also kind of points into a bad/suboptimal API
> 
> Without the "friend" declarations I'd have a design with much less isolation:
> One "friend function" declaration was there before, but C++ forbids them for
> private methods, so I would have had to either make the method public (not
> acceptable for me because:
> - that would've added to the API whereas I'd like to keep it internal and
> - I had hoped that it would be easier to get a not-to-API change committed
> - (PODOFO_Base14FontDef_FindBuiltinData isn't in the PoDoFo API, I hope?),
> - I have doubts it should be public because of OOP and its implementation
> - because of these reasons I couldn't get rid of that "friend" declaration)
> 
> or change it to declare the whole class PdfFontFactory a "friend" which
> would be worse because AFAIK the best design with a "friend" is (the) one
> which makes the breach to isolation minimal, that is, (in this case) which
> gives access to the minimum number of methods (one in this case). I didn't
> want to have the new internal class needed for this to be at namespace level
> because I think that is for public API classes only.
> The "friend PdfFontFactory" declaration in there (nested class Builtin) is
> necessary because otherwise the FindMetrics() method would need to be public
> (C++ gives free access from nested to outer class, not the other way around).
> 
> The other nested class is required to avoid giving the (public API?) class
> PdfFontCache access to the internal Base14 font metrics ("needs to know"
> principle). The "friend" declaration there is give access only to the class
> which needs it (PdfFontCache, restricting it to method level would've been
> more complicated still, so much that I ruled it inelegant and avoided it).
> 
> > design, and also:
> > 
> > > > Should someone desire access to any of this info outside PoDoFo,
> > > > some workaround is possible: e.g. create the font, query its
> > > > metrics and check if they can be converted (dynamic_cast) to
> > > > PdfFontMetricsBase14.
> > 
> > which is quite discouraging for me.
> 
> Why is it discouraging for you, please?
> I only think of it as an interim workaround before API will be introduced
> to handle Base14 font metrics better, that is, without giving access (to
> manipulate, even, with PdfFont::GetFontMetrics2(), at least a copy)
> to the internal values. At that time, it should be deprecated IMHO. 
> 
> > 
> > Just my opinion. If the maintainer will wish to commit the change, then
> > I'm not against it, I'm just not in favor of it myself.
> 
> I'd like to discuss a roadmap to API changes with Dominik, project leader,
> anyway, do you mean him? I thank you in advance for a not-put-off answer.
> 
> > Bye,
> > zyx
> &

[Podofo-users] test/unit/podofo-test EncodingTest (assertions fixed, 1 test still fails)

[Matthew Brincke]

Hello all,

after fixing the CPPUNIT_ASSERT_EQUAL and CPPUNIT_ASSERT_EQUAL_MESSAGE
assertions in EncodingTest.cpp in svn r1884 [1], many of which had the
"expected" and "actual" parameters swapped, one test still fails: the
last assertion in EncodingTest::testDifferencesEncoding has "Expected: 0
- Actual: 1" (i.e., the memcmp() there found the first differing byte
in the expected value higher than in the tested buffer returned from
PdfDifferenceEncoding::ConvertToEncoding() [2]). I haven't fixed that
because I'm no expert for PDF string encoding and would like to get
some more contributions into PoDoFo.

Best regards, mabri

[1] http://sourceforge.net/p/podofo/code/1884
[2] http://en.cppreference.com/w/cpp/string/byte/memcmp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] patch for CVE-2017-8054

[Matthew Brincke]

Hello zyx, hello all,

> zyx <z...@gmx.us> has written on 8 February 2018 at 10:32:
> 
> 
> On Thu, 2018-02-08 at 00:13 +0100, Matthew Brincke wrote:
> > If nobody beats me for the time to the commit, it will be fixed
> > again from svn r1882 on: http://sourceforge.net/p/podofo/code/1882
> 
>   Hi,
> future statements like this cause only confusion. Do not do that,
> please. Reference commits only after you really commit them and you
> know the exact commit ID/revision number. This is a distributed system,
> anyone can commit before you. Thanks for your understanding.

yes, I understand that and will heed your advice, I promise. That is, my
change announcements won't contain any info about which revision would
contain them, like this: I'd like to put comments, which CVE id I fixed
last, before the respective source code region and put a CVE id correction
in the first line of the commit message, referring to the erroneous one.

> 
> With respect of the commit itself, it looks fine and works fine here as
> well. I'd do it the same way.

Thank you very much. I'm relieved :-) you see the content's correctness
the same way ... 

>   Thanks and bye,
>   zyx
> 

Best regards, mabri

> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] patch for CVE-2017-8054

[Matthew Brincke]

Hello all,
> Matthew Brincke <ma...@mailbox.org> has written on 8 February 2018 at 00:58:
> 
> 
> Hello zyx, hello all,
> > Matthew Brincke <ma...@mailbox.org> has written on 8 February 2018 at 00:13:
> > 
> > 
> > Hello zyx, hello all,
> > > zyx <z...@gmx.us> has written on 4 February 2018 at 16:10:
> > > 
> > > 
> > > On Fri, 2018-01-26 at 07:34 +0100, zyx wrote:
> > > > I see. It looks like I did something wrong when testing the change.
> > > > When trying once again now I can confirm what you see, the change
> > > > does
> > > > fix the CVE. I do not know what I did wrong the last time, I'm sorry
> > > > about that.
> > > > 
> > > > I committed the patch as revision 1872:
> > > > http://sourceforge.net/p/podofo/code/1872
> > > 
> > >   Hi,
> > > I reverted the main part of the above change, because it causes
> > > use-after-free in test/unit/podofo-test, more details below. I left
> > 
> > In the Debian Bug Tracking System [1] Matthias Brinke contributed a patch
> > which is a correction for the older one, to fix this bug. Of that patch
> > the first hunk is of interest here, the others are either already in,
> > tiny mostly-docs changes or would require discussion.
> > 
> 
> pardon my error, please: it's the second hunk, not the first. It's correct in
> the commit which is indeed svn r1882: 
> http://sourceforge.net/p/podofo/code/1882

please also pardon my (brown paper bag) error in its commit message, the CVE id
meant is not CVE-2017-5084 as written, but of course CVE-2017-8054.
What should I do (after sleeping first, I suppose ;-) )?

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] patch for CVE-2017-8054

[Matthew Brincke]

Hello zyx, hello all,
> Matthew Brincke <ma...@mailbox.org> has written on 8 February 2018 at 00:13:
> 
> 
> Hello zyx, hello all,
> > zyx <z...@gmx.us> has written on 4 February 2018 at 16:10:
> > 
> > 
> > On Fri, 2018-01-26 at 07:34 +0100, zyx wrote:
> > > I see. It looks like I did something wrong when testing the change.
> > > When trying once again now I can confirm what you see, the change
> > > does
> > > fix the CVE. I do not know what I did wrong the last time, I'm sorry
> > > about that.
> > > 
> > > I committed the patch as revision 1872:
> > > http://sourceforge.net/p/podofo/code/1872
> > 
> > Hi,
> > I reverted the main part of the above change, because it causes
> > use-after-free in test/unit/podofo-test, more details below. I left
> 
> In the Debian Bug Tracking System [1] Matthias Brinke contributed a patch
> which is a correction for the older one, to fix this bug. Of that patch
> the first hunk is of interest here, the others are either already in,
> tiny mostly-docs changes or would require discussion.
> 

pardon my error, please: it's the second hunk, not the first. It's correct in
the commit which is indeed svn r1882: http://sourceforge.net/p/podofo/code/1882

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] patch for CVE-2017-8054

[Matthew Brincke]

Hello zyx, hello all,
> zyx  has written on 4 February 2018 at 16:10:
> 
> 
> On Fri, 2018-01-26 at 07:34 +0100, zyx wrote:
> > I see. It looks like I did something wrong when testing the change.
> > When trying once again now I can confirm what you see, the change
> > does
> > fix the CVE. I do not know what I did wrong the last time, I'm sorry
> > about that.
> > 
> > I committed the patch as revision 1872:
> > http://sourceforge.net/p/podofo/code/1872
> 
>   Hi,
> I reverted the main part of the above change, because it causes
> use-after-free in test/unit/podofo-test, more details below. I left

In the Debian Bug Tracking System [1] Matthias Brinke contributed a patch
which is a correction for the older one, to fix this bug. Of that patch
the first hunk is of interest here, the others are either already in,
tiny mostly-docs changes or would require discussion.

I've contacted him to get the test log, checked it (fine), whereas my
reproduction attempt with the old patch only gave "uncaught exception of
unknown type" in the test output for PagesTreeTest::testDeleteAllCustom.
Of course, that's still bad, and I would've written the fix the same.
Disclosure: The patch is from a friend, who I trust. Feel free to revert
if you would've rejected it (the CONTRIBUTIONS.txt in the svn trunk says
you should "announce or discuss" changes, this is my announcement for the
commit of the correction patch).

> most of the (more or less unrelated) changes of the above change also
> due to conflicting changes in the sources which happened meanwhile.

Rather "less", they were needed to make the diagnostic output work
(would otherwise have a use-after-free there also, breaking output for me).

> 
> That means that CVE-2017-8054 is not fixed since revision 1881:
> http://sourceforge.net/p/podofo/code/1881

If nobody beats me for the time to the commit, it will be fixed
again from svn r1882 on: http://sourceforge.net/p/podofo/code/1882

> 
>   Bye,
>   zyx

[typo in quoted text fixed ]
> 
> P.S.: the reported use-after-free was due to rVar holding the array it
> had been freeing inside the operator=(). Info from Address Sanitizer:

Best regards, mabri

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860995#34

> 
> ==9812==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x606000e23ca0 at pc 0x7f53c345914a bp 0x7ffeb1f284c0 sp 0x7ffeb1f284b0
> READ of size 8 at 0x606000e23ca0 thread T0
> #0 0x7f53c3459149 in PoDoFo::PdfVariant::operator=(PoDoFo::PdfVariant
> const&) /src/base/PdfVariant.cpp:346
> #1 0x7f53c37d8c91 in PoDoFo::PdfPagesTree::GetPageNodeFromArray(int,
> PoDoFo::PdfArray const&, std::deque std::allocator >&) /src/doc/PdfPagesTree.cpp:491
> 
... snip ...
> 
> SUMMARY: AddressSanitizer: heap-use-after-free
> /src/base/PdfVariant.cpp:346 in 
> PoDoFo::PdfVariant::operator=(PoDoFo::PdfVariant const&)
> 

P.S. Only the mentioned line 491 needed an insertion compared to what was
reverted, as you'll see from the commit.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] integer overflow in PdfObjectStreamParserObject::ReadObjectsFromStream (src/base/PdfObjectStreamParserObject.cpp)

[Matthew Brincke]

Hello zyx, hello all,

> zyx  has written on 14 January 2018 at 13:34:
> 
> 
> On Thu, 2018-01-11 at 16:59 -0500, Probe Fuzzer wrote:
> > src/base/PdfObjectStreamParserObject.cpp:99:30: runtime error: signed
> > integer overflow: 94 + 9223372036854775807 cannot be represented in
> > type 'long int'
> 
>   Hi,
> the line 99 of that file looks like this:
> 
>   device.Device()->Seek( static_cast(lFirst + lOff) );
> 
> where both lFirst and lOff are 64bit integers, thus it all depends on
> the static_cast and the size of streamoff, whose size may depend on
> large file support being enabled or not. That's not a problem of
> PoDoFo, is it?

no, the problem is that lFirst + lOff may overflow if they're (e.g.)
both more than half the biggest value.

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Next PoDoFo Release 0.9.6

[Matthew Brincke]

[ grammar fix in quoted text ]

Hello Dominik, hello all,

Dominik Seichter <domseich...@googlemail.com> wrote on 27 January 2018, 13:23:
>  
> 
> Hi Matthew et al.,
> 
> 
> On Fri, Jan 26, 2018 at 11:35 PM, Matthew Brincke <ma...@mailbox.org> wrote: 
> 
>> [ Left Dominik in To to help him follow this thread, fixed text typos ] 
>>  
>>  Hello Dominik, hello all, 
>>  
>>> Dominik Seichter via Podofo-users has written on 26 January 2018 at 17:37: 
>>>
>>>
>>> Hi Mattia,
>>>  
>>> Thanks for the good summary! Let me comment on the open issues.
>>>  
>>> Unfixed security issues:
>>  ... snip ... 
>>> 
>>> https://security-tracker.debian.org/tracker/CVE-2017-8053
>>> -> Please see proposed patch in attachment. Can somebody test/review? 
>>> 
>>  
>>  In line 13 of the patch, there are typos, it should be "already visited", 
>>  line 14 doesn't really fit (which object?), and in general, shouldn't 
>>  there be a maximum recursion depth which is checked for, to prevent a 
>>  stack overflow? AFAICS there is no standard function/method to check 
>>  available stack space ;-( ...
>  
> Yes, typos fixed and line 14 removed. Also agreed, that a maximum check
> might be nice. Still, the patch should address the main issue of being
> vulnerable to certain PDF files.

AIUI without a check for a maximum recursion depth files can be crafted,
maximally some MiB large, which cause so deep recursion that the (default)
stack size is exhausted and, therefore, a stack overflow occurs. For that
reason, Dominik, please include the check in your fix for CVE-2017-8053.

>  
> Best regards,
>  Dominik

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Integer Overflow in PdfXRefStreamParserObject::ParseStream

[Matthew Brincke]

Hello zyx, hello all,

> zyx  has written on 14 January 2018 at 11:55:
> 
> 
> On Sat, 2018-01-06 at 09:25 -0500, Probe Fuzzer wrote:
> > we found that on latest version of PoDoFo (RELEASE_0.9.5_rc1),
> 
>   Hi,
> what is the RELEASE_0.9.5_rc1, please? The "rc1" suffix suggests it's a
> "release candidate", while the release itself had been made like a year
> ago, thus it seems you use some pre-release code. Nonetheless, as
that's a tag in the PoDoFo svn repository at sf.net, but the currently
latest is RELEASE_0.9.5, of course (made ca. 4 days less than a year ago).
> 
> > src/src/base/PdfXRefStreamParserObject.cpp:125:64: runtime error:
> > signed integer overflow: 3 + 9223372036854775807 cannot be
> > represented in type 'long int [3]'
> 
> It looks like it had been fixed more than 6 months ago in the
> development version at revision 1851:
> https://sourceforge.net/p/podofo/code/1851
> as part of the fix for CVE-2017-8787.
>

It looks like still CVE-worthy (specifically, CVE-2018-5295) to me in
svn r1875 as signed integer overflow is undefined behaviour (AFAIK
also for 64-bit integer types). This happens for e.g. nW[0] + nW[1] >
std::numeric_limits::max() - nW[2] assuming all nW[] > 0
(first in line 125).
 
>   Thanks and bye,
>   zyx
> 

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Which image encoding does support PoDoFo library?

[Matthew Brincke]

Hello Alexander, hello all,
> Alexander Zaitsev  has written on 27 January 2018 at 16:51:
> 
> 
> Hello,
> 
> Does PoDoFo support JPEG2000/JPEG and Jbig2 encodings?
> 
> 

PoDoFo does only support the JPEG "encoding" (PDF standard: filter) yet.
I don't know if any of the others (JPEG2000, JBIG2) would be added for
version 0.9.6 of which I have the impression that it'll be (mostly?)
a bug-fix release. After that I hope they'll be accepted (open-source
libraries for them exist).

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Next PoDoFo Release 0.9.6

[Matthew Brincke]

[ Left Dominik in To to help him follow this thread, fixed text typos ]

Hello Dominik, hello all,

> Dominik Seichter via Podofo-users has written on 26 January 2018 at 17:37: 
>  
> 
> Hi Mattia,
>  
> Thanks for the good summary! Let me comment on the open issues.
>  
> Unfixed security issues: 
... snip ...
> 
> https://security-tracker.debian.org/tracker/CVE-2017-8053
> -> Please see proposed patch in attachment. Can somebody test/review?
> 

In line 13 of the patch, there are typos, it should be "already visited",
line 14 doesn't really fit (which object?), and in general, shouldn't
there be a maximum recursion depth which is checked for, to prevent a
stack overflow? AFAICS there is no standard function/method to check
available stack space ;-( ...

> https://security-tracker.debian.org/tracker/CVE-2017-8054
> -> This was fixed by zyx in revision: 1872. I have a test PDF
>for this and cannot reproduce this issue anymore.

The fix was provided by Matthias Brinke 
(stands for "PoDoFo security contributor", I'm a friend of his) on the
Debian Bug Tracking System: https://bugs.debian.org/860995

>  
> Plus this one without CVE that was reported in this ML:  
> https://blogs.gentoo.org/ago/2017/02/01/podofo-null-pointer-dereference-in-pdfinfoguessformat-pdfinfo-cpp/

This is *not* fixed yet. I also don't understand why it didn't get
a CVE entry.

> (CVE-2017-8054 had a tentative patch)
> -> Seems same as above and seems fixed.

The CVE, yes, contrary to the other one without a CVE entry.
 
>  
> A threading problem: 
>  https://sourceforge.net/p/podofo/mailman/message/35915862/
> -> There is no need to make the matrix for XObjects static, so I made
>it a normal member. Same for s_procset in PdfCanvas. So should be
>fixed with my last commit.

As you said in your next e-mail to the ML the double-checked locking pattern
isn't fixed yet: https://sourceforge.net/p/podofo/mailman/message/36205920/

>  
> A copyright issue: 
>  https://sourceforge.net/p/podofo/mailman/message/35633858/
> -> We still do not have a fix for this.
>

I recommend libunistring2 to fix it, but haven't used it yet.
  
> Regarding bug tracker: Yes, a bug tracker would be nice. But I can barely
> follow the mailing list, so I do not feel I able to setup and maintain a
> bug tracker. If somebody volunteers, I would not object. 
> BTW: Just found this on Sourceforge: 
> https://sourceforge.net/p/podofo/bugs/?source=navbar 
> Anybody has experience with this? Shall we just use this feature?
> 

Peter Linnell has said something like that, yes (2.5 months ago on this ML):
https://sourceforge.net/p/podofo/mailman/message/36112914/

> 
> Best regards,
>  Dominik
> 

Best regards, mabri
 
> On Mon, Jan 22, 2018 at 7:25 PM, Mattia Rizzolo  wrote: 
> 
> > [ explicitly put Dominik in To, as I'm unsure how much he follows the 
> >  ML himself… ] 
> >  
> >  On Sun, Jan 14, 2018 at 08:48:05PM +0100, Dominik Seichter via 
> > Podofo-users wrote:
> > > The last version of PoDoFo was released almost a year ago on February 2nd
> > > 2017. I have seen many patches on the mailing list and also many commits 
> > > to
> > > SVN over the last year. So, I think it is time for a new PoDoFo release
> > > 0.9.6.
> > >
> > > As there might have been patches, which either Zyx or I have missing, I
> > > would suggest the following release time line.
> >  
> >  In December there was a similar email to this going on, asking about a 
> >  new release.  It was pointed out that there are still known unfixed CVEs 
> >  and other important issues. 
> >  See https://sourceforge.net/p/podofo/mailman/message/36151169/
> >  
... snip ...
> > 
> >  Who knows what more… 
> >  While you are here, would you reconsider opening a bug tracker 
> >  somewhere?  When it was proposed in the past in this ML, nobody was 
> >  against it, but everybody deferred to you iirc. 
> >  
> >  --
> >  regards,
> >                          Mattia Rizzolo
> >  
> >  GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
> >  more about me:  https://mapreri.org                             : :'  :
> >  Launchpad user: https://launchpad.net/~mapreri                  `. `'`
> >  Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
> >

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Patch replaced: Wannabe-namespaced internal function converted to private method

[Matthew Brincke]

Hello zyx, hello all,

> zyx <z...@gmx.us> has written on 14 January 2018 at 11:40:
> 
> 
> On Thu, 2018-01-04 at 00:59 +0100, Matthew Brincke wrote:
> > > the internal function name PODOFO_Base14FontDef_FindBuiltinData
> > > looks like it should be in a namespace and a class IMHO, therefore
> > > I've converted it to a private method with access only from
> > > PdfFontFactory.
> 
>   Hi,
> I'm sorry, but what is the idea behind the change, please? If only the
> above, then, well, from my point of view, it doesn't make much sense. I
> see that it makes many things more complicated, defines classes inside

no, that was only my original idea, before I knew how to do it in C++.
The reasons why I've made it so "complicated" are that IMHO it's important
to isolate an internal "function" (static method, so "private" applies) as
much as possible (a tenet of OOP AFAIK) and the C++ syntax rules. I've left
off PODOFO_LOCAL only because that's (probably by far) not not the only
location to insert it and that such a change would be advisable later anyway
(by Mattia Rizzolo [1]).

> classes (while possible, I do not like it myself), requirement of
> 'friend' classes, which also kind of points into a bad/suboptimal API

Without the "friend" declarations I'd have a design with much less isolation:
One "friend function" declaration was there before, but C++ forbids them for
private methods, so I would have had to either make the method public (not
acceptable for me because:
- that would've added to the API whereas I'd like to keep it internal and
- I had hoped that it would be easier to get a not-to-API change committed
- (PODOFO_Base14FontDef_FindBuiltinData isn't in the PoDoFo API, I hope?),
- I have doubts it should be public because of OOP and its implementation
- because of these reasons I couldn't get rid of that "friend" declaration)

or change it to declare the whole class PdfFontFactory a "friend" which
would be worse because AFAIK the best design with a "friend" is (the) one
which makes the breach to isolation minimal, that is, (in this case) which
gives access to the minimum number of methods (one in this case). I didn't
want to have the new internal class needed for this to be at namespace level
because I think that is for public API classes only.
The "friend PdfFontFactory" declaration in there (nested class Builtin) is
necessary because otherwise the FindMetrics() method would need to be public
(C++ gives free access from nested to outer class, not the other way around).

The other nested class is required to avoid giving the (public API?) class
PdfFontCache access to the internal Base14 font metrics ("needs to know"
principle). The "friend" declaration there is give access only to the class
which needs it (PdfFontCache, restricting it to method level would've been
more complicated still, so much that I ruled it inelegant and avoided it).

> design, and also:
> 
> > > Should someone desire access to any of this info outside PoDoFo,
> > > some workaround is possible: e.g. create the font, query its
> > > metrics and check if they can be converted (dynamic_cast) to
> > > PdfFontMetricsBase14.
> 
> which is quite discouraging for me.

Why is it discouraging for you, please?
I only think of it as an interim workaround before API will be introduced
to handle Base14 font metrics better, that is, without giving access (to
manipulate, even, with PdfFont::GetFontMetrics2(), at least a copy)
to the internal values. At that time, it should be deprecated IMHO. 

> 
> Just my opinion. If the maintainer will wish to commit the change, then
> I'm not against it, I'm just not in favor of it myself.

I'd like to discuss a roadmap to API changes with Dominik, project leader,
anyway, do you mean him? I thank you in advance for a not-put-off answer.

>   Bye,
>   zyx
> 

Best regards, mabri

[1] https://sourceforge.net/p/podofo/mailman/message/36112580/ (last sentence)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] patch for CVE-2017-8054

[Matthew Brincke]

Hello zyx, hello Mattia, hello all,

> zyx  has written on 14 January 2018 at 11:23:
> 
> 
> On Wed, 2017-12-27 at 09:16 +0100, Mattia Rizzolo wrote:
> > Somebody attached to the Debian bug http://bugs.debian.org/860995 a
> > patch for CVE-2017-8054.
> 
>   Hi,
> thanks for the patch (and its forward). I gave it a try, but it doesn't
> work, not for the PoC referenced from
> https://security-tracker.debian.org/tracker/CVE-2017-8054
> 
> The code still crashes, even with the patch applied.

I finally got around to reproduce it (in a sandbox because of the strict
security policy I'm under on "my" computer) because I'd also like this
CVE fixed, the same as the patch submitter, and the results are:

- it isn't a "crash" (segfault, abort by SIGABRT or similar) but a PdfError
  thrown with error code ePdfError_InvalidDataType (tested with podofogc)
- the file PoC linked on that security-tracker page isn't a PoC (Proof of
  Concept) for the CVE-2017-8054 because the exception happens earlier
  than the CVE location in PdfPagesTree::GetPageNodeFromArray() is reached
- the one "manipulation"/"fuzzing" in the file PoC linked there/I tested
  with which causes the exception is an invalid name as dictionary key
  in 32 0 obj (as a C string "/Le\x80\x00th" instead of valid "/Length",
  no exception with the latter, output written, I've made no other changes)

@zyx: If the "crash" you mean is something else please speak up.
Otherwise please accept (or test with a real PoC for this CVE) the patch,
I'd really like to see it in svn r1872 (if it didn't consist of two logical
changes, so it should be in two commits, if you see that also, then please
put off committing it, but give the green light to Mattia first, please).
  
> 
>   Bye,
>   zyx
> 

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Parse error on Chromium generated PDFs

[Matthew Brincke]

Hello zyx, hello all,

> zyx  has written on 14 January 2018 at 15:42:
> 
> 
> On Wed, 2017-12-06 at 18:34 +0100, le...@free.fr wrote:
> > After some digging, Chromium / Skia do not store annotations as
> > references, but directly as dictionnary under /Annots.
> > Here is a simple patch which solves it but incorrect : the allocated
> > PdfObject is not deleted afterwards.
> 
>   Hi,
> thanks for the notice and the patch. You are right it is not complete,
> the pAnnot is also leaking and couple more issues had been there.
> I extended your change in revision 1867:
> https://sourceforge.net/p/podofo/code/1867

in that revision in src/doc/PdfPage.cpp:380 (i.e. line 380) there is
a typo: it should be pItem instead of pObj (as in line 384 the index
pItem is used for storing, so it should be used for querying also).
The object pObj is an array, you didn't want that as a map key, right?

An issue is also that you replaced the construct (*iterator).member
by iterator->member which is AFAIK non-standard, so (possibly at least)
non-portable. This is because iterator types don't have to be pointers
and aren't (otherwise) required to have an operator-> but only (see [1])
operator*() const for dereferencing the iterator. So please change it
back or please give me a technical reason why that isn't practical
for you.

> 
>   Bye,
>   zyx
> 

[1] http://en.cppreference.com/w/cpp/concept/Iterator
Example implementation in http://en.cppreference.com/w/cpp/iterator/iterator

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Fix for the "could avoid useless dependency" Debian build warning

[Matthew Brincke]

Hello all, hello Mattia, hello zyx,

> Mattia Rizzolo has written on 14 January 2018 at 13:34:
> 
> 
> On Sun, Jan 14, 2018 at 01:18:58PM +0100, zyx wrote:
> > could you provide the exact warning you are referring to and in which
> > stage (some context) it had been written, please? I do not see/did not
> > notice any such warning on Fedora (maybe I overlooked it, or I do not
... snip ...
> 
> It's actually a message not coming from the podofo build system, but
> from dpkg-shlibdeps, i.e. the program that during a package build
> inspects all the ELF binaries to detect what libraries they are linked
> to and generate the list of dependencies.
... snip ...
> 
> This is caused by overlinking, and e.g. using -Wl,--as-needed avoids it
> (but better taking care of it like this patch is trying to do).
> 
> > While the change itself looks fine, I wasn't able to build PoDoFo on
> > Fedora with it, it failed with this error:
> > 
> >  Scanning dependencies of target podofosign
> >  [ 98%] Building CXX object 
> > tools/podofosign/CMakeFiles/podofosign.dir/podofosign.cpp.o
> >  [ 98%] Linking CXX executable podofosign
> >  CMakeFiles/podofosign.dir/podofosign.cpp.o: In function `main':
> > .../tools/podofosign/podofosign.cpp:879: undefined reference to 
> > `OPENSSL_init_ssl'
> >  collect2: error: ld returned 1 exit status
> 
> I'll let the OP take care of this error :)

I don't have Fedora, but I've nevertheless thought of some changes
to my patch (the new version is attached) to fix the build error:
Added LIBCRYPTO_LDFLAGS and OPENSSL_LIBRARIES to the podofosign link.
So please test it on your distro (already tested with sbuild's Debian
sid, zyx, please test with your Fedora, I hope it'll work there).
If it works, please first solve the issue my next e-mail will be about
(and commit), then please commit this.

Best regards, mabri

> 
> -- 
> regards,
>  Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540
> more about me: https://mapreri.org
> Launchpad user: https://launchpad.net/~mapreri
> Debian QA page: https://qa.debian.org/developer.php?login=mattia--- libpodofo-0.9.5.orig/CMakeLists.txt
+++ libpodofo-0.9.5/CMakeLists.txt
@@ -509,10 +509,16 @@ IF(FONTCONFIG_FOUND AND WANT_FONTCONFIG)
   INCLUDE_DIRECTORIES(${FONTCONFIG_INCLUDE_DIR})
 ENDIF(FONTCONFIG_FOUND AND WANT_FONTCONFIG)
 
-SET(PODOFO_LIB
-podofo
-${PODOFO_LIB_DEPENDS}
-)
+IF(WIN32 OR PODOFO_BUILD_STATIC)
+  SET(PODOFO_LIB
+  podofo
+  ${PODOFO_LIB_DEPENDS}
+  )
+ELSE(WIN32 OR PODOFO_BUILD_STATIC)
+  SET(PODOFO_LIB podofo
+  ${stlport_libraries_if_use_stlport}
+  )
+ENDIF(WIN32 OR PODOFO_BUILD_STATIC)
 
 #
 # Setup directories we will need
--- libpodofo-0.9.5.orig/tools/podofosign/CMakeLists.txt
+++ libpodofo-0.9.5/tools/podofosign/CMakeLists.txt
@@ -1,7 +1,16 @@
 ADD_EXECUTABLE(podofosign podofosign.cpp)
 
 TARGET_INCLUDE_DIRECTORIES(podofosign PUBLIC ${LIBCRYPTO_INCLUDE_DIR})
-TARGET_LINK_LIBRARIES(podofosign ${PODOFO_LIB})
+
+SET(podofosign_extra_libs
+${LIBCRYPTO_LDFLAGS}
+${LIBCRYPTO_LIBRARIES}
+${OPENSSL_LIBRARIES}
+)
+TARGET_LINK_LIBRARIES(podofosign
+  ${podofosign_extra_libs}
+  ${PODOFO_LIB}
+)
 SET_TARGET_PROPERTIES(podofosign PROPERTIES COMPILE_FLAGS "${PODOFO_CFLAGS}")
 ADD_DEPENDENCIES(podofosign ${PODOFO_DEPEND_TARGET})
 INSTALL(TARGETS podofosign
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] Fix for the "could avoid useless dependency" Debian build warning

[Matthew Brincke]

Hello all,

the patch for that is attached, please accept.
It's made against version 0.9.5, but to parts
of CMakeLists.txt files which haven't been changed
there (& context) since then AFAIK.
I've build-tested with sbuild into an (up-to-date,
minimal except for GNU autotools, maybe that's
needed for the Debian packing tools however)
Debian sid chroot, then tested the programs by
invoking them without parameters, getting their
respective usage message fine, so no problems with
shared-library linking (at load time, but they don't
use later dynamic loading with dlopen() AFAIK).

Best regards, mabri--- libpodofo-0.9.5.orig/CMakeLists.txt
+++ libpodofo-0.9.5/CMakeLists.txt
@@ -509,10 +509,14 @@ IF(FONTCONFIG_FOUND AND WANT_FONTCONFIG)
   INCLUDE_DIRECTORIES(${FONTCONFIG_INCLUDE_DIR})
 ENDIF(FONTCONFIG_FOUND AND WANT_FONTCONFIG)
 
-SET(PODOFO_LIB
-podofo
-${PODOFO_LIB_DEPENDS}
-)
+IF(WIN32 OR PODOFO_BUILD_STATIC)
+  SET(PODOFO_LIB
+  podofo
+  ${PODOFO_LIB_DEPENDS}
+  )
+ELSE(WIN32 OR PODOFO_BUILD_STATIC)
+  SET(PODOFO_LIB podofo)
+ENDIF(WIN32 OR PODOFO_BUILD_STATIC)
 
 #
 # Setup directories we will need
--- libpodofo-0.9.5.orig/tools/podofosign/CMakeLists.txt
+++ libpodofo-0.9.5/tools/podofosign/CMakeLists.txt
@@ -1,7 +1,12 @@
 ADD_EXECUTABLE(podofosign podofosign.cpp)
 
 TARGET_INCLUDE_DIRECTORIES(podofosign PUBLIC ${LIBCRYPTO_INCLUDE_DIR})
-TARGET_LINK_LIBRARIES(podofosign ${PODOFO_LIB})
+
+SET(podofosign_extra_libs ${LIBCRYPTO_LIBRARIES})
+TARGET_LINK_LIBRARIES(podofosign
+  ${PODOFO_LIB}
+  ${podofosign_extra_libs}
+)
 SET_TARGET_PROPERTIES(podofosign PROPERTIES COMPILE_FLAGS "${PODOFO_CFLAGS}")
 ADD_DEPENDENCIES(podofosign ${PODOFO_DEPEND_TARGET})
 INSTALL(TARGETS podofosign
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [no-feature fix] Empty decoded stream of CCITTFaxDecode decoder

[Matthew Brincke]

Hello all,

the attached patch is for changing the behaviour to what an
unsupported filter should do: throw an exception with code
ePdfError_UnsupportedFilter instead of leaving the output
stream empty, and also for cleaning up the code of the filter
for release (e.g. removing all what's #ifdef'd out). After
the release, feel free to revert it, but please accept it
first (after my other patch), before the next release candidate.
The patch is made to the Debian package, but should apply to
trunk as well with just a little offset.
I have (only) build-tested it with sbuild into a Debian sid
(up-to-date) chroot, I couldn't run-test it for lack of a
suitable input file or tool to generate one (netpbm is so
old even in Debian sid) ;-(.

Best regards, mabri

> Matthew Brincke <ma...@mailbox.org> has written on 16 November 2017 at 16:59:
> 
> 
> Hello Luke, hello all,
> 
> > Luke Kennedy <l...@avia-sys.com> has written on 9 August 2017 at 13:10:
> > 
> > Hi all,
> > 
> > As mentioned in further details here 
> > https://stackoverflow.com/questions/45548467/empty-decoded-stream-of-ccittfaxdecode-decoder-using-podofo
> > 
> > … we’ve hit an issue with CCITTFaxDecode for raster extraction.
> > 
> > The stream is correctly extracted from the PDF file however the call
> > to GetFilteredCopy() does not appear to have applied the CCITTFaxDecode 
> > filter
> > and returns length of zero:
> > 
> > Is this a known issue?
> >
> 
> in a way, yes (and sorry for answering at least ;-) a quarter too late), the
> filter is unimplemented, the only code doing anything is in a #ifdef checking
> for DS_CCITT_DEVELOPMENT_CODE (DS is AFAICS standing for Dominik Seichter, the
> project leader). The encoding side throws ePdfError_UnsupportedFilter.
>   
> > Thanks,
> > 
> > Luke
> 
> Best regards, mabri
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users--- libpodofo-0.9.5.orig/src/base/PdfFiltersPrivate.cpp
+++ libpodofo-0.9.5/src/base/PdfFiltersPrivate.cpp
@@ -1149,53 +1149,6 @@ jpeg_memory_src (j_decompress_ptr cinfo,
 
 #endif // PODOFO_HAVE_JPEG_LIB
 
-#ifdef PODOFO_HAVE_TIFF_LIB
-
-#ifdef DS_CCITT_DEVELOPMENT_CODE
-// ---
-// 
-// ---
-static tsize_t dummy_read(thandle_t, tdata_t, tsize_t)
-{
-return 0;
-}
-
-// ---
-// 
-// ---
-static tsize_t dummy_write(thandle_t, tdata_t, tsize_t size)
-{
-return size;
-}
-
-// ---
-// 
-// ---
-static toff_t dummy_seek(thandle_t, toff_t, int)
-{
-
-}
-
-// ---
-// 
-// ---
-static int dummy_close(thandle_t)
-{
-
-}
-
-// ---
-// 
-// ---
-static toff_t dummy_size(thandle_t)
-{
-
-}
-#endif
-
-// ---
-// Actual filter code below
-// ---
 PdfCCITTFilter::PdfCCITTFilter()
 : m_tiff( NULL )
 {
@@ -1220,80 +1173,19 @@ void PdfCCITTFilter::EndEncodeImpl()
 PODOFO_RAISE_ERROR( ePdfError_UnsupportedFilter );
 }
 
-#ifndef _MSC_VER
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wunused-parameter"
-#endif
-void PdfCCITTFilter::BeginDecodeImpl( const PdfDictionary* pDict )
-{ 
-#ifdef DS_CCITT_DEVELOPMENT_CODE
-
-if( !pDict )
-{
-PODOFO_RAISE_ERROR_INFO( ePdfError_InvalidHandle, "PdfCCITTFilter required a DecodeParms dictionary" );
-} 
-
-m_tiff = TIFFClientOpen("podofo", "w", reinterpret_cast(-1),
-dummy_read, dummy_write,
-dummy_seek, dummy_close, dummy_size, NULL, NULL);
-
-if( !m_tiff ) 
-{
-PODOFO_RAISE_ERROR_INFO( ePdfError_InvalidHandle, "TIFFClientOpen failed" );
-}
-
-m_tiff->tif_mode = O_RDONLY;
-
-TIFFSetField(m_tiff, TIFFTAG_IMAGEWIDTH,  pDict->GetKeyAsLong( PdfName("Columns"), 1728 )->GetNumber() );
-TIFFSetField(m_tiff, TIFFTAG_SAMPLESPERPIXEL, 1);
-TIFFSetField(m_tiff, TIFFTAG_BITSPERSAMPLE,   1);
-TIFFSetField(m_tiff, TIFFTAG_FILLORDER,

[Podofo-users] Wannabe-namespaced internal function converted to private method

[Matthew Brincke]

Hello all,

the internal function name PODOFO_Base14FontDef_FindBuiltinData looks
like it should be in a namespace and a class IMHO, therefore I've
converted it to a private method with access only from PdfFontFactory.
I've also implemented a wrapper method IsBase14Font() to give the
class PdfFontCache access on a need-to-know basis (that is, a boolean
return value instead of a pointer to, possibly even writable, metrics).
Should someone desire access to any of this info outside PoDoFo, some
workaround is possible: e.g. create the font, query its metrics and
check if they can be converted (dynamic_cast) to PdfFontMetricsBase14.

The only not backward-compatible change (by Debian Policy 4.1.2 clause
8.6.2 Shared library ABI changes) is IIUC the removal of the function
named above, which really is internal, right?
I build-tested the change with Debian sbuild into a Debian sid chroot.
No new warnings were produced (build log available on request, not
attached because it's > 100KiB large).
So please (@committers) accept this change, which is attached as a
diff -up format patch to this e-mail (applies the same to 0.9.5 and the
trunk) before the next (candidate) release.

Best regards, mabridiff -rup libpodofo-0.9.5.orig/src/doc/PdfFontCache.cpp libpodofo-0.9.5/src/doc/PdfFontCache.cpp
--- libpodofo-0.9.5.orig/src/doc/PdfFontCache.cpp
+++ libpodofo-0.9.5/src/doc/PdfFontCache.cpp
@@ -396,7 +396,7 @@ PdfFont* PdfFontCache::GetFont( const ch
 if( it.first == it.second )
 {
 if ( (eFontCreationFlags & eFontCreationFlags_AutoSelectBase14) 
- && PODOFO_Base14FontDef_FindBuiltinData(pszFontName) )
+ && PdfFontFactory::FontTypes::IsBase14Font(pszFontName) )
 {
 EPdfFontFlags eFlags = ePdfFont_Normal;
 if( bBold )
diff -rup libpodofo-0.9.5.orig/src/doc/PdfFontFactory.cpp libpodofo-0.9.5/src/doc/PdfFontFactory.cpp
--- libpodofo-0.9.5.orig/src/doc/PdfFontFactory.cpp
+++ libpodofo-0.9.5/src/doc/PdfFontFactory.cpp
@@ -241,7 +241,8 @@ PdfFont* PdfFontFactory::CreateFont( FT_
PdfObject* pBaseFont = NULL;
pBaseFont = pObject->GetIndirectKey( "BaseFont" );
const char* pszBaseFontName = pBaseFont->GetName().GetName().c_str();
-   PdfFontMetricsBase14* pMetrics = PODOFO_Base14FontDef_FindBuiltinData(pszBaseFontName);
+   PdfFontMetricsBase14* pMetrics = dynamic_cast
+  ( Builtin::FindMetrics(pszBaseFontName) );
if ( pMetrics != NULL )
{
// pEncoding may be undefined, found a valid pdf with
@@ -348,9 +349,13 @@ EPdfFontType PdfFontFactory::GetFontType
 return eFontType;
 }
 
+bool PdfFontFactory::FontTypes::IsBase14Font(const char * pszFontName)
+{
+return Builtin::FindMetrics(pszFontName);
+}
 
-PdfFontMetricsBase14*
-PODOFO_Base14FontDef_FindBuiltinData(const char  *font_name)
+PdfFontMetrics*
+PdfFontFactory::Builtin::FindMetrics(const char *font_name)
 {
 unsigned int i = 0;
 	bool found = false;
@@ -371,8 +376,9 @@ PdfFont *PdfFontFactory::CreateBase14Fon
 EPdfFontFlags eFlags, const PdfEncoding * const pEncoding,
 PdfVecObjects *pParent)
 {
-PdfFont *pFont = new PdfFontType1Base14(
-PODOFO_Base14FontDef_FindBuiltinData(pszFontName), pEncoding, pParent);
+PdfFont *pFont = new PdfFontType1Base14(dynamic_cast
+( Builtin::FindMetrics(pszFontName) ),
+pEncoding, pParent );
 if (pFont) {
 pFont->SetBold( eFlags & ePdfFont_Bold ? true : false );
 pFont->SetItalic( eFlags & ePdfFont_Italic ? true : false );
diff -rup libpodofo-0.9.5.orig/src/doc/PdfFontFactory.h libpodofo-0.9.5/src/doc/PdfFontFactory.h
--- libpodofo-0.9.5.orig/src/doc/PdfFontFactory.h
+++ libpodofo-0.9.5/src/doc/PdfFontFactory.h
@@ -104,6 +104,25 @@ class PODOFO_DOC_API PdfFontFactory {
  */
 static EPdfFontType GetFontType( const char* pszFilename );
 
+/** Nested class to restrict access for the font cache to the necessary.
+ */
+class FontTypes {
+  private:
+friend class PdfFontCache;
+static bool IsBase14Font(const char * pszFontName);
+FontTypes(); // prohibit instatiation
+};
+
+/** Nested class to restrict access to PdfFontMetricsBase14's private
+ *  members to the former's method.
+ */
+class Builtin {
+  private:
+friend class PdfFontFactory;
+static PdfFontMetrics* FindMetrics(const char *font_name);
+Builtin(); // prohibit instatiation
+};
+
  private:
 // prohibit instantiation of all-methods-static factory from outside 
 PdfFontFactory();
diff -rup libpodofo-0.9.5.orig/src/doc/PdfFontMetricsBase14.h libpodofo-0.9.5/src/doc/PdfFontMetricsBase14.h
--- libpodofo-0.9.5.orig/src/doc/PdfFontMetricsBase14.h
+++ libpodofo-0.9.5/src/doc/PdfFontMetricsBase14.h
@@ -39,6 +39,7 @@
 

Re: [Podofo-users] How to extract embedded file from pdf

[Matthew Brincke]

Hello all,

I'm forwarding this e-mail exchange for the list's and the public's
benefit. It began with a response to the e-mail I'm replying to here.
I'm sorry to do this only now as I originally tried it (hopefully
only less than a minute) too late to be archived in December 2017,
but with a typo in the address: podofo-users AT list.sourceforge.net

Best regards, mabri

-- Original message --
From: David Swank <dsw...@tslusa.biz>
To: Matthew Brincke <ma...@mailbox.org>
Date: Sat, 30 Dec 2017 07:19:17 -0500
Subject: Re: [Podofo-users] How to extract embedded file from pdf

Setting -DPODOFO_BUILD_SHARED:BOOL=TRUE did the trick with r1863
Thank You very much.


On 12/29/2017 6:37 PM, Matthew Brincke wrote:
> Hallo David Swank,
>
>> David Swank <dsw...@tslusa.biz> has written on 29 December 2017 at 20:30:
>>
>>
>> Thanks for the reply,  but I still have the same issue.
>> On building podofo from current trunk r1863, I did get warning during
>> build.  And only got a libpodofo.a  No .dll or dll.a.
>> then rebuilt r1810 with no warnings an did get all 3 src\ files. with
>> the result is the same as before.
>>
> so you didn't test with svn r1863 (please see below for .dll building,
> the .a file is a static library in GCC format, maybe you could use it)?
> The regression was introduced in svn r1810 (so r1809 was the last "good"
> one before it), fixed in svn 1825, the next revision removes forcing
> the build to the C++98 standard, i.e. the compiler default is used then.
>
> Warning: this can change the ABI too: If you build your project using a
> newer standard (e.g. C++11) please only use PoDoFo from svn r1826 on
> because older ones can be ABI-incompatible because of this alone.
>
> In svn r1815 a change was made which (should have) changed build to
> default to building a shared library (.dll file) on Win32, to explicitly
> specify that (are you building for or on 64-bit Windows?) give the
> option -DPODOFO_BUILD_SHARED:BOOL=TRUE to cmake (as first option).
>
> The warnings (I'm guessing here, as I don't have your environment and so
> can't reproduce them) should be mostly harmless, so please either ignore
> them, use one of the revisions I gave above (which shouldn't have added
> any), or copy them as text with line-breaks preserved into your reply
> (especially if building one of the older revisions, so I can help you
> better, I hope). In any case, do specify the revision you used, any other
> options to cmake, relevant environment variables, whether you used the
> mingw-w64 environment, and its exact version (I couldn't find "7.2.0",
> only as GCC version), also for the (original) MinGW if you use that.
> Please do report your results, also if you succeeded (please spare me
> from fearing you failed without reporting).
> Please also mention if the e-mail is indeed confidential, or if you
> explicitly (are allowed to, and) lift that restriction from the footer.
> Then I'd remove the footer and forward to the mailing list (please
> don't do that yourself just yet).
>   
> Best regards, Matthew

> Matthew Brincke <ma...@mailbox.org> has written on 29 December 2017 at 01:00:
> 
> 
> Hello David, hello all,
> 
> > David Swank <dsw...@tslusa.biz> has written on 27 Dezember 2017 at 22:47: 
> >  
> >  Environment Msys on Win7.  Qt 5.9.2, MinGw 7.2.0, PoDoFo .0.9.5.0 
> >  I am able to Attach my csv files into a pdf just fine. 
> >  Now I am attempting to retrieve the attachments so that i can parse the 
> > csv file data to be read by some other another pc. 
> >  
> >  I have been playing with a example from 2013 referenced here 
> > https://www.mail-archive.com/podofo-users@lists.sourceforge.net/msg02174.html
> >  
> >  
> >  The code will crash at kidskey->GetArray. 
> >  when stepping through the code i found that kidskey->GetDataTypeString() 
> > returns array but kidskey->IsArray returns false. 
> 
> I'm sorry that your build is affected by it: there is an ABI regression in 
> libpodofo 0.9.5 (from
> svn r1810) so please update to current svn trunk.
> 
> Best regards, mabri
> 
> >  
> >  Any assistance would be appreciated, 
> >  Thank You 
> >  
> > 
> > -- 
> > David

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] How to extract embedded file from pdf

[Matthew Brincke]

Hello David, hello all,

> David Swank  has written on 27 Dezember 2017 at 22:47: 
>  
>  Environment Msys on Win7.  Qt 5.9.2, MinGw 7.2.0, PoDoFo .0.9.5.0 
>  I am able to Attach my csv files into a pdf just fine. 
>  Now I am attempting to retrieve the attachments so that i can parse the csv 
> file data to be read by some other another pc. 
>  
>  I have been playing with a example from 2013 referenced here 
> https://www.mail-archive.com/podofo-users@lists.sourceforge.net/msg02174.html 
>  
>  The code will crash at kidskey->GetArray. 
>  when stepping through the code i found that kidskey->GetDataTypeString() 
> returns array but kidskey->IsArray returns false. 

I'm sorry that your build is affected by it: there is an ABI regression in 
libpodofo 0.9.5 (from
svn r1810) so please update to current svn trunk.

Best regards, mabri

>  
>  Any assistance would be appreciated, 
>  Thank You 
>  
> 
> -- 
> David
> 
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Next release ? Many CVE's

[Matthew Brincke]

Hello Mattia, hello zyx, hello all,
 
> Mattia Rizzolo has written on 8 December 2017 at 17:38:
> 
> 
> On Thu, Dec 07, 2017 at 09:57:46AM -0500, Peter Linnell wrote:
> > As I maintain Podofo for openSUSE, there are now a fair amount of CVE's
> > against Podofo with fixes in trunk. I'm wondering if we could get a
> > release out in the next few weeks ?
> 
> OTOH there are still some CVEs that TTBOMK are still unfixed:
> ... snip ...
> https://security-tracker.debian.org/tracker/CVE-2017-8053
> https://security-tracker.debian.org/tracker/CVE-2017-8054
> ... snip ...

at least for the CVE-2017-8054 a fix was posted on the Debian Bug Tracking
System a few days before Christmas ([1], also linked from above). @zyx:
Although the patch was generated for adding to the Debian package, it
should apply mostly cleanly also to the trunk, could you please give the
OK for it to be included (in the package, the maintainer requested it to be
forwarded here)? For the trunk, I'd like to discuss the error code to be
used because "page not found" seems rather non-specific (for the Debian
package probably the objective is compatibility to the original version's
error codes, so please say OK for that unchanged).
 
> 
> 
> But yes, a release with the already fixed ones would be nice I agree :)
>

IMHO it'd be weird to have a full new release with known security bugs
in it, also copyright [2] (for which I recommend libunistring2) and
threading [3] problems ...
I'd love to be able to help with them (that is, I can try, but no
promises yet). Please let me have a go at them before the release.

Best regards, mabri

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860995#20
[2] https://sourceforge.net/p/podofo/mailman/message/35633858/
[3] https://sourceforge.net/p/podofo/mailman/message/35915862/
 
> -- 
> regards,
>  Mattia Rizzolo
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] MRC compression support

[Matthew Brincke]

Hello all,

> zamazan4ik <zamazan...@tut.by> has written on 19 November 2017 at 02:37:
> 
> 
> Thank you for the brief explanation and for the very useful links.
> 
> I am not so familiar with PoDoFo. But... is it possible to do something 
> similar things as pdfbeams do: create PDF page from set of images 
> (background + foreground + text mask)?
> 

as an aside: it isn't pdfbeams, but pdfbeads which I found (after installing
the development package for Ruby, on Ubuntu ruby-dev, "gem install pdfbeads"
without quotes should work).

On to PoDoFo:
After constructing a PdfImage (e.g. from a PdfDocument), use GetObject() to
get its PdfObject, then GetDictionary().AddKey(PdfName::KeyFilter, filtName)
on that, where filtName is the name of the PDF filter which is suitable for
the image data, e.g. "JBIG2Decode" for JBIG2-encoded bi-level (b) image data
or "DCTDecode" for header-less JPEG image data. As the former is not directly
supported by PoDoFo, it is necessary to load the image data using the method
PdfImage::SetImageDataRaw() so that PoDoFo doesn't try to apply a filter.
Don't call GetFilteredCopy() on the resulting stream then, not even indirectly
as for JBIG2Decode, CCITTFaxDecode and JPXDecode that won't work.
(RunLengthDecode also is untested, maybe it also doesn't work.)

You can then use the PdfImage with the PdfPainter::DrawImage() method (even
though the documentation mentions a PdfXObject, pass PdfImage pointers only).

Best regards, mabri

> 
> 18.11.2017 14:47, Matthew Brincke пишет:
> > Hello all,
> >
> >> zamazan4ik has written on 18 November 2017 at 00:18:
> >>
> >> Hello,
> >>
> >> Has PoDoFo library support for MRC compression? Are there segmentator in
> >> the library? Or maybe are there some stuff for writing different layers
> >> with different compression algorithms?
> >>
> > the PoDoFo library does not support any segmentation of images (at least
> > yet), so no, it does not have MRC support.
> > What is available is that you can have PoDoFo change compression filters
> > on a per-PdfObject basis (however you need to have enough RAM for storing
> > the uncompressed stream). Please note that CCITTFax (de)compression is not
> > implemented yet.
> >
> > I don't know if it's appropriate to write here (sorry), but I've found an
> > (reportedly) open-source solution for MRC compression: pdfbeads, a Ruby gem.
> > See this forum thread: https://forum.diybookscanner.org/viewtopic.php?t=987
> > (title: MRC compression + text under images - DIY Book Scanner)
> > For further info, look in the Wikipedia article on "Mixed Raster Content".
> > Also I found this 
> > https://engineering.purdue.edu/~bouman/software/Text-Seg/tip30.pdf
> > (title: Text Segmentation for MRC Document Compression)
> >   
> >> Thank you.
> >>
> > Best regards, mabri
> >

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] MRC compression support

[Matthew Brincke]

Hello all,

> zamazan4ik has written on 18 November 2017 at 00:18:
> 
> Hello,
> 
> Has PoDoFo library support for MRC compression? Are there segmentator in 
> the library? Or maybe are there some stuff for writing different layers 
> with different compression algorithms?
> 

the PoDoFo library does not support any segmentation of images (at least
yet), so no, it does not have MRC support.
What is available is that you can have PoDoFo change compression filters
on a per-PdfObject basis (however you need to have enough RAM for storing
the uncompressed stream). Please note that CCITTFax (de)compression is not
implemented yet.

I don't know if it's appropriate to write here (sorry), but I've found an
(reportedly) open-source solution for MRC compression: pdfbeads, a Ruby gem.
See this forum thread: https://forum.diybookscanner.org/viewtopic.php?t=987
(title: MRC compression + text under images - DIY Book Scanner)
For further info, look in the Wikipedia article on "Mixed Raster Content".
Also I found this 
https://engineering.purdue.edu/~bouman/software/Text-Seg/tip30.pdf
(title: Text Segmentation for MRC Document Compression)
 
> Thank you.
> 

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Empty decoded stream of CCITTFaxDecode decoder

[Matthew Brincke]

Hello Luke, hello all,

> Luke Kennedy  has written on 9 August 2017 at 13:10:
> 
> Hi all,
> 
> As mentioned in further details here 
> https://stackoverflow.com/questions/45548467/empty-decoded-stream-of-ccittfaxdecode-decoder-using-podofo
> 
> … we’ve hit an issue with CCITTFaxDecode for raster extraction.
> 
> The stream is correctly extracted from the PDF file however the call
> to GetFilteredCopy() does not appear to have applied the CCITTFaxDecode filter
> and returns length of zero:
> 
> Is this a known issue?
>

in a way, yes (and sorry for answering at least ;-) a quarter too late), the
filter is unimplemented, the only code doing anything is in a #ifdef checking
for DS_CCITT_DEVELOPMENT_CODE (DS is AFAICS standing for Dominik Seichter, the
project leader). The encoding side throws ePdfError_UnsupportedFilter.
  
> Thanks,
> 
> Luke

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] podofo-0.9.5 for fedora25

[Matthew Brincke]

Hello Alex, hello all,

> Alex  has written on 13 November 2017 at 01:18:
> 
> 
> Hi, does anyone have a working version of podofo-0.9.5 for fedora25?
> It ships with 0.9.1, and 0.9.5 doesn't easily compile:
> 
> Found cppunit. Unit tests will be built.
> -- Found OpenSSL: /usr/lib64/libssl.so
> CMake Error at CMakeLists.txt:396 (FIND_PACKAGE):
>   By not providing "FindFREETYPE.cmake" in CMAKE_MODULE_PATH this project has
>   asked CMake to find a package configuration file provided by "FREETYPE",
>   but CMake did not find one.
>

because PoDoFo 0.9.5 has FindFREETYPE.cmake in the path cmake/modules/ this has
to be a problem with the CMAKE_MODULE_PATH: what happens when you set it on the
command line (in the top-level dir of podofo-0.9.5, first two commands only 
once):
mkdir build && cd build && cmake -DCMAKE_MODULE_PATH=$(pwd)/cmake/modules ..

> ... snip ... 
> 
> I have freetype and freetype-devel installed:
> freetype-2.6.5-9.fc25.x86_64
> freetype-devel-2.6.5-9.fc25.x86_64
> 
> I've also searched through the CMakeOutput.log and CMakeError.log and
> don't see anything relating to why it would have a problem with
> freetype...

Your installation should be sufficient, yes ...
> 
> Neither the FREETYPEConfig.cmake or freetype-config.cmake exist on my system.
> 
(I hope, AFAIK) they don't need to for PoDoFo.

> Does anyone have any ideas of what can be done to get it working with 
> fedora25?
> 
I don't use Fedora nor have I access to an installed system with it, so this is
all I can do before I read your answer with the (relevant part of the) CMake
output with the command above (I hope I've got it right), to help you.

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] ABI fix for the fix CVE-2017-5852

[Matthew Brincke]

Hello Mattia,

> Mattia Rizzolo has written on 23. Oktober 2017 at 11:10:
> 
> On Sun, Oct 22, 2017 at 05:20:31PM +0200, Matthew Brincke wrote:
> > Debian bug 854600 [2], I wonder why no one answered to the last post ...)
> 
> My fault.
> TBH, I totally forgot of that. I suppose I could have come up with
> simple patch to retain ABI compatibility on my own, but I forgot and I
> haven't than that.

that's likely a typo, what do you mean, please? I see from your Debian
Maintainer Dashboard https://udd.debian.org/dmd/?mattia%40debian.org#todo
that there are many to-do list entries, yet could you please accept my
patch also? Could it be that the original one in the Debian bug report
wasn't accepted for Jessie and later because of the ABI break? With that
cured by my patch, wouldn't it be acceptable together? If not, please
tell why not.

> > I wonder why changing a private method is relevant to ABI at all, and
> > (at least when you're still unconvinced ;-) to accept) would welcome your
> > elucidation (if you have come across any, to date), please ...
> 
> There is a more widespread problem in podofo where all symbols are
> exported and therefore are formally part of the public ABI (even if not
> intended to). Even if I suppose no program within Debian uses those
> symbols (I could check, I haven't), I would not happily break the ABI
> nonetheless.
> 
Thanks for the explanation, there's one aspect I'm still curious about:
I wonder why any C++ compiler, much less g++, would export any private
symbols, as they aren't supposed to be accessible from anywhere (beyond
their class and compilation unit) except for friend classes (can those
reside in a different library/executable?), so maybe they should be
marked PODOFO_LOCAL?

> https://sourceforge.net/p/podofo/mailman/message/35819398/
> (then, the lack of an actual bug tracker makes those request/reports
> very hard to track, and I wouldn't be surprised if many missed it, or
> even if they did completely forgot about it, as many other reports)
> 
I concur, I'd also like a tracker for bug reports/feature requests, the
sf.net one was probably closed because of spam, IIRC. Could maybe the
bug reports be copied there by someone with the permissions for that?

-- 
> regards,
>  Mattia Rizzolo
> 

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] License header missing in some files (was: Re: podofosign compile errors under MSVC)

[Matthew Brincke]

Hi zyx,

> zyx <z...@gmx.us> has written on 23 Oktober 2017 at 10:14:
> 
> 
> On Sun, 2017-10-22 at 17:44 +0200, Matthew Brincke wrote:
> > Can I just send a patch to add the copyright & GNU LGPL license
> > headers (as it's hopefully understood that all the files are licensed
> > the same, if not expressly spec'd otherwise) and have it accepted
> > (w/o test)?
> 
>   Hi,
> yes, it would help. There is not much to test on such change, just that
> it still compiles, thus nothing time consuming.

attached is the patch (the revision numbers there mean when the patched
file was last changed, diff -up in svn format). There are the following
special cases I excluded from the change:
- for src/doc/podofo-doc.rc I don't know the comment formats, can't test
- for src/doc/PdfTilingPattern.{cpp,h} there's a no-exception LGPL given
  so Dominik's permission is (probably, IANAL) required for changing it
- src/base/PdfEncrypt.cpp has RSA Data Security's copyright because: MD5
- src/base/Pdf3rdPtyForwardDecl.h is (I hope, IANAL) trivial enough to
  be excluded from copyright protection (forward decls, simple typedefs,
  some explanation)
- src/base/PdfVersion.h is a trivial renaming of preprocessor definitions
- src/CMakeLists.txt (and all the others) I don't know commenting into

Please test and accept/commit it (separately of course). Text suggested
for the commit message is at the beginning of the patch file (please add
attribution).

>   Thanks and bye,
>   zyx
> 

Best regards, mabriAdd license headers to the files which miss them (& I know how to add them to).

--- src/base/PdfCompilerCompat.h	(revision 1825)
+++ src/base/PdfCompilerCompat.h	(working copy)
@@ -1,3 +1,36 @@
+/***
+ *   Copyright (C) 2005 by Dominik Seichter*
+ *   domseich...@web.de*
+ * *
+ *   This program is free software; you can redistribute it and/or modify  *
+ *   it under the terms of the GNU Library General Public License as   *
+ *   published by the Free Software Foundation; either version 2 of the*
+ *   License, or (at your option) any later version.   *
+ * *
+ *   This program is distributed in the hope that it will be useful,   *
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of*
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the *
+ *   GNU General Public License for more details.  *
+ * *
+ *   You should have received a copy of the GNU Library General Public *
+ *   License along with this program; if not, write to the *
+ *   Free Software Foundation, Inc.,   *
+ *   59 Temple Place - Suite 330, Boston, MA  02111-1307, USA. *
+ * *
+ *   In addition, as a special exception, the copyright holders give   *
+ *   permission to link the code of portions of this program with the  *
+ *   OpenSSL library under certain conditions as described in each *
+ *   individual source file, and distribute linked combinations*
+ *   including the two.*
+ *   You must obey the GNU General Public License in all respects  *
+ *   for all of the code used other than OpenSSL.  If you modify   *
+ *   file(s) with this exception, you may extend this exception to your*
+ *   version of the file(s), but you are not obligated to do so.  If you   *
+ *   do not wish to do so, delete this exception statement from your   *
+ *   version.  If you delete this exception statement from all source  *
+ *   files in the program, then also delete it here.   *
+ ***/
+
 #ifndef _PDF_COMPILERCOMPAT_H
 #define _PDF_COMPILERCOMPAT_H
 
--- src/base/PdfCompilerCompatPrivate.h	(revision 1474)
+++ src/base/PdfCompilerCompatPrivate.h	(working copy)
@@ -1,3 +1,36 @@
+/***
+ *   Copyright (C) 2005 by Dominik Seichter*
+ *   domseich...@web.de*
+ * *
+ *   This program is free software; you can redistribute it and/or modify  *
+ *   it under the terms of the GNU Library General Public License as   *
+ *   published by the Free Software Foundation; either ver

[Podofo-users] License header missing in some files (was: Re: podofosign compile errors under MSVC)

[Matthew Brincke]

Hello all,

> Peter Petrov  has written on 1 March 2017 at 09:29:
> 
> Dear zyx,
> 
> Thank you for your patch!
> 
> Just off-topic, I noticed that this file (src/base/PdfCompilerCompatPrivate.h)
> 
> doesn't contain GNU Library General Public License copyright header.
> 
> Also some other files don't contain it.
>

I wonder what can be done about this? Can I just send a patch to add the
copyright & GNU LGPL license headers (as it's hopefully understood that
all the files are licensed the same, if not expressly spec'd otherwise)
and have it accepted (w/o test)?

> — Best Regards, Peter, PDF3D Support Team

Best regards, mabri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] ABI fix for the fix CVE-2017-5852

[Matthew Brincke]

Hello zyx, hello all,

> zyx has written on 22 October 2017 at 15:34:
> 
> On 21.10.2017 0:59, Matthew Brincke wrote:
> > attached is a patch against trunk r1860 (diff -up in svn format) for
> > fixing the ABI (changing it back to the 0.9.5 state for the method
> > PdfPage::GetInheritedKeyFromObject() after the fix for CVE-2017-5852).
> 
>  Hi,
> thanks for the patch. I'm sorry, but I want to ask: what is the idea 
> behind this change, please? I agree that breaking API/ABI is not ideal, 
> but in case of the PoDoFo project the soname versions are bumped each 
> release, thus the idea of providing two methods instead of one with an 
> overloaded argument value doesn't add much to the library users.

you're welcome, the idea behind the change is to augment the fix for
CVE-2017-5852 in svn r1838 [1] to make it a real security update, in which
changing the ABI is not done (for distributors to cherry-pick, inspired by
Debian bug 854600 [2], I wonder why no one answered to the last post ...)
and to provide a little contribution to ABI stability in the future (sadly,
PODOFO_LOCAL is not, AFAIUI in my research [3][4]: cannot be directly,
supported on Windows). I mean, with this change committed, the stability of
name-lookup-based ABI would be restored for the PoDoFo parts unaffected by
the incremental-signing changes (now general incremental-update :-)) IIRC.

I wonder why changing a private method is relevant to ABI at all, and
(at least when you're still unconvinced ;-) to accept) would welcome your
elucidation (if you have come across any, to date), please ...

>  Thanks and bye,
>  zyx

Best regards, mabri

[1] https://sourceforge.net/p/podofo/code/1838/
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854600
[3] https://msdn.microsoft.com/en-us/library/81h27t8c.aspx
[4] 
https://stackoverflow.com/questions/2810118/how-to-tell-the-mingw-linker-not-to-export-all-symbols

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] ABI fix for the fix CVE-2017-5852

[Matthew Brincke]

Hello all,

attached is a patch against trunk r1860 (diff -up in svn format) for
fixing the ABI (changing it back to the 0.9.5 state for the method
PdfPage::GetInheritedKeyFromObject() after the fix for CVE-2017-5852).
I'm sorry to not have tested it because the security policy of the
system I'm writing this from doesn't allow me to, please be so kind
to test and accept it nevertheless into PoDoFo trunk.

Best regards, mabri--- src/doc/PdfPage.h	(revision 1860)
+++ src/doc/PdfPage.h	(working copy)
@@ -291,7 +291,10 @@ class PODOFO_DOC_API PdfPage : public Pd
 /** Method for getting a key value that could be inherited (such as the boxes, resources, etc.)
  *  \returns PdfObject - the result of the key fetching or NULL
  */
-const PdfObject* GetInheritedKeyFromObject( const char* inKey, const PdfObject* inObject, int depth = 0 ) const;
+const PdfObject* GetInheritedKeyFromObject( const char* inKey, const PdfObject* inObject ) const; // wraps the next one
+
+// this is introduced by the fix for CVE-2017-5852, the depth param counts recursion depth, is checked against a max
+const PdfObject* GetInheritedKeyFromObject( const char* inKey, const PdfObject* inObject, int depth ) const PODOFO_LOCAL;
 
 /** Get the annotations array.
  *  \param bCreate if true the annotations array is created 
--- src/doc/PdfPage.cpp	(revision 1860)
+++ src/doc/PdfPage.cpp	(working copy)
@@ -212,6 +212,11 @@ PdfRect PdfPage::CreateStandardPageSize(
 return rect;
 }
 
+const PdfObject* PdfPage::GetInheritedKeyFromObject( const char* inKey, const PdfObject* inObject ) const
+{
+return GetInheritedKeyFromObject( inKey, inObject, 0);
+}
+
 const PdfObject* PdfPage::GetInheritedKeyFromObject( const char* inKey, const PdfObject* inObject, int depth ) const
 {
 const PdfObject* pObj = NULL;
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Podofocolor error

[Matthew Brincke]

Hello Matt, hello all,

currently on encountering an unsupported color space, the information
about it is discarded, so no output file can be produced in that case.
I don't have time to rectify that currently, sorry.

Best regards, mabri

> Matt S Rinc  has written on 26. Juli 2017 at 02:43:
> 
>   Podofocolor (latest library compiled with no errors on Mac) gives me this 
> error when opening CMYK colorspaced PDF:
> 
> > podofocolor lua ../podofo-0.9.5/tools/podofocolor/example.lua 
> > ff_ff-gs-cmyk-icc.pdf ff_dummy.pdf
> > 
> > Processing page  1...
> >    -> Lua is parsing page:    1
> > Unsupported colorspace name: R11Unknown color space 255 type.
> > Error: An error 45 ocurred during processing the pdf file
> > 
> > PoDoFo encountered an error. Error: 45 ePdfError_CannotConvertColor
> >     Error Description: This color format cannot be converted.
> >     Callstack:
> >     #0 Error Source: 
> > /Users/mattsrinc/Documents/Projekti/Freelancer/MyProjects/Convert Image to 
> > CMYK/podofo-0.9.5/tools/podofocolor/colorchanger.cpp:310
> (it doesn't matter what parameters I call podofocolor with, e.g. grayscale 
> etc)
> 
>   and gives me this error when opening RGB colorspaced PDF:
> 
> > podofocolor lua ../podofo-0.9.5/tools/podofocolor/example.lua ff_ff.pdf 
> > ff_dummy.pdf
> > <>
> > Processing page  1...
> >    -> Lua is parsing page:    1
> > Unsupported colorspace name: PatternUnknown color space 255 type.
> > Error: An error 45 ocurred during processing the pdf file
> > 
> > PoDoFo encountered an error. Error: 45 ePdfError_CannotConvertColor
> >     Error Description: This color format cannot be converted.
> >     Callstack:
> >     #0 Error Source: 
> > /Users/mattsrinc/Documents/Projekti/Freelancer/MyProjects/Convert Image to 
> > CMYK/podofo-0.9.5/tools/podofocolor/colorchanger.cpp:310
> 
>   Any help would be really appreciated. I doubt a C(++) program will rescue 
> me e.g. open a PDF, change colors in it and save it.
> 
> -- 
> 
> Matt Sergej Rinc 
>  Elearning, Video Marketing, Webinars, Presentations & SEO Copywriting. 
>  Prekorje 49, Celje, 3211, SI,
>  [www.prezentacija.si](http://www.prezentacija.si)
>  Hire me on Freelancer (mattsrinc)

> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Signing encrypted pdfs

[Matthew Brincke]

Hello all,

> "F. E."  has written on 1 August 2017 at 15:00:
> 
> Hello dear podofo users,
> 
> I want to sign an already encrypted pdf using podofo, but I don't get it
> to work:
... snip ...
> 3.) Ok, so I thought, maybe I've got to set the security options again
> after loading the pdf. Did that, but when performing the write operation
> for signing, I got a cryptic runtime error (read access violation):
> 
> The error is thrown in 'base\PdfParserObj.cpp', Line 346:
> PdfInputStream* pInput = m_pEncrypt->CreateEncryptionInputStream(  );
> 
> The error states: "this->m_pEncrypt-> was 0xFFDF"
> 
... snip ...
> And now I'm out of ideas. Does anyone have a hint for me?

That very much sounds like a bug that should be fixed. Even if something
nonsensical is tried, a specific PdfError exception should be thrown
with an explanatory string, don't you think? I currently don't have time
for the debugging, sorry.

> 
> Best regards,
> 
> F.E.

Best regards, mabri

> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users