Bug#894795: kde-full currently uninstallable
Package: kde-full Version: 5:100 Severity: serious Dear Maintainer, kde-full from meta-kde 5:100 depends on kdepim 4:17.12.xxx, but meta-kde provides the packages kdepim in Version 4:17.08.xxx. Two untested fixes (choose one!) have been provided at https://salsa.debian.org/qt-kde-team/kde/meta-kde/merge_requests/4 and https://salsa.debian.org/qt-kde-team/kde/meta-kde/merge_requests/3 I ran reportbug on a system with kdepim 5:99 installed (as 5:100 is uninstallable), so the dependency list below does contain a kdepim version that is in conflict with kde-full 5:100. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-rc6-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kde-full depends on: ii kde-plasma-desktop 5:100 ii kde-standard 5:100 ii kdeadmin 4:17.08.3+5.100 ii kdeedu 4:17.08.3+5.100 ii kdegames 4:17.08.3+5.100 ii kdegraphics 4:17.08.3+5.100 ii kdemultimedia4:17.08.3+5.100 ii kdenetwork 4:17.08.3+5.100 ii kdepim 4:17.08.3+5.100 ii kdeutils 4:17.08.3+5.100 ii plasma-workspace-wallpapers 4:5.12.1-1 Versions of packages kde-full recommends: pn kdeaccessibility pn kdesdk pn kdetoys pn kdewebdev Versions of packages kde-full suggests: pn calligra ii xorg 1:7.7+19 -- no debconf information
Bug#703281: rygel security issue
Package: rygel Version: 0.14.3-2 Followup-For: Bug #703281 This behaviour is caused by the global (system wide) configuration file /etc/rygel.conf containing "upnp-enabled=true". That file is used as template for the local (user specific) configuration file, which is written when you exit rygel-preferences. On the other hand, to avoid messing with autostart settings of a user that did not enable UPnP his/herself, rygel-preferences treats the parameter "upnp-enabled" as false, if it was loaded from the global configuration file. This behaviour has been introduced in commit https://git.gnome.org/browse/rygel/commit/src/ui?id=4ab1d1f905f38b17cf162c6b34b763a40a292b4e A short-term fix would be to ship with "upnp-enabled=false" in the global configuration file. Which might even actually be what Debian wants. I did not track down whether the global "true" setting already makes the UPnP interface available while rygel is running. Regards, Michael Karcher -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.7.0+ (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages rygel depends on: ii libc62.16-0experimental1 ii libgee2 0.6.4-2 ii libglib2.0-0 2.34.3-1 ii libgssdp-1.0-3 0.12.1-2 ii libgstreamer-plugins-base0.10-0 0.10.36-1.1 ii libgstreamer0.10-0 0.10.36-1.1 ii libgupnp-1.0-4 0.18.3-1 ii libgupnp-av-1.0-20.10.2-1 ii libgupnp-dlna-1.0-2 0.6.6-1 ii libsoup2.4-1 2.40.1-1 ii libsqlite3-0 3.7.13-1 ii libunistring00.9.3-5 ii libuuid1 2.20.1-5.3 ii libxml2 2.8.0+dfsg1-7+nmu1 Versions of packages rygel recommends: ii gstreamer0.10-ffmpeg0.10.13-5 ii gstreamer0.10-plugins-base 0.10.36-1.1 ii gstreamer0.10-plugins-ugly 0.10.19-2+b2 Versions of packages rygel suggests: pn rygel-mediathek pn rygel-playbin ii rygel-preferences 0.14.3-2 pn rygel-tracker ii tumbler0.1.25-1+b1 -- 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
Bug#704769: FTBFS on s390x sid buildds.
Package: libarchive
Severity: normal
The test failures are caused by a bug in libarchive on big-endian 64 bit
architectures, as already suspected. There indeed is an upstream fix for
it, it is in commit da058d4b1a240a3381f37f99ef9edd982e34cabc fixing the
data type of some variable passed to an ioctl call.
The failure is not related to ext3 vs. ext4, but most likely indicates
that the buildd does not use tmpfs on /tmp. The bug does not manifest
on tmpfs file systems, and the testsuite is running in a subdir of
/tmp, which can be overriden using TMPDIR. Running it with TMPDIR
set to a ext3-backed directory makes it fail on the porterbox, too.
The upstream diff from the mentioned commit is attached.
Regards,
Michael Karcher
-- System Information:
Debian Release: 6.0.7
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
commit da058d4b1a240a3381f37f99ef9edd982e34cabc
Author: Andreas Schwab
Date: Wed Aug 29 15:41:51 2012 +0200
Fix more uses of EXT2_IOC_[GS]ETFLAGS
diff --git a/libarchive/archive_read_disk_posix.c b/libarchive/archive_read_disk_posix.c
index 698600e..652deb9 100644
--- a/libarchive/archive_read_disk_posix.c
+++ b/libarchive/archive_read_disk_posix.c
@@ -984,7 +984,7 @@ next_entry(struct archive_read_disk *a, struct tree *t,
#elif defined(EXT2_IOC_GETFLAGS) && defined(EXT2_NODUMP_FL) &&\
defined(HAVE_WORKING_EXT2_IOC_GETFLAGS)
if (S_ISREG(st->st_mode) || S_ISDIR(st->st_mode)) {
- unsigned long stflags;
+ int stflags;
t->entry_fd = open_on_current_dir(t,
tree_current_access_path(t), O_RDONLY | O_NONBLOCK);
diff --git a/libarchive/archive_write_disk_posix.c b/libarchive/archive_write_disk_posix.c
index d79b0f6..6b8bfde 100644
--- a/libarchive/archive_write_disk_posix.c
+++ b/libarchive/archive_write_disk_posix.c
@@ -2403,8 +2403,8 @@ set_fflags_platform(struct archive_write_disk *a, int fd, const char *name,
{
int ret;
int myfd = fd;
- unsigned long newflags, oldflags;
- unsigned long sf_mask = 0;
+ int newflags, oldflags;
+ int sf_mask = 0;
if (set == 0 && clear == 0)
return (ARCHIVE_OK);
Bug#624507: #624507 - Started looping and continuously rewriting metadata file - Debian Bug report logs
Indeed that looping behaviour is not bound to occur only on remote file systems, but it is caused by the current version of the database file (like "home") not referring to the redo log (like "home-01234567.log") that is currently opened by the gvfsd (because it was referred to by the database at the time gvfsd opened the database). The usual reason for this mismatch is that the database has been replaced by a different version referring a different redo log file, but it could be due to data corruption, too. As long as the data base (and the redo log) is only used on a single system, the kernel (mostly?) ensures that once a redo log has been rotated into the data base, the "this redo log is rotated"-Bit is also seen by all other processes using the same redo log. This is why the bug usually does not appear in the single-system setup. There at least two different possible scenarios, how the mismatch could arise on a local file system, too: a) The local file system is exported, and the log has been rotated by a remote machine. b) The gvfs-metadata database directory has been restored from a backup while gvfsd-metadata was running. The temporary fix of disabling the metadata recording on remote file systems would help in scenario a, but not in scenario b. Regards, Michael Karcher -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#634261: [sparc] iceweasel: Bus Error in setbuf()
A summary of the current situation: There are historic programs and libraries relying on the old FILE structure. These programs and libraries assume that any 4-byte aligned FILE structure is acceptable, because that was the case with libio 2.0 Most programs and libraries are compiled with libio 2.1. At least on sparc, this means that FILE objects now need to be aligned on an 8-byte boundary. The compiler assumes this alignment when generating code using libio 2.1 (or newer) headers. The alignment difference is the cause that even though glibc maintainers took a lot of effort to make the old and the new structure compatible, there can be unexpected problems on sparc, because it seems like the alignment issue was not considered at that time. There is no silver bullet - either we have an 8-byte alignment requirement, which keeps compatibility with all libio 2.1 code, or we relax the requirement to 4-byte alignment (by splitting the 64-bit offset field and implementing the 64-bit-arithmetic by hand), which will re-enable full compatibility with libio 2.0 code. Especially as libio 2.0 and libio 2.1 libraries can be dynamically mixed, and all code expects that FILE* pointers of the old and new variant are interchangable for the narrow-character interface, there is some mess outside of glibc already that can never be fixed. A way to minimize the symptoms of this bug is to notice that most, if not all, FILE structures are allocated inside libc. As long as libc code controls the address of FILE objects, it can ensure 8-byte alignment, even for the legacy structures. So my recommendation is: 1. keep not forcing old FILE* to be 8-byte-aligned Forcing it would make the legacy function (versioned GLIBC_2.0) unable to cope with (unaligned) objects they currently can cope with 2. do force 8-byte-alignment on the legacy stdin/stdout/stderr This will make the legacy standard streams compatible with current code 3. do force 8-byte aligment on functions generating FILE structures (like fopen), even in the legacy interface. This will make all stream objects allocated in libc functions (which probably will be all stream objects you encounter) compatible with current code. I am completely aware (as pointed out above) that this is not a perfect fix, but it should be a good enough fix that no observable problems occur, even if you mix libio 2.0 and libio 2.1 code. And finally: 4. implement a lintian check that shared objects (programs and libraries) importing any GLIBC_2.1 or later versioned symbol also contain an *unversioned* export of _IO_stdin_used on those architectures where libio 2.0-compatibility is enabled (for example i386, but not amd64). In my oppinion, this bug is definitely not release critical, because the only thing that is broken is a compatiblity layer for programs more than 10 years old. This would count as "a particular option (or menu item)" of libc6, furthermore not affecting the "core functionality of the package". So the priority should be normal or minor. A build process that mangles the export of _IO_stdin_used is (as defined by the libc ABI, even if not explicitly written down) broken. The bug in this case was caused by such a kind of broken build process in the Mozilla applications that already has been fixed. We are still waiting for a real manifestation of the original bug, which should occur with libio 2.0 programs only. Regards, Michael Karcher -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695614: CVE-2012-6303: buffer overflows
The attached patch fixes the buffer overrun for the fixed-size header
buffer.
--- snack-2.2.10-dfsg1/generic/jkSoundFile.c 2005-12-14 12:29:38.0 +0100
+++ snack-2.2.10-dfsg1+karcher/generic/jkSoundFile.c 2013-01-02 00:29:56.836287036 +0100
@@ -1796,7 +1796,14 @@
GetHeaderBytes(Sound *s, Tcl_Interp *interp, Tcl_Channel ch, char *buf,
int len)
{
- int rlen = Tcl_Read(ch, &buf[s->firstNRead], len - s->firstNRead);
+ int rlen;
+
+ if (len > max(CHANNEL_HEADER_BUFFER, HEADBUF)){
+Tcl_AppendResult(interp, "Excessive header size", NULL);
+return TCL_ERROR;
+ }
+
+ rlen = Tcl_Read(ch, &buf[s->firstNRead], len - s->firstNRead);
if (rlen < len - s->firstNRead){
Tcl_AppendResult(interp, "Failed reading header bytes", NULL);
Bug#634261: [sparc] iceweasel: Bus Error in setbuf()
Am Sonntag, den 23.12.2012, 00:13 +0100 schrieb John Paul Adrian Glaubitz: > > I don't completely follow, so I'll just ask: do you mean that this is > > a case of ABI misuse, with poor error reporting? One could phrase it this way. > As far I understand the problem, the Mozilla developers provide a > version script to the linker to control which symbols get > exported. This helps speeding up the load process of the binary and > reduces the memory footprint. This is correct. > What the Mozilla developers didn't seem to put into account is that if > you prevent the symbol _IO_stdin_used from being exported from your > binary, parts of the ABI of the standard C library will change and it > will behave like an older version which causes the unaligned access > which results in a CPU trap. And this is mostly correct. libc puts lots of effort in providing a stable ABI. A big change in libc was the introduction of libio 2.1. It introduced support for wide-character streams and 64 bit offsets. These changes required an incompatible change to the FILE structure. Because of this, the FILE APIs exist in two variants in glibc[1], if backward compatibility is enabled. The new variant is tagged with the version GLIBC_2.1, while the old one is tagged GLIBC_2.0. For the three standard streams, there are two differently *named*, not just differently *versioned* objects, namely _IO_stdin_ for the old version and _IO_2_1_stdin_ for the new version, while the pointer stdin itself is not version dependent. This might be to make sure that "stdin" itself has the same value regardless of the version of libc that is imported. If a program compiled against the glibc 2.1 (or newer) development files, it will automatically refer to the new functions (i.e. link to the GLIBC_2.1 version of _IO_file_setbuf and so on), while programs and libraries compiled with old glibc 2.0 development files will refer to the GLIBC_2.0 version of these functions. The tricky part are the std* pointers: If a source file is compiled with new development headers and refers to stdin, stdout or stderr, some magic makes the compiler or linker emit a definition of the symbol "_IO_stdin_used" in that module. glibc itself defines it as a *weak* external symbol. The consequence is that if the symbol is not defined anywhere, it just resolves to address 0, but if it is defined in one or more modules, it resolves to a valid address in one of these modules. The resolution of external global variables in ELF systems is internally performed by a GOT lookup (which is the strange code for &_IO_stdin_used observed on disassembling) at runtime. The logic in glibc is that if the new libio functions are used with stdin, there will be a reference to _IO_stdin_used. But if there are no references to _IO_stdin_used, the compatibility layer will kick in, and make the stdin/stdout/stderr pointers by pointers to the compatibility objects. As it happens, the compatibility objects do not contain any 64 bit field, and require a 4-byte-alignent on sparc, while the modern objects (which are in fact the compatibility objects with some extra fields appended) have a 64 bit field containing the current file offset. This makes gcc on sparc require an 8-byte-alignment. gcc compiles functions that work on the new FILE structure with the internal assumption that these objects are aligned as they should, so it expects 8-byte-alignment. The old functions on the other hand work fine with the new structures, stricter aligned, unless the code tries to access the vtable pointer, which is at different location in the old and new object, and most likely the cause to have both versions. It might have been the intention of the libio developers that (unless vtable accesses happen) the old objects can be processed by the new functions, and in that case, glibc is buggy, as it relies on undefined behaviour. Aussuming that intention, it expects that a pointer to the short file structure can be used as a pointer to the long file structure, which is not something you are granted by the C standard. > > Can you describe what iceweasel was doing wrong? Is this documented > > so future coders know not to make the same mistake? Is the version in > > squeeze affected? How about the version in wheezy? > It seems to have been fixed in Firefox 10 which is part of Wheezy: There seems to be no official documentation on it, but hiding the _IO_stdin_used symbol (it still is there, but not visible for dynamic loading) violates internal glibc assumptions and breaks on sparc. Regards, Michael Karcher [1] This is why Bernhard R. Link observed the two different alignof values. You choose between the two variants of FILE/_IO_FILE by defining or not defining _IO_USE_OLD_IO_FILE. In oldstdfile.c, the symbol is defined, while in genops.c, it is not defined. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
