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

2017-11-12 Thread Peter Linnell 
On Fri, 27 Oct 2017 00:54:11 +0200 (CEST)
Matthew Brincke  wrote:

> 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

2017-11-12 Thread Mattia Rizzolo 
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

2017-10-26 Thread Matthew Brincke 
Hello Mattia,

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

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

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

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

-- 
> regards,
>  Mattia Rizzolo
> 

Best regards, mabri

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

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

2017-10-23 Thread Mattia Rizzolo 
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

2017-10-23 Thread zyx 
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

2017-10-22 Thread Matthew Brincke 
Hello zyx, hello all,

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

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

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

>  Thanks and bye,
>  zyx

Best regards, mabri

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

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

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

2017-10-22 Thread zyx 

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

2017-10-20 Thread Matthew Brincke 
Hello all,

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

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