Re: [Podofo-users] ABI fix for the fix CVE-2017-5852
On Fri, 27 Oct 2017 00:54:11 +0200 (CEST) Matthew Brinckewrote: > Hello Mattia, > > > Mattia Rizzolo has written on 23. Oktober 2017 at 11:10: > > > > On Sun, Oct 22, 2017 at 05:20:31PM +0200, Matthew Brincke wrote: > > > Debian bug 854600 [2], I wonder why no one answered to the last > > > post ...) > > > > My fault. > > TBH, I totally forgot of that. I suppose I could have come up with > > simple patch to retain ABI compatibility on my own, but I forgot > > and I haven't than that. > > that's likely a typo, what do you mean, please? I see from your Debian > Maintainer Dashboard > https://udd.debian.org/dmd/?mattia%40debian.org#todo that there are > many to-do list entries, yet could you please accept my patch also? > Could it be that the original one in the Debian bug report wasn't > accepted for Jessie and later because of the ABI break? With that > cured by my patch, wouldn't it be acceptable together? If not, please > tell why not. > > > > I wonder why changing a private method is relevant to ABI at all, > > > and (at least when you're still unconvinced ;-) to accept) would > > > welcome your elucidation (if you have come across any, to date), > > > please ... > > > > There is a more widespread problem in podofo where all symbols are > > exported and therefore are formally part of the public ABI (even if > > not intended to). Even if I suppose no program within Debian uses > > those symbols (I could check, I haven't), I would not happily break > > the ABI nonetheless. > > > Thanks for the explanation, there's one aspect I'm still curious > about: I wonder why any C++ compiler, much less g++, would export any > private symbols, as they aren't supposed to be accessible from > anywhere (beyond their class and compilation unit) except for friend > classes (can those reside in a different library/executable?), so > maybe they should be marked PODOFO_LOCAL? > > > https://sourceforge.net/p/podofo/mailman/message/35819398/ > > (then, the lack of an actual bug tracker makes those request/reports > > very hard to track, and I wouldn't be surprised if many missed it, > > or even if they did completely forgot about it, as many other > > reports) > I concur, I'd also like a tracker for bug reports/feature requests, > the sf.net one was probably closed because of spam, IIRC. Could maybe > the bug reports be copied there by someone with the permissions for > that? > HI all, I had set up Mantis on SF before. As Dominic is the only admin, he the only one with permissions to make changes. Cheers, Peter -- 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=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
Hello Mattia, > Mattia Rizzolo has written on 23. Oktober 2017 at 11:10: > > On Sun, Oct 22, 2017 at 05:20:31PM +0200, Matthew Brincke wrote: > > Debian bug 854600 [2], I wonder why no one answered to the last post ...) > > My fault. > TBH, I totally forgot of that. I suppose I could have come up with > simple patch to retain ABI compatibility on my own, but I forgot and I > haven't than that. that's likely a typo, what do you mean, please? I see from your Debian Maintainer Dashboard https://udd.debian.org/dmd/?mattia%40debian.org#todo that there are many to-do list entries, yet could you please accept my patch also? Could it be that the original one in the Debian bug report wasn't accepted for Jessie and later because of the ABI break? With that cured by my patch, wouldn't it be acceptable together? If not, please tell why not. > > I wonder why changing a private method is relevant to ABI at all, and > > (at least when you're still unconvinced ;-) to accept) would welcome your > > elucidation (if you have come across any, to date), please ... > > There is a more widespread problem in podofo where all symbols are > exported and therefore are formally part of the public ABI (even if not > intended to). Even if I suppose no program within Debian uses those > symbols (I could check, I haven't), I would not happily break the ABI > nonetheless. > Thanks for the explanation, there's one aspect I'm still curious about: I wonder why any C++ compiler, much less g++, would export any private symbols, as they aren't supposed to be accessible from anywhere (beyond their class and compilation unit) except for friend classes (can those reside in a different library/executable?), so maybe they should be marked PODOFO_LOCAL? > https://sourceforge.net/p/podofo/mailman/message/35819398/ > (then, the lack of an actual bug tracker makes those request/reports > very hard to track, and I wouldn't be surprised if many missed it, or > even if they did completely forgot about it, as many other reports) > I concur, I'd also like a tracker for bug reports/feature requests, the sf.net one was probably closed because of spam, IIRC. Could maybe the bug reports be copied there by someone with the permissions for that? -- > regards, > Mattia Rizzolo > Best regards, mabri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] 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] ABI fix for the fix CVE-2017-5852
On Sun, 2017-10-22 at 17:20 +0200, Matthew Brincke wrote: > the idea behind the change is to augment the fix for > CVE-2017-5852 in svn r1838 [1] to make it a real security update, Hi, being it real security change, there would also follow real security release of PoDoFo, thus everyone can benefit, not only "selected" distributions. > I wonder why no one answered to the last post...) Maybe nobody else than Debian folks care? I'm plain guessing here. > 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 ... I already said my reasoning, PoDoFo project works differently in this aspect. I'm not a decision maker here, neither your change seems to cause any harm, still the change seems useless to me due to the way PoDoFo project releases are done. That doesn't mean I'd object if anyone else will commit your change. And you can always propose the change to the Debian bug you referenced, thus they can verify its correctness. Bye, zyx -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] ABI fix for the fix CVE-2017-5852
Hello zyx, hello all, > zyx has written on 22 October 2017 at 15:34: > > On 21.10.2017 0:59, Matthew Brincke wrote: > > attached is a patch against trunk r1860 (diff -up in svn format) for > > fixing the ABI (changing it back to the 0.9.5 state for the method > > PdfPage::GetInheritedKeyFromObject() after the fix for CVE-2017-5852). > > Hi, > thanks for the patch. I'm sorry, but I want to ask: what is the idea > behind this change, please? I agree that breaking API/ABI is not ideal, > but in case of the PoDoFo project the soname versions are bumped each > release, thus the idea of providing two methods instead of one with an > overloaded argument value doesn't add much to the library users. you're welcome, the idea behind the change is to augment the fix for CVE-2017-5852 in svn r1838 [1] to make it a real security update, in which changing the ABI is not done (for distributors to cherry-pick, inspired by Debian bug 854600 [2], I wonder why no one answered to the last post ...) and to provide a little contribution to ABI stability in the future (sadly, PODOFO_LOCAL is not, AFAIUI in my research [3][4]: cannot be directly, supported on Windows). I mean, with this change committed, the stability of name-lookup-based ABI would be restored for the PoDoFo parts unaffected by the incremental-signing changes (now general incremental-update :-)) IIRC. I wonder why changing a private method is relevant to ABI at all, and (at least when you're still unconvinced ;-) to accept) would welcome your elucidation (if you have come across any, to date), please ... > Thanks and bye, > zyx Best regards, mabri [1] https://sourceforge.net/p/podofo/code/1838/ [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854600 [3] https://msdn.microsoft.com/en-us/library/81h27t8c.aspx [4] https://stackoverflow.com/questions/2810118/how-to-tell-the-mingw-linker-not-to-export-all-symbols -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] ABI fix for the fix CVE-2017-5852
On 21.10.2017 0:59, Matthew Brincke wote: attached is a patch against trunk r1860 (diff -up in svn format) for fixing the ABI (changing it back to the 0.9.5 state for the method PdfPage::GetInheritedKeyFromObject() after the fix for CVE-2017-5852). Hi, thanks for the patch. I'm sorry, but I want to ask: what is the idea behind this change, please? I agree that breaking API/ABI is not ideal, but in case of the PoDoFo project the soname versions are bumped each release, thus the idea of providing two methods instead of one with an overloaded argument value doesn't add much to the library users. Thanks and bye, zyx -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] ABI fix for the fix CVE-2017-5852
Hello all, attached is a patch against trunk r1860 (diff -up in svn format) for fixing the ABI (changing it back to the 0.9.5 state for the method PdfPage::GetInheritedKeyFromObject() after the fix for CVE-2017-5852). I'm sorry to not have tested it because the security policy of the system I'm writing this from doesn't allow me to, please be so kind to test and accept it nevertheless into PoDoFo trunk. Best regards, mabri--- src/doc/PdfPage.h (revision 1860) +++ src/doc/PdfPage.h (working copy) @@ -291,7 +291,10 @@ class PODOFO_DOC_API PdfPage : public Pd /** Method for getting a key value that could be inherited (such as the boxes, resources, etc.) * \returns PdfObject - the result of the key fetching or NULL */ -const PdfObject* GetInheritedKeyFromObject( const char* inKey, const PdfObject* inObject, int depth = 0 ) const; +const PdfObject* GetInheritedKeyFromObject( const char* inKey, const PdfObject* inObject ) const; // wraps the next one + +// this is introduced by the fix for CVE-2017-5852, the depth param counts recursion depth, is checked against a max +const PdfObject* GetInheritedKeyFromObject( const char* inKey, const PdfObject* inObject, int depth ) const PODOFO_LOCAL; /** Get the annotations array. * \param bCreate if true the annotations array is created --- src/doc/PdfPage.cpp (revision 1860) +++ src/doc/PdfPage.cpp (working copy) @@ -212,6 +212,11 @@ PdfRect PdfPage::CreateStandardPageSize( return rect; } +const PdfObject* PdfPage::GetInheritedKeyFromObject( const char* inKey, const PdfObject* inObject ) const +{ +return GetInheritedKeyFromObject( inKey, inObject, 0); +} + const PdfObject* PdfPage::GetInheritedKeyFromObject( const char* inKey, const PdfObject* inObject, int depth ) const { const PdfObject* pObj = NULL; -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users