openssl-0.9.8g-r2 (of course a security upgrade) removes < libssl.so.0.9.8 and < libcrypto.so.0.9.8. Past ebuilds of openssl-0.9.8* didn't do that. Removal of those libraries breaks a number of things without warning on systems (for instance production servers) that have not been aggressively updated (but only when security concerns mandated it). For instance, older versions of wget fail without, say libssl.so.0.9.7 - which means that even emerge, when it goes to run wget, breaks. In my case (production server) doing the wrong thing - symlinking the 0.9.8 libraries to 0.9.7 and 0.9.6 has temporarily fixed things well enough so far. But the right way to have handled this is for the openssl ebuild to have left the earlier library versions, then presented instructions on how to identify what's linked against them, rebuild that, and then manually remove them. The security issue here, after all, is not high level - its potential DoS for ssl-linked apps, not intrusion. Forcing breakage of systems is not warranted. What it teaches sysadmins is not to trust Gentoo security upgrades, which in the long term will lead to not quickly implementing them. Reproducible: Always
Sure this isn't local problem? openssl-0.9.8g-r2 has the preserve_old_lib() hack still in place - unless you added "preserve-libs" as feature flag - something you should not do without running Portage 2.2.
I did not use a "preserve-libs" flag. Here's how it ran: # emerge -pv openssl ... [ebuild R ] dev-libs/openssl-0.9.8g-r2 USE="zlib -bindist -gmp -kerberos -sse2 -test" 0 kB That was just after installing portage-2.2_rc1 (I have ~x86 set for portage in package.keywords). So this may be specific to installing openssl-0.9.8g-r2 with portage-2.2_rc1. (As for why I have ~x86 for portage, there must have been something previous I needed that depended on updating portage first.) The old libraries definitely disappeared right with the install. The server happens to run pure-ftpd with authorization through a php4 script (against a MySQL database). The older libraries that php4 was compiled against disappeared right then, and so the log ins all started failing at the precise moment. Phone calls from concerned clients (this being part of a data service) followed shortly. Perhaps I should have used a "preserve-libs" flag? Sorry to say I don't know anything about it. I did look at the flags openssl proposed to use first, but as you see it doesn't show up there.
First a paragraph starting with "my production server" and then admitting to run testing Portage - do you have an idea what I think about that?! Yes, running Portage 2.2 you should and it should probably be default - just that there are or at least were bugs open regarding this feature afaik. @Portage team: Before Portage 2.2 goes stable, this feature definitely needs to be enabled by default.
(In reply to comment #3) > @Portage team: Before Portage 2.2 goes stable, this feature definitely needs to > be enabled by default. It is already enabled by default.
Hi Carsten, It's not worth pedantry points to go search out the documentation to prove this, but at least at one time ~x86 did _not_ mean "testing," it meant "stable on x86." Also, I _never_ switch anything to ~x86 unless the "stable on all platforms" version turns out to be broken at a particular time, so that going to a later version is the most reasonable way to work around that. It generally is. Filing a bug report against the older version often gets a "please try the newer version in ~x86" response. Some problems, the best way is forward, not back, especially in contexts where "back" involves insecure stuff on a public-facing server. Hey Marius, So if it's "enable by default," and I accepted the defaults, you admit you've got a bug?
i'm sorry, but "~x86" has *never* *ever* meant "stable on x86". ive been around before we even had the notion of ~arch, and assisted in defining things, and that is absolutely never been a valid interpretation. please read the bugzilla documentation. you need to post `emerge --info` whenever filing a bug.
SpanKY, I'll grant you the one if you grant me the other - that it's sometimes _necessary_ in working around a bug the current "x86" (not ~x86) version to either go forward (to ~x86) or go back (to something that in some cases turns out to be incompatible with another package that's a current security concern). Yes, it's perverse. But the "stable" stuff is sometimes _less_ stable than the more recent version (since on the whole there's progress in software, and destabilizing bugs decrease, on average, as versions iterate). I've _never_ gone to ~x86 except when the current x86 version was bad. However, once moved up to ~x86, it's a PITA to move back, since the dependencies build up, so I tend to leave it in package.keywords. For better or worse, I've been running Gentoo since a few months after its initial release. Personally, I'd say y'all made a bad decision in rejecting drobbins' recent offer to take back the helm. Quality isn't what it used to be - far too many packages arbitrarily switch default flags between versions, which isn't quite the problem here, although this does appear to be flag related - that one's supposed to be defaulted to that isn't even displayed to emerge -p, so how would a person ever tell? (And yes, I carefully go through the flags with each package upgraded any more, after the increasingly-bizarre defaults bit me a few times too many.) Anyway, here's your --info - if you really want this noise in every single report.... # emerge --info Portage 2.2_rc1 (default-linux/x86/2007.0/server, gcc-3.3.6, glibc-2.3.5-r2, 2.4.20 i686) ================================================================= System uname: Linux-2.4.20-i686-Intel-R-_Pentium-R-_III_CPU_-_S_________1400MHz-with-glibc2.0 Timestamp of tree: Fri, 27 Jun 2008 14:03:01 +0000 app-shells/bash: 3.2_p17 dev-lang/python: 2.2.3-r5, 2.3.4, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.11.13-r1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1, 1.10 sys-devel/binutils: 2.16.1 sys-devel/gcc-config: 1.3.12-r4 sys-devel/libtool: 1.4.3-r4, 1.5.23b virtual/os-headers: 2.4.19-r1, 2.4.26-r1 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo" CXXFLAGS="-march=pentium3 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks parallel-fetch preserve-libs sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl apache2 berkdb cli cracklib crypt dri fortran gdbm gpm iconv ipv6 isdnlog ldap mailwrapper mbox midi mudflap mysql ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session spl ssl tcpd truetype unicode x86 xml xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
i didnt say there wasnt a bug. as Carsten said, expecting ~x86 to not break x86 and being surprised when it does is unreasonable. especially on a production machine.
(In reply to comment #5) > So if it's "enable by default," and I accepted the defaults, you admit you've > got a bug? I haven't really looked at the issue yet.
Another example of this removal being an issue: net-misc/dropbox-1.2.51 depends on dev-libs/openssl:0.9.8, because it wants to have libssl.so.0.9.8 and libcrypto.so.0.9.8 available, but the new dev-libs/openssl-0.9.8t removes those libraries (defeating the purpose of depending on dev-libs/openssl:0.9.8 in the first place).
i've just deleted the logic now. no point in keeping it around anymore. Commit message: Drop upgrade logic for avoiding collisions as these versions are very old at this point http://sources.gentoo.org/dev-libs/openssl/openssl-0.9.8y.ebuild?r1=1.8&r2=1.9
