2:23 p.m.
I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64
this morning, and now I get this stderr output:
$ /usr/bin/stap -V >/dev/null
/usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in
shared object, consider re-linking
The message comes from ld.so; that symbol comes from libssl3.so.
Should I be worried about this? Do we need a rebuild of all
nss-dependent packages to clear this message?
11:38 p.m.
New subject: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
On 08/28/2015 03:23 PM, Josh Stone wrote:
I update from nss-3.19.3-1.0.fc22.x86_64 to
nss-3.20.0-1.0.fc22.x86_64
this morning, and now I get this stderr output:
$ /usr/bin/stap -V >/dev/null
/usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in
shared object, consider re-linking
The message comes from ld.so; that symbol comes from libssl3.so.
Should I be worried about this? Do we need a rebuild of all
nss-dependent packages to clear this message?
Well, it's an ABI break. If you care about ABI issues then the change
causing the breakage needs reverting and the broken packages need to
be rebuilt.
c.
6:14 a.m.
New subject: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
On Pá, 2015-09-04 at 00:38 -0400, Carlos O'Donell wrote:
On 08/28/2015 03:23 PM, Josh Stone wrote:
> I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64
> this morning, and now I get this stderr output:
>
> $ /usr/bin/stap -V >/dev/null
> /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in
> shared object, consider re-linking
>
> The message comes from ld.so; that symbol comes from libssl3.so.
>
> Should I be worried about this? Do we need a rebuild of all
> nss-dependent packages to clear this message?
Well, it's an ABI break. If you care about ABI issues then the change
causing the breakage needs reverting and the broken packages need to
be rebuilt.
The size of the SSL_ImplementedCiphers array is not part of the public
API so it is not really an ABI break in practice. However ld.so of
course cannot know that. Is there any way to make the message disappear
other than rebuild of the dependent package? I am afraid that
unfortunately not.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
8:38 a.m.
New subject: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
On Fri, 2015-09-04 at 13:14 +0200, Tomas Mraz wrote:
On Pá, 2015-09-04 at 00:38 -0400, Carlos O'Donell wrote:
> On 08/28/2015 03:23 PM, Josh Stone wrote:
> > I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64
> > this morning, and now I get this stderr output:
> >
> > $ /usr/bin/stap -V >/dev/null
> > /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in
> > shared object, consider re-linking
> >
> > The message comes from ld.so; that symbol comes from libssl3.so.
> >
> > Should I be worried about this? Do we need a rebuild of all
> > nss-dependent packages to clear this message?
>
> Well, it's an ABI break. If you care about ABI issues then the change
> causing the breakage needs reverting and the broken packages need to
> be rebuilt.
The size of the SSL_ImplementedCiphers array is not part of the public
API so it is not really an ABI break in practice. However ld.so of
course cannot know that. Is there any way to make the message disappear
other than rebuild of the dependent package? I am afraid that
unfortunately not.
If it not public why is it exported in the first place ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
8:41 a.m.
New subject: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
On 09/04/2015 03:38 PM, Simo Sorce wrote:
On Fri, 2015-09-04 at 13:14 +0200, Tomas Mraz wrote:
> On Pá, 2015-09-04 at 00:38 -0400, Carlos O'Donell wrote:
>> On 08/28/2015 03:23 PM, Josh Stone wrote:
>>> I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64
>>> this morning, and now I get this stderr output:
>>>
>>> $ /usr/bin/stap -V >/dev/null
>>> /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in
>>> shared object, consider re-linking
>>>
>>> The message comes from ld.so; that symbol comes from libssl3.so.
>>>
>>> Should I be worried about this? Do we need a rebuild of all
>>> nss-dependent packages to clear this message?
>>
>> Well, it's an ABI break. If you care about ABI issues then the change
>> causing the breakage needs reverting and the broken packages need to
>> be rebuilt.
>
> The size of the SSL_ImplementedCiphers array is not part of the public
> API so it is not really an ABI break in practice. However ld.so of
> course cannot know that. Is there any way to make the message disappear
> other than rebuild of the dependent package? I am afraid that
> unfortunately not.
If it not public why is it exported in the first place ?
The *size* is not part of the ABI, but the symbol is. ELF keeps track
of data here which is completely pointless.
There is no way to obtain the actual size of the array from C, so I
think the warning could be suppressed using a symbol alias with a
constant size.
--
Florian Weimer / Red Hat Product Security
8:57 a.m.
New subject: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
On Fri, 2015-09-04 at 15:41 +0200, Florian Weimer wrote:
On 09/04/2015 03:38 PM, Simo Sorce wrote:
> On Fri, 2015-09-04 at 13:14 +0200, Tomas Mraz wrote:
>> On Pá, 2015-09-04 at 00:38 -0400, Carlos O'Donell wrote:
>>> On 08/28/2015 03:23 PM, Josh Stone wrote:
>>>> I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64
>>>> this morning, and now I get this stderr output:
>>>>
>>>> $ /usr/bin/stap -V >/dev/null
>>>> /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size
in
>>>> shared object, consider re-linking
>>>>
>>>> The message comes from ld.so; that symbol comes from libssl3.so.
>>>>
>>>> Should I be worried about this? Do we need a rebuild of all
>>>> nss-dependent packages to clear this message?
>>>
>>> Well, it's an ABI break. If you care about ABI issues then the change
>>> causing the breakage needs reverting and the broken packages need to
>>> be rebuilt.
>>
>> The size of the SSL_ImplementedCiphers array is not part of the public
>> API so it is not really an ABI break in practice. However ld.so of
>> course cannot know that. Is there any way to make the message disappear
>> other than rebuild of the dependent package? I am afraid that
>> unfortunately not.
>
> If it not public why is it exported in the first place ?
The *size* is not part of the ABI, but the symbol is. ELF keeps track
of data here which is completely pointless.
I see, I wonder why not just expose a pointer instead of an array.
There is no way to obtain the actual size of the array from C, so I
think the warning could be suppressed using a symbol alias with a
constant size.
Would changing the symbol to a pointer break the ABI ?
It probably will cause the same kind of warning even though it probably
makes no real difference in all the architectures we care about.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
8:49 a.m.
New subject: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
On Fri, Sep 04, 2015 at 01:14:08PM +0200, Tomas Mraz wrote:
On Pá, 2015-09-04 at 00:38 -0400, Carlos O'Donell wrote:
> On 08/28/2015 03:23 PM, Josh Stone wrote:
> > I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64
> > this morning, and now I get this stderr output:
> >
> > $ /usr/bin/stap -V >/dev/null
> > /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in
> > shared object, consider re-linking
> >
> > The message comes from ld.so; that symbol comes from libssl3.so.
> >
> > Should I be worried about this? Do we need a rebuild of all
> > nss-dependent packages to clear this message?
>
> Well, it's an ABI break. If you care about ABI issues then the change
> causing the breakage needs reverting and the broken packages need to
> be rebuilt.
The size of the SSL_ImplementedCiphers array is not part of the public
API so it is not really an ABI break in practice. However ld.so of
course cannot know that. Is there any way to make the message disappear
other than rebuild of the dependent package? I am afraid that
unfortunately not.
Clearly it is used by some programs, so it should be considered part of the
public API. If it wasn't meant to be exported, it should not have been
exported. The ld.so warning is only emitted if there is a copy relocation
against that symbol and the symbol has different size in the copy relocation
vs. the new size in the shared library.
Jakub
8:58 a.m.
New subject: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
On 09/04/2015 03:49 PM, Jakub Jelinek wrote:
Clearly it is used by some programs, so it should be considered part
of the
public API. If it wasn't meant to be exported, it should not have been
exported. The ld.so warning is only emitted if there is a copy relocation
against that symbol and the symbol has different size in the copy relocation
vs. the new size in the shared library.
Ugh, I forgot.
Will the process use the size from the shared library, or will the
object be truncated, so that when the library tries to traverse the
array (using its hard-coded size), it will read past the end of the
allocated portion?
--
Florian Weimer / Red Hat Product Security
9:11 a.m.
New subject: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
On Fri, Sep 04, 2015 at 03:58:12PM +0200, Florian Weimer wrote:
On 09/04/2015 03:49 PM, Jakub Jelinek wrote:
> Clearly it is used by some programs, so it should be considered part of the
> public API. If it wasn't meant to be exported, it should not have been
> exported. The ld.so warning is only emitted if there is a copy relocation
> against that symbol and the symbol has different size in the copy relocation
> vs. the new size in the shared library.
Ugh, I forgot.
Will the process use the size from the shared library, or will the
object be truncated, so that when the library tries to traverse the
array (using its hard-coded size), it will read past the end of the
allocated portion?
It copies the minimum of the two sizes.
Jakub
10 a.m.
New subject: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
On 09/04/2015 04:11 PM, Jakub Jelinek wrote:
On Fri, Sep 04, 2015 at 03:58:12PM +0200, Florian Weimer wrote:
> On 09/04/2015 03:49 PM, Jakub Jelinek wrote:
>
>> Clearly it is used by some programs, so it should be considered part of the
>> public API. If it wasn't meant to be exported, it should not have been
>> exported. The ld.so warning is only emitted if there is a copy relocation
>> against that symbol and the symbol has different size in the copy relocation
>> vs. the new size in the shared library.
>
> Ugh, I forgot.
>
> Will the process use the size from the shared library, or will the
> object be truncated, so that when the library tries to traverse the
> array (using its hard-coded size), it will read past the end of the
> allocated portion?
It copies the minimum of the two sizes.
Do references in other dynamic shared objects matter for determining the
final size? Or is this simply between the main program and the library
which defines the symbol?
--
Florian Weimer / Red Hat Product Security
10:04 a.m.
New subject: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
On Fri, Sep 04, 2015 at 05:00:15PM +0200, Florian Weimer wrote:
On 09/04/2015 04:11 PM, Jakub Jelinek wrote:
> On Fri, Sep 04, 2015 at 03:58:12PM +0200, Florian Weimer wrote:
>> On 09/04/2015 03:49 PM, Jakub Jelinek wrote:
>>
>>> Clearly it is used by some programs, so it should be considered part of the
>>> public API. If it wasn't meant to be exported, it should not have been
>>> exported. The ld.so warning is only emitted if there is a copy relocation
>>> against that symbol and the symbol has different size in the copy
relocation
>>> vs. the new size in the shared library.
>>
>> Ugh, I forgot.
>>
>> Will the process use the size from the shared library, or will the
>> object be truncated, so that when the library tries to traverse the
>> array (using its hard-coded size), it will read past the end of the
>> allocated portion?
>
> It copies the minimum of the two sizes.
Do references in other dynamic shared objects matter for determining the
final size? Or is this simply between the main program and the library
which defines the symbol?
Well, only the program (normal or PIE) and the DSO that defines the symbol
matters for determining the size that is copied by the copy relocation
of course. But, other DSOs (which do not use copy relocations) will
supposedly refer to the definition in the main program, so in this case
one with the smaller size (if any).
Jakub
12:32 p.m.
New subject: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
On 09/04/2015 07:11 AM, Jakub Jelinek wrote:
On Fri, Sep 04, 2015 at 03:58:12PM +0200, Florian Weimer wrote:
> On 09/04/2015 03:49 PM, Jakub Jelinek wrote:
>
>> Clearly it is used by some programs, so it should be considered part of the
>> public API. If it wasn't meant to be exported, it should not have been
>> exported. The ld.so warning is only emitted if there is a copy relocation
>> against that symbol and the symbol has different size in the copy relocation
>> vs. the new size in the shared library.
>
> Ugh, I forgot.
>
> Will the process use the size from the shared library, or will the
> object be truncated, so that when the library tries to traverse the
> array (using its hard-coded size), it will read past the end of the
> allocated portion?
It copies the minimum of the two sizes.
FWIW I found this Mozilla bug which added accessor functions:
https://bugzilla.mozilla.org/show_bug.cgi?id=496993
I think the comment about this being "pedantic nonsense" is very wrong,
especially since this minimum size copied will not match with reported
SSL_NumImplementedCiphers. Or if you rely on the 0-terminating entry of
that array, that might not be copied and you'll go off the end.
Anyway, I'll see about porting my code to the accessor functions to
sidestep the whole issue.
3150
days inactive
3157
days old
11 comments
6 participants
participants (6)
-
Carlos O'Donell -
Florian Weimer -
Jakub Jelinek -
Josh Stone -
Simo Sorce -
Tomas Mraz