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 |Received on Wed Sep 29 2004 - 14:49:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:14 UTC