Bug#1070246: libayatana-appindicator version of Debian package does not match the upstream version
Source: libayatana-appindicator Severity: serious Version: 0.5.92-1 Version: 0.5.93-1 The package of libayatana-appindicator on Debian is not building from the right orig tarball as indicated on the package version. Both package versions on Debian 12 and testing (versions 0.5.92-1 and 0.5.93-1) are actually version 0.5.90 of upstream. $ apt-cache policy libayatana-appindicator3-1 libayatana-appindicator3-1: Installed: 0.5.92-1 Candidate: 0.5.92-1 Version table: *** 0.5.92-1 500 500 http://deb.debian.org/debian bookworm/main amd64 Packages 100 /var/lib/dpkg/status $ zcat /usr/share/doc/libayatana-appindicator3-1/changelog.gz|head Overview of changes in libayatana-appindicator 0.5.90 - Mono bindings: Change namespace from ayatana-appindicator-sharp3 to ayatana-appindicator3-sharp (and similar). - Port to CMake. - Default to GTK+-3.0 as default build flavour. - Add Travis CI configuration. - Add --keep-env option to dbus-test-runner calls. Allows propagating e.g. a build HOME into the DBus test environment. See how on the upstream changelog file it says version "0.5.90" I have triple checked this by comparing the orig.tar.gz tarball from the Debian packages VS the ones at https://github.com/AyatanaIndicators/libayatana-appindicator/tags And the version shipped on Debian (both for 0.5.92-1 and 0.5.93-1) is actually the upstream 0.5.90 version Please fix this Thanks
Bug#962596: ca-certificates: Removal of GeoTrust Global CA requires investigation
On 11/06/2020 18:34, Michael Borg wrote: > Yep I know but I cannot tell all my customers to run this workaround, some > of our users are not experienced at all The only thing I see here is > that I need to provide a hotfix ourselves. We cannot wait for days... You > are saying we cannot make an exception and push this fix ASAP? Pushing packages to Debian takes time. If you need something for today you need to fix it yourself. You can downgrade to the old version of the package ca-certificates or install the missed certificate manually This recipe allows to do that: wget --no-check-certificate -c https://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.pem \ && mkdir /usr/local/share/ca-certificates/extra \ && mv GeoTrust_Global_CA.pem /usr/local/share/ca-certificates/extra/GeoTrust_Global_CA.crt \ && update-ca-certificates And when you upgrade to the fixed version of ca-certificates you can remove the directory /usr/local/share/ca-certificates/extra and run the command update-ca-certificates again. signature.asc Description: OpenPGP digital signature
Bug#863201: libpam-ldap not longer installs the file /usr/share/pam-configs/ldap needed for pam-auth-update
Package: libpam-ldap Version: 186-3 Severity: grave libpam-ldap 184-8.7 (Jessie) installed a config file on /usr/share/pam-configs/ldap telling pam-auth-update how it should re-configure the files on /etc/pam.d when the command pam-auth-update is executed (that the package libpam-ldap executes on the postinstall) libpam-ldap 186-3 (Stretch) not longer installs this file jessie $ dpkg --contents libpam-ldap_184-8.7+b1_amd64.deb | grep pam-configs/ldap -rw-r--r-- root/root 518 2014-11-08 18:35 ./usr/share/pam-configs/ldap stretch $ dpkg --contents libpam-ldap_186-3_amd64.deb | grep pam-configs # nothing Therefore the package on Stretch is pretty much useless for new installs. The workaround is to copy this file manually from libpam-ldap=184-8.7 and manually execute pam-auth-update. Please, bring /usr/share/pam-configs/ldap back into libpam-ldap signature.asc Description: OpenPGP digital signature
Bug#830824: [Pkg-zfsonlinux-devel] Bug#830824: Bug#830824: Silently corrupted file in snapshots after send/receive
Control: tag -1 +pending On 11/08/16 17:51, Carlos Alberto Lopez Perez wrote: > 1) Wait for the patch on PR #4833 to be merged, then import it > defaulting to ignore hole_birth until the issue is fixed. This patch was finally merged on ZoL/master but with the option set to false by default. I have cherry-picked it and then added another patch defaulting it to true. On the PR #4833 [1], Brian Behlendorf comments he is also thinking in defaulting this to true for the upcoming 0.8.5 Regards. [1] https://github.com/zfsonlinux/zfs/pull/4833 signature.asc Description: OpenPGP digital signature
Bug#834169: Apache2 can't be installed on testing/sid
Package: apache2 Version: 2.4.23-3 Severity: grave On a new fresh created Debian Sid ADM64 chroot, installing apache2 is not possible: $ sudo apt-get install -y apache2 Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: autoconf-archive fonts-lato libmpfr4 libpython-stdlib libpython2.7-minimal libpython2.7-stdlib libwrap0 python python-minimal python2.7 python2.7-minimal Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: ssl-cert Suggested packages: apache2-doc apache2-suexec-pristine | apache2-suexec-custom openssl-blacklist The following NEW packages will be installed: apache2 ssl-cert 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. 31 not fully installed or removed. Need to get 0 B/248 kB of archives. After this operation, 641 kB of additional disk space will be used. Preconfiguring packages ... (Reading database ... 45161 files and directories currently installed.) Preparing to unpack .../0-apache2_2.4.23-3_amd64.deb ... preinst called with unknown argument `install' dpkg: error processing archive /tmp/apt-dpkg-install-qHR4wD/0-apache2_2.4.23-3_amd64.deb (--unpack): subprocess new pre-installation script returned error exit status 1 Selecting previously unselected package ssl-cert. Preparing to unpack .../1-ssl-cert_1.0.38_all.deb ... Unpacking ssl-cert (1.0.38) ... Errors were encountered while processing: /tmp/apt-dpkg-install-qHR4wD/0-apache2_2.4.23-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) It seems the preinst script aborts when called with $1=install $ apt-get download apache2 Get:1 http://debian.univ-tlse2.fr/debian sid/main amd64 apache2 amd64 2.4.23-3 [227 kB] Fetched 227 kB in 0s (250 kB/s) $ dpkg -I apache2_2.4.23-3_amd64.deb preinst |grep ^case -A99|grep ^esac -B99 case "$1" in upgrade) if dpkg --compare-versions "$2" lt-nl "2.4.23-3~" ; then list_fixup_conffiles | replace_broken_conffiles fi ;; abort-upgrade) list_fixup_conffiles | revert_broken_conffiles ;; *) echo "preinst called with unknown argument \`$1'" >&2 exit 1 ;; esac I workaround this by manually installing apache2 from Jessie, which has a case "$1" in install|upgrade) [ ... ] esac on the preinst script, and later upgrading to the one from testing/sid. signature.asc Description: OpenPGP digital signature
Bug#830824: [Pkg-zfsonlinux-devel] Bug#830824: Silently corrupted file in snapshots after send/receive
On 09/08/16 16:35, Petter Reinholdtsen wrote: > [ Antonio Russo 2016-07-11 ] >> Sorry, there is no 0.6.5.8 release. The fix does exist in the master branch, >> however. (bc77ba7: OpenZFS 6513 - partially filled holes lose birth time) > > As far as I can see from https://github.com/zfsonlinux/zfs/issues/4809 > >, > the issue is still unsolved upstream. > > Are you sure that commit is enough to solve the problem? There are others > mentioned in issue #4809. > > See also https://www.illumos.org/issues/6370 >, > https://www.illumos.org/issues/6513 > and > https://www.illumos.org/issues/6844 >. > It seems there are several issues affecting zfs send/receive when the hole_birth feature is enabled. Commit bc77ba7 fixes one of this issues, but not the others. The best fix right now seems to completely ignore hole_birth. A patch was proposed here that ignores it, and adds a module parameter to enable it back [1]. Options I see going forward: 1) Wait for the patch on PR #4833 to be merged, then import it defaulting to ignore hole_birth until the issue is fixed. 2) If we don't want to wait for the patch to be merged, we can import it anyway but removing the part that adds a kernel module parameter tunable to avoid adding any option that is still not upstreamed. So just disable hole_birth always. 3) Do nothing and wait for upstream to fix this issues with hole_birth and zfs send/receive. Right now, I'm inclined to proceed with option #2 and disable hole_birth until the issues with it are 100% fixed upstream and a new major release is made. Opinions? PS: There is still an user reporting some problems observed even with ignore_hole_birth=1, but is still not 100% clear if in this case the problem is the same. Let's wait some days to see how this evolves [2]. BTW: I'm a bit surprised that this has been raised to RC bug on Debian unstable, but on Ubuntu LTS nobody cares about it. [3] Or I'm missing something? [1] https://github.com/zfsonlinux/zfs/pull/4833 [2] https://github.com/zfsonlinux/zfs/issues/4809#issuecomment-238503468 [3] https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1600060 signature.asc Description: OpenPGP digital signature
Bug#800574: backport to sid/stable? (was RE: libc6: lock elision hazard on Intel Broadwell and Skylake)
On 26/10/15 20:13, Carlos Alberto Lopez Perez wrote: > On 23/10/15 22:10, Henrique de Moraes Holschuh wrote: >> On Fri, Oct 23, 2015, at 11:13, Carlos Alberto Lopez Perez wrote: >>> I was having trouble (crashes with the NVIDIA proprietary driver) on a >>> Debian system with an i7-5775C and libc6=2.19-18+deb8u1 (stable) >> >> This is very very likely to be braindamage on the NVIDIA driver, though. >> >> Are you sure that driver is not doing something as idiotic as unlocking >> an already unlocked mutex ? >> >> The proper fix in that case is _always_ to fix whatever is broken, >> because eventually it will run on something that has working hardware >> lock elision... and crash. >> > > I can't know, since I don't have access to the source code of the > driver, neither the debug symbols are available, so any attempt to get a > meaningful backtrace was hopeless. > > At first I also thought it was the driver doing something wrong, but > then I found several reports of people with the same cryptic backtrace > than me saying that this was because of the TSX-NI bug of recent Intel > CPUs [1]. > > And effectively, after upgrading glibc to this one that disables TSX-NI > for broadwell it suddenly works as expected... > > So this seems to suggest that effectively TSX-NI is buggy on this CPU. > > In any case... Do you know of any program or test that I can run to > check if TSX-NI (both HLE and RTM) is working as it should or is still > buggy on this CPU? That way we can verify better if the problem is in > the CPU or in the driver. > I'm re-reading your explanation [2] about programs crashing with SIGSEV in __lll_unlock_elision when TSX is enabled to be caused by the program itself trying to unlock an already unlocked lock. That would explain everything, and will point indeed to a bug in the NVIDIA driver rather than in the CPU. Also, this specific model of CPU (i7-5775C) for what I have been reading seems to have fixed TSX-NI support. At least the ark page of Intel still advertises it [3]. In any case I'm still interested in testing this to be 100% sure. If you know about any test program that I can run, please let me know about it. Cheers -- [2] https://bugzilla.kernel.org/show_bug.cgi?id=103351#c86 [3] http://ark.intel.com/products/88040/Intel-Core-i7-5775C-Processor-6M-Cache-up-to-3_70-GHz signature.asc Description: OpenPGP digital signature
Bug#800574: backport to sid/stable? (was RE: libc6: lock elision hazard on Intel Broadwell and Skylake)
On 23/10/15 22:10, Henrique de Moraes Holschuh wrote: > On Fri, Oct 23, 2015, at 11:13, Carlos Alberto Lopez Perez wrote: >> I was having trouble (crashes with the NVIDIA proprietary driver) on a >> Debian system with an i7-5775C and libc6=2.19-18+deb8u1 (stable) > > This is very very likely to be braindamage on the NVIDIA driver, though. > > Are you sure that driver is not doing something as idiotic as unlocking > an already unlocked mutex ? > > The proper fix in that case is _always_ to fix whatever is broken, > because eventually it will run on something that has working hardware > lock elision... and crash. > I can't know, since I don't have access to the source code of the driver, neither the debug symbols are available, so any attempt to get a meaningful backtrace was hopeless. At first I also thought it was the driver doing something wrong, but then I found several reports of people with the same cryptic backtrace than me saying that this was because of the TSX-NI bug of recent Intel CPUs [1]. And effectively, after upgrading glibc to this one that disables TSX-NI for broadwell it suddenly works as expected... So this seems to suggest that effectively TSX-NI is buggy on this CPU. In any case... Do you know of any program or test that I can run to check if TSX-NI (both HLE and RTM) is working as it should or is still buggy on this CPU? That way we can verify better if the problem is in the CPU or in the driver. >> I tried first to update the Intel microcode with the "unreleased" 0x13 >> microcode version but it didn't disabled the TSX-NI instructions [1] >> neither the crashes. > > Mobile Broadwell-H seems to disable TSX, while Desktop Broadwell-H > doesn't. That's why we blacklisted the whole thing: inconsistent > behavior on the same microcode, and that behavior is itself inconsistent > with the errata sheet that says such processors shouldn't even be able > to advertise Intel TSX RTM in CPUID. > > At the moment, we don't even know what is wrong with RTM in > Broadwell/Broadwel-H/Broadwell-DE. We do know some of what is wrong > with HLE in Broadwell/-H/-DE (and it is really nasty), but HLE is not > used by glibc in the first place, and the HLE erratum is supposedly > worked around somehow (because it is documented to be so on the Xeon > D-1500/Broadwell-DE) by the batch of microcode updates available in the > kernel bugzilla bug report mentioned in this bug report. > > Broadwell-H Microcode 0x13 is useful anyway because it fixes other > critical errata that hangs/oopses the kernel: you box should be a _lot_ > more stable with it. And at least one person reported that not all > hangs were fixed by microcode 0x12, thus you probably should use keep > using microcode 0x13 (or newer, should one become available). > Good to know, thanks for the advice. I will keep using this 0x13 "unofficial" microcode until a new one is out. I can't keep wondering why Intel is not releasing this :\ Regards! [1] https://lists.archlinux.org/pipermail/arch-general/2015-April/038953.html signature.asc Description: OpenPGP digital signature
Bug#800574: backport to sid/stable? (was RE: libc6: lock elision hazard on Intel Broadwell and Skylake)
Hi, Thanks for this patch. I was having trouble (crashes with the NVIDIA proprietary driver) on a Debian system with an i7-5775C and libc6=2.19-18+deb8u1 (stable) I tried first to update the Intel microcode with the "unreleased" 0x13 microcode version but it didn't disabled the TSX-NI instructions [1] neither the crashes. Finally I upgraded to glibc=2.21-0experimental2 and it fixed the crashes. I wonder: Should this patch be backported both to stable and unstable? Thanks for your awesome work ! Regards --- [1] https://bugzilla.kernel.org/show_bug.cgi?id=103351#c93 signature.asc Description: OpenPGP digital signature
Bug#785672: Critical ext4 data corruption bug (maybe is dm-crypt related ?)
Are you using dm-crypt? Then this may be related to another bug that appeared on 4.0. See: http://thread.gmane.org/gmane.linux.kernel/1942014 The following issue on RH's tracker is also related: https://bugzilla.redhat.com/show_bug.cgi?id=1223332 I can confirm that last bug (dm-crypt). I have experimented this issue after upgrading to 4.0.2 (lot of libata errors). Luckily I quickly noticed it and downgraded to 3.16, and I didn't suffered of any data corruption/loss (or at least didn't noticed so far). Regards. signature.asc Description: OpenPGP digital signature
Bug#774163: root-system: diff for NMU version 5.34.19+dfsg-1.2
On 16/01/15 01:12, Sebastian Ramacher wrote: > Control: tags 774163 + patch > Control: tags 774163 + pending > > Dear maintainer, > > I've prepared an NMU for root-system (versioned as 5.34.19+dfsg-1.2) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. > > Cheers > > diff -Nru root-system-5.34.19+dfsg/debian/changelog > root-system-5.34.19+dfsg/debian/changelog > --- root-system-5.34.19+dfsg/debian/changelog 2014-10-24 13:44:02.0 > +0200 > +++ root-system-5.34.19+dfsg/debian/changelog 2015-01-16 00:43:59.0 > +0100 > @@ -1,3 +1,12 @@ > +root-system (5.34.19+dfsg-1.2) unstable; urgency=medium > + > + * Non-maintainer upload. > + * debian/control: Make ttf-root-installer depend on ca-certificates. > +Certificates need to be available for postint configure to work. > +(Closes: #774163) > + > + -- Sebastian Ramacher Fri, 16 Jan 2015 00:43:11 > +0100 > + Interesting... When I reported the bug the CA signing the certificate for https://root.cern.ch was a custom one (kind of self-signed: (CERN Grid Certification Authority)). Now is signed by COMODO. I guess somebody told them to use a proper CA. Indeed... https://root.cern.ch/phpBB3/viewtopic.php?f=7&t=18818 Regards! signature.asc Description: OpenPGP digital signature
Bug#760552: PyAssertionError bitmap.GetWidth prevents startup
Hi, Just installed tribler on debian testing, and I'm running it without problems. So far I didn't hit the bug that is reported here. signature.asc Description: OpenPGP digital signature
Bug#774163: Unable to upgrade or install ttf-root-installer (dpkg: error processing package) because of invalid certificate on root.cern.ch
Seems on the past there were also problems with this file served via ftp. https://bugs.launchpad.net/ubuntu/+source/root-system/+bug/349860 signature.asc Description: OpenPGP digital signature
Bug#774163: Unable to upgrade or install ttf-root-installer (dpkg: error processing package) because of invalid certificate on root.cern.ch
Package: ttf-root-installer Version: 5.34.19+dfsg-1.1 Severity: grave Hi, when upgrading my system ttf-root-installer broke the upgrade because its configure script failed. I tried to purge it completely and install it again, unfortunately it broke again: $ sudo apt-get install ttf-root-installer Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: ttf-root-installer 0 upgraded, 1 newly installed, 0 to remove and 633 not upgraded. Need to get 28.1 kB of archives. After this operation, 91.1 kB of additional disk space will be used. Get:1 http://mirror.ovh.net/debian/ sid/contrib ttf-root-installer all 5.34.19+dfsg-1.1 [28.1 kB] Fetched 28.1 kB in 0s (135 kB/s) Retrieving bug reports... Done Parsing Found/Fixed information... Done Preconfiguring packages ... Selecting previously unselected package ttf-root-installer. (Reading database ... 572464 files and directories currently installed.) Preparing to unpack .../ttf-root-installer_5.34.19+dfsg-1.1_all.deb ... Unpacking ttf-root-installer (5.34.19+dfsg-1.1) ... Setting up ttf-root-installer (5.34.19+dfsg-1.1) ... dpkg: error processing package ttf-root-installer (--configure): subprocess installed post-installation script returned error exit status 5 Errors were encountered while processing: ttf-root-installer E: Sub-process /usr/bin/dpkg returned an error code (1) Upon furter investigation : $ sudo DEBCONF_DEBUG=developer dpkg -D777 --configure ttf-root-installer D01: ensure_diversions: new, (re)loading D01: process queue pkg ttf-root-installer:all queue.len 0 progress 1, try 1 D40: checking dependencies of ttf-root-installer:all (- ) D000400: checking group ... D000400: checking possibility -> debconf D000400: checking non-provided pkg debconf:all D000400: is installed, ok and found D000400: found 3 D000400: found 3 matched 0 possfixbytrig - D000400: checking group ... D000400: checking possibility -> wget D000400: checking non-provided pkg wget:amd64 D000400: is installed, ok and found D000400: found 3 D000400: found 3 matched 0 possfixbytrig - D000400: checking group ... D000400: checking possibility -> xfonts-utils D000400: checking non-provided pkg xfonts-utils:amd64 D000400: is installed, ok and found D000400: found 3 D000400: found 3 matched 0 possfixbytrig - D40: ok 2 msgs >><< D40: checking Breaks D000400: checking virtbroken root-ttf Setting up ttf-root-installer (5.34.19+dfsg-1.1) ... D02: fork/exec /var/lib/dpkg/info/ttf-root-installer.postinst ( configure ) debconf (developer): frontend started debconf (developer): frontend running, package name is ttf-root-installer debconf (developer): starting /var/lib/dpkg/info/ttf-root-installer.config configure debconf (developer): <-- TITLE ROOT TTF Installer debconf (developer): --> 0 debconf (developer): <-- INPUT high ttf-root-installer/blurb debconf (developer): --> 30 question skipped debconf (developer): <-- INPUT high ttf-root-installer/dldir debconf (developer): --> 30 question skipped debconf (developer): <-- GO debconf (developer): --> 0 ok debconf (developer): <-- GET ttf-root-installer/dldir debconf (developer): --> 0 debconf (developer): <-- INPUT high ttf-root-installer/savedir debconf (developer): --> 30 question skipped debconf (developer): <-- GO debconf (developer): --> 0 ok debconf (developer): <-- GET ttf-root-installer/savedir debconf (developer): --> 0 debconf (developer): starting /var/lib/dpkg/info/ttf-root-installer.postinst configure + archive=ttf_fonts.tar.gz + db_get ttf-root-installer/dldir + _db_cmd GET ttf-root-installer/dldir + _db_internal_IFS= + IFS= + printf %s\n GET ttf-root-installer/dldir + IFS= + IFS= read -r _db_internal_line debconf (developer): <-- GET ttf-root-installer/dldir debconf (developer): --> 0 + RET= + return 0 + LOCALCOPY= + db_get ttf-root-installer/savedir + _db_cmd GET ttf-root-installer/savedir + _db_internal_IFS= + IFS= + printf %s\n GET ttf-root-installer/savedir + debconf (developer): <-- GET ttf-root-installer/savedir IFS= + IFS= read -r _db_internal_line debconf (developer): --> 0 + RET= + return 0 + SAVEDIR= + test ! -f /var/cache/ttf-root-installer + echo + tr [:upper:] [:lower:] + test x != xnone + pwd + savdir=/ + mktemp -d + tmpdir=/tmp/tmp.LG7ux68bWG + cd /tmp/tmp.LG7ux68bWG + test -z + wget --continue --tries=1 --dns-timeout=20 --connect-timeout=20 --read-timeout=300 -q --directory-prefix . -c http://root.cern.ch/download/ttf/ttf_fonts.tar.gz dpkg: error processing package ttf-root-installer (--configure): subprocess installed post-installation script returned error exit status 5 D01: ensure_diversions: same, skipping Errors were encountered while processing: ttf-root-installer Trying to reproduce it manually: $ wget --continue --tries=1 --dns-timeout=20 --connect-timeout
Bug#747535: Please don't make upgrades noisier than necessary
On 10/05/14 05:26, Josh Triplett wrote: > If the maintainers of the packages involved have done their jobs well > (and they have), upgrading should be an entirely smooth process. Much > like upgrading to a new version of the Linux kernel or a new bootloader, > you won't actually get the new version until you reboot, so there may be > value in a "you need to reboot" reminder after finishing the upgrade, > but that's true for just about every Debian major release upgrade. > However, adding a new prompt *before* the upgrade just makes the upgrade > process that much less pleasant for everyone who *doesn't* actually hold > religious opinions about init systems, which in practice is a far > greater chunk of Debian users than those who do. In practice, upgrading > from GNOME 2 to GNOME 3 will have a more noticeable impact on the user, > and we don't nag the user with a debconf prompt about that either, nor > should we. > > Upgrading from one Debian major release to another makes a large number > of substantial changes to the system; for example, it may replace > module-init-tools with the completely reimplemented kmod-based tools. > Those changes don't merit debconf noise either. > This makes sense when what is replaced not longer exists on Debian (that are precisely you examples: GNOME2 or module-init-tools). *But*, when you are replace something that will continue to be on Debian and to be supported, then is a serious bug. This bug is like if tomorrow Debian decides that default MTA should be Postfix, and on upgrade you replace my MTA (Exim) with Postfix. I would scream to you very loud. The default has changed (systemd), but the previous default (sysvinit) is *not* gone. So you can't replace it on upgrades without asking the administrator first. Full period. signature.asc Description: OpenPGP digital signature
Bug#726661: Does not permit login as root from version 1:6.2p2-6
On 13/02/14 22:19, Colin Watson wrote: > On Thu, Feb 13, 2014 at 08:14:15PM +0100, Carlos Alberto Lopez Perez wrote: >> I hit this bug after upgrading a machine. After rebooting it I was >> unable to login again. > > Unfortunately I haven't successfully reproduced this yet ... > >> On /var/log/auth.log was the following error: >> sshd[10480]: error: PAM: pam_open_session(): Cannot make/remove an entry for >> the specified session > > Could you clarify whether "pam_loginuid(sshd:session): set_loginuid > failed" is also in the log, as per the first message in this bug report? > Yes. The complete auth.log for a failed attempt to login as root is: Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: Accepted publickey for root from 192.168.0.121 port 37267 ssh2: DSA 1a:f2:16:e1:71:43:62:b6:13:af:91:67:e6:f0:59:8a Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: pam_loginuid(sshd:session): set_loginuid failed Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: pam_unix(sshd:session): session opened for user root by (uid=0) Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: error: PAM: pam_open_session(): Cannot make/remove an entry for the specified session Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: Received disconnect from 192.168.0.121: 11: disconnected by user Is also worth telling that not only login as root was failing, but also login as any other normal user via PAM/LDAP: Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ip121.dynamic.igalia.com user=clopez Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: Accepted password for clopez from 192.168.0.121 port 37262 ssh2 Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: pam_loginuid(sshd:session): set_loginuid failed Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: pam_unix(sshd:session): session opened for user clopez by (uid=0) Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: error: PAM: pam_open_session(): Cannot make/remove an entry for the specified session Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10413]: Received disconnect from 192.168.0.121: 11: disconnected by user I didn't tried with a local normal (not-root) user, but I can give it a try if you think is worth. signature.asc Description: OpenPGP digital signature
Bug#726661: Does not permit login as root from version 1:6.2p2-6
found 726661 1:6.4p1-2 thanks Hi, Current version on testing is also affected. I hit this bug after upgrading a machine. After rebooting it I was unable to login again. On /var/log/auth.log was the following error: sshd[10480]: error: PAM: pam_open_session(): Cannot make/remove an entry for the specified session The machine is configured with PAM/LDAP. Downgrading openssh-server to the version on stable (1:6.0p1-4) fixed the problem. signature.asc Description: OpenPGP digital signature
Bug#731155: arpwatch consumes excessive CPU with libpcap0.8 1.5.1-1
On 12/02/14 22:58, Arthur Marsh wrote: > > > Florian Schlichting wrote, on 13/02/14 07:48: >> Hi Arthur, Carlos, >> >> the issue you reportied looks a lot like >> https://github.com/the-tcpdump-group/libpcap/issues/333 or >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733747, which was >> fixed in libpcap 1.5.3 (uploaded 2014-01-16, in jessie since >> 2014-01-27). >> >> As I'm unable to reproduce the issue today, would you care to check if a >> current libpcap0.8 >= 1.5.3 makes the infinite loop go away? >> >> Florian >> >> > > Hi, I don't appear to be having this problem with > > libpcap0.8:i386 1.5.3-2 > > Regards, > > Arthur. > Same here. The problem seems fixed. Thanks! signature.asc Description: OpenPGP digital signature
Bug#368297: Does OpenLDAP has any GPLv2 dependency?
On 24/04/12 17:25, Thorsten Glaser wrote: > Hi all, > > this bug has been brought to my attention by my boss today. > If I understand the situation correctly, the problem is: > > • OpenLDAP links against GnuTLS (gnutls26) > • gnutls26 links against gcrypt, which has the bug > • gnutls28 links against nettle, but also gmp which is LGPLv3+ > • OpenLDAP thus can’t link against gnutls28, as it has reverse > dependencies that are not LGPLv3-/GPLv3-compatible > • the package affected is libnss-ldap though > Which ones are the reverse dependencies of libnss-ldap or OpenLDAP that are LGPLv3+ incompatibles? According to [1], the only combination forbidden is GPLv2 (LGPLv2 and LGPLv2.1 is allowed per point 3. of the license, explained also on [1] ). Looking at the recursive reverse dependencies of libnss-ldap [2] I fail to find any package that is GPLv2 only. If there isn't any GPLv2 reverse dependency, then OpenLDAP can be just recompiled to link against gnutls28 and this long standing bug will be fixed. Thoughts? Regards! [1] https://bugzilla.redhat.com/show_bug.cgi?id=986347 [2] $ apt-rdepends libnss-ldap signature.asc Description: OpenPGP digital signature
Bug#648160: util-vserver sponsorship request [was: Re: Bug#648160: util-vserver: wheezy vserver guests don't start]
On 26/08/13 22:03, Carlos Alberto Lopez Perez wrote: > On 26/08/13 17:51, micah wrote: >> Hi Carlos! >> >> A quick reply because I do not have very much time. I wanted to let you >> know that I am happy to have a look and sponsor it, but I wont have time >> until first week of Sept. >> >> Sorry I can't do it quicker, but I will! >> >> micah > > No problem. There is no hurry at all. > > Thanks for the follow-up :) > Hi Micah, I wonder if you will have any time to review and/or upload the package that is still on mentors: http://mentors.debian.net/package/util-vserver If not, please let me know that, and I will seek for a mentor on the mailing list of debian-mentors. Thanks! signature.asc Description: OpenPGP digital signature
Bug#707201: Unable to initialize /machine cgroup: Invalid argument
This is a me-too report.
I have just upgraded from 1.0.3-1 to 1.1.1-1 of libvirt-bin and when
I tried to start a VM from virt-manager I got the following error:
Error starting domain: internal error: Missing '/' separator in cgroup mount ''
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 117, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/domain.py", line 1160, in startup
self._backend.create()
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 698, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: Missing '/' separator in cgroup mount ''
Executing "umount -l /sys/fs/cgroup" as suggested makes the problem go away.
signature.asc
Description: OpenPGP digital signature
Bug#648160: util-vserver sponsorship request [was: Re: Bug#648160: util-vserver: wheezy vserver guests don't start]
On 26/08/13 17:51, micah wrote: > Hi Carlos! > > A quick reply because I do not have very much time. I wanted to let you > know that I am happy to have a look and sponsor it, but I wont have time > until first week of Sept. > > Sorry I can't do it quicker, but I will! > > micah No problem. There is no hurry at all. Thanks for the follow-up :) signature.asc Description: OpenPGP digital signature
Bug#648160: util-vserver sponsorship request [was: Re: Bug#648160: util-vserver: wheezy vserver guests don't start]
Hi Micah! As we discussed some months ago, I would like to take care of the package util-vserver. I have migrated the repository to git [1], and I have prepared a new upload that fixes the this bug (#648160) as also #605473 and #586510 This new upload sets me as the new maintainer of the package as we agreed. I did extensive testing and QA with this new package on some of my servers and looks everything OK. Now creating a new wheezy guest works without problems. I would thank you if you can review the upload and sponsor it, if it looks good enough for you. Otherwise let me know what should be fixed. The new upload is available at mentors.d.o [2], and the source package on the following dsc: http://mentors.debian.net/debian/pool/main/u/util-vserver/util-vserver_0.30.216-pre3038-1.dsc Thanks a lot !! Regards! [1] http://anonscm.debian.org/gitweb/?p=pkg-vserver/pkg-vserver.git [2] http://mentors.debian.net/package/util-vserver signature.asc Description: OpenPGP digital signature
Bug#573483: linux-headers-3.9-1-amd64 : Depends: linux-kbuild-3.9 but it is not installable
And again... $ sudo apt-get install linux-headers-3.9-1-amd64 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: linux-headers-3.9-1-amd64 : Depends: linux-kbuild-3.9 but it is not installable E: Unable to correct problems, you have held broken packages. $ rmadison linux-headers-3.9-1-amd64 linux-headers-3.9-1-amd64 | 3.9.4-1 | sid | amd64, i386 $ rmadison linux-kbuild-3.9 $ rmadison -S linux-tools libusbip-dev | 1.1.1+3.2.17-1 | wheezy| amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc libusbip-dev | 1.1.1+3.2.17-1 | jessie| amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc libusbip-dev | 1.1.1+3.8.11-1 | sid | amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc linux-kbuild-3.2 | 3.2.1-2~bpo60+1 | squeeze-backports | amd64, armel, i386, ia64, mips, mipsel, powerpc, s390, sparc linux-kbuild-3.2 | 3.2.17-1| wheezy| amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc linux-kbuild-3.2 | 3.2.17-1| jessie| amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc linux-kbuild-3.8 | 3.8.11-1| sid | amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc linux-tools | 3.2.1-2~bpo60+1 | squeeze-backports | source linux-tools | 3.2.17-1| wheezy| source linux-tools | 3.2.17-1| jessie| source linux-tools | 3.8.11-1| sid | source linux-tools-3.2 | 3.2.1-2~bpo60+1 | squeeze-backports | amd64, armel, i386, powerpc, s390, sparc linux-tools-3.2 | 3.2.17-1| wheezy| amd64, armel, armhf, i386, powerpc, s390, s390x, sparc linux-tools-3.2 | 3.2.17-1| jessie| amd64, armel, armhf, i386, powerpc, s390, s390x, sparc linux-tools-3.8 | 3.8.11-1| sid | amd64, armel, armhf, i386, powerpc, s390, s390x, sparc usbip| 1.1.1+3.2.17-1 | wheezy| amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc usbip| 1.1.1+3.2.17-1 | jessie| amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc usbip| 1.1.1+3.8.11-1 | sid | amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc signature.asc Description: OpenPGP digital signature
Bug#648160: util-vserver: wheezy vserver guests don't start
On 01/05/13 17:32, micah wrote: > Carlos Alberto Lopez Perez writes: > >> On 28/04/13 02:50, micah wrote: >>>> I will happily sign for that. However I would like to migrate the >>>> package scm from svn to git. I have not experience packaging with svn >>>> and learning to do that now will be a backwards step IMHO. >>> >>> As I mentioned on IRC, I think that is a fantastic idea. >>> >>>> If you can add my alioth user (clopez-guest) to the pkg-vserver project >>>> and create a new empty git repository on alioth for pkg-vserver I can >>>> take care of migrating the svn repository to git (I already have >>>> experience doing this kind of migrations) and uploading the result there >>>> for review. >>> >>> I added you to the group. >>> >> >> Hi. >> >> I don't have permissions to create the git repository. I need you to >> either grant me admin permissions on the Alioth project or to enable the >> usage of git repository on Alioth. > > I added you as an admin in the alioth project. Let me know if that still > doesn't work. > > micah > Great! I just did the migration to git. Here is a summary of the steps I followed: 1) I converted the repository from svn to git following the guide http://wiki.debian.org/Alioth/Git#Convert_a_SVN_Alioth_repository_to_Git -> At the end I renamed the tags imported from the svn repository to svn/$tag instead of debian/$tag to allow in the following step importing all dsc(s) without overwriting tags. 2) Then I imported all known debian releases. -> I got all dscs [1] from snapshoot d.o and imported them [2] I uploaded the repository to anonscm.debian.org/git/pkg-vserver/pkg-vserver.git Let me know if you find some problem or issue with what I did. Otherwise I will take this git repository as base to continue working from there. Regards! [1] curl -s http://snapshot.debian.org/package/util-vserver/|grep "li.*href"|cut -d\" -f2|while read ver; do curl -s "http://snapshot.debian.org/package/util-vserver/$ver";|grep "href.*dsc"|cut -d\" -f2; done|while read dsc; do dget -du "http://snapshot.debian.org/$dsc";; done [2] git-import-dscs --pristine-tar --author-is-committer --author-date-is-committer-date /tmp/util-verver-dscs/*.dsc signature.asc Description: OpenPGP digital signature
Bug#648160: util-vserver: wheezy vserver guests don't start
On 28/04/13 02:50, micah wrote: >> I will happily sign for that. However I would like to migrate the >> package scm from svn to git. I have not experience packaging with svn >> and learning to do that now will be a backwards step IMHO. > > As I mentioned on IRC, I think that is a fantastic idea. > >> If you can add my alioth user (clopez-guest) to the pkg-vserver project >> and create a new empty git repository on alioth for pkg-vserver I can >> take care of migrating the svn repository to git (I already have >> experience doing this kind of migrations) and uploading the result there >> for review. > > I added you to the group. > Hi. I don't have permissions to create the git repository. I need you to either grant me admin permissions on the Alioth project or to enable the usage of git repository on Alioth. Here is how to do that: http://wiki.debian.org/Alioth/FAQ#How_do_I_create_a_subversion.2Farch.2Fbzr.2Fgit.2Fhg.2Fdarcs_repository_for_my_project_.3F Thanks! signature.asc Description: OpenPGP digital signature
Bug#648160: util-vserver: wheezy vserver guests don't start
On 26/04/13 16:38, micah wrote: > Carlos Alberto Lopez Perez writes: >> I don't think this is an appropriate approach to deal with this problem. >> I rather would ask you to remove the package util-vserver from Debian >> sid completely than to have it in a broken state. > > Well, that is what I was planning on doing - removing it from > sid. Without the kernel support available, I was thinking I will give up > the package entirely. I used to provide kernel patch packages, but I am > going to attempt to migrate away from Linux-Vservers now, even though I > like them more than the current alternatives. > I'm in the same situation. I use both Debian and linux-vserver daily. Debian removed support for the vserver kernel flavor on wheezy. So I have to choose between: migrating from linux-vserver to LXC/OpenVZ or building my own kernels. LXC is not yet production ready from a security perspective. A root user on a LXC container can do very nasty things to the host system. OpenVZ faces the same fate than linux-vserver. Support for it got removed from Debian, so I would end in the same situation that I'm right now with linux-vserver. So the most reasonable option for me is building my own kernels with the vserver patchset and wait until LXC becomes at least as secure as vserver is. > So, the question then becomes... would you like to maintain this package > in Debian? It would be quite useful for people to have an active > maintainer of the user-space utilities in Debian, in my opinon. However, > I can no longer be that person. I would however be able to sponsor > package uploads, if you, or someone else, would be interested and > wanting to do that work. > I will happily sign for that. However I would like to migrate the package scm from svn to git. I have not experience packaging with svn and learning to do that now will be a backwards step IMHO. If you can add my alioth user (clopez-guest) to the pkg-vserver project and create a new empty git repository on alioth for pkg-vserver I can take care of migrating the svn repository to git (I already have experience doing this kind of migrations) and uploading the result there for review. Regards! signature.asc Description: OpenPGP digital signature
Bug#648160: util-vserver: wheezy vserver guests don't start
On 25/04/13 20:23, micah wrote: > > Hi Carlos, > > Carlos Alberto Lopez Perez writes: > >> So please: update the package to a newer upstream version. > > util-vserver was removed from wheezy as was the kernel support. It is > not surprising that this version doesn't work, it only worked with > squeeze. At this stage, it will not be included in wheezy at all. > I'm already aware of that. But that don't means that this should not be fixed on sid isn't it? > If you are interested in doing work on the user-space utilities in > Debian, or doing the work to provide the support in the kernel, it would > be welcome. > In this case, upgrading the package to the newer upstream version is quite easy. I could provide a .dsc with the changes required if you want, but I don't think I did nothing special about it. I just put the debian/ directory of the old package on the new upstream tarball, updated the changelog and cleaned debian/patches/* > With your permission, I'd like to close this bug. > I don't think this is an appropriate approach to deal with this problem. I rather would ask you to remove the package util-vserver from Debian sid completely than to have it in a broken state. Thanks for your understanding. signature.asc Description: OpenPGP digital signature
Bug#368297: About the libgcrypt and OpenLDAP issue
On 20/04/13 20:18, Carlos Alberto Lopez Perez wrote: > So, we have the following chain of successes: ^ events > > sudo/passwd/su/etc -> libpam ---(if system==PAM/LDAP)--> libpam-ldap -> > libldap ---(if URI==ldaps://)--> gnutls -> libgcrypt signature.asc Description: OpenPGP digital signature
Bug#368297: About the libgcrypt and OpenLDAP issue
On 20/04/13 02:04, Werner Koch wrote: > On Sat, 20 Apr 2013 01:35, clo...@igalia.com said: > >> I think it would be a good idea to add this feature to libgcrypt. > > See attached patch against master. It is not tested, though. You may > backport it to 1.5 and use it like this: > > #if GCRYPT_VERSION_NUMBER > 0x010502 > gcry_control (GCRYCTL_DISABLE_PRIV_DROP, 0); > #endif /* libgcrypt > 1.5.2 */ > Thanks for the patch :) Are you planning to merge it upstream? I believe it will be useful for everyone that asked for this feature on the past and ended workarounding the problem by disabling secmem. One examples of that is cryptsetup : https://code.google.com/p/cryptsetup/source/browse/lib/crypto_backend/crypto_gcrypt.c#55 >> However, I don't think that it would help us with this specific Debian >> bug because it would be implemented as an optional feature. > > I can't understand what you want to say. > I was meaning that this patch adds a flag (GCRYCTL_DISABLE_PRIV_DROP) that the application should enable. Therefore, after patching libgcrypt with the patch you provided to add support for this flag, is still needed to patch either libldap or gnutls to enable the flag. So, to fix this Debian bug with this approach, we will need patching at least two packages: 1. libgcrypt (to add support for the flag). 2. openldap or gnutls (to enable the flag). This is probably a bigger diff change than the previous ones proposed, and maybe the release team is not happy with that at this point of the freeze. >> And the suid application (sudo/su/passwd/...) can't know anything about >> libgcrypt, so it can't set this flag or any other libgcrypt flag. > > The application (sudo,su,passwd) needs to set this flag! No library is > able to know what the applications wants. Optionally you may put > wrappers in the mentioned libraries, but that makes things more > complicated and fragile. > IMHO is just impossible to add this at the application level. This applications don't have a dependency on libgcrypt. They don't use any library or symbol related to libgcrypt. So (i guess) asking their developers to introduce a dependency on libgcrypt just to enable such flag is a no-go. This applications just happen to have a dependency on libpam. And when PAM is configured to use LDAP as backend, the libpam-ldap module for PAM will chain to libldap (openldap). Then, libldap will need to use gnutls and libgcrypt related functions to talk to the LDAP backend *if* this one has SSL enabled. So, we have the following chain of successes: sudo/passwd/su/etc -> libpam ---(if system==PAM/LDAP)--> libpam-ldap -> libldap ---(if URI==ldaps://)--> gnutls -> libgcrypt And the first "libgcrypt aware" library on this chain is libldap (openldap). The previous ones on the chain have no idea about libgcrypt. Therefore such flag could only be enabled at libldap or gnutls. signature.asc Description: OpenPGP digital signature
Bug#368297: About the libgcrypt and OpenLDAP issue
On 20/04/13 00:08, Werner Koch wrote: >> At least, I think that you should consider adding a new flag to >> > libgcrypt that allows the application/library developer to complete >> > disable the dropping privileges feature. Perhaps something like: > That was my suggesttion. Shall we go for that? > I think it would be a good idea to add this feature to libgcrypt. However, I don't think that it would help us with this specific Debian bug because it would be implemented as an optional feature. And the suid application (sudo/su/passwd/...) can't know anything about libgcrypt, so it can't set this flag or any other libgcrypt flag. So the only option would be to set the flag either in gnutls or libldap. And this is more or less what the previous proposed patches are doing by disabling secmem. signature.asc Description: OpenPGP digital signature
Bug#368297: About the libgcrypt and OpenLDAP issue
On 19/04/13 20:56, Werner Koch wrote: > Having said this, I don't see a reason why not to put the > responsibilities in the hands of the suid program authors. They anyway > wake up every night due to a nightmare telling them to check this and > that and - oh - I am using a library I didn't checked for 2 releases; > lets set 2 years aside for another full audit of my entire program. > Adding two lines of code right at startup shouldn't make their headaches > worse. Basically because the authors of this programs don't know they are using libgcrypt under the hood. And they shouldn't know. They just call a standard function (ex: getpwent). This function may or may not chain with libgcrypt depending on how the system libraries are compiled and how the system is configured. On the case of a Debian system configured to use PAM/LDAP this will chain to libldap->libgrypt. The two patches proposed to fix this problem until now, what are doing under the hood, is basically disable the secmem feature of libgcrypt to prevent the dropping privileges problem. This is a suboptimal solution. I think that anybody would agree that the usage of "mlocked" memory regions for this kind of data like passwords is encouraged. The whole initialization routine of GnuTLS (which is right now broken for a threaded application that sets GCRYCTL_SET_THREAD_CBS by the libgcrypt commit d769529) disables secmem [1]. This is why reverting that commit fixes this bug (fixes the GnuTLS init routine). Why would anyone ever want to to disable the usage of secmem when handling such critical data as a TLS library could handle? Just to avoid the dropping privileges problem?? Is just insane! At least, I think that you should consider adding a new flag to libgcrypt that allows the application/library developer to complete disable the dropping privileges feature. Perhaps something like: GCRYCTL_INIT_SECMEM_NODROP_PRIVS IMHO is not the business of libgcrypt to care about the security of the application that uses it. And dropping privileges for the caller application when not directly asked is, at least, rude. The programmer of the suid application should care himself about dropping privileges when he feels like that. If you force him to drop privileges he will just skip your secmem routine. This is bad for everyone. [1] http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/gcrypt/init.c;h=3d69f44 signature.asc Description: OpenPGP digital signature
Bug#368297: About the libgcrypt and OpenLDAP issue
On 19/04/13 10:22, Werner Koch wrote: > While we are in the business of refreshing our URL memories, let me > follow up with: > > http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2198 > > Florian Weimer comes to the same conclusion regarding the PAM > architecture but also asked why we still need a suid for mlock. The > simple reason is that some installations still use suid(e.g. gpg) and > rely on Libgcrypt dropping the privileges. Thus we can't change that. I'm sure in the past was a good reason to do this (mlock required suid) but nowadays is not longer the case and you can see it causes more trouble than benefit. What about removing this feature of dropping privileges from libgcrypt and adding it to gpg itself? gpg could check if is run suid and drop itself the privileges without relying on libgcrypt to do that. This way you avoid the security problem of letting old installations run gpg suid, and the rest of the world can use the secmem feature of libgcrypt without the dropping privileges problem. Otherwise is just impossible for any suid application (that wants to stay suid) to use the libgcrypt secmem feature. Developers of this applications end disabling the secmem feature to avoid that, which in turns causes more harm than good to the security of the system. signature.asc Description: OpenPGP digital signature
Bug#368297: About the libgcrypt and OpenLDAP issue
On 19/04/13 19:25, Julien Cristau wrote: > On Fri, Apr 19, 2013 at 19:07:02 +0200, Werner Koch wrote: > >> What about my suggestion on how to solve the problem? >> > If that "solution" is to have sudo itself call into libgcrypt, that > doesn't sound like a solution at all. sudo doesn't know how libldap > implements crypto, it doesn't care, and it shouldn't have to care IMO. > Also, is not only sudo the program that is broken, but *any* setuid binary that chains into libldap->libgcrypt (aka calls getpwent() and family). This includes among others: passwd, sudo and su signature.asc Description: OpenPGP digital signature
Bug#368297: About the libgcrypt and OpenLDAP issue
On 19/04/13 10:22, Werner Koch wrote: > On Fri, 19 Apr 2013 02:52, mgilb...@debian.org said: >>> 1.a) Patch libgcrypt to revert commit >>> d769529a71ccda4e833f919f3c5693d25b005ff0 >>> >> >>> >> Urgs. That is a short sighted fix. >> > >> > That seems to be the solution the rest of the open source community is >> > converging toward. Short sighted is an odd categorization since it >> > seems to have taken 8 years to come to this conclusion. > Misunderstanding? With "a short sighted fix" I mean 1.a; that is the > proposal to _revert_ commit d769529. > > Anyway, this commit is there for a good reason; I can't remember any > details but for sure Moritz had a valid reason to do this. Those who > are interested may want to do dig the gnupg/gcrypt/poldi archives. I couldn't find anything relevant on the archives. Saying that there is a good reason for this commit to be there and at the same time saying that such good reason is unknown... won't help. It would be good to know which good reason is that. Not only for the sake of getting this bug fixed, but also because the Ubuntu guys went the way of reverting d769529. So, if reverting this commit could cause some security issue or any other kind of problem it will be good to know it before the harm is done. I'm CC'ing Moritz, perhaps he can throw a bit of light here. signature.asc Description: OpenPGP digital signature
Bug#368297: About the libgcrypt and OpenLDAP issue
On 18/04/13 20:24, Adam D. Barratt wrote: > On Thu, 2013-04-18 at 18:58 +0200, Werner Koch wrote: >> On Tue, 16 Apr 2013 20:37, a...@adam-barratt.org.uk said: >> >>> libgcrypt maintainers - any thoughts on this? >> >> Did anything change since my comments from 2010? >> >> OpenLDAP needs to get it right and it would even be better if all >> applications would set up a their policy regarding their demand for >> private key protection. For instacne by setting up a custom memory >> handler. >> Howard Chu (CC'ed) (main OpenLDAP developer) thinks the other way. Check: http://bugs.debian.org/658896#115 >> My current problem with OpenLDAP is that it can't be used anymore with >> GnuTLS 3 because the OpenSSL emulation switched to GPLv3+ > > GnuTLS 3 isn't particularly relevant to getting this RC bug fixed in > wheezy, given that wheezy will be shipping with 2.12. > >> The straightforward solution would be to change OpenLDAP to use the >> native GNUTLS API and while at it also fix the libgcrypt >> initialization. > > In less than two weeks, without introducing any new bugs? > > The realistic alternatives as far as I can see currently are that the > suggested fix gets applied or this bug remains unfixed for wheezy. > > Opinions that help towards a constructive resolution appreciated. > > Regards, > > Adam > > I see two options to get this fixed for Wheezy: [Option 1] -- Do the same that Ubuntu did. That is: 1.a) Patch libgcrypt to revert commit d769529a71ccda4e833f919f3c5693d25b005ff0 1.b) Patch python-gnutls to fix the regression that 1.a) will introduce. Check: http://bugs.debian.org/368297#173 [Option 2] -- Patch OpenLDAP to set the flag GCRYCTL_DISABLE_SECMEM if GCRYCTL_INITIALIZATION_FINISHED is false. This is the patch I previously proposed at http://bugs.debian.org/368297#135 Any of the two options will fix the problem. Which one is better? You bet signature.asc Description: OpenPGP digital signature
Bug#368297: About the libgcrypt and OpenLDAP issue
On 03/04/13 16:09, Jack Bates wrote: > Hi, here is a blog post about this issue: > > http://jdbates.blogspot.ca/2013/04/its-crazy-how-much-time-and-effort-one.html > Really very interesting stuff. Thanks for sharing Now I'm convinced that the right fix for this is to revert upstream d769529a71ccda4e833f919f3c5693d25b005ff0 [1] commit on libgcrypt like Ubuntu did. The Regression introduced on python-gnutls by such reversion was already fixed on Ubuntu with another patch (see LP:#1013798 [2]) and they have been running with the patch for some time without more problems (AFAIK) so I think that we can assume that there are no more regressions. Therefore I think we should reassign this bug back to libgcrypt11. Fix it with a patch that reverts d769529a71ccda4e833f919f3c5693d25b005ff0 [1] and then fill another RC bug for python-gnutls asking for applying the same patch that Ubuntu applied (see LP:#1013798 [2]) Andreas.. what do you think? looks this like the way to go for you? Furthermore libgcrypt upstream seems to be ok with this change, isn't it? [3] Regards! [1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=d769529a71ccda4e833f919f3c5693d25b005ff0 [2] https://bugs.launchpad.net/bugs/1013798 [3] http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2198 signature.asc Description: OpenPGP digital signature
Bug#702669: reopen 702669
On 10/03/13 23:43, Adam D. Barratt wrote: > Please don't do that; you just marked the bug as no longer fixed in > unstable. > > The BTS is quite capable of tracking the status of the bug across > multiple suites. Having it closed with appropriate versions as soon as > any of them is fixed is the correct and desired behaviour. I have to admit I'm confused about this behavior of BTS. How can I know which bugs were fixed on unstable but not on stable? Thanks in advance. signature.asc Description: OpenPGP digital signature
Bug#702669: reopen 702669
reopen 702669 thanks I'm reopening it because the fix was only uploaded to unstable (as far as I can see). signature.asc Description: OpenPGP digital signature
Bug#702669: TYPO3-CORE-SA-2013-001: SQL Injection and Open Redirection in TYPO3 Core
On 09/03/13 22:43, Carlos Alberto Lopez Perez wrote: > It has been discovered that TYPO3 Core is susceptible to SQL Injection > and Open Redirection. > > Here is the relevant information: > > https://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2013-001/ > > A CVE number was asked at: http://seclists.org/oss-sec/2013/q1/611 Forgot to mention that the SQL Injection is being exploited on the wild. """ Note: It has been reported to the TYPO3 Security Team that this problem is known and exploited in the wild. """ signature.asc Description: OpenPGP digital signature
Bug#702669: TYPO3-CORE-SA-2013-001: SQL Injection and Open Redirection in TYPO3 Core
Package: typo3
Version: 4.3.9+dfsg1-1+squeeze7
Severity: grave
Tags: security, upstream
Hi,
It has been discovered that TYPO3 Core is susceptible to SQL Injection
and Open Redirection.
Here is the relevant information:
https://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2013-001/
A CVE number was asked at: http://seclists.org/oss-sec/2013/q1/611
The patch that fixes the SQL Injection is the following:
http://git.typo3.org/TYPO3v4/CoreProjects/MVC/extbase.git/commitdiff/d00f4b6523507db3c4c7601cf7758333c8290c1d
However, to make it apply over the older typo3 at Squeeze you have to
apply it first the following ones:
http://git.typo3.org/TYPO3v4/CoreProjects/MVC/extbase.git/commitdiff/76f0c979dd5d221807c086cb7a4eb912055d8318
http://git.typo3.org/TYPO3v4/CoreProjects/MVC/extbase.git/commitdiff/68a2f3d653d77d8ed9a283e30f07e6f718c18f19
I'm attaching the file 10-SecBull-TYPO3-CORE-SA-2013-001.patch that is
ready to drop on debian/patches that is the result of applying, in
order, the above commits:
* 76f0c979dd5d221807c086cb7a4eb912055d8318
* 68a2f3d653d77d8ed9a283e30f07e6f718c18f19
* d00f4b6523507db3c4c7601cf7758333c8290c1d
For the another issue of the security bulletin (open redirection issue),
the relevant commit seems to be
http://git.typo3.org/TYPO3v4/Core.git/commit/71135d82ccb74b3ccf8673ce197cd8c4340d5163
but I don't have a backport of it to squeeze.
Typo3 at squeeze-backports and wheezy is also affected.
Regards!
--- a/typo3/sysext/extbase/Classes/Persistence/Storage/Typo3DbBackend.php
+++ b/typo3/sysext/extbase/Classes/Persistence/Storage/Typo3DbBackend.php
@@ -494,18 +494,17 @@
$typeOfRelation = $columnMap->getTypeOfRelation();
if ($typeOfRelation === Tx_Extbase_Persistence_Mapper_ColumnMap::RELATION_HAS_AND_BELONGS_TO_MANY) {
$relationTableName = $columnMap->getRelationTableName();
- $sql['where'][] = $tableName . '.uid IN (SELECT ' . $columnMap->getParentKeyFieldName() . ' FROM ' . $relationTableName . ' WHERE ' . $columnMap->getChildKeyFieldName() . '=' . $this->getPlainValue($operand2) . ')';
+ $sql['where'][] = $tableName . '.uid IN (SELECT ' . $columnMap->getParentKeyFieldName() . ' FROM ' . $relationTableName . ' WHERE ' . $columnMap->getChildKeyFieldName() . '=?)';
+ $parameters[] = intval($this->getPlainValue($operand2));
} elseif ($typeOfRelation === Tx_Extbase_Persistence_Mapper_ColumnMap::RELATION_HAS_MANY) {
$parentKeyFieldName = $columnMap->getParentKeyFieldName();
if (isset($parentKeyFieldName)) {
- $columnName = $this->dataMapper->convertPropertyNameToColumnName($operand1->getPropertyName(), $source->getNodeTypeName());
$childTableName = $columnMap->getChildTableName();
- $sql['where'][] = $tableName . '.uid=(SELECT ' . $childTableName . '.' . $parentKeyFieldName . ' FROM ' . $childTableName . ' WHERE ' . $childTableName . '.uid=' . $this->getPlainValue($operand2) . ')';
+ $sql['where'][] = $tableName . '.uid=(SELECT ' . $childTableName . '.' . $parentKeyFieldName . ' FROM ' . $childTableName . ' WHERE ' . $childTableName . '.uid=?)';
+ $parameters[] = intval($this->getPlainValue($operand2));
} else {
- $statement = '(' . $tableName . '.' . $operand1->getPropertyName() . ' LIKE \'%,' . $this->getPlainValue($operand2) . ',%\'';
- $statement .= ' OR ' . $tableName . '.' . $operand1->getPropertyName() . ' LIKE \'%,' . $this->getPlainValue($operand2) . '\'';
- $statement .= ' OR ' . $tableName . '.' . $operand1->getPropertyName() . ' LIKE \'' . $this->getPlainValue($operand2) . ',%\')';
- $sql['where'][] = $statement;
+ $sql['where'][] = 'FIND_IN_SET(?,' . $tableName . '.' . $columnName . ')';
+ $parameters[] = intval($this->getPlainValue($operand2));
}
} else {
throw new Tx_Extbase_Persistence_Exception_RepositoryException('Unsupported relation for contains().', 1267832524);
@@ -830,9 +829,9 @@
*/
protected function parseLimitAndOffset($limit, $offset, array &$sql) {
if ($limit !== NULL && $offset !== NULL) {
- $sql['limit'] = $offset . ', ' . $limit;
+ $sql['limit'] = intval($offset) . ', ' . intval($limit);
} elseif ($limit !== NULL) {
- $sql['limit'] = $limit;
+ $sql['limit'] = intval($limit);
}
}
signature.asc
Description: OpenPGP digital signature
Bug#702314: checkinstall aborts with illegal instruction on kFreeBSD
Package: checkinstall Severity: grave Version: 1.6.2-3 Justification: Renders the package unusable. On a Debian/kFreeBSD AMD64 machine running sid, checkinstall aborts with illegal instruction when trying to build a package. # checkinstall --install=no checkinstall 1.6.2, Copyright 2009 Felipe Eduardo Sanchez Diaz Duran This software is released under the GNU GPL. The package documentation directory ./doc-pak does not exist. Should I create a default set of package docs? [y]: Preparing package documentation...OK Please write a description for the package. End your description with an empty line or EOF. >> valgrind-freebsd-3.8.0 >> * Debian package creation selected *** * This package will be built according to these values: 0 - Maintainer: [ root@debian-kfreebsd ] 1 - Summary: [ valgrind-freebsd-3.8.0 ] 2 - Name:[ valgrind-freebsd ] 3 - Version: [ 3.8.0 ] 4 - Release: [ 1 ] 5 - License: [ GPL ] 6 - Group: [ checkinstall ] 7 - Architecture: [ kfreebsd-amd64 ] 8 - Source location: [ valgrind-freebsd-3.8.0 ] 9 - Alternate source location: [ ] 10 - Requires: [ ] 11 - Provides: [ valgrind-freebsd ] 12 - Conflicts: [ ] 13 - Replaces: [ ] Enter a number to change any of them or press ENTER to continue: Installing with make install... = Installation results === /usr/bin/installwatch: line 338: 53656 Illegal instruction "$@" Installation failed. Aborting package creation. Cleaning up...OK Bye. Seems that is caused by the preloaded library. Check this: # export LD_PRELOAD=/usr/lib/checkinstall/installwatch.so # nano /tmp/hello Illegal instruction # vi Vim: Caught deadly signal ILL Vim: Finished. Illegal instruction # bash Illegal instruction # dpkg -l Illegal instruction This is the relevant information: # ldd /usr/lib/checkinstall/installwatch.so libdl.so.2 => /lib/x86_64-kfreebsd-gnu/libdl.so.2 (0x000801458000) libc.so.0.1 => /lib/x86_64-kfreebsd-gnu/libc.so.0.1 (0x00080165d000) /lib/ld-kfreebsd-x86-64.so.1 (0x01021000) # apt-cache policy libc0.1:kfreebsd-amd64 libc0.1: Installed: 2.13-38 Candidate: 2.13-38 Version table: *** 2.13-38 0 500 http://ftp.debian.org/debian/ sid/main kfreebsd-amd64 Packages 100 /var/lib/dpkg/status # apt-cache policy checkinstall checkinstall: Installed: 1.6.2-3 Candidate: 1.6.2-3 Version table: *** 1.6.2-3 0 500 http://ftp.debian.org/debian/ sid/main kfreebsd-amd64 Packages 100 /var/lib/dpkg/status # uname -a GNU/kFreeBSD debian-kfreebsd 9.0-2-amd64 #0 Sat Nov 24 04:44:27 UTC 2012 x86_64 amd64 QEMU Virtual CPU version 1.1.2 GNU/kFreeBSD Thanks! signature.asc Description: OpenPGP digital signature
Bug#658739: merging with 368297 and re-assigning to openldap
reassign 658739 libldap-2.4-2 2.4.31-1 forcemerge 368297 658739 thanks This bug is the same than #368297 and others. I have attached a very small patch for openldap that solves the issue for Wheezy. It's here: http://bugs.debian.org/658896#104 signature.asc Description: OpenPGP digital signature
Bug#658896: LDAP, GnuTLS/libgcrypt
On 25/01/13 03:00, Howard Chu wrote: >> Hi! >> >> >> I have been digging on this issue and I found the ultimate cause of this >> problem. >> >> >> When sudo/su/passwd/ on >> a system configured with PAM/LDAPs it chains into libldap, which uses >> GnuTLS/libgcrypt to manage the TLS channel. >> >> >> The problem is that when OpenLDAP calls gnutls_global_init(), this >> function does nothing because OpenLDAP had previously already >> initialized libgcrypt at some point on the stack (probably by mistake). > > For the record, there is no mistake in OpenLDAP. And also for the > record, we on the OpenLDAP Project warned you guys multiple times that > GnuTLS/libgcrypt are broken by design, and should not be used. (E.g. as > I noted here > https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/62) > > The libgcrypt documentation states in section 2.5 that you *must* set > the thread callbacks before calling *any* other libgcrypt functions. > libldap's code does that. It's not our fault that libgcrypt's design is > so broken that even when you use it as documented it doesn't work. We've > been telling you for *years* that GnuTLS is broken by design. > I agree with you. But, keep in mind that GnuTLS not longer supports libgcrypt (they even removed the code from their repository). They now only support libnettle. So there is no point at all in trying to fix GnuTLS now. The upstream OpenLDAP project should probably have to remove support for libgcrypt from their code. And about the idea of patching the GnuTLS version that Debian Wheezy ships (with libgcrypt support) I'm afraid that this could break some unrelated package that relies in this broken design of GnuTLS/libgcrypt. And for Wheezy+1 GnuTLS will have to migrate to the new version (with nettle), so IMHO there is no point in fixing it now. On the other hand, I feel like this small patch for OpenLDAP is the less intrusive approach to make things just work for Wheezy. Regards! signature.asc Description: OpenPGP digital signature
Bug#368297: [PATCH] Fix dropping privileges issue on setuid programs on systems with PAM/LDAP and GnuTLS/libgcrypt
reassign 368297 libldap-2.4 2.4.31-1 thanks Hi! I have been digging on this issue and I found the ultimate cause of this problem. When sudo/su/passwd/ on a system configured with PAM/LDAPs it chains into libldap, which uses GnuTLS/libgcrypt to manage the TLS channel. The problem is that when OpenLDAP calls gnutls_global_init(), this function does nothing because OpenLDAP had previously already initialized libgcrypt at some point on the stack (probably by mistake). So, gnutls_global_init() checks that some basic initialization of libgcrypt was already done and skips completely any action. The problem is that gnutls_global_init() is supposed to set the flag GCRYCTL_DISABLE_SECMEM which disables both the use of secure memory *and* the "feature" of dropping privileges that libgcrypt has. [1] So, what is happening is that the initialization of libgcrypt is not being done as expected. I cooked a very small patch that, just after calling gnutls_global_init() checks if the initialization was successful, and if was not, then it sets this flag (DISABLE_SECMEM) I understand that (perhaps) the right fix could be to patch GnuTLS to check for INITIALIZATION_FINISHED instead of ANY_INITIALIZATION. But there are two problems with this: * One is that this could introduce some regression or bug on some program that could be (wrongly) relying on this "feature" of GnuTLS. Keep in mind that this code has been there since the beginning of the project (I was blaming the git repository) * The second problem is that GnutTLS (upstream) completely dropped the support for libgcrypt (they even removed the code). So IMHO it don't makes sense to fix GnuTLS at this point. For Jessie, GnuTLS should switch to nettle. And OpenLDAP will have to switch to another crypto library other than libgcrypt, or will have to patch the file libraries/libldap/tls_g.c to stop using any GnuTLS code. So, for the moment (Wheezy) I think the best approach to solve this bug is to apply the small patch for OpenLDAP that I'm attaching. It is the less intrusive approach to fix this bug. It don't needs to touch anything on GnuTLS or libgcrypt. It is really fixing the problem where is: OpenLDAP is not setting DISABLE_SECMEM when initializing libgcrypt. The approach taken by Ubuntu, to patch libgcrypt (LP: #423252), already caused some regressions (LP: #1013798) If someone wants to try it, I have uploaded the debs (AMD64) and the sources to this URL: http://ftp.neutrino.es/debian/OpenLDAP/ I tested that with this small patch the problem goes completely away. Example of test: 1) Install current libldap-2.4-2 from Wheezy and test sudo: root ~ # apt-get install --reinstall libldap-2.4-2=2.4.31-1 clopez ~ $ sudo whoami [sudo] password for clopez: sudo: PERM_ROOT: setresuid(0, -1, -1): Operation not permitted sudo: unable to open /var/lib/sudo/clopez/8: Operation not permitted sudo: unable to set supplementary group IDs: Operation not permitted sudo: unable to execute /usr/bin/whoami: Operation not permitted 2) Install fixed libldap-2.4-2 and test sudo: root ~ # wget http://ftp.neutrino.es/debian/OpenLDAP/libldap-2.4-2_2.4.31-1.1_amd64.deb root ~ # dpkg -i libldap-2.4-2_2.4.31-1.1_amd64.deb clopez ~ $ sudo whoami [sudo] password for clopez: root - Therefore I'm reassigning this bug to libldap-2.4 (src:OpenLDAP) Attached is also a debdiff for src:OpenLDAP Read the comments inside the patch for further information. I'm CC'ing libgcrypt/OpenLDAP/GnuTLS maintainers and will be later reporting on Ubuntu's LP this. Regards! [1] http://lists.debian.org/debian-devel/2010/03/msg00298.html https://bugs.g10code.com/gnupg/issue1181 diff -u openldap-2.4.31/debian/changelog openldap-2.4.31/debian/changelog --- openldap-2.4.31/debian/changelog +++ openldap-2.4.31/debian/changelog @@ -1,3 +1,14 @@ +openldap (2.4.31-1.1) unstable; urgency=low + + * Non-maintainer upload. + + [ Carlos Alberto Lopez Perez ] + * debian/patches/fix-dropping-privileges-by-libgcrypt-secmem.diff: +Ensure that we don't use secure memory when libgcrypt is initialized. + Avoids dropping privileges. Closes: #368297 + + -- Carlos Alberto Lopez Perez Thu, 24 Jan 2013 22:53:57 +0100 + openldap (2.4.31-1) unstable; urgency=low * New upstream release. diff -u openldap-2.4.31/debian/patches/series openldap-2.4.31/debian/patches/series --- openldap-2.4.31/debian/patches/series +++ openldap-2.4.31/debian/patches/series @@ -21,0 +22 @@ +fix-dropping-privileges-by-libgcrypt-secmem.diff only in patch2: unchanged: --- openldap-2.4.31.orig/debian/patches/fix-dropping-privileges-by-libgcrypt-secmem.diff +++ openldap-2.4.31/debian/patches/fix-dropping-privileges-by-libgcrypt-secmem.diff @@ -0,0 +1,63 @@ +Author: Carlos Alberto Lopez Perez +Date: Thu Jan 24 22:38:25 2013 +0100 +Subject: Check if the call gnutls_global_init() succeded to initalize + libg
Bug#658896: Please apply patch no_global_init_during_thread_callbacks.diff
On 23/01/13 19:48, Andreas Metzler wrote: > On 2013-01-23 Carlos Alberto Lopez Perez wrote: >> On 23/01/13 19:04, Andreas Metzler wrote: >>> On 2013-01-23 Carlos Alberto Lopez Perez wrote: > ..] >>>> I'm attaching the debdiff. I rebuilt libgcrypt11 with the attached debdiff. >>>> After installing it, sudo works as expected. >>> [...] > >>> According to the experiences in Ubuntu it breaks other stuff: >>> https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1013798 >>> (+ 2 merged bugreports) > [...] > >> If you download the last Ubuntu dsc for libgcrypt11 > >> $ dget -u >> http://archive.ubuntu.com/ubuntu/pool/main/libg/libgcrypt11/libgcrypt11_1.5.0-3ubuntu2.1.dsc > > >> You will see that the patch they are carrying is the one that >> I put on the debdiff (no-global-init-thread-callbacks.diff) > >> The previous patch (enable-global-init-secure-memory.patch) >> applied on libgcrypt11/1.5.0-3ubuntu1 was the one that caused >> the regression and was the patch reverted (. > [...] > > Hello, > > I am pretty sure you are mistaken. > > Doublechecking LP #1013798 we find this: > https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1013798/comments/12 > | I just found the apparent root cause for the libgcrypt11 crash: > | Ubuntu includes a patch called > | 'no_global_init_during_thread_callbacks.diff' > > https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1013798/comments/23 > | This bug was fixed in the package libgcrypt11 - 1.5.0-3ubuntu2 > | [...] > | * debian/patches/enable-global-init-secure-memory.patch: > | Fix regression during disable/suspend of secure memory > > https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1013798/comments/25 > | Afaict this bug should not be marked as "fixed released" anymore because > | 1.5.0-3ubuntu2.1 reverted 1.5.0-3ubuntu2. > > enable-global-init-secure-memory.patch would have fixed LP #1013798 > but was reverted back to no-global-init-thread-callbacks.diff (which > fixes the sudo/LDAP issue) because the regression > <https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1076906> > from no-global-init-thread-callbacks.diff to > enable-global-init-secure-memory.patch > was too severe. > > LP #1013798 is still open and unfixed. > > cu andreas > I see. Thanks for the clarification I can confirm that this patch is breaking python-gnutls: $ python Python 2.7.3 (default, Sep 9 2012, 17:41:34) [GCC 4.7.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gnutls.crypto Segmentation fault There is only one reverse-dependency for python-gnutls on the archive: $ apt-rdepends -r python-gnutls Reading package lists... Done Building dependency tree Reading state information... Done python-gnutls Reverse Depends: mandos (1.6.0-1) mandos signature.asc Description: OpenPGP digital signature
Bug#658896: Please apply patch no_global_init_during_thread_callbacks.diff
On 23/01/13 19:30, Carlos Alberto Lopez Perez wrote: > On 23/01/13 19:04, Andreas Metzler wrote: >> On 2013-01-23 Carlos Alberto Lopez Perez wrote: >>> severity 658896 serious >>> thanks >>> justification: Breaks unrelated software. It renders sudo unusable on >>> systems with LDAP/PAM >> [...] >> >>> What fixed the issue was applying the patch >>> no_global_init_during_thread_callbacks.diff >>> from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658896#28 >> >> >>> I'm attaching the debdiff. I rebuilt libgcrypt11 with the attached debdiff. >>> After installing it, sudo works as expected. >> [...] >> >> According to the experiences in Ubuntu it breaks other stuff: >> https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1013798 >> (+ 2 merged bugreports) >> >> I do not know whether this is a fair exchange, or whether it could >> be fixed simply. However applying the patch clearly comes at a cost. >> >> I am sorry I cannot be more helpful, but I am just not a programmer. >> >> cu andreas > > If you download the last Ubuntu dsc for libgcrypt11 > > $ dget -u > http://archive.ubuntu.com/ubuntu/pool/main/libg/libgcrypt11/libgcrypt11_1.5.0-3ubuntu2.1.dsc > > > You will see that the patch they are carrying is the one that > I put on the debdiff (no-global-init-thread-callbacks.diff) > > > The previous patch (enable-global-init-secure-memory.patch) > applied on libgcrypt11/1.5.0-3ubuntu1 was the one that caused > the regression and was the patch reverted (. > > > This one seems to be fine and don't cause regression. > > > CC'ing Ubuntu maintainer. > > > Adam, can you confirm if the patch no-global-init-thread-callbacks.diff > is fine for fixing LP: #423252 or is causing some regression? > > $ cat libgcrypt11-1.5.0/debian/patches/no-global-init-thread-callbacks.diff > --- a/src/global.c > +++ b/src/global.c > @@ -445,8 +445,6 @@ > > case GCRYCTL_SET_THREAD_CBS: >err = ath_install (va_arg (arg_ptr, void *), any_init_done); > - if (! err) > - global_init (); >break; > > case GCRYCTL_FAST_POLL: > > > > Thanks! > Basically, this patch is reverting commit d769529a upstream http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=d769529a Its from 2005 :\ Squeeze version of libgcrypt11 has this code and don't causes this problem. Why we are running into this bug now? signature.asc Description: OpenPGP digital signature
Bug#658896: Please apply patch no_global_init_during_thread_callbacks.diff
On 23/01/13 19:04, Andreas Metzler wrote: > On 2013-01-23 Carlos Alberto Lopez Perez wrote: >> severity 658896 serious >> thanks >> justification: Breaks unrelated software. It renders sudo unusable on >> systems with LDAP/PAM > [...] > >> What fixed the issue was applying the patch >> no_global_init_during_thread_callbacks.diff >> from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658896#28 > > >> I'm attaching the debdiff. I rebuilt libgcrypt11 with the attached debdiff. >> After installing it, sudo works as expected. > [...] > > According to the experiences in Ubuntu it breaks other stuff: > https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1013798 > (+ 2 merged bugreports) > > I do not know whether this is a fair exchange, or whether it could > be fixed simply. However applying the patch clearly comes at a cost. > > I am sorry I cannot be more helpful, but I am just not a programmer. > > cu andreas If you download the last Ubuntu dsc for libgcrypt11 $ dget -u http://archive.ubuntu.com/ubuntu/pool/main/libg/libgcrypt11/libgcrypt11_1.5.0-3ubuntu2.1.dsc You will see that the patch they are carrying is the one that I put on the debdiff (no-global-init-thread-callbacks.diff) The previous patch (enable-global-init-secure-memory.patch) applied on libgcrypt11/1.5.0-3ubuntu1 was the one that caused the regression and was the patch reverted (. This one seems to be fine and don't cause regression. CC'ing Ubuntu maintainer. Adam, can you confirm if the patch no-global-init-thread-callbacks.diff is fine for fixing LP: #423252 or is causing some regression? $ cat libgcrypt11-1.5.0/debian/patches/no-global-init-thread-callbacks.diff --- a/src/global.c +++ b/src/global.c @@ -445,8 +445,6 @@ case GCRYCTL_SET_THREAD_CBS: err = ath_install (va_arg (arg_ptr, void *), any_init_done); - if (! err) - global_init (); break; case GCRYCTL_FAST_POLL: Thanks! signature.asc Description: OpenPGP digital signature
Bug#658739: Re: Bug#658739: Broken su/sudo/whatever - breaks systems - up goes the severity
On 03/11/12 17:46, Andreas Metzler wrote: > On 2012-10-24 Joerg Jaspert wrote: > [...] >> Maybe the rebuild without gcrypt is a solution. I don't know, I have >> no idea what other functionality then might be missing. > > Hello, > It is not possible currently for Debian to use nettle instead of > gcrypt for license reasons. Nettle links against gmp which is LGPLv3+, > but some of the gnutls-using applications in Debian have an LGPLv3 > incompatible license like GPLv2, e.g. cups. > On 02/12/12 09:11, Andreas Metzler wrote: > We cannot switch to a GPLv2-incompatible gnutls stack on Debian > currently.[1] > > cu andreas > > [1] We will need to do this for wheezy + 1, because Debian > does not have the manpower to fork GnuTLS 2.x. But that is a different > discussion. > And how this "legal" issue will be solved in Wheezy+1? I fail to see how this will change in the future other than compiling cups with OpenSSL. I found this old discussion about dual-licensing GMP: http://gmplib.org/list-archives/gmp-devel/2011-May/001946.html But after reading it, I know the same than before... Cheers. signature.asc Description: OpenPGP digital signature
Bug#697871: dma generated headers misses the domain part (violates section-3.4.1 of rfc2822)
Package: dma Severity: grave Justification: violates section-3.4.1 of rfc2822, therefore could make unrelated software on the system to break or cause data loss (missing/bounced e-mails) DMA should append the system mailname (/etc/mailname), or the system hostname when the mailname is not available automatically to the generated e-mails when the user don't specify a domain name. Take, for example the following headers of a generated mail from cron on a system running dma: """ Received: from root (uid 0) (envelope-from root@localhost) id 18000e2 by localhost (DragonFly Mail Agent); Thu, 10 Jan 2013 17:33:25 +0100 From: root (Cron Daemon) To: root Subject: Cron test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.hourly ) (failed) Content-Type: text/plain; charset=UTF-8 X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: Date: Thu, 10 Jan 2013 07:33:25 +0100 Message-Id: <50ee60b5.18000e2.7a0902f8@localhost> """ The same message when generated by a sane MTA (Exim for example) will have: """ From: root@localhost (Cron Daemon) To: root@localhost """ To reproduce, Execute the following command on a system running DMA. echo "This is the main body of the mail" | mail -s "Testing dma sanity" mym...@address.com -- -f root If DMA is configured to deliver to an smarthost (exim), you will get your mail bounced back. """ This is the DragonFly Mail Agent at satellite.address.com. There was an error delivering your mail to . mail.adress.com [192.168.122.1] did not like our MAIL FROM: 501 : sender address must contain a domain Message headers follow. Received: from root (uid 0) (envelope-from root) id 1806b45 by satellite.address.com (DragonFly Mail Agent); Thu, 10 Jan 2013 19:12:42 +0100 To: mym...@address.com Subject: Testing dma sanity Date: Thu, 10 Jan 2013 19:12:42 +0100 Message-Id: <50ef049a.1806b45.2d33b...@satellite.address.com> From: """ Now do the same test on another system running Exim and you will see how Exim automatically adds an @mailname.tld The MTA should append _always_ an @ with the mailname/hostname part when the user don't specify it. Since this bug potentially breaks unrelated software I am marking it as a RC bug. I noticed this because my procmail rules stopped working as expected and because of bounced mails after installing DMA. Regards! signature.asc Description: OpenPGP digital signature
Bug#693048: Gajim fails to handle invalid certificates
Package: gajim Version: 0.15-1.1 Severity: grave Tags: security, upstream Forwarded: https://trac.gajim.org/ticket/7252 Gajim does not seem to properly handle invalid/broken/expired certificates. The _ssl_verify_callback function in tls_nb.py is called by OpenSSL for every certificate in the certificate chain (CA first, server certificate last) but always return True whether an error was encountered or not. This forces OpenSSL to verify each certificate until none is left, at which points it will call _ssl_verify_callback one last time with an error number of 0. (This behavior is documented here: man 3 SSL_CTX_set_verify "If verify_callback returns 1, the verification process is continued. If verify_callback always returns 1, the TLS/SSL handshake will not be terminated with respect to verification failures and the connection will be established." And can be observed in function crypto/x509/x509_vfy.c:internal_verify() in OpenSSL source code.) _ssh_verify_callback only stores the last error code, which always is 0 unless an error was encountered in the deepest level of the chain (the CA), so gajim will not warn as long as the CA is recognized. https://trac.gajim.org/ticket/7252 signature.asc Description: OpenPGP digital signature
Bug#666468: Possible duplicate
Not sure if #682308 is a duplicate of this bug, but I believe that this is the case. I was able to solve this issue by applying the third workaround on #682308 http://bugs.debian.org/682308 Regards! signature.asc Description: OpenPGP digital signature
Bug#686164: dma is unable to handle multiple address on the cc field
Package: dma
Version: 0.0.2010.06.17-13
Severity: grave
Justification: makes unrelated software on the system break
dma is not able to handle the cc field (and possibly neither the
to: and bcc: fields) when multiple address are specified (comma
separated) on such field.
Take, for example the following php script:
# cat testmail.php
\n";
$headers .= "To: User1 \n";
$headers .= "Cc: User2 , User3
\n";
$subject = "Hi!";
$body = "Hi,\n\nHow are you?\n";
if (mail($to, $subject, $body, $headers)) {
echo("Message successfully sent!\n");
} else {
echo("Message delivery failed...\n");
}
?>
If you run this script with dma installed, you get a fatal error:
# php testmail.php
sendmail: invalid recipient `'
Message delivery failed...
And the mail never is delivered.
Executing the same script on a system with another MTA (exim,
nullmailer, postfix...) works without problem.
You can check in http://www.mailinator.com if the mails were
delivered or not when testing this. You will see that with
any MTA other than dma it works without problems, but dma
fails miserably.
Since this bug potentially breaks many web applications I am
marking it as a RC bug. (I noticed this because roundcube
stopped working as expected after installing dma)
signature.asc
Description: OpenPGP digital signature
Bug#656762: Set the debug property on the fail whale so it can be moved with the mouse to a corner
Hi! When I was using gnome3 some months ago this bug annoyed me more than a couple of times, I was able to work-around it by making the annoying whale window to be a normal desktop window, so when it pop-ups you can move it to a corner with the mouse and save your data before logging out. To make the whale be a movable desktop window you just have to set the debug property. Here is the patch that I applied to achieve this: $ cat gnome-session-3.2.1/debian/patches/make-whale-be-debug.patch --- a/gnome-session/gsm-manager.c +++ b/gnome-session/gsm-manager.c @@ -286,7 +286,7 @@ allow_logout = !_log_out_is_locked_down (manager); } -gsm_fail_whale_dialog_we_failed (FALSE, +gsm_fail_whale_dialog_we_failed (TRUE, allow_logout, want_extensions_ui); } signature.asc Description: OpenPGP digital signature
Bug#677864: compiz works just fine
On 12/07/12 02:49, Adam Borowski wrote: > Could you please elaborate what exactly is the problem with compiz 0.8? > It works well; I use it at home (currently with xfce) and the only problem is > remembered window positions being wrong on startup. > > At least the situation is worlds better than the current state of certain > other window managers that are somehow made default. > Agree. I am running compiz with gnome3 fallback mode from time ago and it works like a charm. > So I don't think there is a reason for this artificial RC bug, just because > a newer but messy upstream version exists. > > I agree with Alex Goebel: compiz in its current state is fully releaseable, > even if it's not at the bleeding edge. > +1 Based on my own experience, I can say that the current version of Compiz on Debian wheezy (0.8.4) is rock solid and more than adequate for a release. I even think is much more safe to ship this fully tested version of Compiz rather than a new one (0.9.x) that may introduce bugs. signature.asc Description: OpenPGP digital signature
Bug#680414: aircrack-ng: FTBFS on most architectures
On 28/07/12 00:13, Carlos Alberto Lopez Perez wrote: > * Removed patch 013-workaround-681113-kfreebsd.diff (not longer needed > since bug #681113 was fixed) ^^^ Seems that #681113 was fixed, but the build machines are running an older version of eglibc, so the build broke on the kfreebsd machines. https://buildd.debian.org/status/logs.php?pkg=aircrack-ng I have uploaded a 1:1.1-5 version to mentors with this patch. This will allow the tests to pass on kfreebsd and the package will build. http://mentors.debian.net/debian/pool/main/a/aircrack-ng/aircrack-ng_1.1-5.dsc Is a better option to include this patch than to make the build depend on an specific version of eglibc since #681113 only breaks the tests (blackholes the buffer between aircrack-ng and grep) but it don't breaks aircrack-ng. It will be nice if you can sponsor also this new minor upload Thanks a lot! signature.asc Description: OpenPGP digital signature
Bug#683031: shoes don't works (no such file to load -- rubygems)
Package: shoes Version: 0.r396-5.2 Severity: grave Justification: makes the package in question unusable Hello, I cannot make shoes work. No matter what command switch option I try (man shoes), it always complains with: no such file to load -- rubygems $ shoes -h no such file to load -- rubygems $ shoes -m no such file to load -- rubygems $ shoes -s no such file to load -- rubygems $ shoes no such file to load -- rubygems Thanks! -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (999, 'testing'), (99, 'unstable'), (50, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.3.2-trinity (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages shoes depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-33 ii libcairo2 1.12.2-2 ii libfontconfig1 2.9.0-6 ii libfreetype62.4.9-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libgif4 4.1.6-9.1 ii libglib2.0-02.32.3-1 ii libgtk2.0-0 2.24.10-1 ii libjpeg88d-1 ii libpango1.0-0 1.30.0-1 ii libruby1.8 1.8.7.358-4 ii rubygems [rubygems1.8] 1.8.24-1 shoes recommends no packages. shoes suggests no packages. signature.asc Description: OpenPGP digital signature
Bug#680414: aircrack-ng: FTBFS on most architectures
On 27/07/12 17:17, Hector Oron wrote: > Hello, > > On Thu, Jul 19, 2012 at 06:56:03PM +0200, Carlos Alberto Lopez Perez wrote: > >> So, I would like to upload this new version [2] to unstable, but I need >> a sponsor since Paul is on holidays. >> >> >> Will you be willing to sponsor it or should I fill a RFS on debian-mentors? > > I am willing to sponsor your package and following uploads, in case is needed. > I have been using your version from mentors successfully and it even builds on > arm*. > Is it ok to sponsor your package upload? > > Regards, Hi! I have ready a new version (its named also 1:1.1-4) * I have deleted the previous one from mentors and uploaded this new one. * Be sure to re-download it again: $ dget -u http://mentors.debian.net/debian/pool/main/a/aircrack-ng/aircrack-ng_1.1-4.dsc [X] Changes on this version respect the previous one on mentors: * Included the copyright entries for the patches that add new files. * Included a patch that adds some unittests for double-ensuring that the patch 011 (gcrypt support) works as expected on all architectures. * Included a trivial patch that fixes lintian warning hardening-no-relro * Included a patch to fix bug #570981 (move some manpages to section 8) * Included a patch to fix big endian issues on aircrack-ng (fixed this after testing the package on mips). Patch forwarded to upstream * Removed patch 013-workaround-681113-kfreebsd.diff (not longer needed since bug #681113 was fixed) * Updated MAC:Vendor mappings (airodump-ng-oui.txt) * Simplified debian/rules by using makeflags [X] The summary of the changes from this new version to the last one on Debian (1:1.1-3) are reflected on the changelog I will thank you a lot if you can sponsor this new version upload, otherwise let me know it so I can fill a RFS on debian-mentors. BTW: the gcrypt patches are already committed upstream: http://trac.aircrack-ng.org/changeset/2169 http://trac.aircrack-ng.org/changeset/2170 Thanks in advance! signature.asc Description: OpenPGP digital signature
Bug#680414: aircrack-ng: FTBFS on most architectures
On 21/07/12 04:32, intrigeri wrote: > hi, > > Carlos Alberto Lopez Perez wrote (21 Jul 2012 02:08:33 GMT) : >> This patches were already reviewed by upstream [1] and will be >> committed to the aircrack-ng repository ASAP. > > Looks good! :) > > There are minor differences (in changes to src/Makefile) with the > patch submitted upstream, though. Will these differences subsist, in > the form of a Debian-specific patch, once the patch submitted upstream > is part of a future upstream release? > No, this differences are not Debian specific. This differences are because the patch submitted to upstream is rebased to the last svn version meanwhile the patch on the Debian package is for the stable version 1.1 (In the last svn version there is a new binary besside-ng, that uses some functions of crypto.c so sha1-git needs to be part of the linking process otherwise gcc will complain) On the other hand, given that there is not need anymore for keeping the debdiff small, I would probably seize this to add a new patch with the part 2 of the patch submitted to upstream (the unittests) into the package to double-ensure that all works as expected. >>> Also, debian/copyright lacks information about src/sha1-git.c. > >> because src/sha1-git.c is not part of the upstream tarball. This file is >> part of the patch debian/patches/011-add-support-for-gcrypt.diff > >> Anyway I will be adding specific copyrights on debian/copyright for the >> patches of debian/patches > > Great. Be the file part of the upstream tarball or added by a patch, > mentioning its copyright information in debian/copyright is not > optional, regardless of what must be put into the Files: field. > Didn't know this. What is your recommendation? a? b? both? a) for each new file added by a patch add a copyright entry as if the file was part of the upstream tarball. b) add copyright entries only for the patches debian/patches/patch.diff that introduces a new file. I guess option a is easy, is enough with option a? Thanks! signature.asc Description: OpenPGP digital signature
Bug#680414: aircrack-ng: FTBFS on most architectures
On 21/07/12 02:51, intrigeri wrote: > I had a look at the debdiff. To be honest, I don't feel competent to > evaluate the gnutls/gcrypt patches myself, so I'd rather not upload > this into Debian unless I'm convinced upstream will integrate these > patches, or they are reviewed by a knowledgeable third-party. > This patches were already reviewed by upstream [1] and will be committed to the aircrack-ng repository ASAP. > Also, debian/copyright lacks information about src/sha1-git.c. > because src/sha1-git.c is not part of the upstream tarball. This file is part of the patch debian/patches/011-add-support-for-gcrypt.diff Anyway I will be adding specific copyrights on debian/copyright for the patches of debian/patches Regards! [1] http://trac.aircrack-ng.org/ticket/1012 signature.asc Description: OpenPGP digital signature
Bug#680414: aircrack-ng: FTBFS on most architectures
On 18/07/12 20:06, intrigeri wrote: > Carlos Alberto Lopez Perez wrote (18 Jul 2012 17:45:08 GMT) : >> I have the new version ready on mentors. > > Cool! > >> I will let you know when I get the OK from the release-team to the >> unblock request. > > Sure. > Seems that the release-team is not willing to accept aircrack-ng on Wheezy, I tried my best to convince them but without success [1] We won't have aircrack-ng on the next stable release :( So, I would like to upload this new version [2] to unstable, but I need a sponsor since Paul is on holidays. Will you be willing to sponsor it or should I fill a RFS on debian-mentors? Thanks in advance! -- [1] http://bugs.debian.org/682005 [2] http://mentors.debian.net/package/aircrack-ng signature.asc Description: OpenPGP digital signature
Bug#680414: aircrack-ng: FTBFS on most architectures
On 18/07/12 19:37, intrigeri wrote: > Hi, > > Carlos Alberto Lopez Perez wrote (05 Jul 2012 22:39:11 GMT) : >> I don't think that the current version (1:1.1-3) should go into Wheezy >> because of this issues. Perhaps (1:1.1-4) if the release team give an >> exception could be the only chance of having aircrack-ng on Wheezy. > >> Will be working on this... thanks for reporting the issue! > > Any progress? > > Cheers, > -- > intrigeri > | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc > | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc > Yes. I have the new version ready on mentors. http://mentors.debian.net/package/aircrack-ng Paul is on holidays, so I would need some other DD to sponsor the upload. But before getting the upload sponsored to unstable I would like first to wait for the unblock approval from the release-team http://bugs.debian.org/682005 so it can make to wheezy. I will let you know when I get the OK from the release-team to the unblock request. Best regards! signature.asc Description: OpenPGP digital signature
Bug#681113: libpthread breaks pipe buffer
Package: libc0.1
Version: 2.13-34
Severity: serious
Hello!,
On a Debian/KFreeBSD 64-bits system (sid)
debian-kfreebsd ~ # uname -a
GNU/kFreeBSD debian-kfreebsd 9.0-1-amd64 #0 Fri Jun 15 21:15:10 UTC 2012 x86_64
amd64 QEMU Virtual CPU version 1.0 GNU/kFreeBSD
See the following behavior:
cat > testbuf.c << EOF
#include
#include
void *f1(){
sleep(1);
printf("Inside thread1\n");
pthread_exit(0);
}
void *f2(){
sleep(1);
printf("Inside thread2\n");
pthread_exit(0);
}
main() {
pthread_t f2_thread, f1_thread;
void *f2(), *f1();
printf ("Going to start thread1 ond thread2...\n");
pthread_create(&f1_thread,NULL,f1,NULL);
pthread_create(&f2_thread,NULL,f2,NULL);
pthread_join(f1_thread,NULL);
pthread_join(f2_thread,NULL);
}
EOF
debian-kfreebsd ~ # gcc -lpthread testbuf.c -o testbuf
debian-kfreebsd ~ # ./testbuf
Going to start thread1 ond thread2...
Inside thread1
Inside thread2
debian-kfreebsd ~ # ./testbuf | cat
<<(nothing outputs)
debian-kfreebsd ~ # ./testbuf | wc -l
0
However this don't happens every-time, sometimes it works, sometimes it don't
works. See this:
debian-kfreebsd ~ # for x in $(seq 1 20); do ./testbuf | wc -l; done
3
3
3
3
3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
But, if you run the program with "stdbuf -oL" it handles the pipe buffer as
expected every-time:
debian-kfreebsd ~ # for x in $(seq 1 20); do stdbuf -oL ./testbuf|wc -l; done
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
Needless to say that this only happens on Debian/KFreeBSD.
Neither on Debian/Linux nor in Debian/Hurd this behavior is reproducible.
Regards!
--
~~~~~~~~~~~
Carlos Alberto Lopez Perez http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~
signature.asc
Description: OpenPGP digital signature
Bug#673563: twistd crashed with TypeError in __init__(): 'reconnect' is an invalid keyword argument for this function
Package: python-poker-network Version: 1.7.7-3.2 Severity: grave Justification: renders package unusable Tags: patch -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.3.2-trinity (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-poker-network depends on: ii adduser 3.113+nmu1 ii apg 2.2.3.dfsg.1-2 ii dbconfig-common 1.8.47+nmu1 ii debconf [debconf-2.0]1.5.41 ii libjson-perl 2.53-1 ii mysql-client 5.5.23-2 ii mysql-client-5.5 [mysql-client] 5.5.23-2 ii python 2.7.2-10 ii python-central 0.6.17 ii python-memcache 1.48-1 ii python-mysqldb 1.2.3-1 ii python-openssl 0.13-1 ii python-poker-engine 1.3.6-1.1 ii python-simplejson2.3.2-1 ii python-soappy0.12.0-4 ii python-twisted 12.0.0-1 ii python2.62.6.7-4 ii rsync3.0.9-1 ii ucf 3.0025+nmu2 python-poker-network recommends no packages. Versions of packages python-poker-network suggests: ii munin-node ii mysql-server 5.5.23-2 Versions of packages python-poker-network suggests: ii munin-node ii mysql-server 5.5.23-2 -- Configuration Files: /etc/default/python-poker-network changed [not included] -- debconf information excluded -- debsums errors found: debsums: changed file /usr/share/pyshared/pokernetwork/pokerdatabase.py (from python-poker-network package) This bug is the same as launchpad #839256 https://bugs.launchpad.net/ubuntu/+source/poker-network/+bug/839256 I can confirm that the workaround suggested by Jeff Downton works: > Was able to get past this error by removing reconnect = 1 from the > list of MySQLdb.connect params on lines 63 and 123 of file > /usr/lib/python2.7/dist-packages/pokernetwork/pokerdatabase.py > I assume the version of MySQLdb packaged in this distribution is > different from the one originally used with this python package. Regards! -- ~~~~~~~~~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Bug#660420: Brother DCP-8065DN prints blank sheets
On 27/02/12 15:43, Michael Schmitt wrote: > Am 27.02.2012 13:07, schrieb Carlos Alberto Lopez Perez: >> I can confirm this. >> >> >> After the upgrade to cups=1.5.2-5 my printer "Brother DCP-8065DN >> BR-Script3" prints blank sheets. >> >> I had workarounded this downgrading the package:: >> >>sudo apt-get install -t testing cups=1.5.0-13 >> >> >> And all is working back as expected. > > Please check if changing the driver to something more generic enables > you to print again. As said, BR-Script (Brother) and KPDL (Kyocera) are > both vendor specific Postscript incarnations, so set the driver to > something similar to Postscript 1/2/3 and see if that helps. > I had success with generic Postscript 1 from foomatic. I need > confirmation that this is indeed somewhat driver specific before I want > to poke the devs even more. :) > > regards > Michael > AFAIK there is no free driver (foomatic or gutenprint) for my printer (Brother DCP-8065DN) I tried both with "Brother DCP-8045D Foomatic/Postscript" and "Brother DCP-8085DN Foomatic/Postscript" without luck. Neither of this two drivers is able to print pages. Tried both with cups 1.5.2-5 and 1.5.0-13 Regards signature.asc Description: OpenPGP digital signature
Bug#660420: Brother DCP-8065DN prints blank sheets
I can confirm this. After the upgrade to cups=1.5.2-5 my printer "Brother DCP-8065DN BR-Script3" prints blank sheets. I had workarounded this downgrading the package:: sudo apt-get install -t testing cups=1.5.0-13 And all is working back as expected. -- ~~~~~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Bug#639123: kernel-package: kernel-headers broken by linux-3.0
This has bitted me today when building a custom kernel with kernel-package I have applied the patch suggested by Mihail and it works. I have changed the logic on the first line of the patch to match kernels 3.x and above (who knows when Linus will decide to release kernel 4.x) so we avoid having this issue another time in the not-so-long future. I am attaching the patch here. The patch is above commit 3ead01d of the git repository of the package git://git.debian.org/~srivasta/debian/kernel-package.git Regards! -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ commit ec02b476e5037b22e5f3060a6703f8a93770eb11 Author: Carlos Alberto Lopez Perez Date: Wed Feb 1 03:52:49 2012 +0100 Kernel headers: match kernels from 2.6.23 (including 3.x and above) * Closes #635563 * Closes #639123 diff --git a/kernel/ruleset/targets/headers.mk b/kernel/ruleset/targets/headers.mk index ec3975c..ec1c730 100644 --- a/kernel/ruleset/targets/headers.mk +++ b/kernel/ruleset/targets/headers.mk @@ -31,7 +31,7 @@ ### LINK_ARCH=$(KERNEL_ARCH) -ifeq ($(shell if [ $(PATCHLEVEL) -eq 6 ] && [ $(SUBLEVEL) -gt 23 ] ; then \ +ifeq ($(shell if [ $(VERSION) -ge 3 ] || [ $(PATCHLEVEL) -eq 6 -a $(SUBLEVEL) -gt 23 ] ; then \ if [ $(KERNEL_ARCH) = "i386" ] || [ $(KERNEL_ARCH) = "x86_64" ] ; then \ echo "yes" ; fi ; fi ),yes) LINK_ARCH=x86 @@ -101,7 +101,7 @@ debian/stamp/install/$(h_package): -tar cfh - scripts | (cd $(SRCDIR); umask 000; tar xsf -) test ! -e arch/powerpc/lib/crtsavres.o || \ tar cfh - arch/powerpc/lib/crtsavres.o | (cd $(SRCDIR); umask 000; tar xsf -) - (cd $(SRCDIR)/include; rm -rf asm; ln -s asm-$(LINK_ARCH) asm) + (cd $(SRCDIR)/include; rm -rf asm; ln -s ../arch/$(LINK_ARCH)/include/asm asm) find . -path './scripts/*' -prune -o -path './Documentation/*' -prune -o \ -path './debian/*'-prune -o -type f \ \( -name Makefile -o -name 'Kconfig*' \) -print | \ @@ -115,7 +115,7 @@ debian/stamp/install/$(h_package): -tar cf - scripts |(cd $(SRCDIR); umask 000; tar xsf -) test ! -e arch/powerpc/lib/crtsavres.o || \ tar cfh - arch/powerpc/lib/crtsavres.o | (cd $(SRCDIR); umask 000; tar xsf -) - (cd $(SRCDIR)/include; rm -f asm; ln -s asm-$(LINK_ARCH) asm) + (cd $(SRCDIR)/include; rm -f asm; ln -s ../arch/$(LINK_ARCH)/include/asm asm) find . -path './scripts/*' -prune -o -path './Documentation/*' -prune -o \ -path './debian/*' -prune -o -type f \ \( -name Makefile -o -name 'Kconfig*' \) -print | \ signature.asc Description: OpenPGP digital signature
Bug#652235: Multiple new security issues
profile image security CVE-2012-0794 Moodle MSA-12-0005: Encryption enhancement CVE-2012-0795 Moodle MSA-12-0006: Additional email address validation CVE-2012-0796 Moodle MSA-12-0007: Email injection prevention CVE-2012-0797 Moodle MSA-12-0008: Unsynchronised access via tokens CVE-2012-0798 Moodle MSA-12-0009: Role access issue CVE-2012-0799 Moodle MSA-12-0010: Unauthorised access to session key CVE-2012-0800 Moodle MSA-12-0011: Browser autofill password issue CVE-2012-0801 Moodle MSA-12-0012: Form validation issue > > MSA-12-0001: Recaptcha transmission consistency issue > Affects: 2.2, 2.1.x, 2.0.x, 1.9.x > Fix: > http://git.moodle.org/gw?p=moodle.git;a=commitdiff;h=b608b227bac4efba76da43dabe9bc2e32fb8fa32 > Reference: http://moodle.org/mod/forum/discuss.php?d=194008 > This is an enhancement and appears to have no security impact. > > MSA-12-0002: Personal information leak > Affects: 1.9.x > Fix: > http://git.moodle.org/gw?p=moodle.git;a=commitdiff;h=36b0ddeed45d0751508dcd9fa50f17fda43bae54 > Reference: http://moodle.org/mod/forum/discuss.php?d=194009 > > Please use CVE-2012-0792 for this issue. > MSA-12-0003: Added password protection > Affects: 2.2, 2.1.x, 2.0.x, 1.9.x > Fix: > http://git.moodle.org/gw?p=moodle.git;a=commitdiff;h=aa30d3e8ce0dd41d3d0f7dae856beb180fed1f83 > Reference: http://moodle.org/mod/forum/discuss.php?d=194011 > Security enhancement to help prevent browsers from remembering a users password. > > MSA-12-0004: Added profile image security > Affects: 2.2, 2.1.x, 2.0.x, 1.9.x > Fix: > http://git.moodle.org/gw?p=moodle.git;a=commit;h=90911c4ff98dc2078a3acef5ddf5a1a8f7e20ba5 > Reference: http://moodle.org/mod/forum/discuss.php?d=194012 > Please use CVE-2012-0793 for this issue. > > MSA-12-0005: Encryption enhancement > Affects: 2.2, 2.1.x, 2.0.x, 1.9.x > Fix: > http://git.moodle.org/gw?p=moodle.git;a=commitdiff;h=98456628a24bba25d336860d38a45b5a4e3895da > Reference: http://moodle.org/mod/forum/discuss.php?d=194013 > Please use CVE-2012-0794 for this issue. > MSA-12-0006: Additional email address validation > Affects: 2.2, 2.1.x, 2.0.x, 1.9.x > Fix: > http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-13572 > Reference: http://moodle.org/mod/forum/discuss.php?d=194014 > Please use CVE-2012-0795 for this issue. > > MSA-12-0007: Email injection prevention > Affects: 2.2, 2.1.x, 2.0.x, 1.9.x > Fix: > http://git.moodle.org/gw?p=moodle.git;a=commit;h=62988bf0bbc73df655f51884aaf1f523928abff9 > Reference: http://moodle.org/mod/forum/discuss.php?d=194015 > Please use CVE-2012-0796 for this issue. > > MSA-12-0008: Unsynchronised access via tokens > Affects: 2.2, 2.1.x, 2.0.x > Fix: > http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-28126 > Reference: http://moodle.org/mod/forum/discuss.php?d=194016 > Please use CVE-2012-0797 for this issue. > > MSA-12-0009: Role access issue > Affects: 2.2, 2.1.x > Fix: > http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-29469 > Reference: http://moodle.org/mod/forum/discuss.php?d=194017 > Please use CVE-2012-0798 for this issue. > > MSA-12-0010: Unauthorised access to session key > Affects: 2.1.x, 2.0.x > Fix: > http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-27334 > Reference: http://moodle.org/mod/forum/discuss.php?d=194018 > Please use CVE-2012-0799 for this issue. > > MSA-12-0011: Browser autofill password issue > Affects: 2.2, 2.1.x, 2.0.x > Fix: > http://git.moodle.org/gw?p=moodle.git;a=commitdiff;h=6e9989dbd3f261b2e1586ff77b0bf22fc7091485 > Reference: http://moodle.org/mod/forum/discuss.php?d=194019 > Please use CVE-2012-0800 for this issue. > > MSA-12-0012: Form validation issue > Affects: 2.2, 2.1.x > Fix: > http://git.moodle.org/gw?p=moodle.git;a=commit;h=51070abc78b9e1db1db9a44855e8623b22bebd48 > Reference: http://moodle.org/mod/forum/discuss.php?d=194020 > Please use CVE-2012-0801 for this issue. -- -- -- Kurt Seifried / Red Hat Security Response Team -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
