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