Re: [Podofo-users] PoDoFo SO versioning
Hi Francesco, On Sun, Mar 19, 2023 at 11:26:27PM +0100, Francesco Pretto wrote: > It was reported that SO version changed at each release, which was not > positive for Debian/Ubuntu. Indeed. It was that way because before there was really nobody actually caring about ABI stability, so it would sometimes break sometimes not, but since nobody was actually paying attention it was easier to just change SOVERSION all the time... Which indeed was annoying as a packager. > It has been like that since at least > PoDoFO 0.8.0. I decided to decouple SO version from PoDoFo version, > and decided to arbitrarily set[1] the SO version to 10, to start > afresh with an easy versioning that should be incremented each time > the library becomes ABI incompatible. I would really like to not have > an ABI version in the form x.y.z. Any objection to this move? Any > suggestion? Very well for me. The 10 is very arbitrary indeed, I think you could just go with 1 instead :) > It would be also great for the future to integrate some automation[2], > to check for ABI changes against a previous version, and increment the > SO version in the repository. In Debian, we have tools that verify that the ABI doesn't break, but that's mostly partial, as it only checks function symbols, and as you know the ABI is much more than that. So indeed, some automated testing wouldn't be bad. -- 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 `- signature.asc Description: PGP signature ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo SO versioning
On Mon, Mar 20, 2023 at 07:49:43AM +0100, zyx wrote: > looking into my /usr/lib64/ there are three types of library versioning > here: > > a) no version at all (it's odd, but I really have there some such), >thus there's only a plain .so file These are either broken, or they are the unversioned links used during development/building to find the "most recent" library version, and is not used by built programs for dynamic linking. > b) one-number version - there's only a plain .so.X file > c) two-numbers version - there's a .so.X symlink to a .so.X.Y > d) three-numbers version - there's a .so.X symlink to a .so.X.Y.Z These are all good. There are many reasons to support multiple versions like that, although personally I consider them relics of the past, and confusion-inducing practices. IIRC, that's standard libtool behaviour, so it got cargo-culted by all libtool-using projects. Potentially, if you use more than one number (especially the 2-number variant) you can use that to identify versions that added symbols without removing something else, therefore the ABI was "increased" without breaking. But OTOH that just doesn't really work decently from a program perspective... Sticking with 1 and only 1 number in the SONAME (without links) is really what I recommend these days. > I know there is a document describing why to use the three-numbers > version, together with a description how to work with it and what each > number means. I do not have the link handy, I even do not recall where > it was, probably semver.org ? > I think maybe with libtool or autotools or something like that, > but as I do not recall precisely, it could be anywhere else. The thing > is that I believe it was something official, not a blog of an > enthusiast, thus something one can use as "a source of truth". Mh.. > My question is: why do you want to change it? What is that going to > fix? Is that just a personal reason? As he mentioned, it's a real pain for packagers, and probably also for other users, as it forces all dynamically-linked programs to be rebuilt for every PoDoFo version, even where there is otherwise no ABI change. I understand that for many (young?) people nowadays dynamic linking feels weird, used as they are with golang or rust that has no/shitty dynamic link support, but I honestly consider proper dynamic linking a very good thing myself, that should be properly handled and supported. -- 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 `- signature.asc Description: PGP signature ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] podofo 0.9.8 fails with GCC 12
Hi Wolfgang,
On Sun, Jul 24, 2022 at 04:25:34PM +, Wolfgang Stoeggl via Podofo-users
wrote:
> this is the patch, which is currently used in Fedora
> [1]:https://src.fedoraproject.org/rpms/podofo/raw/rawhide/f/podofo-gcc12.patch
Thank you for the link.
So, effectively fedora is just disabing the failing tests.
Indeed, I just received a proposed similar patch in Debian too:
https://salsa.debian.org/debian/libpodofo/-/merge_requests/2
So nobody has actually investigated the failures and did a real fix?
--
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 `-
signature.asc
Description: PGP signature
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] podofo 0.9.8 fails with GCC 12
Hello people,
It seems that time has come for GCC 12, and it also seems that the
latest 0.9.8 release fails to build with it.
I see that most of the recent effort has been directed towards
podofo-next, but I'd still like podofo "current" to build :D
https://bugs.debian.org/1012987
Does anybody here have any patch floating around for this? :)
--
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 `-
signature.asc
Description: PGP signature
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PoDoFo virtual meeting
On Wed, May 25, 2022 at 11:20:20PM +0200, Francesco Pretto wrote:
> As corrected by Dominik, the meeting is set on June 8th at 10am UTC+2.
Thank you for setting the date!
FWIW, I plan to very silently attend the meeting; don't expect any
interesting input for me, but I figured that since I should be free I'll
lurk in it if you don't mind :)
--
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 `-
signature.asc
Description: PGP signature
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Future ABI stability of PoDoFo
Hi (especially Francesco),
Something that I don't think I've read in the past mails: do you have
any plans regarding ABI stability of PoDoFo?
Currently there is no promise of ABI stability across versions, and as
such the SONAME also changes for each release, even if sometimes it
could have been avoided.
For me this is relevant because for each release the updates needs to be
manually approved by Debian's archive admins due to the changed soname,
which is something I would be happier without :)
--
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 `-
signature.asc
Description: PGP signature
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [PROPOSAL] Relicense PoDoFo to Mozilla Public License 2.0
Hello everybody, I just want to share a few notes. Overall I have no real stakes here, so I don't hold much of an opinion on the proposal. On Sat, Feb 12, 2022 at 07:17:13PM +0100, Francesco Pretto wrote: > I make one > example: let's suppose a Fortune 500 company is now using and > redistributing PoDoFo in a program of theirs, or a shared library: we > all have now the right to ask this company to release the object code > that was generated and linked in the final executables or libraries. > What is the value of having this right in the "real" world? I answer for > my self only: for me the value is less than zero in the case of a Library > such PoDoFo, and exercise this right would sounds more like a > coercitive move attempting to damage/jeopardize the company business. Just as a data point, there is currently a lawsuit running in California against Vizio, Inc. that includes their refusal (by staying silent) to provide said object code linked against LGPL-2.1 libraries. https://sfconservancy.org/copyleft-compliance/vizio.html https://sfconservancy.org/docs/software-freedom-conservancy-v-vizio-complaint-2021-10-19.pdf But yes, honestly I also agree that that particular LGPL provision is useless in real world scenarios, however nice it is when told during an idealistic speech. > I suggest he should name the people that contributed most to PoDoFo > and that should take part in this decision. I'll defer to who better knows Copyright laws and stuff, but from what I concerned, the people that needs contacted are those who actually wrote copyright claims, that for the LGPL parts of PoDoFo (src/* and some tests/*, the rest is GPL-2+) it means: 2000-2016 Dominik Seichter 2008 Craig Ringer Well... since you seems to be taking some care on the licensing and copyright matters, I hope that going forward some more care is put in keeping those headers relevant. That would help a ton in these cases... FTR, the committers (which are not the authors, but SVN doesn't distinguish between authors and committers, and for sure it's not an indication of copyright ownership): 1 ulricharnold001 2 hashimsaleem 2 oleksa 3 mrdocs 4 ceztko 27 pzent 35 pierre_marchand 51 mabri 55 lrosenthol 83 mc-zyx 195 aja_ 269 ringerc 1010 domseichter > I think in many of these cases we can take for granted that posting of > small "trivial" patches into PoDoFo mailing list automatically makes > these patches "public domain". Depending how small, such patches may very well not even be copyrightable, so you can easily get away from those. > Also we should think what do if some people, but not > the majority, disagree with the re-licensing, especially in case of > non-trivial contributors. There is not much to think about. If somebody doesn't agree, that part they own copyright own can't be relicensed, that simple. Your only choices are to either keep those files with the previous license (which would be a legal annoyance), or get rid of those files altogether and reimplement whatever was in it (paying attention to not copy too much from the previous implementation otherwise it becomes a derivative work). Actually, that's the same if somebody doesn't answer. > Currently the license of pdfmm is LGPL 2.1 fixed[5], which it would make > it incompatible to merge new files from pdfmm into PoDoFo I don't think it would. PoDoFo is LGPL-2.0+, if you merge LGPL-2.1 stuff into it, the whole final work becomes LGPL-2.1, and that is not considered a relicensing due to the way the "+" in the LGPL-2.0+ works, afaik. > With one exception (libidn), all the dependencies have permissive (non > coercitive) licenses: > - libidn: LGPL -> FAIL > > I believe at some point we can just take a more permissive stringprep > implementation written in another language/framework and port it to C++. Why is this not a blocker for going forward? Wouldn't linking against libidn make the resulting library effectively be under LGPL too? -- 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 `- signature.asc Description: PGP signature ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Releasing 0.9.7 ?
On Tue, Nov 05, 2019 at 10:56:49PM +0100, Matthew Brincke wrote: > 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. Well, IMHO it's not something to be ashemed of :) Bugs happen all the time to all kind of projects, security issues are just one kind of them. Considering the flow and the rate at which they are being fixed, it just feels to me that some are going to take quite a while more to see a fix. > 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)? I'm not sure what you mean here. Clearly, every time I take a single commit into the packaging that is not part of the base release, that's called "cherry-picking", isn't it? I'm not particularly bothered by the cherry-picking per se, just that at one point it can get tricky to apply patches that are conflicting with each other, plus due to the nature of this project that doesn't consider ABI stability yet we also have to double check that the ABI isn't broken (like it happened a couple of years ago), so it's just somewhat annoying at times. > > 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. Yes, I've seen the posts about r2000. I see we are only a commi away from it ;) In any case, just take this thread of mine as a kind request for a new release, nothing more. I have to take on commits for the debian stable releases anyway, so I'm going to survive either way! No need to hurry or anything. -- 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 `- signature.asc Description: PGP signature ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Releasing 0.9.7 ?
Hello,
I believe it's high time for a new PoDoFo release.
It has been slighly more than one year since the last one was done.
Alright, there are still a few CVEs and other bugs opeened, but many
have been fixed in the same time, and it's getting slighly 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.
Are there any particular blockers for 0.9.7 at this time?
--
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 `-
signature.asc
Description: PGP signature
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Untracked CVE issues now fixed (was: Re: CVE confusion, also in Debian (was: Re: Next PoDoFo Release 0.9.6))
On Sat, Aug 25, 2018 at 12:20:59AM +0200, Matthew Brincke wrote: > 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/ mh, what about CVE-2017-7380 ? To be clear, do you agree that these diffs: - https://sourceforge.net/p/podofo/code/1933 -> CVE-2017-7381 - https://sourceforge.net/p/podofo/code/1936 -> CVE-2017-7382 - https://sourceforge.net/p/podofo/code/1937 -> CVE-2017-7383 are enough to cover the referenced CVEs by themselves (it surely looks so to me reading the description and the diff). > This means also: the Debian security tracker should be updated > (the "fixed versions" there didn't fix it AFAIK). :( BTW, if you wish you could directly provide me diffs against https://salsa.debian.org/security-tracker-team/security-tracker.git (file data/CVE/list), just beware that is a very weird git repository, it's going to melt your CPU. That would potentially save round-trips and misunderstandings :) -- 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 `- signature.asc Description: PGP signature -- 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
On Fri, Aug 03, 2018 at 06:32:47PM +0200, zyx wrote: > On 31.7.2018 at 0:51 Matthew Brincke wrote: > > 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. > > Hi, > okay, that's fine by me. It's just another way to deal with the problem. I'm > not going to change anything then. At any rate, I opened https://sourceforge.net/p/podofo/tickets/28 to decently trank this issue, and I'm going to upload that workaround I mentioned (which is not a decent solution) to debian experimental soon. -- 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 `- signature.asc Description: PGP signature -- 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)
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!). > Nontheless, we should concentrate on fixing CVEs in a follow-up release. If > fixes are ready, I can provide another relase 0.9.7 in short time. 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. > > 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… :( > > (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. -- 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 `- signature.asc Description: PGP signature -- 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)
On Fri, Jun 15, 2018 at 10:47:14AM +0200, Mattia Rizzolo wrote:
> Thanks for all your help, and sorry for the delay in dealing with this.
Now that 0.9.6 is out I took my time and had a look at also the new CVEs
that appeared this year. I've reported them in the podofo issue
tracker (there are also some specifically against 0.9.6-rc1 !).
Also, I've committed these changes according to what had been wrote in
the several issues on upstream:
https://salsa.debian.org/security-tracker-team/security-tracker/commit/5a88ada26271b6f2e12ebcb3dd2bacfa0f20e1eb.patch
https://salsa.debian.org/debian/libpodofo/commit/9d6b7844377f8444fc4d5c73ccc103eac5facb35
Just FYI, but I believe at this all the confusion is pretty much gone
already :) (hopefully…)
--
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 `-
signature.asc
Description: PGP signature
--
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] 0.9.6 fails to link a test with -DPODOFO_HAVE_GCC_SYMBOL_VISIBILITY
/ParserTest.cpp:1704:
undefined reference to
`PoDoFo::PdfXRefStreamParserObject::~PdfXRefStreamParserObject()'
|/usr/bin/ld: ./obj-x86_64-linux-gnu/test/unit/./test/unit/ParserTest.cpp:1759:
undefined reference to
`PoDoFo::PdfXRefStreamParserObject::PdfXRefStreamParserObject(PoDoFo::PdfVecObjects*,
PoDoFo::PdfRefCountedInputDevice const&, PoDoFo::PdfRefCountedBuffer const&,
std::vector >*)'
|/usr/bin/ld: ./obj-x86_64-linux-gnu/test/unit/./test/unit/ParserTest.cpp:1762:
undefined reference to `PoDoFo::PdfXRefStreamParserObject::Parse()'
|/usr/bin/ld: ./obj-x86_64-linux-gnu/test/unit/./test/unit/ParserTest.cpp:1763:
undefined reference to `PoDoFo::PdfXRefStreamParserObject::ReadXRefTable()'
|/usr/bin/ld: ./obj-x86_64-linux-gnu/test/unit/./test/unit/ParserTest.cpp:1814:
undefined reference to
`PoDoFo::PdfXRefStreamParserObject::PdfXRefStreamParserObject(PoDoFo::PdfVecObjects*,
PoDoFo::PdfRefCountedInputDevice const&, PoDoFo::PdfRefCountedBuffer const&,
std::vector >*)'
|/usr/bin/ld: ./obj-x86_64-linux-gnu/test/unit/./test/unit/ParserTest.cpp:1817:
undefined reference to `PoDoFo::PdfXRefStreamParserObject::Parse()'
|/usr/bin/ld: ./obj-x86_64-linux-gnu/test/unit/./test/unit/ParserTest.cpp:1818:
undefined reference to `PoDoFo::PdfXRefStreamParserObject::ReadXRefTable()'
|/usr/bin/ld: ./obj-x86_64-linux-gnu/test/unit/./test/unit/ParserTest.cpp:1814:
undefined reference to
`PoDoFo::PdfXRefStreamParserObject::~PdfXRefStreamParserObject()'
|/usr/bin/ld: ./obj-x86_64-linux-gnu/test/unit/./test/unit/ParserTest.cpp:1759:
undefined reference to
`PoDoFo::PdfXRefStreamParserObject::~PdfXRefStreamParserObject()'
|/usr/bin/ld: ./obj-x86_64-linux-gnu/test/unit/./test/unit/ParserTest.cpp:1704:
undefined reference to
`PoDoFo::PdfXRefStreamParserObject::~PdfXRefStreamParserObject()'
|/usr/bin/ld: ./obj-x86_64-linux-gnu/test/unit/./test/unit/ParserTest.cpp:1649:
undefined reference to
`PoDoFo::PdfXRefStreamParserObject::~PdfXRefStreamParserObject()'
|/usr/bin/ld: ./obj-x86_64-linux-gnu/test/unit/./test/unit/ParserTest.cpp:1594:
undefined reference to
`PoDoFo::PdfXRefStreamParserObject::~PdfXRefStreamParserObject()'
|/usr/bin/ld:
CMakeFiles/podofo-test.dir/ParserTest.cpp.o:./obj-x86_64-linux-gnu/test/unit/./test/unit/ParserTest.cpp:1539:
more undefined references to
`PoDoFo::PdfXRefStreamParserObject::~PdfXRefStreamParserObject()' follow
|collect2: error: ld returned 1 exit status
|make[3]: *** [test/unit/CMakeFiles/podofo-test.dir/build.make:377:
test/unit/podofo-test] Error 1
|make[3]: Leaving directory '/build/libpodofo-0.9.6/obj-x86_64-linux-gnu'
|make[2]: *** [CMakeFiles/Makefile2:832:
test/unit/CMakeFiles/podofo-test.dir/all] Error 2
|make[2]: Leaving directory '/build/libpodofo-0.9.6/obj-x86_64-linux-gnu'
|make[1]: *** [Makefile:133: all] Error 2
|make[1]: Leaving directory '/build/libpodofo-0.9.6/obj-x86_64-linux-gnu'
This can be fixed by e.g.:
|--- a/src/base/PdfXRefStreamParserObject.h
|+++ b/src/base/PdfXRefStreamParserObject.h
|@@ -48,7 +48,7 @@
| *
| * It is mainly here to make PdfParser more modular.
| */
|-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?
Otherwise, something else should be done to allow its linkage even with
-fvisibility=hidden.
--
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 `-
signature.asc
Description: PGP signature
--
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 confusion, also in Debian (was: Re: Next PoDoFo Release 0.9.6)
On Tue, Jun 12, 2018 at 03:17:20PM +0200, Matthew Brincke wrote:
> I erred here, I think, AFAICS it
Errr, please, please do try to pay attention and be precise about what
fixed what and where.
Messing CVEs numbers in commit messages (and in messages in general)
it's only going to cause *a lot* of confusion.
> @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).
I'm sorry, I find your sentence way too misunderstandable, so I'm going
to ask for confirmation of what you really mean.
Please confirm all of the above, or correct approriatel (I believe the
context is clear enough without any extra explenation of what every
single line mean, but feel free to ask any clarification).
# security-tracker.debian.org:
|diff --git a/data/CVE/list b/data/CVE/list
|index 0e480453ea..fd6015b0e0 100644
|--- a/data/CVE/list
|+++ b/data/CVE/list
|@@ -68732,11 +68732,12 @@ CVE-2017-5855 (The
PoDoFo::PdfParser::ReadXRefSubsection function in PdfParser.c
|NOTE: upstream commit: http://sourceforge.net/p/podofo/code/1843
| CVE-2017-5854 (base/PdfOutputStream.cpp in PoDoFo 0.9.4 allows remote
attackers to ...)
|{DLA-929-1}
|- - libpodofo 0.9.4-5 (bug #854602)
|+ - libpodofo (bug #854602)
|+ [stretch] - libpodofo (Minor issue)
|[jessie] - libpodofo (Minor issue)
|NOTE:
https://blogs.gentoo.org/ago/2017/02/01/podofo-null-pointer-dereference-in-pdfoutputstream-cpp
|NOTE:
https://sourceforge.net/p/podofo/mailman/podofo-users/thread/12497325.VLNgGImML2%40blackgate/#msg35640936
|- NOTE: upstream commit: https://sourceforge.net/p/podofo/code/1836
|+ NOTE: upstream commit: https://sourceforge.net/p/podofo/code/1870
| CVE-2017-5853 (Integer overflow in base/PdfParser.cpp in PoDoFo 0.9.4 allows
remote ...)
|{DLA-929-1}
|- libpodofo 0.9.4-5 (bug #854601)
# bugs.debian.org commands:
|unarchive 854602
|reopen 854602
|tag 854602 fixed-upstream # by https://sourceforge.net/p/podofo/code/1870
|tag 854605 fixed-upstream # by https://sourceforge.net/p/podofo/code/1836
|close 854605 0.9.4-5
# the packaging:
|diff --git a/debian/changelog b/debian/changelog
|index 7e53789..4d4aac2 100644
|--- a/debian/changelog
|+++ b/debian/changelog
|@@ -115,9 +115,9 @@ libpodofo (0.9.4-5) unstable; urgency=high
| * Add upstream patches for security issues:
| + CVE-2017-5853 Closes: #854601
| + CVE-2017-6844 Closes: #861561
|-+ CVE-2017-5854 Closes: #854602
| + CVE-2017-5886 Closes: #854604
| + CVE-2017-7379 Closes: #859331
|++ Fix NULL pointer dereference in pdfinfo. Closes: #854605
|
| -- Mattia Rizzolo Wed, 03 May 2017 11:41:19 +0200
|
|diff --git a/debian/patches/CVE-2017-5854.patch
b/debian/patches/null-point-dereference.patch
|similarity index 78%
|rename from debian/patches/CVE-2017-5854.patch
|rename to debian/patches/null-point-dereference.patch
|index a9753c0..a40ed04 100644
|--- a/debian/patches/CVE-2017-5854.patch
|+++ b/debian/patches/null-point-dereference.patch
|@@ -1,8 +1,8 @@
|-Description: CVE-2017-5854
|+Description: Fix NULL pointer dereference in PdfInfo::GuessFormat
(pdfinfo.cpp)
| Acked-By: Markus Koschany
| Acked-By: Mattia Rizzolo
|-Last-Update: 2017-05-03
|-Bug-Debian: https://bugs.debian.org/854602
|+Last-Update: 2018-06-12
|+Bug-Debian: https://bugs.debian.org/854605
| Origin: https://sourceforge.net/p/podofo/code/1836
|
| --- a/tools/podofopdfinfo/pdfinfo.cpp
|diff --git a/debian/patches/series b/debian/patches/series
|index 07038c1..21657a4 100644
|--- a/debian/patches/series
|+++ b/debian/patches/series
|@@ -3,7 +3,7 @@ fix_test_on_32bit.patch
| spelling_fixes.patch
| CVE-2017-5852.patch
| CVE-2017-5853-and-CVE-2017-6844.patch
|-CVE-2017-5854.patch
|+null-point-dereference.patch
| CVE-2017-5855.patch
| CVE-2017-5886.patch
| CVE-2017-6840-and-CVE-2017-6842-and-CVE-2017-6843.patch
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)?
wheezy-lts now ended, so fixes there can't land anymore, but I suppose
we could at least fix the metadata on the security-tracker (I'd need to
check with the LTS team though, I don't really know a thing about their
workflow).
The changes should be in
https://salsa.debian.org/debian/libpodofo/commits/wheezy - I would be
very happy if you could double check.
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.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org
Re: [Podofo-users] ABI incompatible changes
On Mon, Apr 16, 2018 at 12:14:59PM +0200, Antonio Larrosa wrote: > Then I checked the full list of changes between 0.9.5 and current > code in trunk and noticed there are many changes that give an > incompatible ABI with respect to 0.9.5 . > > Is there any policy with respect to maintaining ABI compatibility in > different versions of the library? I think it's important for users > to keep a compatible ABI, as otherwise, any update forces a rebuild > of all applications using podofo PoDoFo bumps SONAME in each release, and it has always been like that. As you noticed there are plenty of ABI changes (just looking at the symbols… I haven't actually checked public enums, structs etc). Trying to avoid a single one is kind of pointless. BTW, before trying to achieve some kind of ABI stability, there are plenty of private symbols that leak, which makes tracking ABI very hard¹ > and some times, that's not easy for users to do. That's why in the linux world there distributors between developers and users, to take care of this kind of stuff (that falls in the bigger word of "integration"). And those users that build directly PoDoFo themeselves, they better know what a shared library is and how to handle it, otherwise they probably shouldn't do what they are doing. ¹ I try this pretty much at every release: https://salsa.debian.org/debian/libpodofo/commit/5e4030ce3b889907eb888fdf072cbab466c0b7cb https://salsa.debian.org/debian/libpodofo/commit/df41e92eb97c42f3b3b7f8c60d3d256a2963e0c4 https://salsa.debian.org/debian/libpodofo/commit/4217d13c7e3501331e81ceab67e30ae833db1b5a https://salsa.debian.org/debian/libpodofo/commit/6ff3485962aa9844ed600c0ff7d1461d4d36079b Between the last one and the others I've spent some hours trying to get something that worked for more than only amd64, but there are several symbols that varies across all archs (which is kind of fine, it's due to things like size_t, ssize_t, uint64_t, etc, but there are really too many and I'm convinced very few of them should be visible). -- 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 `- signature.asc Description: PGP signature -- 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-5853 and CVE-2017-6844 testing (overflow fixed, but unhandled exception present)
On Fri, Apr 13, 2018 at 02:09:40PM +, Mark Rogers wrote:
> If I can also submit the parser unit tests now, but I was planning
> to wait until 0.9.6 release was complete
If you have actual unit tests (i.e., patches to tests/unit, or even
within tests/ only, and not external reproducers), I'd recommend
submitting them, and I would also recommend libpodofo maintainers to
accept them (as really, more tests can't possibly be a bad thing…).
--
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 `-
signature.asc
Description: PGP signature
--
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
On Sun, Apr 08, 2018 at 05:26:45PM +0200, Dominik Seichter wrote:
> I committed a fix as revision 1915 to trunk. I hope this fixes the build
> error. Could you please verify this? I do not have an i386 system arround.
Yes, with that it builds correctly, thank you!
--
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 `-
signature.asc
Description: PGP signature
--
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
On Sun, Apr 08, 2018 at 02:12:32PM +0200, Dominik Seichter via Podofo-users
wrote:
> 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
>
> Only critical patches will be integrated before release from now on.
Not critical, but I'd fine nice if you could fix these last few spelling
errors :)
Patch attached!
--
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 `-
--- a/src/doc/PdfAnnotation.cpp
+++ b/src/doc/PdfAnnotation.cpp
@@ -375,7 +375,7 @@
m_eAnnotation != ePdfAnnotation_Underline &&
m_eAnnotation != ePdfAnnotation_Squiggly &&
m_eAnnotation != ePdfAnnotation_StrikeOut )
-PODOFO_RAISE_ERROR_INFO( ePdfError_InternalLogic, "Must be a text markup annotation (hilight, underline, squiggly or strikeout) to set quad points" );
+PODOFO_RAISE_ERROR_INFO( ePdfError_InternalLogic, "Must be a text markup annotation (highlight, underline, squiggly or strikeout) to set quad points" );
this->GetObject()->GetDictionary().AddKey( "QuadPoints", rQuadPoints );
}
--- a/tools/podofoencrypt/podofoencrypt.cpp
+++ b/tools/podofoencrypt/podofoencrypt.cpp
@@ -92,9 +92,9 @@
printf(" -o The required owner password\n");
printf(" Permissions:\n");
printf(" --print Allow printing the document\n");
-printf(" --editAllow modifying the document besides annotations, form fields or chaning pages\n");
+printf(" --editAllow modifying the document besides annotations, form fields or changing pages\n");
printf(" --copyAllow text and graphic extraction\n");
-printf(" --editnotes Add or modify text annoations or form fields (if ePdfPermissions_Edit is set also allow to create interactive form fields including signature)\n");
+printf(" --editnotes Add or modify text annoations or form fields (if ePdfPermissions_Edit is set also allow the creation interactive form fields including signature)\n");
printf(" --fillandsign Fill in existing form or signature fields\n");
printf(" --accessible Extract text and graphics to support user with disabillities\n");
printf(" --assembleAssemble the document: insert, create, rotate delete pages or add bookmarks\n");
@@ -231,7 +231,7 @@
}
- printf("%s was sucessfully encrypted to: %s\n", pszInput, pszOutput );
+ printf("%s was successfully encrypted to: %s\n", pszInput, pszOutput );
return 0;
}
--- a/tools/podofoimgextract/podofoimgextract.cpp
+++ b/tools/podofoimgextract/podofoimgextract.cpp
@@ -60,7 +60,7 @@
nNum = extractor.GetNumImagesExtracted();
- printf("Extracted %i images sucessfully from the PDF file.\n", nNum );
+ printf("Extracted %i images successfully from the PDF file.\n", nNum );
return 0;
}
--- a/tools/podofopdfinfo/podofopdfinfo.cpp
+++ b/tools/podofopdfinfo/podofopdfinfo.cpp
@@ -154,7 +154,7 @@
}
-// std::cerr << "All information written sucessfully.\n" << std::endl << std::endl;
+// std::cerr << "All information written successfully.\n" << std::endl << std::endl;
return 0;
}
--- a/tools/podofouncompress/podofouncompress.cpp
+++ b/tools/podofouncompress/podofouncompress.cpp
@@ -67,7 +67,7 @@
*/
- printf("%s was sucessfully uncompressed to: %s\n", pszInput, pszOutput );
+ printf("%s was successfully uncompressed to: %s\n", pszInput, pszOutput );
return 0;
}
signature.asc
Description: PGP signature
--
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
On Sun, Apr 08, 2018 at 02:12:32PM +0200, Dominik Seichter via Podofo-users
wrote:
> 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
This tarball contains the following empty directories.
Do you think it's feasible to not ship them?
* doc/html/
* doc/latex/
* test/system/data/
--
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 `-
signature.asc
Description: PGP signature
--
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
[ Sorry Dominik for the double mail… used the wrong address for the ML ]
On Sun, Apr 08, 2018 at 02:12:32PM +0200, Dominik Seichter via Podofo-users
wrote:
> 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
Fails to build on i386:
[ 65%] Building CXX object test/unit/CMakeFiles/podofo-test.dir/StringTest.cpp.o
cd "/build/libpodofo-0.9.6~rc1/obj-i686-linux-gnu/test/unit" &&
/usr/lib/ccache/c++ -DPODOFO_HAVE_GCC_SYMBOL_VISIBILITY
-I"/build/libpodofo-0.9.6~rc1/obj-i686-linux-gnu"
-I"/build/libpodofo-0.9.6~rc1" -I/usr/include/i386-linux-gnu
-I/usr/include/cppunit -I/usr/include/lua5.1 -I"/build/libpodofo-0.9.6~rc1/src"
-I/usr/include/freetype2 -I/src -I/src/os -g -O2
-fdebug-prefix-map=/build/libpodofo-0.9.6~rc1=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall
-Woverloaded-virtual -Wswitch-enum -Wcast-qual -Wwrite-strings
-Wredundant-decls -Wreorder -Wno-deprecated-declarations -W
-fvisibility=hidden -g -o CMakeFiles/podofo-test.dir/StringTest.cpp.o -c
"/build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp"
/build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp: In function 'void
print(PoDoFo::pdf_utf16be*, PoDoFo::pdf_long)':
/build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp:47:36: warning: format
'%li' expects argument of type 'long int', but argument 2 has type
'PoDoFo::pdf_long {aka int}' [-Wformat=]
printf("start lLen=%li\n", lLen);
^
In file included from /usr/include/cppunit/TestCase.h:6:0,
from /usr/include/cppunit/TestCaller.h:5,
from /usr/include/cppunit/extensions/HelperMacros.h:9,
from /build/libpodofo-0.9.6~rc1/test/unit/StringTest.h:24,
from /build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp:21:
/build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp: In member function 'void
StringTest::TestLibUnistringInternal(const char*, long int, long int)':
/build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp:73:5: error: no matching
function for call to 'assertEquals(long int, PoDoFo::pdf_long&,
CppUnit::SourceLine, const char [66])'
CPPUNIT_ASSERT_EQUAL_MESSAGE( "Comparing length of output buffer after
utf8 -> utf16 conversion.", lLenUtf16 + 1, result1 );
^
/usr/include/cppunit/TestAssert.h:127:6: note: candidate: template
void CppUnit::assertEquals(const T&, const T&, CppUnit::SourceLine, const
string&)
void assertEquals( const T& expected,
^~~~
/usr/include/cppunit/TestAssert.h:127:6: note: template argument
deduction/substitution failed:
/build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp:73:5: note: deduced
conflicting types for parameter 'const T' ('long int' and 'PoDoFo::pdf_long
{aka int}')
CPPUNIT_ASSERT_EQUAL_MESSAGE( "Comparing length of output buffer after
utf8 -> utf16 conversion.", lLenUtf16 + 1, result1 );
^
/build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp:78:5: error: no matching
function for call to 'assertEquals(long int, PoDoFo::pdf_long&,
CppUnit::SourceLine, const char [74])'
CPPUNIT_ASSERT_EQUAL_MESSAGE( "Comparing length of output buffer after
utf8 -> utf16 -> utf8 conversion.", lLenUtf8 + 1, result2 );
^
/usr/include/cppunit/TestAssert.h:127:6: note: candidate: template
void CppUnit::assertEquals(const T&, const T&, CppUnit::SourceLine, const
string&)
void assertEquals( const T& expected,
^~~~
/usr/include/cppunit/TestAssert.h:127:6: note: template argument
deduction/substitution failed:
/build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp:78:5: note: deduced
conflicting types for parameter 'const T' ('long int' and 'PoDoFo::pdf_long
{aka int}')
CPPUNIT_ASSERT_EQUAL_MESSAGE( "Comparing length of output buffer after
utf8 -> utf16 -> utf8 conversion.", lLenUtf8 + 1, result2 );
^
test/unit/CMakeFiles/podofo-test.dir/build.make:377: recipe for target
'test/unit/CMakeFiles/podofo-test.dir/StringTest.cpp.o' failed
make[3]: *** [test/unit/CMakeFiles/podofo-test.dir/StringTest.cpp.o] Error 1
--
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 `-
signature.asc
Description: PGP signature
--
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] manpage for podofobox
It seems like in Debian we have an extra manpage for podofobox, compared to what's in the new man/ directory. It's not much, but could you please commit it as well? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .TH "PODOFOBOX" "1" "2010-12-09" "PoDoFo" "podofobox" .PP .SH NAME podofobox \- set the media, crop, bleed, trim, and art box on pages of a PDF file\. .PP .SH SYNOPSIS \fBpodofobox\fR [inputfile] [outpufile] [box] [left] [bottom] [width] [height] .PP .SH DESCRIPTION .B podofobox is one of the command line tools from the PoDoFo library that provide several useful operations to work with PDF files\. It can set the media, crop, bleed, trim, and art box on pages of a PDF file\. .PP .SH "SEE ALSO" .BR podofocountpages (1), .BR podofocrop (1), .BR podofoencrypt (1), .BR podofogc (1), .BR podofoimg2pdf (1), .BR podofoimgextract (1), .BR podofoimpose (1), .BR podofomerge (1), .BR podofoincrementalupdates (1), .BR podofopages (1), .BR podofopdfinfo (1), .BR podofotxt2pdf (1), .BR podofotxtextract (1), .BR podofouncompress (1), .BR podofoxmp (1) .PP .SH AUTHOR .PP PoDoFo is written by Dominik Seichter and others\. .PP This manual page was written by Oleksandr Moskalenko for the Debian Project (but may be used by others)\. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< (of course feel free to adapt/improve it, I haven't reviewed it) -- 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 `- signature.asc Description: PGP signature -- 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] Three new CVEs
FYI, 3 new CVEs were published yesterday for PoDoFo.
Accordingly, I've opened 3 bugs:
CVE-2018-8000 - heap-based buffer overflow in
PoDoFo::PdfTokenizer::GetNextToken()
https://sourceforge.net/p/podofo/tickets/13/
CVE-2018-8001 - heap-based buffer over-read in UnescapeName()
https://sourceforge.net/p/podofo/tickets/14/
CVE-2018-8002 - infinite loop vulnerability in
PdfParserObject::ParseFileComplete()
https://sourceforge.net/p/podofo/tickets/15/
I'm reporting this on the ML as well as I don't think all the usual
contributors subscribed to the bug tracker yet (but I think you should).
--
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 `-
signature.asc
Description: PGP signature
--
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
On Sun, Feb 18, 2018 at 01:09:31PM +0100, zyx wrote:
> Right. Since the bug tracker is opened, I guess the best would be to
> use the bug tracker for new issues and for those CVE-s without patches,
> thus they won't get lost.
I've done so.
I opened a bug report for all CVEs that TTBOMK are still not fixed in
trunk.
See https://sourceforge.net/p/podofo/tickets/
--
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 `-
signature.asc
Description: PGP signature
--
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] Visibility support checking in the build (was: exported symbols)
On Sat, Feb 10, 2018 at 10:47:41PM +0100, Matthew Brincke wrote:
> The CMake variable to set to express visibility support is now the unset
> PODOFO_HAVE_GCC_SYMBOL_VISIBILITY ("GCC" means "GCC-compatible" here).
> This variable should be set by a feature test in the CMakeLists.txt which
> I'm sorry for not being able to implement right now, I've never done such
> and would really like to contribute other fixes too (@Dom: until which time?).
I asked around this a bit some weeks ago, and it seems that a way to do
it is to use CHECK_C_COMPILER_FLAG / CHECK_CXX_COMPILER_FLAG (which
comes from /usr/share/cmake-3.9/Modules/CheckCXXCompilerFlag.cmake and
is even available for cmake back 2.6, so there should be no need to
vendor that .cmake file).
That doesn't cover a case that for example libssh's variant does:
https://sources.debian.org/src/libssh/0.8.0~20170825.94fa1e38-1/ConfigureChecks.cmake/?hl=40#L37
There it tries to build 'void __attribute__((visibility(\"default\")))
test() {} int main(void){ return 0; }' with -fvisibility=hidden.
Apparently, according to one person from my IRC circle,
ISTR -fvisibility=hidden is quietly accepted by any new enough GCC,
but when you actually try to use the attribute you get warnings if
the target platform doesn't support it. so to avoid a very noisy
build on such platforms you may want to run a test compile with -Werror
I'll leave to whoever implements this to figure out the best course of
action.
> > bunch of exported symbols, alas not that many, probably more
> > PODOFO_LOCAL and PODOFO_API are still needed through the codebase.
>
> Yes, probably, I hope that can still be changed after the release candidate.
I don't think there is any need to rush this part, or get crazy about.
--
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 `-
signature.asc
Description: PGP signature
--
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
On Sun, Jan 28, 2018 at 12:52:55AM +0100, Matthew Brincke wrote:
> > > 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 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).
So I've received another patch for this in Debian,
https://bugs.debian.org/889511, from Matthias Brinke:
> I've implemented a patch to fix this vulnerability, it is attached
> and tested with the PoC from the report (RedHat Bugzilla #1531897)
> and GCC 7 UBSan (-fsanitize=undefined in CXXFLAGS set via .sbuildrc).
> The builds were done with sbuild in an up-to-date Debian sid chroot.
> I've done the tests in a sandbox, where without the patch,
> signed integer overflow was detected, with it, nothing from UBSan.
> Otherwise, the same (expected, correct for the PoC) exception message
> with detailed info and "call stack" (via PdfError method) was output
> by podofoimgextract.
The patch is attached (it's against released 0.9.5).
(PS: should we start moving these kind of things to the bug tracker, or
perhaps only start with new ones, etc?)
--
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 `-
Description: Fix CVE-2018-5295
Author: Matthias Brinke
Last-Updated: 2018-01-30
---
--- libpodofo-0.9.5.orig/src/base/PdfXRefStreamParserObject.cpp
+++ libpodofo-0.9.5/src/base/PdfXRefStreamParserObject.cpp
@@ -38,7 +38,9 @@
#include "PdfStream.h"
#include "PdfVariant.h"
-#include
+// #include
+
+#include
namespace PoDoFo {
@@ -122,12 +124,25 @@ void PdfXRefStreamParserObject::ParseStr
{
char*pBuffer;
pdf_long lBufferLen;
-const size_t entryLen = static_cast(nW[0] + nW[1] + nW[2]);
-if( nW[0] + nW[1] + nW[2] < 0 )
+for(pdf_int64 nLengthSum = 0, i = 0; i < W_ARRAY_SIZE; i++ )
{
-PODOFO_RAISE_ERROR_INFO( ePdfError_NoXRef, "Invalid entry length in XRef stream" );
+if ( nW[i] < 0 )
+{
+PODOFO_RAISE_ERROR_INFO( ePdfError_NoXRef,
+"Negative field length in XRef stream" );
+}
+if ( std::numeric_limits::max() - nLengthSum < nW[i] )
+{
+PODOFO_RAISE_ERROR_INFO( ePdfError_NoXRef,
+"Invalid entry length in XRef stream" );
+}
+else
+{
+nLengthSum += nW[i];
+}
}
+const size_t entryLen = static_cast(nW[0] + nW[1] + nW[2]);
this->GetStream()->GetFilteredCopy( &pBuffer, &lBufferLen );
signature.asc
Description: PGP signature
--
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 tracker (was: Re: Next PoDoFo Release 0.9.6)
[sorry Dominik for the double email, sending this from the correct
address]
On Fri, Feb 02, 2018 at 06:00:07PM +0100, Dominik Seichter via Podofo-users
wrote:
> Thanks for the hint zyx! I think I was able to reconfigure the ticket
> system in sourceforge.
>
> Can you please check: https://sourceforge.net/p/podofo/tickets
*Thank you* for configuring it!
I actually trying filing another non-coding bug, so it definitely does
the job. :)
--
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 `-
signature.asc
Description: PGP signature
--
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: [cve-requ...@mitre.org: Re: [scr293896] podofo - 0.9.4]
I'm forwarding here the message I got back from mitre when I tried to ask for a CVE about https://blogs.gentoo.org/ago/2017/02/01/podofo-null-pointer-dereference-in-pdfinfoguessformat-pdfinfo-cpp/ This is just for public safekeeping of the message, so it doesn't stay secret in my own mailbox... (it's also nicely inline PGP signed itself, so you can say it's really from mitre :P) - Forwarded message from cve-requ...@mitre.org - Date: Sun, 12 Feb 2017 13:33:38 -0500 From: cve-requ...@mitre.org To: mat...@mapreri.org CC: cve-requ...@mitre.org Subject: Re: [scr293896] podofo - 0.9.4 Message-ID: <2f885f0085e24805adb9409f1fe34...@imshyb02.mitre.org> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 We have provided an explanation below, after the text associated with your https://cveform.mitre.org submission. You may republish or redistribute this message. We think that someone has already posted to oss-security about this issue. To make oss-security list members aware that there is no CVE ID assignment, you could reply to that oss-security post and include pertinent information below. Again, the best solution is to "reply" to an oss-security post, so that the text below stays within an oss-security thread. Please do not use a "forward" option that begins a separate thread. > [Suggested description] > podofo: NULL pointer dereference in PdfInfo::GuessFormat (pdfinfo.cpp) > > -- > > [Additional Information] > Originally reported in oss-security, but nobody seemed to reply there, > see https://marc.info/?l=oss-security&m=148603648823037&w=2 There > might be a CVE already that I didn't found, you should probably > double check before issuing a duplicate. > > -- > > [Vulnerability Type] > NULL pointer dereference > > -- > > [Vendor of Product] > podofo > > -- > > [Affected Product Code Base] > podofo - 0.9.4 > > -- > > [Reference] > https://blogs.gentoo.org/ago/2017/02/01/podofo-null-pointer-dereference-in-pdfinfoguessformat-pdfinfo-cpp/ > > -- > > [Discoverer] > Agostino Sarubbo As far as we can tell, an end user experiences a loss of functionality after the podofopdfinfo command-line tool crashes with a NULL pointer dereference (because the end user can completely work around this by not repeating the specific command-line invocation, there would be no security impact). Although some parts of PoDoFo are library code that could be reached from an arbitrary application, the reported code in PdfInfo::GuessFormat appears to be reachable only from the podofopdfinfo command-line tool. Thus, we are not assigning a CVE ID unless there is additional information about a security impact. - -- CVE Assignment Team M/S M300, 202 Burlington Road, Bedford, MA 01730 USA [ A PGP key is available for encrypted communications at http://cve.mitre.org/cve/request_id.html ] -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJYoKpQAAoJEHb/MwWLVhi2tToP+gIlkpTboYXAKUxALCebNyXT kgT3lcA4UkdCzDcdI54aOJzV+ZkWAxl10dERZAY+hrsB0mV0CGcTS35RkBvf7AHA GGyMW74uyOIz5WXx3ihyxfa1iVtqduamQasdHoNDrlYAWa72ecOyK3pLJLZjg87n ynn1fM7/4bEYuczHArTRPXNhTF4Bc5VNXojjJcA/NPF9O4zbpaaUVJYd00FT2hi0 i7cKuiXZWGoyvXvjelOwjEaMVJE9NHa9V6AgolT1Odl8c84/PowomixHIQGhhs4/ zUMQTZlniAWfIPt6YvAIPaQeIZ6z5OsLTmG7UnZhmz7GvDm3SpbNnTQ2LTLfww3o H8/gHCokvCHQOt2AmjsGltXTJRjcRIdn872+H1FoQEz4NvBjDb/BU3lP0M1M3gGI NBKyY9E0iZXb7Hh/U7DjN/i8Cu3rl1QMEN8/lPQmdnmb2xgpHvjoskp39oQTussZ WiV/YX8nr7dDQHhLnAXrbNDx7z8XaI4pRjqdPn4Ph+2cvqBtdxhHAUBMAh2yIQPl QGSWo0vGH5QQBhQWUwMIEFMsSMuEr6gAOHfw+VIEnBDXVhGklhBZyq+2XbRGeAdy dlo+9xisMuqmouKq2iO4rpxGdWzOsjhy4ekom3ZVUYSLPj7AFcwjob6T/eoklB/z 8Jh4i8El1uffbiOZ6xkt =vacu -END PGP SIGNATURE- - End forwarded message - -- 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 `- signature.asc Description: PGP signature -- 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
On Fri, Jan 26, 2018 at 11:35:44PM +0100, Matthew Brincke wrote: > > 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 asked for one back then (it was about the time the workflow to request CVEs from mitre changed from "random mail on oss-security" to the more private web form,), and after basically copy-pasting the web page into the form I got back this message on 2017-02-12: > [snip] > You may republish or redistribute this message. We think that someone > has already posted to oss-security about this issue. To make > oss-security list members aware that there is no CVE ID assignment, > you could reply to that oss-security post and include pertinent > information below. > [snip] > As far as we can tell, an end user experiences a loss of functionality > after the podofopdfinfo command-line tool crashes with a NULL pointer > dereference (because the end user can completely work around this by > not repeating the specific command-line invocation, there would be no > security impact). > > Although some parts of PoDoFo are library code that could be reached > from an arbitrary application, the reported code in > PdfInfo::GuessFormat appears to be reachable only from the > podofopdfinfo command-line tool. > > Thus, we are not assigning a CVE ID unless there is additional > information about a security impact. > > - -- > CVE Assignment Team After all I didn't redistributed the message for some reason (probably I was just too lazy). So it seems the reason the CVE was rejected is only because the crash doesn't happen in the library, but in the tool itself. -- 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 `- signature.asc Description: PGP signature -- 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
[ 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/
To recap from that thread:
Unfixed security issues:
https://security-tracker.debian.org/tracker/CVE-2017-6845
https://security-tracker.debian.org/tracker/CVE-2017-6846
https://security-tracker.debian.org/tracker/CVE-2017-6849
https://security-tracker.debian.org/tracker/CVE-2017-8053
https://security-tracker.debian.org/tracker/CVE-2017-8054
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/
(CVE-2017-8054 had a tentive patch)
A copyright issue:
https://sourceforge.net/p/podofo/mailman/message/35633858/
A threading problem:
https://sourceforge.net/p/podofo/mailman/message/35915862/
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 `-
signature.asc
Description: PGP signature
--
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
finfo debian/libpodofo-utils/usr/bin/podofotxt2pdf debian/libpodofo-utils/usr/bin/podofoincrementalupdates debian/libpodofo-utils/usr/bin/podofosign debian/libpodofo-utils/usr/bin/podofoimpose debian/libpodofo-utils/usr/bin/podofoimg2pdf debian/libpodofo-utils/usr/bin/podofotxtextract debian/libpodofo-utils/usr/bin/podofoxmp debian/libpodofo-utils/usr/bin/podofogc debian/libpodofo-utils/usr/bin/podofocountpages debian/libpodofo-utils/usr/bin/podofouncompress debian/libpodofo-utils/usr/bin/podofocolor debian/libpodofo-utils/usr/bin/podofoencrypt debian/libpodofo-utils/usr/bin/podofoimgextract debian/libpodofo-utils/usr/bin/podofomerge debian/libpodofo-utils/usr/bin/podofocrop debian/libpodofo-utils/usr/bin/podofobox debian/libpodofo-utils/usr/bin/podofopages were not linked against libjpeg.so.62 (they use none of the library's symbols) |dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libpodofo-utils/usr/bin/podofopdfinfo debian/libpodofo-utils/usr/bin/podofotxt2pdf debian/libpodofo-utils/usr/bin/podofoincrementalupdates debian/libpodofo-utils/usr/bin/podofosign debian/libpodofo-utils/usr/bin/podofoimpose debian/libpodofo-utils/usr/bin/podofoimg2pdf debian/libpodofo-utils/usr/bin/podofotxtextract debian/libpodofo-utils/usr/bin/podofoxmp debian/libpodofo-utils/usr/bin/podofogc debian/libpodofo-utils/usr/bin/podofocountpages debian/libpodofo-utils/usr/bin/podofouncompress debian/libpodofo-utils/usr/bin/podofocolor debian/libpodofo-utils/usr/bin/podofoencrypt debian/libpodofo-utils/usr/bin/podofoimgextract debian/libpodofo-utils/usr/bin/podofomerge debian/libpodofo-utils/usr/bin/podofocrop debian/libpodofo-utils/usr/bin/podofobox debian/libpodofo-utils/usr/bin/podofopages were not linked against libidn.so.11 (they use none of the library's symbols) |dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libpodofo-utils/usr/bin/podofopdfinfo debian/libpodofo-utils/usr/bin/podofotxt2pdf debian/libpodofo-utils/usr/bin/podofoincrementalupdates debian/libpodofo-utils/usr/bin/podofosign debian/libpodofo-utils/usr/bin/podofoimpose debian/libpodofo-utils/usr/bin/podofoimg2pdf debian/libpodofo-utils/usr/bin/podofotxtextract debian/libpodofo-utils/usr/bin/podofoxmp debian/libpodofo-utils/usr/bin/podofogc debian/libpodofo-utils/usr/bin/podofocountpages debian/libpodofo-utils/usr/bin/podofouncompress debian/libpodofo-utils/usr/bin/podofocolor debian/libpodofo-utils/usr/bin/podofoencrypt debian/libpodofo-utils/usr/bin/podofoimgextract debian/libpodofo-utils/usr/bin/podofomerge debian/libpodofo-utils/usr/bin/podofocrop debian/libpodofo-utils/usr/bin/podofobox debian/libpodofo-utils/usr/bin/podofopages were not linked against libz.so.1 (they use none of the library's symbols) |dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libpodofo-utils/usr/bin/podofopdfinfo debian/libpodofo-utils/usr/bin/podofotxt2pdf debian/libpodofo-utils/usr/bin/podofoincrementalupdates debian/libpodofo-utils/usr/bin/podofosign debian/libpodofo-utils/usr/bin/podofoimpose debian/libpodofo-utils/usr/bin/podofoimg2pdf debian/libpodofo-utils/usr/bin/podofotxtextract debian/libpodofo-utils/usr/bin/podofoxmp debian/libpodofo-utils/usr/bin/podofogc debian/libpodofo-utils/usr/bin/podofocountpages debian/libpodofo-utils/usr/bin/podofouncompress debian/libpodofo-utils/usr/bin/podofocolor debian/libpodofo-utils/usr/bin/podofoencrypt debian/libpodofo-utils/usr/bin/podofoimgextract debian/libpodofo-utils/usr/bin/podofomerge debian/libpodofo-utils/usr/bin/podofocrop debian/libpodofo-utils/usr/bin/podofobox debian/libpodofo-utils/usr/bin/podofopages were not linked against libfreetype.so.6 (they use none of the library's symbols) 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 :) -- 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 `- signature.asc Description: PGP signature -
Re: [Podofo-users] Next release ? Many CVE's
On Wed, Dec 27, 2017 at 12:57:41AM +0100, Matthew Brincke wrote:
> at least for the CVE-2017-8054 a fix was posted on the Debian Bug Tracking
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860995#20
Right, the submitter privately acked me for forwarding it myself, so
I've done so as a separated thread.
> in it, also copyright [2] (for which I recommend libunistring2) and
> [2] https://sourceforge.net/p/podofo/mailman/message/35633858/
Oh wow. I'm impressed somebody remembers it without proper tracking! :)
♥
--
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 `-
signature.asc
Description: PGP signature
--
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 for CVE-2017-8054
Somebody attached to the Debian bug http://bugs.debian.org/860995 a
patch for CVE-2017-8054.
I'm forwarding this on behalf of Matthias Brinke
(whom asked me privately to do so).
The patch applies cleanly with `patch -p1` on current trunk r1863.
Attached you can also find a PoC generator for this bug.
--
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 `-
#include
using namespace PoDoFo;
void CreatePagesLoopPoC(PdfDocument& doc)
{
PdfPage* pFirstPage = doc.GetPage( 0 );
PdfObject* pFirstPageObject = pFirstPage->GetObject();
PdfObject* pParentObject = pFirstPageObject->MustGetIndirectKey("Parent");
PdfArray & rParentKidsArray = pParentObject->MustGetIndirectKey("Kids")
->GetArray();
rParentKidsArray.insert(rParentKidsArray.begin(),
pParentObject->Reference());
pdf_int64 ll2 = 2; // needed to make the following call unambiguous
pParentObject->GetDictionary().AddKey("Count", ll2); // 1 original, 1 loop
}
#define FONTNAME "Helvetica"
#define TEXTPOS_X 72.0
#define TEXTPOS_Y 72.0
#define SAMPLE_TEXT "Sample"
void DrawSampleTextOnPage(PdfPage* pPage)
{
PdfPainter painter;
painter.SetPage( pPage );
PdfFont* pFont = PdfFontFactory::CreateBase14Font( FONTNAME,
ePdfFont_Normal,
PdfEncodingFactory::GlobalWinAnsiEncodingInstance(),
pPage->GetObject()->GetOwner() );
painter.SetFont( pFont );
painter.DrawText( TEXTPOS_X, TEXTPOS_Y, PdfString( SAMPLE_TEXT,
pFont->GetEncoding() ));
painter.FinishPage();
delete pFont;
}
#define OUTFILE "my-CVE-2017-8054-PoC.pdf"
int main()
{
PdfMemDocument doc;
PdfPage* pPage
= doc.CreatePage( PdfPage::CreateStandardPageSize( ePdfPageSize_A4 ));
DrawSampleTextOnPage( pPage );
CreatePagesLoopPoC( doc );
doc.Write( OUTFILE );
return 0;
}
Description: Fix CVE-2017-8054
The recursive call in the case of the requested page index
having an array has been removed to prevent possibility of
stack overflow there, and replaced it by code setting the
variable which had been modified in the new stack frame in
the former revision, directly, after checking its validity.
The second hunk inserts cycle detection for the parent list.
Author: Matthias Brinke
Bug-Debian: https://bugs.debian.org/860995
Forwarded: no
Last-Update: 2017-12-21
---
--- libpodofo-0.9.5.orig/src/doc/PdfPagesTree.cpp
+++ libpodofo-0.9.5/src/doc/PdfPagesTree.cpp
@@ -34,6 +34,7 @@
#include "PdfPagesTree.h"
#include "base/PdfDefinesPrivate.h"
+#include
#include "base/PdfArray.h"
#include "base/PdfDictionary.h"
@@ -478,7 +479,17 @@ PdfObject* PdfPagesTree::GetPageNodeFrom
if( rVar.IsArray() )
{
// Fixes some broken PDFs who have trees with 1 element kids arrays
-return GetPageNodeFromArray( 0, rVar.GetArray(), rLstParents );
+// Recursive call removed to prevent stack overflow, replaced by:
+// all the following inside this conditional, plus restart looping
+const PdfArray & rVarArray = rVar.GetArray();
+if (rVarArray.GetSize() == 0)
+{
+PdfError::LogMessage( eLogSeverity_Critical, "Trying to access"
+" first page index of empty array" );
+return NULL;
+}
+rVar = rVarArray[0];
+continue;
}
else if( !rVar.IsReference() )
{
@@ -502,6 +513,18 @@ PdfObject* PdfPagesTree::GetPageNodeFrom
if( !pgObject->GetDictionary().HasKey( "Kids" ) )
return NULL;
+if ( std::find( rLstParents.begin(), rLstParents.end(), pgObject )
+!= rLstParents.end() ) // cycle in parent list detected, fend
+{ // off security vulnerability CVE-2017-8054 (infinite recursion)
+std::ostringstream oss;
+oss << "Cycle in page tree: child in /Kids array of object "
+<< ( *(rLstParents.rbegin()) )->Reference().ToString()
+<< " back-references to object " << pgObject->Reference()
+.ToString() << " one of whose descendants the former is.";
+
+PODOFO_RAISE_ERROR_INFO( ePdfError_PageNotFound, oss.str() );
+}
+
rLstParents.push_b
Re: [Podofo-users] Next release ? Many CVE's
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:
https://security-tracker.debian.org/tracker/CVE-2017-6845
https://security-tracker.debian.org/tracker/CVE-2017-6846
https://security-tracker.debian.org/tracker/CVE-2017-6849
https://security-tracker.debian.org/tracker/CVE-2017-8053
https://security-tracker.debian.org/tracker/CVE-2017-8054
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/
But yes, a release with the already fixed ones would be nice I agree :)
--
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 `-
signature.asc
Description: PGP signature
--
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] exported symbols
On Wed, May 03, 2017 at 12:00:20PM +0200, Mattia Rizzolo wrote: > I noticed that libpodofo exports symbols for all of its methods, which > means that things like https://sourceforge.net/p/podofo/code/1838 > actually break the ABI despite it not needed to, as that's a private > method. > > > It would be quite nice if somebody could go through all of the codebase, > and do something like https://gcc.gnu.org/wiki/Visibility So, I had a chance to dig around a tiny bit, and discovered things about PODOFO_LOCAL and PODOFO_API, which seem to exist with the exact porpuse of tweaking symbol visibility. See the CODINDSTYLE.txt file. Though, all the interesting part of those macros are enabled only with cmake's variable PODOFO_USE_VISIBILITY enabled, which is automatically enabled only when cmake detects a GCC version 4.* with some weird code. So, one problem is that apparently that part doesn't consider that GCC now changed versioning scheme Also that code calls `gcc --version` unconditionally, so I'm wondering how that's going to work if I have both gcc and clang instaled but I'm compiling with an old version of clang that doesn't support -fvisibility... So, that check needs an overhoul to be useful again. Anyway, starting from the next SONAME bump (i.e. podofo release) I'll be manually setting -DPODOFO_USE_VISIBILITY, it seemed to remove a good bunch of exported symbols, alas not that many, probably more PODOFO_LOCAL and PODOFO_API are still needed through the codebase. -- 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 `- signature.asc Description: PGP signature -- 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
On Fri, Oct 27, 2017 at 12:54:11AM +0200, Matthew Brincke wrote: > > 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? mhh, what typo? > I see from your Debian > Maintainer Dashboard https://udd.debian.org/dmd/?mattia%40debian.org#todo > that there are many to-do list entries, Please don't let that page fool you: it defaults on showing stuff for all packages I even glanced upon, including the ones I sponsored ages ago of which I know nothing about. See https://udd.debian.org/dmd/?email1=mattia%40debian.org&nosponsor1=on#todo for a more real "to-do list". Even so, I don't use the DMD (Debian Maintainer Dashboard) myself, there is too much data formtted in a way I can't really parse. > 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. Yep, your patch is totally acceptable for me, and I've just uploaded it to Debian unstable (together with two other CVE fixes that were done in June but didn't notice). > 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? So, marking PODOFO_LOCAL still doesn't help by itself apparently: even after your patch added PODOFO_LOCAL to that method, its symbol was still exported. I grepped around and discovered a thing, but I'll write that in the other thread I started in May. -- 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 `- signature.asc Description: PGP signature -- 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
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.
> 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.
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)
--
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 `-
signature.asc
Description: PGP signature
--
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] cppunit 1.14 requires C++11, but PoDoFo enforces C++98
On Mon, Jul 31, 2017 at 05:33:21PM +0200, zyx wrote:
> it's not. Well, the current development version doesn't do that:
> http://sourceforge.net/p/podofo/code/1826
ahah, cool then :)
--
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 `-
signature.asc
Description: PGP signature
--
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] cppunit 1.14 requires C++11, but PoDoFo enforces C++98
cppunit 1.14 requires C++11, cauing PoDoFo build (when built with the
tests enabled) to fail with
[ 60%] Building CXX object test/unit/CMakeFiles/podofo-test.dir/ColorTest.cpp.o
cd /build/1st/libpodofo-0.9.5/obj-arm-linux-gnueabihf/test/unit && /usr/bin/c++
-I/build/1st/libpodofo-0.9.5/obj-arm-linux-gnueabihf
-I/build/1st/libpodofo-0.9.5 -I/usr/include/arm-linux-gnueabihf
-I/usr/include/cppunit -I/usr/include/lua5.1 -I/build/1st/libpodofo-0.9.5/src
-I/usr/include/freetype2 -I/src -I/src/os -g -O2 -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++98
-Wall -Woverloaded-virtual -Wswitch-enum -Wcast-qual -Wwrite-strings
-Wredundant-decls -Wreorder -W -g -o
CMakeFiles/podofo-test.dir/ColorTest.cpp.o -c
/build/1st/libpodofo-0.9.5/test/unit/ColorTest.cpp
In file included from /usr/include/c++/6/type_traits:35:0,
from /usr/include/cppunit/tools/StringHelper.h:7,
from /usr/include/cppunit/TestAssert.h:8,
from /usr/include/cppunit/TestCase.h:6,
from /usr/include/cppunit/TestCaller.h:5,
from /usr/include/cppunit/extensions/HelperMacros.h:9,
from /build/1st/libpodofo-0.9.5/test/unit/ColorTest.h:24,
from /build/1st/libpodofo-0.9.5/test/unit/ColorTest.cpp:21:
/usr/include/c++/6/bits/c++0x_warning.h:32:2: error: #error This file requires
compiler and library support for the ISO C++ 2011 standard. This support must
be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support \
^
TTBOMK the only solution is to build with c++11, but is PoDoFo ready
for it? Why is CMakeLists.txt injecting -std=c++98?
--
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 `-
signature.asc
Description: PGP signature
--
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 r1810 ABI mess
On Thu, Jul 20, 2017 at 12:22:13PM +0200, Joerg Sonnenberger wrote:
> While I love PoDoFo, it certainly needs a lot of love when it
> comes to API and ABI stability.
podofo never had any ABI stability, indeed the soname is versioned with
all the version string (including the "patch number" in semver lingo),
so you certantly should not be expecing that.
And you should not be expecing any ABI stability from any project if you
are using stuff from their development repository...
That said, it would be great to get to a point where the versioning
means something, and ABI doesn't break across patch releases…
--
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 `-
signature.asc
Description: PGP signature
--
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] another bunch of crashes
On Mon, May 08, 2017 at 07:27:34PM +0200, zyx wrote: > I looked on other bunch of the CVEs and here's the result: I've uploaded to Debian unstable most of the patches. To my count, this leaves out: https://security-tracker.debian.org/tracker/CVE-2017-8787 https://security-tracker.debian.org/tracker/CVE-2017-8378 https://security-tracker.debian.org/tracker/CVE-2017-8054 Also, the following are claimed by you to be unreproducible in current trunk, it would be very cool if somebody could identify the fixing commits: https://security-tracker.debian.org/tracker/CVE-2017-8053 https://security-tracker.debian.org/tracker/CVE-2017-6849 https://security-tracker.debian.org/tracker/CVE-2017-6846 https://security-tracker.debian.org/tracker/CVE-2017-6845 https://security-tracker.debian.org/tracker/CVE-2017-6841 Just for the record, I didn't upload the patches for the following because the first one breaks the ABI and I'm not happy to do it (two choices here: either break it as it's a private method anyway, or provide a wrapper), and the other is quite invasive and didn't have the chance to sit long enough with it. https://security-tracker.debian.org/tracker/CVE-2017-5852 https://security-tracker.debian.org/tracker/CVE-2017-7994 I got rid of that TEMP-… issue, as Mitre claimed it's not CVE-worthy, and you said it's fixed in trunk either way. -- 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 `- signature.asc Description: PGP signature -- 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: heap overflow in podofo's pdf parser
On Thu, May 04, 2017 at 09:56:00AM +0200, zyx wrote: > On Wed, 2017-05-03 at 21:43 +0200, Matthew Brincke wrote: > > > nice, I gave it a quick try and using that provided PDF and the > > > code suggested there, with svn trunk at revision 1824, I get this > > > output: > > > > very probably there are transposed digits, you actually meaning the > > svn revision 1842 > > oops, right, that was a typo on my side, I'm sorry about that. The > revision I used was really 1842. It would be very helpful if somebody could do a bisect or something and identify the fixing commit. -- 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 `- signature.asc Description: PGP signature -- 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-2017-8787: heap based overflow in ReadXRefStreamEntry
0 in PoDoFo::PdfParser::ReadXRefContents(long, bool) podofo-0.9.5/src/base/PdfParser.cpp:682 #5 0x594106 in PoDoFo::PdfParser::ReadDocumentStructure() podofo-0.9.5/src/base/PdfParser.cpp:337 #6 0x593734 in PoDoFo::PdfParser::ParseFile(PoDoFo::PdfRefCountedInputDevice const&, bool) podofo-0.9.5/src/base/PdfParser.cpp:220 #7 0x59331e in PoDoFo::PdfParser::ParseFile(char const*, bool) podofo-0.9.5/src/base/PdfParser.cpp:164 #8 0x540f4f in PoDoFo::PdfMemDocument::Load(char const*, bool) podofo-0.9.5/src/doc/PdfMemDocument.cpp:256 #9 0x53fde9 in PoDoFo::PdfMemDocument::PdfMemDocument(char const*, bool) podofo-0.9.5/src/doc/PdfMemDocument.cpp:102 #10 0x4b8021 in PdfInfo::PdfInfo(std::__cxx11::basic_string, std::allocator > const&) podofo-0.9.5/tools/podofopdfinfo/pdfinfo.cpp:25 #11 0x4bee20 in main podofo-0.9.5/tools/podofopdfinfo/podofopdfinfo.cpp:110 #12 0x7fe5111a882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #13 0x4b7ee8 in _start (podofopdfinfo+0x4b7ee8) 0x621190ff is located 1 bytes to the left of 4096-byte region [0x62119100,0x6211a100) allocated by thread T0 here: #0 0x7fe512a0779a in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9879a) #1 0x591652 in PoDoFo::podofo_calloc(unsigned long, unsigned long) podofo-0.9.5/src/base/PdfMemoryManagement.cpp:136 #2 0x591aa6 in PoDoFo::PdfMemoryOutputStream::PdfMemoryOutputStream(long) podofo-0.9.5/src/base/PdfOutputStream.cpp:77 #3 0x4db667 in PoDoFo::PdfStream::GetFilteredCopy(char**, long*) const podofo-0.9.5/src/base/PdfStream.cpp:91 #4 0x5bccb1 in PoDoFo::PdfXRefStreamParserObject::ParseStream(long const*, std::vector > const&) podofo-0.9.5/src/base/PdfXRefStreamParserObject.cpp:127 #5 0x5bc9b0 in PoDoFo::PdfXRefStreamParserObject::ReadXRefTable() podofo-0.9.5/src/base/PdfXRefStreamParserObject.cpp:118 #6 0x598894 in PoDoFo::PdfParser::ReadXRefStreamContents(long, bool) podofo-0.9.5/src/base/PdfParser.cpp:858 #7 0x597720 in PoDoFo::PdfParser::ReadXRefContents(long, bool) podofo-0.9.5/src/base/PdfParser.cpp:682 #8 0x594106 in PoDoFo::PdfParser::ReadDocumentStructure() podofo-0.9.5/src/base/PdfParser.cpp:337 #9 0x593734 in PoDoFo::PdfParser::ParseFile(PoDoFo::PdfRefCountedInputDevice const&, bool) podofo-0.9.5/src/base/PdfParser.cpp:220 #10 0x59331e in PoDoFo::PdfParser::ParseFile(char const*, bool) podofo-0.9.5/src/base/PdfParser.cpp:164 #11 0x540f4f in PoDoFo::PdfMemDocument::Load(char const*, bool) podofo-0.9.5/src/doc/PdfMemDocument.cpp:256 #12 0x53fde9 in PoDoFo::PdfMemDocument::PdfMemDocument(char const*, bool) podofo-0.9.5/src/doc/PdfMemDocument.cpp:102 #13 0x4b8021 in PdfInfo::PdfInfo(std::__cxx11::basic_string, std::allocator > const&) podofo-0.9.5/tools/podofopdfinfo/pdfinfo.cpp:25 #14 0x4bee20 in main podofo-0.9.5/tools/podofopdfinfo/podofopdfinfo.cpp:110 #15 0x7fe5111a882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) SUMMARY: AddressSanitizer: heap-buffer-overflow podofo-0.9.5/src/base/PdfXRefStreamParserObject.cpp:224 PoDoFo::PdfXRefStreamParserObject::ReadXRefStreamEntry(char*, long, long const*, int) Shadow bytes around the buggy address: 0x0c427fffb1c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffb1d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffb1e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffb1f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffb200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c427fffb210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa] 0x0c427fffb220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c427fffb230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c427fffb240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c427fffb250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c427fffb260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe ==23234==ABORTING [how to reproduce] compile the podofo project with address sanitizer, and run the following command ./podofopdfinfo ./heap-overflow-ReadXRefStreamEntry [how to fix] I think checking the value of the nW array to ensure they are positive will work. Please feel free to ask me if you have further question about this report. Best Regards, Xiang Xiaobo of VARAS@IIE - End for
[Podofo-users] exported symbols
I noticed that libpodofo exports symbols for all of its methods, which
means that things like https://sourceforge.net/p/podofo/code/1838
actually break the ABI despite it not needed to, as that's a private
method.
It would be quite nice if somebody could go through all of the codebase,
and do something like https://gcc.gnu.org/wiki/Visibility
this could even pave the way to having some kind of ABI
stability, and detach the SONAME from the library version…
--
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 `-
signature.asc
Description: PGP signature
--
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] another bunch of crashes
On Fri, Apr 28, 2017 at 07:21:38PM +0200, zyx wrote:
> I made a little walk-through of the CVEs and
> https://security-tracker.debian.org/tracker/CVE-2017-6846
> references reproducer for CVE-2017-6845, it should be
> https://blogs.gentoo.org/ago/2017/03/02/podofo-null-pointer-dereference-in-graphicsstacktgraphicsstackelementsetnonstrokingcolorspace-graphicsstack-h/
> instead.
Uops, copy-paste failure on my side, fixed, thank you!
I suppose I could start cherry-picking the one with a fix, so the index
would get a bit more clear
> TEMP-0854605-651F03, which end with exception, instead of crashing,
btw, about this thing, I asked for a CVE, and was denied as "not a
security bug"
--
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 `-
signature.asc
Description: PGP signature
--
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: heap overflow in podofo's pdf parser
On Mon, Apr 24, 2017 at 08:20:04PM +0200, zyx wrote:
> thanks for reporting. It seems to not be filled here yet [1].
>
> Adding it to [1] would be also nice to have (not a question
> for you, I suppose).
Would be nice to have a CVE id also.
Could somebody fill https://cveform.mitre.org/ asking for one? Once a
CVE id is published there are people routinely triaging those and adding
to the list in [1].
> []1 https://security-tracker.debian.org/tracker/source-package/libpodofo
--
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 `-
signature.asc
Description: PGP signature
--
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] Installation and Compiling PoDoFo
On Thu, Apr 13, 2017 at 09:12:19PM +, Manrique, Beatriz wrote: > I am having trouble finding any sort of documentation or help with installing > and compiling PoDoFo. I think I have installed the library as I can find it > on my virtual machine in /usr/include but I am lost after that. I have also > installed the necessary dependencies: libpodofo is in the official Ubuntu repository, and in particular 16.04 ships with podofo 0.9.3. If that version is cool enough for you, you can just install it using apt. To also get the headers and the .so symlink just run sudo apt install libpodofo-dev After that if you are using any sane build system for your project you should be able to dynamically link to it. > * cppunit (optional) > * freetype2 > * fontconfig (Linux/Unix only) > * libjpeg (optional) > * libtiff (optional) > * libpng (optional) > * OpenSSL > * zlib Otherwise you can only use the ubuntu package to get the build-dependencies of libpodofo installed: sudo apt build-dep libpodofo (this requires deb-src lines in /etc/apt/sources.list) This won't pull cppunit, btw. -- 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 `- signature.asc Description: PGP signature -- 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] another bunch of crashes
On Thu, Mar 30, 2017 at 01:49:16PM +0200, zyx wrote: > Right. It had been just a coincidence that two people here reported one > same issue and I happen to fix it without the reference (also because I > didn't use Agostino's reference, but that other person's). I think it would be greatly appreciated (from me at least), if the CVE IDs were to be included in the commit message. That would be more than enough to reference such issues unambiguously. > I had a private chat with Agostino on Tuesday, he asked me to drop a > commit link to his blog post when the change references one of those > issues, from which I understood that he'll update the Debian summary > page (link given earlier in this thread). I also can update that summary page whenever is needed (talking about https://security-tracker.debian.org/tracker/source-package/libpodofo, and all of those referenced from there) If you need so feel free to drop me a line. -- 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 `- signature.asc Description: PGP signature -- 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] please move manpages out of debian/ directory
On Fri, Mar 24, 2017 at 07:13:55PM +0100, zyx wrote:
> On Mon, 2017-03-13 at 13:42 +0100, Mattia Rizzolo wrote:
> > Do you mind if I ask about the status of this (doesn't seem to be done
> > in SVN):
>
> Hi,
> you are right, it was not done. I ran those three commands now and
> committed it as revision 1832:
> http://sourceforge.net/p/podofo/code/1832
Thank you!!
--
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 `-
signature.asc
Description: PGP signature
--
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] another bunch of crashes
On Mon, Mar 13, 2017 at 01:39:00PM +0100, Mattia Rizzolo wrote: > On Thu, Mar 02, 2017 at 05:31:34PM +0100, Agostino Sarubbo wrote: > > Please consider the following: > > > > … > > All of these now have CVEs associated. And apparently the Debian release team is considering these severe enough to warrant removing libpodofo from the next debian stable release rather then leaving them unfixed (http://bugs.debian.org/856592). I severely lack time (and real proper knowledge) to start to help with these, but I'd appreciate if you could prioritize them. > I find the Debian view for security issues particularly nice to look at: > https://security-tracker.debian.org/tracker/source-package/libpodofo -- 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 `- signature.asc Description: PGP signature -- 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] please move manpages out of debian/ directory
Do you mind if I ask about the status of this (doesn't seem to be done in SVN): On Wed, Feb 08, 2017 at 05:48:02PM +0100, Mattia Rizzolo wrote: > I've never quite understood why manpages are in debian/man instead of > man/ or doc/man/ or whatever. > > This makes for a tad akward situation for Debian, actually, where > importing a new upstream usually includes `rm -rf debian` from the > upstream tarball (in the sense that tools usually do that). > > I propose the following (not providing a patch as svn kinda sucks at > moving files and making a patch out of it): > > $ svn mv debian/man . > $ svn rm debian > $ sed -i 's/debian/man/' CMakeLists.txt > > What do you think? The debian/ directory doesn't really contain > anything else besides the manpages and the jumper CMakeLists.txt, so it > is really free to go, imho. > > Thank you for considering! PS: … but why is the bug tracker not open :( (this might be just me not understanding how tracking issue via email is easier than a bug tracker) -- 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 `- signature.asc Description: PGP signature -- Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] another bunch of crashes
On Thu, Mar 02, 2017 at 05:31:34PM +0100, Agostino Sarubbo wrote:
> Please consider the following:
>
> …
All of these now have CVEs associated.
I find the Debian view for security issues particularly nice to look at:
https://security-tracker.debian.org/tracker/source-package/libpodofo
--
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 `-
signature.asc
Description: PGP signature
--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] manpage of podofobox talks about podofocolor
On Wed, Feb 15, 2017 at 07:21:40PM +0100, zyx wrote:
> please do attach patches.
Yes, I usually do, but what I copied before was not a patch, but showing
a diff of the current 2 files, to show that they are wrong.
I do not know what podofobox.1 should best contain, maybe partially
reverting the commit I noted my first email is the best way to go here.
> Mail clients can, and some do, change the
> whitespaces in the message body, including wrapping, thus simple
> copy&paste into a file not always work.
Well, my doesn't :P
And I trust my fellow readers will use a sane enough MUA...
But I do attach patches usually, yes, because they are more easy to
handle, thanks to be able to juts save the single attachment instead of
messing with copy/pasting or so.
--
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 `-
signature.asc
Description: PGP signature
--
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] Spelling error in manpages
Attached is a patch fixing some errors in manpages.
Notes:
* podofoencrypt.1 is because 'allow to create' is not syntactically
correct ('allow to' requires a third object: to whom the thing is
allowed).
* podofocolor.1 is because that's plain wrong groff syntax :)
* podofoxmp.1 is actually the only spelling error
(but really there is no better way to send patch or stuff than this
mailing list?)
--
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 `-
Index: debian/man/podofocolor.1
===
--- debian/man/podofocolor.1 (revision 1822)
+++ debian/man/podofocolor.1 (working copy)
@@ -12,7 +12,7 @@
useful operations to work with colors in PDF files\. It can parse and/or
modify all colors or colorspaces in a PDF file\. The
modifications can be defined via C++ or a Lua script\. Custom conversions like
-\fconvert all colors to grayscale\f are included. Please note that only colors
+\fBconvert all colors to grayscale\fR are included. Please note that only colors
of vector objects on pages and in XObjects are affected\. This tool does not
transform colos in images at the moment\.
.PP
Index: debian/man/podofoencrypt.1
===
--- debian/man/podofoencrypt.1 (revision 1822)
+++ debian/man/podofoencrypt.1 (working copy)
@@ -75,7 +75,7 @@
\fB\-\-editnotes\fR
.RS
.PP
-Add or modify text annoations or form fields (if ePdfPermissions_Edit is set also allow to create interactive form fields including signature)
+Add or modify text annoations or form fields (if ePdfPermissions_Edit is set also allow the creation of interactive form fields including signature)
.RE
.PP
\fB\-\-fillandsign\fR
Index: debian/man/podofoxmp.1
===
--- debian/man/podofoxmp.1 (revision 1822)
+++ debian/man/podofoxmp.1 (working copy)
@@ -24,7 +24,7 @@
\fB[xmpfile]\fR
.RS
.PP
-Optional file that provides PDF XMP structure\. It must be used in conjuction
+Optional file that provides PDF XMP structure\. It must be used in conjunction
with an [outputfile]\.
.RE
.PP
@@ -31,7 +31,7 @@
\fB[outputfile]\fR
.RS
.PP
-Output PDF file\. It is only used in conjuction with an [xmpfile]\.
+Output PDF file\. It is only used in conjunction with an [xmpfile]\.
.RE
.PP
.SH SEE ALSO
signature.asc
Description: PGP signature
--
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] manpage of podofobox talks about podofocolor
This seems wrong to me :)
It seem to have happened in r1390, back in 2011 when the podofocolor
manpage was addedd.
mattia@warren ..an/libpodofo/upstream/trunk/debian/man (svn)-[trunk:1822] %
diff -u podofocolor.1 podofobox.1
--- podofocolor.1 2017-02-15 17:44:00.507545860 +0100
+++ podofobox.1 2017-02-15 17:44:00.503545854 +0100
@@ -21,17 +21,13 @@
.RS
dummy - Convert all colors to red\. Just a dummy and test implementation which
serves as an example for developers\.
-.RE
-.RS
grayscale - Convert all colors of vector objects in a PDF to grayscale\.
-.RE
-.RS
-lua [script] - Convert all colors based on a Lua description\. A lua script
has to be
+lua - Convert all colors based on a Lua description\. A lua script has to be
passed as an additional parameter.
.RE
.PP
.SH "SEE ALSO"
-.BR podofobox (1),
+.BR podofocolor (1),
.BR podofocountpages (1),
.BR podofocrop (1),
.BR podofoencrypt (1),
1 mattia@warren ..an/libpodofo/upstream/trunk/debian/man (svn)-[trunk:1822] %
:(
--
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 `-
signature.asc
Description: PGP signature
--
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 test failure on 32 bit architectures
Hi!
Running the build on 32 bit architecutures with tests enabled (i.e.,
libcppunit available) leads to a build failure:
|/«PKGBUILDDIR»/test/unit/EncryptTest.cpp:213:76: error: invalid initialization
of non-const reference of type 'PoDoFo::pdf_long& {aka int&}' from an rvalue of
type 'PoDoFo::pdf_long {aka int}'
| pEncrypt->Decrypt( pEncryptedBuffer, nOutputLen, pDecryptedBuffer,
m_lLen );
|
^~
|In file included from /«PKGBUILDDIR»/src/podofo-base.h:52:0,
| from /«PKGBUILDDIR»/src/podofo.h:47,
| from /«PKGBUILDDIR»/test/unit/EncryptTest.h:24,
| from /«PKGBUILDDIR»/test/unit/EncryptTest.cpp:21:
|/«PKGBUILDDIR»/src/base/PdfEncrypt.h:378:18: note: initializing argument 4
of 'virtual void PoDoFo::PdfEncrypt::Decrypt(const unsigned char*,
PoDoFo::pdf_long, unsigned char*, PoDoFo::pdf_long&) const'
|virtual void Decrypt(const unsigned char* inStr, pdf_long inLen,
| ^~~
|test/unit/CMakeFiles/podofo-test.dir/build.make:185: recipe for target
'test/unit/CMakeFiles/podofo-test.dir/EncryptTest.cpp.o' failed
|make[3]: *** [test/unit/CMakeFiles/podofo-test.dir/EncryptTest.cpp.o] Error 1
Full log:
https://buildd.debian.org/status/fetch.php?pkg=libpodofo&arch=i386&ver=0.9.5-1&stamp=1486631394&raw=0
The fix to me is pretty simple:
--- a/test/unit/EncryptTest.h
+++ b/test/unit/EncryptTest.h
@@ -87,7 +87,7 @@
private:
char* m_pEncBuffer;
- long m_lLen;
+ PoDoFo::pdf_long m_lLen;
int m_protection;
};
(also attached for convenience)
Thank you!
--
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 `-
Description: use the correct type for m_lLen
pdf_long happens to be compatible with long on 64 bit architectures, but
clashes on 32 bits. Given that m_lLen is only used in place where pdf_long
should be used instead, let's change the definition.
Author: Mattia Rizzolo
Forwarded: no
Last-Update: 2017-02-15
--- a/test/unit/EncryptTest.h
+++ b/test/unit/EncryptTest.h
@@ -87,7 +87,7 @@
private:
char* m_pEncBuffer;
- long m_lLen;
+ PoDoFo::pdf_long m_lLen;
int m_protection;
};
signature.asc
Description: PGP signature
--
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] please move manpages out of debian/ directory
Hi!
I've never quite understood why manpages are in debian/man instead of
man/ or doc/man/ or whatever.
This makes for a tad akward situation for Debian, actually, where
importing a new upstream usually includes `rm -rf debian` from the
upstream tarball (in the sense that tools usually do that).
I propose the following (not providing a patch as svn kinda sucks at
moving files and making a patch out of it):
$ svn mv debian/man .
$ svn rm debian
$ sed -i 's/debian/man/' CMakeLists.txt
What do you think? The debian/ directory doesn't really contain
anything else besides the manpages and the jumper CMakeLists.txt, so it
is really free to go, imho.
Thank you for considering!
--
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 `-
signature.asc
Description: PGP signature
--
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] security bugs in PoDoFo
recently some CVEs have been assigned to PoDoFo thanks to some fuzz
checks performed by Gentoo.
CVE-2017-5853
https://blogs.gentoo.org/ago/2017/02/01/podofo-signed-integer-overflow-in-pdfparser-cpp/
CVE-2017-5852
https://blogs.gentoo.org/ago/2017/02/01/podofo-infinite-loop-in-podofopdfpagegetinheritedkeyfromobject-pdfpage-cpp/
CVE-2017-5854
https://blogs.gentoo.org/ago/2017/02/01/podofo-null-pointer-dereference-in-pdfoutputstream-cpp/
https://blogs.gentoo.org/ago/2017/02/03/podofo-heap-based-buffer-overflow-in-podofopdftokenizergetnexttoken-pdftokenizer-cpp/
Now, I haven't looked anywhere else other than that. Also all those
bugs are confirmed only on 0.9.4, no idea about others.
Also all the pages says "The upstream project denies me to open a new
ticket. So, I'm unable to communicate with them", therefore I don't know
whether you're aware of those.
Could you please check them out?
Thanks in advance.
--
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 `-
signature.asc
Description: PGP signature
--
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] non-free piece of code in src/base/PdfString.cpp
On Wed, Jan 25, 2017 at 10:22:14PM +0100, Dominik Seichter wrote: > Thanks for pointing out that very important issue. I fear we have to remove > this code before the release, which would require a second release > candidate and will delay the release currently planned for February 2nd. Well, I don't know much you value this problem; also it has been here for quite a lot of time, so I think it's ok to also postpone this issue to 0.9.6 targetting ~end 2017. > The best option seems to be to replace our current implementation with this > BSD licensed code: > http://www.bsdua.org/files/unicode.tar.gz (Linked from > http://unicode.org/resources/utf8.html) Sounds like a great option for me. > Another option would be to replace it with the original file without > modifications (as done in Ghostscript or taglib): > https://ghostscript.com/doc/base/ConvertUTF.c > http://developer.kde.org/~wheeler/files/src/taglib-0.95/ > taglib/toolkit/unicode.cpp While this is true that it would be ok for you, then it doesn't fix the root problem that you're shipping what is non-free code. To give some background to my original email: I spotted this issue thanks to an automated check done in Debian, see: https://lintian.debian.org/tags/license-problem-convert-utf-code.html While nobody have made an effort of going to file a bug against all of those (currently) 50 apparently affected packages yet, I expect this to happen at some point; note that the check is very recent, it has been implemented not even a month ago. You quote ghostscript, but according to it's Debian's copyright file, the maintainer is already stripping the code copy before uploading the source, which is IMHO an unnecessary burden if it can be fixed at the root by using a different implementation (or some other solution). > I will have to take a deeper look into this issue! Thank you very much for caring about what to somebody might seem like a petty detail… PS: you also have another small thing that is not totally free, which is the test file lena.jpg; see https://en.wikipedia.org/wiki/File:Lenna.png#Licensing The fact that no real license exists is a problem on itself, as without license people whom are not the copyright holder have no rights at all over the product, including redistribution. For people still considering that file free, I find the unclearness of the situation as althoughter annoying by itself and worth calming just for it :) -- 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 `- signature.asc Description: PGP signature -- 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] non-free piece of code in src/base/PdfString.cpp
It seems there is a excerpt of code in src/base/PdfString.cpp coming
from Unicode, Inc.
The license of that code is as follow:
/*
* Copyright 2001-2004 Unicode, Inc.
*
* Disclaimer
*
* This source code is provided as is by Unicode, Inc. No claims are
* made as to fitness for any particular purpose. No warranties of any
* kind are expressed or implied. The recipient agrees to determine
* applicability of information provided. If this file has been
* purchased on magnetic or optical media from Unicode, Inc., the
* sole remedy for any claim will be exchange of defective media
* within 90 days of receipt.
*
* Limitations on Rights to Redistribute This Code
*
* Unicode, Inc. hereby grants the right to freely use the information
* supplied in this file in the creation of products supporting the
* Unicode Standard, and to make copies of this file in any form
* for internal or external distribution as long as this notice
* remains attached.
*/
Such license is not free, as:
1) it doesn't grant right to modify the code (which you did, so
technically you'd be in violation)
2) it is worded in a way that seems to limit the usage of the code,
only in works aimed at supporting the Unicode standard.
Now, apparently Unicode, Inc changed its standard licenses few years
ago, and so if there is a new version of that code it might be possible
to pull that and have a really free license (I don't know how feasible
it is, according to your local changes).
Another way would be of course to reimplement those functions. Or to
depend on similar implementations coming from external libraries.
--
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 `-
signature.asc
Description: PGP signature
--
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 Release Plan
On Thu, Jan 05, 2017 at 06:59:32PM +, Mark Rogers wrote:
> I’m not certain if PoDoFo makes any guarantees on binary compatibility
> between releases (although C++ makes it hard to provide any guarantee
> on binary compatibility). These patches will break binary
> compatibility (by changing the memory layout of member variables) but
> won’t affect source compatibility.
I don't think this is interesting, considering that every PoDoFo release
increments the SONAME used (matching the actual PoDoFo version), which
is safe way to be able to just ignore binary compatibility across
releases.
--
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 `-
signature.asc
Description: PGP signature
--
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.4 fails to build with openSSL 1.1.0
On Fri, Oct 28, 2016 at 03:43:54PM +0200, Dominik Seichter wrote:
> Thanks for forwarding this. Were you able to test this patch and can
> confirm that this fixes the issue?
Yes, I successfully built podofo with this patch against both of OpenSSL
1.0.2 and 1.1.0.
--
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 `-
signature.asc
Description: PGP signature
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] podofo 0.9.4 fails to build with openSSL 1.1.0
On Mon, Oct 10, 2016 at 11:38:00AM +, Mattia Rizzolo wrote:
> Hi there.
>
> Debian received a bug report that podofo fails to build with the newer
> openSSL.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828407
>
> I'd report this as a bug report, but the bug tracker is not open to the
> public :)
FTR, I received a patch for this, attached to this message.
Credits go to Reiner Herrmann .
--
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 `-
Description: be compatible with OpenSSL 1.1.0 API
Author: Reiner Herrmann
Acked-By: Mattia Rizzolo
Bug-Debian: https://bugs.debian.org/828407
--- a/src/base/PdfEncrypt.cpp
+++ b/src/base/PdfEncrypt.cpp
@@ -99,19 +99,19 @@
AESCryptoEngine()
{
-EVP_CIPHER_CTX_init(&aes);
+aes = EVP_CIPHER_CTX_new();
}
-EVP_CIPHER_CTX* getEngine() {return &aes;}
+EVP_CIPHER_CTX* getEngine() {return aes;}
~AESCryptoEngine()
{
-EVP_CIPHER_CTX_cleanup(&aes);
+EVP_CIPHER_CTX_free(aes);
}
private:
-EVP_CIPHER_CTX aes;
+EVP_CIPHER_CTX *aes;
};
// A class that holds the RC4 Crypto object
@@ -121,19 +121,19 @@
RC4CryptoEngine()
{
-EVP_CIPHER_CTX_init(&rc4);
+rc4 = EVP_CIPHER_CTX_new();
}
-EVP_CIPHER_CTX* getEngine() {return &rc4;}
+EVP_CIPHER_CTX* getEngine() {return rc4;}
~RC4CryptoEngine()
{
-EVP_CIPHER_CTX_cleanup(&rc4);
+EVP_CIPHER_CTX_free(rc4);
}
private:
-EVP_CIPHER_CTX rc4;
+EVP_CIPHER_CTX *rc4;
};
/** A class that can encrypt/decrpyt streamed data block wise
@@ -1459,24 +1459,23 @@
// UE = AES-256 encoded file encryption key with key=hash
// CBC mode, no padding, init vector=0
-EVP_CIPHER_CTX aes;
-EVP_CIPHER_CTX_init(&aes);
+EVP_CIPHER_CTX *aes = EVP_CIPHER_CTX_new();
-int status = EVP_EncryptInit_ex(&aes, EVP_aes_256_cbc(), NULL, hashValue, NULL);
+int status = EVP_EncryptInit_ex(aes, EVP_aes_256_cbc(), NULL, hashValue, NULL);
if(status != 1)
PODOFO_RAISE_ERROR_INFO( ePdfError_InternalLogic, "Error initializing AES encryption engine" );
-EVP_CIPHER_CTX_set_padding(&aes, 0); // disable padding
+EVP_CIPHER_CTX_set_padding(aes, 0); // disable padding
int dataOutMoved;
-status = EVP_EncryptUpdate(&aes, m_ueValue, &dataOutMoved, m_encryptionKey, m_keyLength);
+status = EVP_EncryptUpdate(aes, m_ueValue, &dataOutMoved, m_encryptionKey, m_keyLength);
if(status != 1)
PODOFO_RAISE_ERROR_INFO( ePdfError_InternalLogic, "Error AES-encrypting data" );
-status = EVP_EncryptFinal_ex(&aes, &m_ueValue[dataOutMoved], &dataOutMoved);
+status = EVP_EncryptFinal_ex(aes, &m_ueValue[dataOutMoved], &dataOutMoved);
if(status != 1)
PODOFO_RAISE_ERROR_INFO( ePdfError_InternalLogic, "Error AES-encrypting data" );
-EVP_CIPHER_CTX_cleanup(&aes);
+EVP_CIPHER_CTX_free(aes);
}
void PdfEncryptSHABase::ComputeOwnerKey(const unsigned char * ownerpswd, int len)
@@ -1515,24 +1514,23 @@
// OE = AES-256 encoded file encryption key with key=hash
// CBC mode, no padding, init vector=0
-EVP_CIPHER_CTX aes;
-EVP_CIPHER_CTX_init(&aes);
+EVP_CIPHER_CTX *aes = EVP_CIPHER_CTX_new();
-int status = EVP_EncryptInit_ex(&aes, EVP_aes_256_cbc(), NULL, hashValue, NULL);
+int status = EVP_EncryptInit_ex(aes, EVP_aes_256_cbc(), NULL, hashValue, NULL);
if(status != 1)
PODOFO_RAISE_ERROR_INFO( ePdfError_InternalLogic, "Error initializing AES encryption engine" );
-EVP_CIPHER_CTX_set_padding(&aes, 0); // disable padding
+EVP_CIPHER_CTX_set_padding(aes, 0); // disable padding
int dataOutMoved;
-status = EVP_EncryptUpdate(&aes, m_oeValue, &dataOutMoved, m_encryptionKey, m_keyLength);
+status = EVP_EncryptUpdate(aes, m_oeValue, &dataOutMoved, m_encryptionKey, m_keyLength);
if(status != 1)
PODOFO_RAISE_ERROR_INFO( ePdfError_InternalLogic, "Error AES-encrypting data" );
-status = EVP_EncryptFinal_ex(&aes, &m_oeValue[dataOutMoved], &dataOutMoved);
+status = EVP_EncryptFinal_ex(aes, &m_oeValue[dataOutMoved], &dataOutMoved);
if(status != 1)
PODOFO_RAISE_ERROR_INFO( ePdfError_InternalLogic, "Error AES-encrypting data" );
-EVP_CIPHER_CTX_cleanup(&aes)
[Podofo-users] podofo 0.9.4 fails to build with openSSL 1.1.0
Hi there.
Debian received a bug report that podofo fails to build with the newer
openSSL.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828407
I'd report this as a bug report, but the bug tracker is not open to the
public :)
More informations are available on that downstream bug above, but the
short version is that it fails with:
cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/c++
-Dpodofo_shared_EXPORTS -I/usr/include/x86_64-linux-gnu -I/usr/include/lua5.1
-I/<>/obj-x86_64-linux-gnu -I/<>
-I/<>/src -I/usr/include/freetype2 -g -O2 -fPIE
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -std=c++98 -Wall -Woverloaded-virtual
-Wswitch-enum -Wcast-qual -Wwrite-strings -Wredundant-decls -Wreorder -W
-DBUILDING_PODOFO -o CMakeFiles/podofo_shared.dir/base/PdfInputStream.cpp.o -c
/<>/src/base/PdfInputStream.cpp
/<>/src/base/PdfEncrypt.cpp:94:24: error: field 'aes' has
incomplete type 'EVP_CIPHER_CTX {aka evp_cipher_ctx_st}'
EVP_CIPHER_CTX aes;
^
In file included from /usr/include/openssl/evp.h:14:0,
from /<>/src/base/PdfEncrypt.cpp:46:
/usr/include/openssl/ossl_typ.h:89:16: note: forward declaration of
'EVP_CIPHER_CTX {aka struct evp_cipher_ctx_st}'
typedef struct evp_cipher_ctx_st EVP_CIPHER_CTX;
^
/<>/src/base/PdfEncrypt.cpp:116:20: error: field 'rc4' has
incomplete type 'EVP_CIPHER_CTX {aka evp_cipher_ctx_st}'
EVP_CIPHER_CTX rc4;
^
In file included from /usr/include/openssl/evp.h:14:0,
from /<>/src/base/PdfEncrypt.cpp:46:
/usr/include/openssl/ossl_typ.h:89:16: note: forward declaration of
'EVP_CIPHER_CTX {aka struct evp_cipher_ctx_st}'
typedef struct evp_cipher_ctx_st EVP_CIPHER_CTX;
^
/<>/src/base/PdfEncrypt.cpp: In member function 'void
PoDoFo::PdfEncryptSHABase::ComputeUserKey(const unsigned char*, int)':
/<>/src/base/PdfEncrypt.cpp:1461:20: error: aggregate
'EVP_CIPHER_CTX aes' has incomplete type and cannot be defined
EVP_CIPHER_CTX aes;
^
/<>/src/base/PdfEncrypt.cpp: In member function 'void
PoDoFo::PdfEncryptSHABase::ComputeOwnerKey(const unsigned char*, int)':
/<>/src/base/PdfEncrypt.cpp:1517:20: error: aggregate
'EVP_CIPHER_CTX aes' has incomplete type and cannot be defined
EVP_CIPHER_CTX aes;
^
/<>/src/base/PdfEncrypt.cpp: In member function 'virtual void
PoDoFo::PdfEncryptAESV3::GenerateEncryptionKey(const PoDoFo::PdfString&)':
/<>/src/base/PdfEncrypt.cpp:1665:20: error: aggregate
'EVP_CIPHER_CTX aes' has incomplete type and cannot be defined
EVP_CIPHER_CTX aes;
^
src/CMakeFiles/podofo_shared.dir/build.make:305: recipe for target
'src/CMakeFiles/podofo_shared.dir/base/PdfEncrypt.cpp.o' failed
make[3]: *** [src/CMakeFiles/podofo_shared.dir/base/PdfEncrypt.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
CMakeFiles/Makefile2:120: recipe for target
'src/CMakeFiles/podofo_shared.dir/all' failed
make[2]: *** [src/CMakeFiles/podofo_shared.dir/all] Error 2
make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
Makefile:130: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
--
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 `-
signature.asc
Description: PGP signature
--
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
