Bug#817960: libc6: relocation error version GLIBC_PRIVATE not defined in file libc.so.6
Package: libc6 Version: 2.22-2 Severity: critical Justification: breaks the whole system Dear Maintainer, When I upgrade from libc6 2.21-9 to 2.22-2, I get the error "relocation error version GLIBC_PRIVATE not defined in file libc.so.6" whenever I launch most programs (sed, grep, ls, etc.) and the program fails to start. This extends to booting up and so the system is unbootable. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-rc7-chiraag (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#775255: [pkg-fetchmail-maint] Bug#775255: fetchmail: Fails to start when libssl has SSLv3 disabled
Yes, it works with the version of libssl from unstable since SSLv3 is not
disabled in that version. The main problem is that currently, fetchmail does
not work with more secure versions of libssl (which have SSLv3 disabled
completely). I just provided one solution (completely disable SSLv3 in
fetchmail), but if another one (such as automatically detecting that libssl
does not provide SSLv3 and therefore not even attempting to load the SSLv3
symbols) works better, that's fine too.
Currently, the version of fetchmail in experimental is the same as the version
of fetchmail in unstable. If necessary, you could release a different version
of fetchmail for experimental which drops SSLv3 support entirely (if updating
the one in unstable seems like a bad idea currently), since SSLv3 support
*should* be dropped at some point due to the POODLE bug.
This is not an issue of fetchmail negotiating SSLv3 by default, this is an
issue of fetchmail looking for symbols in libssl *which don't exist*. The first
would only surface if, for example, libssl provided an empty implementation of
SSLv3 but still exported the symbols. What's happening right now is that the
symbols don't even exist, which leads to the program not working at all. This
is regardless of whether or not I actually utilize SSLv3 as my protocol (which
I never specifically requested).
- Chiraag
--
Chiraag M Nataraj
Senior at the California Institute of Technology
Email: chiraag.nata...@gmail.com
Phone: 610-350-6329
Website: http://chiraag.nataraj.us
On Wed, Jan 14, 2015 at 12:38:54AM +0100, Nico Golde wrote:
> Hi,
> * Chiraag Nataraj [2015-01-13 12:22]:
> > Package: fetchmail
> > Version: 6.3.26-1+b1
> > Severity: grave
> > Justification: renders package unusable
>
> You filed a bug against a version that works absolutely fine with the openssl
> version it is supposed to work with. Hence, I'm inclined to close that bug or
> downgrade it to wishlist in favor of removing/disabling sslv3 support in
> fetchmail.
>
> > When the latest version of libssl1.0.0 is installed from experimental
> > (which has SSLv3 disabled), Fetchmail exits with the following error:
> >
> > fetchmail: relocation error: fetchmail: symbol SSLv3_client_method, version
> > OPENSSL_1.0.0 not defined in file libssl.so.1.0.0 with link time reference
>
> See above
>
> > Fetchmail should be rebuilt to not require SSLv3.
>
> The patch you included simply removes this feature entirely:
> --- fetchmail-6.3.26/socket.c 2013-04-23 22:00:45.0 +0200
> +++ socket.c2015-01-14 00:29:53.412608735 +0100
> @@ -913,8 +913,6 @@
> report(stderr, GT_("Your operating system does not
> support SSLv2.\n"));
> return -1;
> #endif
> - } else if(!strcasecmp("ssl3",myproto)) {
> - _ctx[sock] = SSL_CTX_new(SSLv3_client_method());
> } else if(!strcasecmp("tls1",myproto)) {
> _ctx[sock] = SSL_CTX_new(TLSv1_client_method());
> } else if (!strcasecmp("ssl23",myproto)) {
>
> In the current git version of fetchmail, sslv3 is not negotiated by default,
> unless a user explicitly requests to do so. As such I'm not sure how useful
> this patch is as well.
>
> Matthias, do you mind weighing in on this?
>
> Thanks
> Nico
> --
> Nico Golde - XMPP: n...@jabber.ccc.de - GPG: 0xA0A0
signature.asc
Description: Digital signature
Bug#775255: Fixed socket.c attached
I have attached the fixed socket.c - as far as I can tell, that appears to fix
the problem. The only change I made was to remove lines 916 and 917.
Sincerely,
Chiraag
--
Chiraag M Nataraj
Senior at the California Institute of Technology
Email: chiraag.nata...@gmail.com
Phone: 610-350-6329
Website: http://chiraag.nataraj.us
/*
* socket.c -- socket library functions
*
* Copyright 1998 by Eric S. Raymond.
* For license terms, see the file COPYING in this directory.
*/
#include "config.h"
#include
#include
#include
#include /* isspace() */
#ifdef HAVE_MEMORY_H
#include
#endif /* HAVE_MEMORY_H */
#include
#include
#ifndef HAVE_NET_SOCKET_H
#include
#else
#include
#endif
#include
#include
#ifdef HAVE_ARPA_INET_H
#include
#endif
#include
#if defined(STDC_HEADERS)
#include
#endif
#if defined(HAVE_UNISTD_H)
#include
#endif
#if defined(HAVE_STDARG_H)
#include
#else
#include
#endif
#if TIME_WITH_SYS_TIME
# include
# include
#else
# if HAVE_SYS_TIME_H
# include
# else
# include
# endif
#endif
#include "socket.h"
#include "fetchmail.h"
#include "getaddrinfo.h"
#include "i18n.h"
#include "sdump.h"
/* Defines to allow BeOS and Cygwin to play nice... */
#ifdef __BEOS__
static char peeked;
#define fm_close(a) closesocket(a)
#define fm_write(a,b,c) send(a,b,c,0)
#define fm_peek(a,b,c) recv(a,b,c,0)
#define fm_read(a,b,c) recv(a,b,c,0)
#else
#define fm_close(a) close(a)
#define fm_write(a,b,c) write(a,b,c)
#define fm_peek(a,b,c) recv(a,b,c, MSG_PEEK)
#ifdef __CYGWIN__
#define fm_read(a,b,c) cygwin_read(a,b,c)
static ssize_t cygwin_read(int sock, void *buf, size_t count);
#else /* ! __CYGWIN__ */
#define fm_read(a,b,c) read(a,b,c)
#endif /* __CYGWIN__ */
#endif
/* We need to define h_errno only if it is not already */
#ifndef h_errno
# if !HAVE_DECL_H_ERRNO
extern int h_errno;
# endif
#endif /* ndef h_errno */
#ifdef HAVE_SOCKETPAIR
static char *const *parse_plugin(const char *plugin, const char *host, const char *service)
{
char **argvec;
const char *c, *p;
char *cp, *plugin_copy;
unsigned int plugin_copy_len;
unsigned int plugin_offset = 0, plugin_copy_offset = 0;
unsigned int i, s = 2 * sizeof(char*), host_count = 0, service_count = 0;
unsigned int plugin_len = strlen(plugin);
unsigned int host_len = strlen(host);
unsigned int service_len = strlen(service);
for (c = p = plugin; *c; c++)
{ if (isspace((unsigned char)*c) && !isspace((unsigned char)*p))
s += sizeof(char*);
if (*p == '%' && *c == 'h')
host_count++;
if (*p == '%' && *c == 'p')
service_count++;
p = c;
}
plugin_copy_len = plugin_len + host_len * host_count + service_len * service_count;
plugin_copy = (char *)malloc(plugin_copy_len + 1);
if (!plugin_copy)
{
report(stderr, GT_("fetchmail: malloc failed\n"));
return NULL;
}
while (plugin_copy_offset < plugin_copy_len)
{ if ((plugin[plugin_offset] == '%') && (plugin[plugin_offset + 1] == 'h'))
{ strcpy(plugin_copy + plugin_copy_offset, host);
plugin_offset += 2;
plugin_copy_offset += host_len;
}
else if ((plugin[plugin_offset] == '%') && (plugin[plugin_offset + 1] == 'p'))
{ strcpy(plugin_copy + plugin_copy_offset, service);
plugin_offset += 2;
plugin_copy_offset += service_len;
}
else
{ plugin_copy[plugin_copy_offset] = plugin[plugin_offset];
plugin_offset++;
plugin_copy_offset++;
}
}
plugin_copy[plugin_copy_len] = 0;
argvec = (char **)malloc(s);
if (!argvec)
{
free(plugin_copy);
report(stderr, GT_("fetchmail: malloc failed\n"));
return NULL;
}
memset(argvec, 0, s);
for (p = cp = plugin_copy, i = 0; *cp; cp++)
{ if ((!isspace((unsigned char)*cp)) && (cp == p ? 1 : isspace((unsigned char)*p))) {
argvec[i] = cp;
i++;
}
p = cp;
}
for (cp = plugin_copy; *cp; cp++)
{ if (isspace((unsigned char)*cp))
*cp = 0;
}
return argvec;
}
static int handle_plugin(const char *host,
const char *service, const char *plugin)
/* get a socket mediated through a given external command */
{
int fds[2];
char *const *argvec;
/*
* The author of this code, Felix von Leitner , says:
* he chose socketpair() instead of pipe() because socketpair creates
* bidirectional sockets while allegedly some pipe() implementations don't.
*/
if (socketpair(AF_UNIX,SOCK_STREAM,0,fds))
{
report(stderr, GT_("fetchmail: socketpair failed\n"));
return -1;
}
switch (fork()) {
case -1:
/* error */
report(stderr, GT_("fetchmail: fork failed\n"));
return -1;
case 0: /* child */
/* fds[1] is the parent's end; close it for proper EOF
** detection */
(void) close(fds[1]);
if ( (dup2(fds[0],0) == -1) || (dup2(fds[0],1) == -1) ) {
report(stderr, GT_("dup2 failed\n"));
_exit(EXIT_FAILURE);
}
/* fds[0] is now connected to 0 and 1; close it */
(void) close(fds[0]);
if (outlevel >= O_VERBOSE)
report(stderr, GT_("running %s (host %s service %s)\n"), plugin, host, service);
argvec = parse_plugin(plugin,host,service);
if (argve
Bug#775255: fetchmail: Fails to start when libssl has SSLv3 disabled
Package: fetchmail Version: 6.3.26-1+b1 Severity: grave Justification: renders package unusable Dear Maintainer, When the latest version of libssl1.0.0 is installed from experimental (which has SSLv3 disabled), Fetchmail exits with the following error: fetchmail: relocation error: fetchmail: symbol SSLv3_client_method, version OPENSSL_1.0.0 not defined in file libssl.so.1.0.0 with link time reference Fetchmail should be rebuilt to not require SSLv3. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.18.0-chiraag (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fetchmail depends on: ii adduser 3.113+nmu3 ii debianutils 4.4+b1 ii libc6 2.19-13 ii libcomerr21.42.12-1 ii libgssapi-krb5-2 1.13~alpha1+dfsg-1 ii libkrb5-3 1.13~alpha1+dfsg-1 ii libssl1.0.0 1.0.2~beta3-1 ii lsb-base 4.1+Debian13+nmu1 Versions of packages fetchmail recommends: ii ca-certificates 20141019 Versions of packages fetchmail suggests: pn default-mta | mail-transport-agent pn fetchmailconf pn resolvconf -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
