HEADS-UP: Library version number bumps

Ken Smith kensmith at cse.Buffalo.EDU
Wed Sep 29 09:49:50 PDT 2004


On Wed, Sep 29, 2004 at 03:40:11PM +0300, Ruslan Ermilov wrote:

> Can you or Kris post some additional details of what in these
> libraries have changed so they can't be used for 4.x binaries?

Kris has a script that compares the symbols in libraries.  The raw
output of that run against 4.X and 5.X is here:

	http://people.freebsd.org/~kensmith/library_symbols.txt

(at least until the next time /d gets full on freefall...).

And below is the analysis he sent us based on what libraries the
ports use and what level to expect breakage at.  Keep in mind it's
not a perfect world so we're being a tiny bit conservative on a
couple of things.  For example some of the libraries had 'extern'
keywords removed from some of their variables but a quick glance
at the code suggests that *might* be the only substantial change.
One would hope the developers of the library knew what they were
doing and those variables were not part of the library's published
interfaces.  But programmers have been known to use unpublished
things like this from time to time so ...

From: Kris Kennaway <kris at obsecurity.org>
Subject: Re: Library symbol comparison

I did an audit of the 4.x package collection for binaries that link to
the libraries in my earlier list.

Summary: libpcap.so.2 must be bumped.  It's likely libopie will need
to be too, but I haven't been able to exhibit the failure mode.  I
also think libhistory and libreadline may have runtime failures in
certain situations because the unresolved mbrlen/mbrtowc symbols that
are present in the 5.x library, but I haven't worked out how to
trigger this.  If so, they must be bumped too. =20

The others are still unclear because the symbols removed were global
(extern) variables.  These do not cause runtime linker problems, but
if a 4.x binary sets the variable expecting the library to change its
behaviour as it would in 4.x, it will be disappointed since the 5.x
library has forgotten all about it.  I think the only way to check for
this is to look closely at what the variables do and to audit the
source code for all affected ports.


libpcap.so.2
[5.x]
    64: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __xuname

[4.x]
    23: 000052ec    83 FUNC    GLOBAL DEFAULT    9 yy_delete_buffer
    35: 00005138    89 FUNC    GLOBAL DEFAULT    9 yyrestart
    41: 0001bb6c     4 OBJECT  GLOBAL DEFAULT   18 yystacksize
    52: 000053fc   169 FUNC    GLOBAL DEFAULT    9 yy_scan_buffer
    53: 00005260   135 FUNC    GLOBAL DEFAULT    9 yy_create_buffer
    54: 00005204    88 FUNC    GLOBAL DEFAULT    9 yy_load_buffer_state
    59: 0001bb70     4 OBJECT  GLOBAL DEFAULT   18 yyerrflag
    64: 0001bb40     4 OBJECT  GLOBAL DEFAULT   18 yytext
    72: 0000ec98  4048 FUNC    GLOBAL DEFAULT    9 yyparse
    77: 0001bb74     4 OBJECT  GLOBAL DEFAULT   18 yysslim
    90: 0001bb78     4 OBJECT  GLOBAL DEFAULT   18 yyvsp
   101: 000056b0    12 FUNC    GLOBAL DEFAULT    9 yywrap
   104: 0001bb7c     4 OBJECT  GLOBAL DEFAULT   18 yyssp
   120: 0001bb88     4 OBJECT  GLOBAL DEFAULT   18 yynerrs
   121: 0001af60     4 OBJECT  GLOBAL DEFAULT   12 yyout
   122: 0001bb8c     8 OBJECT  GLOBAL DEFAULT   18 yyval
   124: 0001bb44     4 OBJECT  GLOBAL DEFAULT   18 yyleng
   126: 0001bb94     4 OBJECT  GLOBAL DEFAULT   18 yyss
   139: 000053a4    83 FUNC    GLOBAL DEFAULT    9 yy_flush_buffer
   150: 000054ac    52 FUNC    GLOBAL DEFAULT    9 yy_scan_string
   163: 000054e4   151 FUNC    GLOBAL DEFAULT    9 yy_scan_bytes
   166: 0001af5c     4 OBJECT  GLOBAL DEFAULT   12 yyin
   173: 0001bb98     4 OBJECT  GLOBAL DEFAULT   18 yydebug
   191: 00005198   102 FUNC    GLOBAL DEFAULT    9 yy_switch_to_buffer
   193: 00005344    91 FUNC    GLOBAL DEFAULT    9 yy_init_buffer
   201: 00004070  2870 FUNC    GLOBAL DEFAULT    9 yylex
   208: 0001bb9c     4 OBJECT  GLOBAL DEFAULT   18 yyvs
   210: 0001bba0     4 OBJECT  GLOBAL DEFAULT   18 yychar

