Bug#837700: gnutls: GNUTLS segfaults on initialization

2016-09-14 Thread J Phelps

>Can you provide a (simple) way to reproduce the issue?

Reproduction was simple on my machine: Just try to run Chromium 53.0.2785.92,
which depends on libgnutls30. It crashed immediately.

I had just upgraded from a much older version of Chromium (in the 30s IIRC)
using Aptitude.

Running it under GDB showed that the segfault happened in Nettle.

>Your diagnosis cannot be completely correct. e.g. libgnutls30
>3.5.4-2 on i386 (which you reported the issue against) was built against
>nettle-dev i386 3.2-1 which continues to be the latest version of nettle
>available in Debian. So you cannot experience a breakage in Debian
>caused by the Debian-installed nettle version being newer and having a
>different ABI than the version GnuTLS was built against.

I think that the binary in the .deb package was compiled from a different
Nettle source than the one that you find in the corresponding .dsc package.
Otherwise, compiling the .dsc package should have given me a binary that was
compatible with the one that was already installed on my system.

Instead, I had unresolved symbols (I don't remember which ones), and I had
to go to Nettle's Git repository (https://git.lysator.liu.se/nettle/nettle)
to find source code that could produce a linkable library. The symbols
that were unresolved were only found in the "ecc-support" branch of that
repo. Compiling from the trunk led to the same symbols being unresolved.

The recompiled library produced the same crash as the original binary. The
diagnosis was done with the Git version of Nettle and the .dsc version of
libgnutls.



Bug#837700: gnutls: GNUTLS segfaults on initialization

2016-09-13 Thread J Phelps
Package: libgnutls30
Version: 3.5.4-2
Severity: grave
File: gnutls
Justification: renders package unusable

The bug is caused by GNUTLS being compiled with the headers of and old
version of Nettle, but the package depending on (or failing to account
for a breaking change to) a newer version of Nettle.

In the newer version of Nettle, in the struct "yarrow256_ctx", the type
of the "key" member has changed from "aes256_ctx" to "aes_ctx".

"aes_ctx" is like "aes256_ctx", except it has an extra integer, which
makes the whole yarrow256_ctx type one integer bigger as well.

GNUTLS contains a yarrow256_ctx in one of its structs, followed
immediately by a buffer, but it's compiled with the old yarrow256_ctx,
which is too small. Both the struct and the buffer are passed
as arguments to yarrow256_init, but in Nettle's code, yarrow256_ctx
is bigger, so the buffer is treated as being within the yarrow256_ctx
object's address space. As a result, initializing the buffer overwrites
a pointer in the yarrow256_ctx object, leading to a NULL pointer
dereference.

A quick fix to this problem is to simply edit /usr/include/nettle/yarrow.h
and add a padding integer (of type "unsigned") to its definition of
"yarrow256_ctx" right after the "key" object, and then recompiling
GNUTLS. This is good enough, since GNUTLS doesn't look at the internal
structure of yarrow256_ctx, so only the size needs to be corrected.

By doing this, I was able to get Chromium 53.0.2785.92 working, which was
previously crashing because of this problem.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libgnutls30:i386 depends on:
ii  libc62.24-2
ii  libgmp10 2:6.0.0+dfsg-6
ii  libhogweed4  3.2-1
ii  libidn11 1.28-1
ii  libnettle6   3.2-1
ii  libp11-kit0  0.23.2-5
ii  libtasn1-6   4.8-1
ii  zlib1g   1:1.2.8.dfsg-1

libgnutls30:i386 recommends no packages.

Versions of packages libgnutls30:i386 suggests:
pn  gnutls-bin  

-- no debconf information



Bug#561514: Can't load mplayer: libcucul.so.0 not found

2009-12-17 Thread J Phelps
Package: mplayer
Version: 1.0~rc2-6
Severity: grave
Justification: renders package unusable


After an upgrade, I noticed that mplayer is completely broken. It depends
on a file called libcucul.so.0, which was replaced in the repository with
a similarly-named libcaca (on which mplayer also depends). Running mplayer
is impossible.

Furthermore, installing mplayer from the repository is also impossible,
because of some dependencies that are not going to be installed.


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages mplayer depends on:
ii  debconf [debconf-2.0]  1.5.28Debian configuration management sy
ii  libasound2 1.0.21a-1 shared library for ALSA applicatio
ii  libatk1.0-01.28.0-1  The ATK accessibility toolkit
ii  libaudio2  1.9.2-3   Network Audio System - shared libr
ii  libaudiofile0  0.2.6-8   Open-source version of SGI's audio
ii  libc6  2.10.2-2  GNU C Library: Shared libraries
ii  libcaca0   0.99.beta16-2.1   colour ASCII art library
ii  libcairo2  1.8.8-2   The Cairo 2D vector graphics libra
ii  libcdparanoia0 3.10.2+debian-9   audio extraction tool for sampling
ii  libcucul0  0.99.beta16-2.1   transitional dummy package
ii  libdirectfb-0.9-25 0.9.25.1-6direct frame buffer graphics - sha
ii  libesd00.2.41-6  Enlightened Sound Daemon - Shared 
ii  libfontconfig1 2.6.0-4   generic font configuration library
ii  libfreetype6   2.3.11-1  FreeType 2 font engine, shared lib
ii  libgcc11:4.3.2-1.1   GCC support library
ii  libgif4 [libungif4g]   4.1.6-8   library for GIF images (library)
ii  libgl1-mesa-glx [libgl 7.0.3-7   A free implementation of the OpenG
ii  libglib2.0-0   2.22.3-1  The GLib library of C routines
ii  libgtk2.0-02.18.3-1  The GTK+ graphical user interface 
ii  libjpeg62  6b-15 The Independent JPEG Group's JPEG 
ii  liblircclient0 0.8.3-5   infra-red remote control support -
ii  libncurses55.7+20090803-2shared libraries for terminal hand
ii  libogg01.1.4~dfsg-1  Ogg bitstream library
ii  libpango1.0-0  1.26.1-1  Layout and rendering of internatio
ii  libpng12-0 1.2.40-1  PNG library - runtime
ii  libsdl1.2debian1.2.13-5  Simple DirectMedia Layer
ii  libsmbclient   2:3.3.4-1 shared library for communication w
ii  libspeex1  1.2~rc1-1 The Speex codec runtime library
ii  libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
ii  libsvga1   1:1.4.3-28console SVGA display libraries
ii  libtheora0 1.0-2.1   The Theora Video Compression Codec
ii  libungif4g 4.1.6-6   library for GIF images (transition
ii  libx11-6   2:1.1.5-2 X11 client-side library
ii  libxcomposite1 1:0.4.1-1 X11 Composite extension library
ii  libxcursor11:1.1.10-1X cursor management library
ii  libxdamage11:1.1.2-1 X11 damaged region extension libra
ii  libxext6   2:1.0.4-1 X11 miscellaneous extension librar
ii  libxfixes3 1:4.0.4-1 X11 miscellaneous 'fixes' extensio
ii  libxi6 2:1.2.1-2 X11 Input extension library
ii  libxinerama1   2:1.0.3-2 X11 Xinerama extension library
ii  libxrandr2 2:1.3.0-2 X11 RandR extension library
ii  libxrender11:0.9.5-1 X Rendering Extension client libra
ii  libxt6 1:1.0.7-1 X11 toolkit intrinsics library
ii  libxv1 2:1.0.5-1 X11 Video extension library
ii  libxvmc1   2:1.0.5-1 X11 Video extension library
ii  libxxf86dga1   2:1.0.2-1 X11 Direct Graphics Access extensi
ii  libxxf86vm11:1.0.2-1 X11 XFree86 video mode extension l
ii  mplayer-skin-blue [mpl 1.6-2 blue skin for mplayer
ii  zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime

mplayer recommends no packages.

Versions of packages mplayer suggests:
ii  bzip2   1.0.5-3  high-quality block-sorting file co
ii  fontconfig  2.6.0-4  generic font configuration library
ii  mplayer-doc 1:1.0.rc2svn20091101-0.0 Documentation for mplayer
pn  netselect | fpi none   (no description available)
ii  ttf-freefont20090104-5   Freefont Serif, Sans and Mono True

-- 

Bug#549528: Fix discovered.

2009-10-21 Thread J Phelps
This turns out to be a duplicate of bug #535305 (common-lisp-controller:
update fails rebuilding sb-grovel, asdf broken as a result). It's
supposedly fixed, but apt-get upgrade doesn't apply the fix to testing.

In the meantime, you can fix it manually as follows (this is the same
fix suggested in the other bug report):

As root, from the / directory, apply this patch:

===BEGIN PATCH===
--- 
/usr/share/common-lisp/source/common-lisp-controller/post-sysdef-install.lisp.orig
  2009-10-21 14:42:00.0 -0400
+++ 
/usr/share/common-lisp/source/common-lisp-controller/post-sysdef-install.lisp   
2009-10-21 14:40:59.0 -0400
@@ -61,7 +61,7 @@
 #+sbcl
 (defun get-owner-and-mode (directory)
   (when (eq :directory
-   (sb-impl::native-file-kind (namestring directory)))
+   (sb-impl::unix-file-kind (namestring directory)))
 ;; check who owns it
 (multiple-value-bind (res dev ino mode nlink uid gid rdev size atime mtime)
(sb-unix:unix-stat (namestring directory))
===END PATCH=

Run dpkg-reconfigure cl-asdf.


-- 
All your .signature are belong to us.
Take off every 'sig' for great justice.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#549528: sbcl: Still can't find package CLC, even after bug fix.

2009-10-03 Thread J Phelps
Package: sbcl
Version: 1:1.0.25.0-1
Severity: grave
Justification: renders package unusable


This is another occurence of bug #471598 (SBCL can't
find CLC package). In the original bug report, Ken Harris
kengru...@gmail.com believed that the problem was caused by a
bug in the Linux kernel, which was fixed in version 2.6.25, after
which Luca Capello l...@pca.it closed the bug report.

I'm running Linux 2.6.30, so I should not experience the problem with
SBCL, if the problem in the older kernel was causing the problem with
SBCL.  However, attempting to run SBCL under SLIME from EMACS still
results in the error message 'package CLC not found' from SBCL.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages sbcl depends on:
ii  common-lisp-controller6.18   Common Lisp source and compiler ma
ii  libc6 2.9-25 GNU C Library: Shared libraries

Versions of packages sbcl recommends:
ii  binfmt-support1.2.14 Support for extra binary formats

Versions of packages sbcl suggests:
ii  sbcl-doc1:1.0.25.0-1 Documentation for Steel Bank Commo
pn  sbcl-source none   (no description available)
ii  slime   1:20090908-1 Superior LISP Interaction Mode for

-- 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