Affected packages:
bandwidthd-1.2.1
bro-0.8_1
honeyd-0.8b
ipfm-0.11.5
rid-1.0

e.g.

pointyhat# ./ipfm
/usr/libexec/ld-elf.so.1: /usr/lib/libpcap.so.2: Undefined symbol "__xuname"

If this were fixed by removing the __xuname reference from libpcap, I
think binaries would still be broken because of the functions removed
from the 5.x version.

=3D=3D=3D=3D
libopie.so.2
[5.x]
    37: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __xuname

Should have the same failure mode as libpcap.  I havent been able to
test this because it requires configuring the software, but the
following ports link to libopie:

qpopper-2.53_4
tac_plus-F4.0.4_3
cyrus-sasl-2.1.19
wu-ftpd-2.6.2_5
wu-ftpd+ipv6-2.6.2_6
fetchmail-6.2.5_2

OTOH, running the 4.x opiekey binary on 5.x dumps core, so perhaps
something in the on-disk format changed too and this is all moot:

pointyhat# opiekey 1 foobar
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Segmentation fault (core dumped)
pointyhat# gdb opiekey opiekey.core
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain condition=
s.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols f=
ound)...
Core was generated by `opiekey'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libopie.so.2...(no debugging symbols found)..=
.done.
Reading symbols from /usr/lib/libmd.so.2...(no debugging symbols found)...d=
one.
Reading symbols from /usr/lib/libc.so.4...(no debugging symbols found)...do=
ne.
Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found=
)...done.
#0  0x2806d478 in __opiegetutmpentry () from /usr/lib/libopie.so.2
(gdb) bt
#0  0x2806d478 in __opiegetutmpentry () from /usr/lib/libopie.so.2
#1  0x2806c452 in opieinsecure () from /usr/lib/libopie.so.2
#2  0x8048e30 in opieversion ()
#3  0x80488fa in opieversion ()

=3D=3D=3D=3D
libhistory.so.4
1) mbrlen reference added to new version of common libraries but is unresol=
ved within common libraries
1) mbrtowc reference added to new version of common libraries but is unreso=
lved within common libraries

There are code paths in the new library that call these unresolved
functions, so 4.x binaries will fail if they hit these codepaths.  I
don't know what triggers that though.

=3D=3D=3D=3D
libreadline.so.4:
1) mbrlen reference added to new version of common libraries but is unresol=
ved within common libraries
1) mbrtowc reference added to new version of common libraries but is unreso=
lved within common libraries

    32: 000245a8     4 OBJECT  GLOBAL DEFAULT   12 rl_line_buffer
    44: 00021636     1 OBJECT  GLOBAL DEFAULT   12 history_comment_char
    47: 0002456c     4 OBJECT  GLOBAL DEFAULT   12 rl_instream
    91: 0002457c     4 OBJECT  GLOBAL DEFAULT   12 rl_already_prompted
   107: 00024574     4 OBJECT  GLOBAL DEFAULT   12 readline_echoing_p
   115: 000245ac     4 OBJECT  GLOBAL DEFAULT   12 rl_line_buffer_len
   127: 00024560     4 OBJECT  GLOBAL DEFAULT   12 rl_explicit_arg
   224: 00024568     4 OBJECT  GLOBAL DEFAULT   12 rl_last_func
   240: 00021660     4 OBJECT  GLOBAL DEFAULT   12 _rl_last_c_pos
   242: 00024594     4 OBJECT  GLOBAL DEFAULT   12 rl_terminal_name
   265: 00024590     4 OBJECT  GLOBAL DEFAULT   12 rl_pending_input
   271: 000215f0     4 OBJECT  GLOBAL DEFAULT   12 rl_event_hook
   283: 00024570     4 OBJECT  GLOBAL DEFAULT   12 rl_outstream
   336: 000218a4     4 OBJECT  GLOBAL DEFAULT   12 rl_completion_type
   350: 000245a4     4 OBJECT  GLOBAL DEFAULT   12 rl_erase_empty_line
   375: 00024588     4 OBJECT  GLOBAL DEFAULT   12 rl_pre_input_hook
   456: 000218c0     4 OBJECT  GLOBAL DEFAULT   12 rl_special_prefixes
   552: 00021600     4 OBJECT  GLOBAL DEFAULT   12 _rl_executing_macro
   555: 00024584     4 OBJECT  GLOBAL DEFAULT   12 rl_startup_hook
   559: 000218dc     4 OBJECT  GLOBAL DEFAULT   12 rl_char_is_quoted_p

=3D=3D=3D=3D
libm.so.2

   221: 00019de0     4 OBJECT  GLOBAL DEFAULT   12 signgam

Global variables.

=3D=3D=3D=3D
libgnuregex.so.2

    22: 000075cc     4 OBJECT  GLOBAL DEFAULT   12 re_syntax_options

Global variables.

=3D=3D=3D=3D
libwrap.so.3
    83: 00006b78     4 OBJECT  GLOBAL DEFAULT   12 dry_run

Global variables.

=3D=3D=3D=3D
libncurses.so.5
    23: 0003e270     4 OBJECT  GLOBAL DEFAULT   12 SP
   166: 0000ee58    26 FUNC    GLOBAL DEFAULT    9 _nc_tracebits
   170: 00037c0e     2 OBJECT  GLOBAL DEFAULT   12 ospeed
   175: 00037c2c     4 OBJECT  GLOBAL DEFAULT   12 TABSIZE
   188: 00036870     4 OBJECT  GLOBAL DEFAULT   12 BC
   247: 00037744     4 OBJECT  GLOBAL DEFAULT   12 COLOR_PAIRS
   333: 00037c0c     1 OBJECT  GLOBAL DEFAULT   12 PC
   370: 00037c1c     4 OBJECT  GLOBAL DEFAULT   12 cur_term
   406: 00037540   512 OBJECT  GLOBAL DEFAULT   12 acs_map
   434: 00037748     4 OBJECT  GLOBAL DEFAULT   12 COLORS
   450: 0003e260     4 OBJECT  GLOBAL DEFAULT   12 stdscr
   495: 00037c28     4 OBJECT  GLOBAL DEFAULT   12 COLS
   498: 0003e268     4 OBJECT  GLOBAL DEFAULT   12 newscr
   515: 0003e264     4 OBJECT  GLOBAL DEFAULT   12 curscr
   528: 0003686c     4 OBJECT  GLOBAL DEFAULT   12 UP
   545: 00037c24     4 OBJECT  GLOBAL DEFAULT   12 LINES
py23-ncurses-0.3_1: lib/python2.3/site-packages/ncurses/_curses.so (libncur=
ses.so.5) matches symbols _nc_tracebits TABSIZE COLOR_PAIRS acs_map COLORS =
stdscr COLS LINES _nc_tracebits TABSIZE COLOR_PAIRS acs_map COLORS stdscr C=
OLS LINES
ruby18-ncurses-0.9.1: lib/ruby/site_ruby/1.8/i386-freebsd4/ncurses.so (libn=
curses.so.5) matches symbols _nc_tracebits TABSIZE COLOR_PAIRS acs_map COLO=
RS stdscr COLS newscr curscr LINES _nc_tracebits TABSIZE COLOR_PAIRS acs_ma=
p COLORS stdscr COLS newscr curscr LINES

These ports appear to provide bindings for the ncurses.so.5 API, so
the only new problem here is if a ruby or python script called
_nc_tracebits, which is probably unlikely (According to curs_trace(3)
this is a debugging function).

Every other library in my earlier list is unused by the ports
collection, but may be used by other third party applications, so
certain libraries may still warrant bumps.

Kris

--lrZ03NoBR/3+SXJZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)

iD4DBQFBWDqtWry0BWjoQKURAtUUAJ4nWrdS5ASnN6Ig+iT5mm2rzj5hVQCYkUck
Zy2GH0pXsFp1/UvxIp+u9Q==
=i27U
-----END PGP SIGNATURE-----

--lrZ03NoBR/3+SXJZ--



-- 
						Ken Smith
- From there to here, from here to      |       kensmith at cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |


More information about the freebsd-current mailing list