Bug#885989: chromium: MitM-ed TLS sites are being recognized as secure even though they are not
severity 885989 wishlist tags 885989 + wontfix thanks TemTem wrote: > A large portion of websites are being (willingly) attacked by > man-in-the-middles (MitM) such as Cloudflare. When someone commissions a service provider such as CloudFlare to host their web site CloudFlare then of course CloudFlare hosts their web site. Since CloudFlare is hosting then of course they are also terminating the TLS endpoint connection. That is inherently how things work. The decision is made by the web site owner. It is their choice. They can choose host at CloudFlare or at another hosting provider or they can build up their own infrastructure. It is their decision. > Chromium aims to provide a SAFER web browsing experience, but it > fails to do that by not preventing users from being attacked by a > MitM. It is not an attack when it has been explicitly chosen by the web site to host their web server. > TLS is designed to protect against MitM attacks by providing > an end-to-end encrypted connection between the client and the > server. And so it does here. Here end to end is between the client and the server. The server is a CloudFlare server. They are being commissioned to host the web site. They are therefore terminating the TLS connection endpoint. Since they are the web site server. > Cloudflare and other similar services undermines TLS by decrypting > the connection, which is a very grave security and privacy concern, > especially for Tor users. If passwords are entered in a such service > pwned site, whether you are using TLS or not, the password (and any > other sensitive data) would be known by an unintended third-party. When CloudFlare is commissioned to host a web site then they host that web site. They are not "unintended". It is no different from any other web site. > How can Chromium know that the user is visiting a MitM-ed site? > Let's look at Cloudflare. Cloudflare uses a "cf-ray:" HTTP > header. Similar services probably has a similar kind to the > "cf-ray:" header too. Use those headers and whatever kind which will > identify that the site is pwned. If you do not trust the server site then you also cannot trust headers that it is sending. And just from a practical perspective those headers might not exist at all or might be different for every hosting provider or might be changing very frequently. All of those things make using such headers problematic. Bob signature.asc Description: PGP signature
Bug#873623: sudo: occasionally stalls infinitely instead of running command
Alban Browaeys wrote: > This is likely sssd related. > > I upgraded both today (sssd to 1.15.3-1) and "sudo ls" output was empty. > > Local workaround was to comment out "sss" on /etc/nsswitch.conf "sudoers:" > sudoers:files sss > to > sudoers:files #sss While sss might be involved additionally I reproduce the problem on my system and I do not have sssd installed at all. The sudo problem is independent of sssd. There is no sssd installed on my system which also exhibits the sudo hang problem. Bob
Bug#833741: pepperflash-nonfree: patch/nmu ?
ydir...@free.fr wrote:
> tags 833741 + patch
> thanks
>
> Is there any reason not to apply that patch ?
Unfortunately that patch does not apply cleanly now and also has a few
bugs in it such as accidentally coding in version 23.0.0.162 into the
download. Plus it added a dependency upon the "jq" program. However
the spirit of it was good and it inspired me to improve it. :-)
I spent some time today rewriting the patch and testing it with the
current 23.0.0.207 and then caught the update tonight to 24.0.0.186.
Due to the various active chromium bugs right now I was only able to
test these with chromium version 53. I can only assume that once
the current chromium 55 is stable that it will work okay with it too.
Attached is a more complete patch to pull from Adobe rather than
Google. This is working for me. (Hint to others reading this: Apply
with "patch -p1 < pepperflashplugin-nonfree.patch" in the top level
package source directory.)
Bob
diff -ru pepperflashplugin-nonfree-1.8.1+deb8u1/debian/changelog pepperflashplugin-nonfree-1.8.1+deb8u2~1/debian/changelog
--- pepperflashplugin-nonfree-1.8.1+deb8u1/debian/changelog 2016-05-20 07:25:49.0 -0600
+++ pepperflashplugin-nonfree-1.8.1+deb8u2~1/debian/changelog 2016-12-13 02:31:35.970536968 -0700
@@ -1,3 +1,13 @@
+pepperflashplugin-nonfree (1.8.1+deb8u2~1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Patched to use Adobe upstream rather than Google.
+ * Inspired by the patch provided in Bug#833741#15 by Kristian Klausen
+but rewritten. Closes: #833741.
+ * Adds in 32-bit support.
+
+ -- Bob Proulx <b...@proulx.com> Mon, 12 Dec 2016 15:41:55 -0700
+
pepperflashplugin-nonfree (1.8.1+deb8u1) jessie; urgency=medium
* Non-maintainer upload.
diff -ru pepperflashplugin-nonfree-1.8.1+deb8u1/debian/control pepperflashplugin-nonfree-1.8.1+deb8u2~1/debian/control
--- pepperflashplugin-nonfree-1.8.1+deb8u1/debian/control 2016-05-24 15:17:59.0 -0600
+++ pepperflashplugin-nonfree-1.8.1+deb8u2~1/debian/control 2016-12-13 01:10:19.124710115 -0700
@@ -8,11 +8,11 @@
Package: pepperflashplugin-nonfree
Architecture: amd64
-Depends: debconf | debconf-2.0, wget, gnupg, libatk1.0-0, libcairo2, libfontconfig1, libfreetype6, libgcc1, libglib2.0-0, libgtk2.0-0 (>= 2.14), libnspr4, libnss3, libpango-1.0-0 | libpango1.0-0, libstdc++6, libx11-6, libxext6, libxt6, libcurl3-gnutls, binutils, ${misc:Depends}, ${shlibs:Depends}
+Depends: debconf | debconf-2.0, wget, gnupg, libatk1.0-0, libcairo2, libfontconfig1, libfreetype6, libgcc1, libglib2.0-0, libgtk2.0-0 (>= 2.14), libnspr4, libnss3, libpango-1.0-0 | libpango1.0-0, libstdc++6, libx11-6, libxext6, libxt6, libcurl3-gnutls, binutils, ${misc:Depends}
Pre-Depends: ca-certificates
Suggests: chromium, ttf-mscorefonts-installer, ttf-dejavu, ttf-xfree86-nonfree, hal
Conflicts: libflash-mozplugin, chromium (<< 37.0.2062.120-4)
Description: Pepper Flash Player - browser plugin
- This package will download Chrome from Google, and unpack it to make the
+ This package will download Chrome from Adobe, and unpack it to make the
included Pepper Flash Player available for use with Chromium. The end user
- license agreement is available at Google.
+ license agreement is available at Adobe.
diff -ru pepperflashplugin-nonfree-1.8.1+deb8u1/debian/install pepperflashplugin-nonfree-1.8.1+deb8u2~1/debian/install
--- pepperflashplugin-nonfree-1.8.1+deb8u1/debian/install 2014-10-22 00:13:17.0 -0600
+++ pepperflashplugin-nonfree-1.8.1+deb8u2~1/debian/install 2016-12-12 19:54:11.636246715 -0700
@@ -1,3 +1,2 @@
update-pepperflashplugin-nonfree usr/sbin/
-pubkey-google.txt usr/lib/pepperflashplugin-nonfree/
debian/etc/chromium.d/pepperflashplugin-nonfree etc/chromium.d/
Only in pepperflashplugin-nonfree-1.8.1+deb8u2~1/debian: pepperflashplugin-nonfree
Only in pepperflashplugin-nonfree-1.8.1+deb8u2~1/debian: pepperflashplugin-nonfree.debhelper.log
Only in pepperflashplugin-nonfree-1.8.1+deb8u2~1/debian: pepperflashplugin-nonfree.substvars
diff -ru pepperflashplugin-nonfree-1.8.1+deb8u1/debian/postinst pepperflashplugin-nonfree-1.8.1+deb8u2~1/debian/postinst
--- pepperflashplugin-nonfree-1.8.1+deb8u1/debian/postinst 2013-07-09 11:55:07.0 -0600
+++ pepperflashplugin-nonfree-1.8.1+deb8u2~1/debian/postinst 2016-12-13 02:38:01.048755457 -0700
@@ -5,6 +5,9 @@
case "$1" in
configure)
update-pepperflashplugin-nonfree --install --fast || true
+ # Clean up the old Google debs as we are now using Adobe tar.gz files.
+ rm -rf /var/cache/pepperflashplugin-nonfree/*.deb
+ rm -rf /var/cache/pepperflashplugin-nonfree/latest-stable-verified.txt
;;
abort-upgrade|abort-remove|abort-deconfigure)
Only in pepperflashplugin-nonfree-1.8.1+deb8u1: pubkey-google.txt
diff -ru pepperflashplugin-nonfree-1.8.1+deb8u1/update-pepperflashplugin-nonfree pepperflashplugin-nonfree-1.8.1+deb8u2~1/update-pepperflashplugin-nonfree
---
Bug#841427: unifdef: FTBFS under some locales (eg. fr_CH.UTF-8)
severity 841427 important tags 841427 + pending thanks Changing severity level to prevent removal from Testing. This is a build time issue not a run time issue. I don't think this is a severe enough problem to warrant removing the working package from Testing. Bob
Bug#841427: unifdef: FTBFS under some locales (eg. fr_CH.UTF-8)
Chris Lamb wrote: > unifdef fails to build from source in unstable/amd64 under some > locales (eg. LANG="fr_CH.UTF-8"). Thank you for the report. I am preparing a new package upload and will fix this in that upload. > This is due to hard-coded error messages in the testsuite: I would say due to insufficient defensive setup of the test suite. But the result is the same. It fails if not being built in the C locale. :-) > - $(MAKE) test > + LC_ALL=C $(MAKE) test > touch build-stamp Agreed. Thanks! Bob signature.asc Description: PGP signature
Bug#808216: Removal of debmirror from testing
Bernhard wrote: > Do you see any chance to prevent the autoremoval? > I see you have a patch because of bug #808216. > For me, this package works fine, because i don't use the diff-files. I don't think 'grave' "renders package unusable" is correct for this since it seems to only affect those using diff files. I also don't use diff files and had not noticed any breakage. It would be a tragedy if it were removed from Testing for being unsuable since the package isn't actually unusable. It is quite usable to many. Most? Well... At least some of us. Who knows how many since there is no way to tell how many use --diff=none or not. Bob
Bug#802636: Make a bootable USB with SYNC command when the ISO source from USB, then both of USB become bootable
severity 802636 normal tag 802636 + moreinfo thanks Imam Kurniawan wrote: > First, I do apologize if I have put this into the wrong category of bug > report. > Because I have to submit the package name, which is sync command is from the > coreutils package. > But it definitely related with Debian ISO image, too. I read the report in detail. I do not believe this is a bug in either cp or sync. I have therefore downgraded the severity of this report. > >From these Installation Guide pages: > https://www.debian.org/releases/stable/i386/ch04s03.html.en > https://www.debian.org/releases/stable/amd64/ch04s03.html.en > > We only need 2 commands to make a bootable USB stick: > # cp debian.iso /dev/sdX > # sync > > These were what I use to make a bootable USB stick: > - 1 TB external hard disk with two partitions (1 GB formatted with NTFS and > the > rest of space formatted with EXT4). > - 8 GB flashdisk. > > These were the steps what I did: > - I have Debian ISO image in my external hard disk, in the EXT4 partition > (source). > - I would like to make a bootable USB stick on my flashdisk (destination). Okay. > - I did cp command (debian-8.2.0-amd64-DVD-1.iso) from external hard disk to > the flashdisk, both of them exactly via USB connection. > - Then I did sync command. What was the exact command you ran verbatim? Of most importance is knowing what device names you used in the copy. > After that, both of them became bootable USB! > I lost the partitions and data in my external hard disk. They won't be > displayed, because already became a Debian USB installer. If that is true then you mistakenly copied the iso image on top of your 1TB external hard disk and overwrote data there. I think it most likely that you used the device name of the 1T disk as the target of the cp command instead of the 8G flash usb storage. > I'm afraid if I restore the partition in my external hard disk, all the data > would become corrupt. I fear you have already overwritten the contents of the external hard disk by the size of the iso file copied over it. Because your NTFS was first on the disk it was mostly overwritten and is why it is more lost. If the size of the ISO image is smaller than the NTFS partition then it will have stopped overwriting before reaching the ext4 partition and the ext4 partition will be okay once the partition table is restored. > I don't know this problem is related with the coreutils package or Debian ISO > image. > But it would happen if use those commands when the ISO source from the USB > connection, too. > Then both of the USB drives would become bootable. > > This problem doesn't explained at the Installation Guides page. At least, > someone has tried before me. > It could be a big mess for an end user, partition and data loss at USB source. I do not believe this is a bug in the software which is why I downgraded the severity. I fear you have misunderstood the documentation describing /dev/sdX to be the target device you wish to copy onto and replaced /dev/sdX with the device name of your 1T external USB hard disk. Instead it should have been the device name of your USB 8G flash storage device. Assuming *three* devices attached to your system then /dev/sda would be the disk you booted from, /dev/sdb would be the next discovered USB device, /dev/sdc would be the next discovered USB device after that point. Because you are using USB devices which are hotplugged devices the names will be dynamically assigned in the order in which the devices were plugged into the system. You would always need to look in detail to determine which one is which one and use the correct one. It is easier with only one USB device. Because then /dev/sda is almost always the boot device and /dev/sdb would be the additional USB device. (Usually. Because of the way Linux assigns names this may not always be true and should always be verified.) In your case of using two USB devices then the device names are assigned in order of installation and may be different. Bob
Bug#793745: [pkg-ntp-maintainers] Bug#793745: ntp fails to start
Christophe Wolfhugel wrote: Kurt Roeckx wrote: Do you use the default ntp.conf as shipped in the latest package? If not can you either try that or add rlimit memlock 0 at the top of ntp.conf? Good hit Kurt. No I do not use the stock ntp.conf ... Same here. I have the exact same results as Christophe reports. The problem is the requirement for rlimit memlock 0 to be present in the configuration file. That wasn't needed previously. I would conclude that something somewhere makes the getpw* call fail when rlimit memlock 0 is not used. Yes. As it is now anyone who upgrades and keeps their previously working ntp.conf file will find the daemon unable to start. I think any option that is required is no longer optional. :-( Michael Stone wrote: Based on the conversations upstream, I'd say that rlimit memlock 0 should be the default in debian, not something that needs to be added to working configs. ... Agreed. Bob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793745: ntp fails to start
Package: ntp Version: 1:4.2.8p3+dfsg-1 Severity: serious After today's update ntp no longer starts on my Sid system. After being gone on travel for ten days I return and update Sid and now ntp isn't running. The log message reports: Jul 26 19:23:54 hysteria ntpd[15300]: ntpd 4.2.8p3@1.3265-o Sat Jul 25 15:02:27 UTC 2015 (1): Starting Jul 26 19:23:54 hysteria ntpd[15300]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 109:116 Jul 26 19:23:54 hysteria ntpd[15301]: proto: precision = 0.838 usec (-20) Jul 26 19:23:54 hysteria ntpd[15301]: restrict 0.0.0.0: KOD does nothing without LIMITED. Jul 26 19:23:54 hysteria ntpd[15301]: restrict ::: KOD does nothing without LIMITED. Jul 26 19:23:54 hysteria ntpd[15301]: Listen and drop on 0 v6wildcard [::]:123 Jul 26 19:23:54 hysteria ntpd[15301]: Listen and drop on 1 v4wildcard 0.0.0.0:123 Jul 26 19:23:54 hysteria ntpd[15301]: Listen normally on 2 lo 127.0.0.1:123 Jul 26 19:23:54 hysteria ntpd[15301]: Listen normally on 3 br0 192.168.230.119:123 Jul 26 19:23:54 hysteria ntpd[15301]: Listen normally on 4 lo [::1]:123 Jul 26 19:23:54 hysteria ntpd[15301]: Listen normally on 5 br0 [fe80::21c:c0ff:fe8c:7300%3]:123 Jul 26 19:23:54 hysteria ntpd[15301]: Listening on routing socket on fd #22 for interface updates Jul 26 19:23:54 hysteria ntpd[15301]: Cannot find user ID 109 $ grep 109 /etc/passwd ntp:x:109:116::/home/ntp:/bin/false $ grep 116 /etc/group ntp:x:116: Downgrading to 1:4.2.6.p5+dfsg-7 still available in Testing fixes the problem. apt-get install ntp=1:4.2.6.p5+dfsg-7 To prevent the new ntp from migrating to Testing I have assigned the severity to serious which I believe is the lowest severity that will prevent automated migration to Testing. Thank you for maintaining ntp in Debian! Bob -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages ntp depends on: ii adduser 3.113+nmu3 ii dpkg 1.18.1 ii libc62.19-19 ii libcap2 1:2.24-9 ii libedit2 3.1-20150325-1 ii libgcc1 1:5.1.1-14 ii libopts251:5.18.6~pre3-3 ii libssl1.0.0 1.0.2d-1 ii lsb-base 4.1+Debian13+nmu1 ii netbase 5.3 Versions of packages ntp recommends: ii perl 5.20.2-6 Versions of packages ntp suggests: ii ntp-doc 1:4.2.8p3+dfsg-1 -- Configuration Files: /etc/ntp.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792176: mysql-server-5.5: uninstallable in sid
Andreas Beckmann wrote: Since the upload of mysql-5.6 mysql-5.5 is no longer installable in sid. I am not the maintainer but just another interested user. In that spirit I note that mysql-5.1 is no longer installable in Sid either. Is that a bug? Isn't that simply the nature of Sid that things move forward there leaving older versions behind? The new mysql-server-5.5 5.5.43-0+deb8u1 Pre-Depends mysql-common (= 5.5.43-0+deb8u1) and mysql-common in sid has been replaced. Installing 5.5 will require a DOWNGRADE of mysql-common and therefore must be specified explicitly. One can install 5.5 by explicitly installing the previous version this way: apt-get install mysql-server-5.5 mysql-common=5.5.43-0+deb8u1 However that depends upon the availability of mysql-common version 5.5.43-0+deb8u1 which will need to be pulled from either Testing (while available there) or snapshot.debian.org. On my Sid machine today I see this: # apt-cache policy mysql-common mysql-common: Installed: 5.6.25-2 Candidate: 5.6.25-2 Version table: *** 5.6.25-2 0 500 http://ftp.us.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status 5.5.43-0+deb8u1 0 500 http://ftp.us.debian.org/debian/ sid/main amd64 Packages 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages To help with transitions in Sid it is a best practice to include Testing in the sources.list file for these and other cases. However anything older will need snapshot.debian.org for retrieval. Bob signature.asc Description: Digital signature
Bug#770695: Still getting fault in dovecot-core (1:2.2.13-11)
Dom Noble wrote: So I notice this bug has been reported as fixed, but i tried to do a apt-get upgrade over crimbo and my dpkg seems to be throwing the same fault in dovecot-core (1:2.2.13-11), As I read your report it is returning an error. Bug#770695 is about a hang during installation. Your problem reads to me like a completely different problem. Setting up dovecot-core (1:2.2.13-11) ... Job for dovecot.service failed. See 'systemctl status dovecot.service' and 'journalctl -xn' for details. invoke-rc.d: initscript dovecot, action start failed. dpkg: error processing package dovecot-core (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of dovecot-imapd: dovecot-imapd depends on dovecot-core (= 1:2.2.13-11); however: Package dovecot-core is not configured yet. That exited with an error so seems like a completely different problem from the hang bug. It looks like a package upgrade problem preventing the daemon from starting. I suggest making a new bug report with these problem details so that it can be dealt with individually. Bob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770695: Dovecot-core unable to finish its installation
I just tested the latest 1:2.2.13-11 and all went perfectly. No hangs. No file conflicts. All good! Thank you and everyone for persevering on this problem! Bob # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: dovecot-core dovecot-gssapi dovecot-imapd dovecot-ldap dovecot-mysql dovecot-pgsql dovecot-sieve dovecot-sqlite 9 upgraded, 0 newly installed, 0 to remove and 6 not upgraded. Need to get 6857 kB of archives. After this operation, 1024 B of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.us.debian.org/debian/ sid/main dovecot-sqlite amd64 1:2.2.13-11 [529 kB] Get:2 http://ftp.us.debian.org/debian/ sid/main dovecot-imapd amd64 1:2.2.13-11 [646 kB] Get:3 http://ftp.us.debian.org/debian/ sid/main dovecot-pgsql amd64 1:2.2.13-11 [533 kB] Get:4 http://ftp.us.debian.org/debian/ sid/main dovecot-sieve amd64 1:2.2.13-11 [766 kB] Get:5 http://ftp.us.debian.org/debian/ sid/main dovecot-ldap amd64 1:2.2.13-11 [544 kB] Get:6 http://ftp.us.debian.org/debian/ sid/main dovecot-gssapi amd64 1:2.2.13-11 [530 kB] Get:7 http://ftp.us.debian.org/debian/ sid/main dovecot-mysql amd64 1:2.2.13-11 [531 kB] Get:8 http://ftp.us.debian.org/debian/ sid/main dovecot-core amd64 1:2.2.13-11 [2654 kB] Fetched 6857 kB in 54s (125 kB/s) (Reading database ... 606280 files and directories currently installed.) Preparing to unpack .../dovecot-sqlite_1%3a2.2.13-11_amd64.deb ... Unpacking dovecot-sqlite (1:2.2.13-11) over (1:2.2.13-10) ... Preparing to unpack .../dovecot-imapd_1%3a2.2.13-11_amd64.deb ... Stopping IMAP/POP3 mail server: dovecot. Unpacking dovecot-imapd (1:2.2.13-11) over (1:2.2.13-10) ... Preparing to unpack .../dovecot-pgsql_1%3a2.2.13-11_amd64.deb ... Unpacking dovecot-pgsql (1:2.2.13-11) over (1:2.2.13-10) ... Preparing to unpack .../dovecot-sieve_1%3a2.2.13-11_amd64.deb ... Unpacking dovecot-sieve (1:2.2.13-11) over (1:2.2.13-10) ... Preparing to unpack .../dovecot-ldap_1%3a2.2.13-11_amd64.deb ... Unpacking dovecot-ldap (1:2.2.13-11) over (1:2.2.13-10) ... Preparing to unpack .../dovecot-gssapi_1%3a2.2.13-11_amd64.deb ... Unpacking dovecot-gssapi (1:2.2.13-11) over (1:2.2.13-10) ... Preparing to unpack .../dovecot-mysql_1%3a2.2.13-11_amd64.deb ... Unpacking dovecot-mysql (1:2.2.13-11) over (1:2.2.13-10) ... Preparing to unpack .../dovecot-core_1%3a2.2.13-11_amd64.deb ... Stopping IMAP/POP3 mail server: dovecot. Unpacking dovecot-core (1:2.2.13-11) over (1:2.2.13-10) ... Processing triggers for mime-support (3.57) ... Processing triggers for desktop-file-utils (0.22-1) ... Processing triggers for menu (2.1.47) ... Processing triggers for man-db (2.7.0.2-4) ... Setting up dovecot-core (1:2.2.13-11) ... Starting IMAP/POP3 mail server: dovecot. Setting up dovecot-sqlite (1:2.2.13-11) ... Setting up dovecot-imapd (1:2.2.13-11) ... Setting up dovecot-pgsql (1:2.2.13-11) ... Setting up dovecot-sieve (1:2.2.13-11) ... Setting up dovecot-ldap (1:2.2.13-11) ... Setting up dovecot-gssapi (1:2.2.13-11) ... Setting up dovecot-mysql (1:2.2.13-11) ... Processing triggers for menu (2.1.47) ... Processing triggers for dovecot-core (1:2.2.13-11) ... Restarting IMAP/POP3 mail server: dovecot. Starting IMAP/POP3 mail server: dovecot. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770695: Dovecot-core unable to finish its installation
I just upgraded dovecot 1:2.2.13-10. I also tested --reinstall. There were no hangs. The upgrade completed without the previous hang problem. I did however run into a file conflict which I reported as https://bugs.debian.org/772885 I think that might simply be a bad -8 and will test and followup for that issue in that report. In the meantime I didn't have any hang problems with -10. Yay! Thanks for giving this problem all of your efforts. Bob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770695: Dovecot-core unable to finish its installation
Jaldhar H. Vyas wrote: I'm concentrating on this file because it has upto now been the cause of the postinst hang in every report I've received but the thing is the 10-ssl.conf you sent me is precisely what we should expect to see after a successful upgrade to -8. So if you did have something different in your file it has already been overwritten. I don't suppose you use something like etckeeper do you? Or maybe some backup from around when you had -5 or 6 installed. How would previous changes to that file explain the current hang upon a --reinstall? At the present time the only changes I have outstanding are in the 10-mail.conf file. I do actually use etckeeper and can reach back in time to pull forward previous file versions. However the current state of those files is enough to trigger the problem so it doesn't seem necessary to reach back in time to find a previous version. The current state is sufficient to do it. Hmm... It appears to leave it in a state that reconfiguring again succeeds. ... Yes, by this time the new config file has been installed and whatever caused the hang has been overwritten. Hmm... I am not seeing any dialog prompts about merging new configuration files. I haven't seen any ucf prompts. If you are suspicious of the ucf config file handling then 10-mail.conf is locally modified. I will make some experients there. But again if I --reinstall then the problem is recreated. It is repeatable on my system. Unfortunately I can't reproduce this. Can you run the command ucfq dovecot-core before and after reinstalling? It will tell us if any config file has changed. Yes. The state before and after are identical therefore I attach only one file for both. Bob Configuration filePackage Exists Changed /etc/dovecot/conf.d/10-auth.conf dovecot-coreYes No /etc/dovecot/conf.d/10-director.conf dovecot-coreYes No /etc/dovecot/conf.d/10-logging.conf dovecot-coreYes No /etc/dovecot/conf.d/10-mail.conf dovecot-coreYesYes /etc/dovecot/conf.d/10-master.confdovecot-coreYes No /etc/dovecot/conf.d/10-ssl.conf dovecot-coreYes No /etc/dovecot/conf.d/10-tcpwrapper.confdovecot-coreYes No /etc/dovecot/conf.d/15-lda.conf dovecot-coreYes No /etc/dovecot/conf.d/15-mailboxes.conf dovecot-coreYes No /etc/dovecot/conf.d/90-acl.conf dovecot-coreYes No /etc/dovecot/conf.d/90-plugin.confdovecot-coreYes No /etc/dovecot/conf.d/90-quota.conf dovecot-coreYes No /etc/dovecot/conf.d/auth-checkpassword.conf.e dovecot-coreYes No /etc/dovecot/conf.d/auth-deny.conf.extdovecot-coreYes No /etc/dovecot/conf.d/auth-master.conf.ext dovecot-coreYes No /etc/dovecot/conf.d/auth-passwdfile.conf.ext dovecot-coreYes No /etc/dovecot/conf.d/auth-sql.conf.ext dovecot-coreYes No /etc/dovecot/conf.d/auth-static.conf.ext dovecot-coreYes No /etc/dovecot/conf.d/auth-system.conf.ext dovecot-coreYes No /etc/dovecot/conf.d/auth-vpopmail.conf.extdovecot-coreYes No /etc/dovecot/dovecot-db.conf.ext dovecot-coreYes /etc/dovecot/dovecot-dict-sql.conf.extdovecot-coreYes /etc/dovecot/dovecot-sql.conf.ext dovecot-coreYes /etc/dovecot/dovecot.conf dovecot-coreYes No /etc/ssl/certs/dovecot.pemdovecot-core /etc/ssl/private/dovecot.pem dovecot-core
Bug#770695: Dovecot-core unable to finish its installation
Jaldhar H. Vyas wrote: Sorry, one more question. Do the files /etc/dovecot/dovecot.pem and /etc/dovecot/private/dovecot.pem exist? Questions are good. -rw-r--r-- 1 root dovecot 1257 May 12 2010 /etc/dovecot/dovecot.pem -rw--- 1 root dovecot 887 May 12 2010 /etc/dovecot/private/dovecot.pem Bob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770695: Dovecot-core unable to finish its installation
reopen 770695 ! thanks Since 2014-11-28 I have been unable to continue an installation of dovecot on my up to date Sid amd64 system. The problem sounds identical to the previous posters here. I read through the bug log and I do not believe the problem has been fixed yet. apt-get upgrade ... Setting up dovecot-core (1:2.2.13-7) ... Replacing config file /etc/dovecot/conf.d/10-ssl.conf with new version Starting IMAP/POP3 mail server: dovecot. ...hang...never returns... root 415 32407 0 15:16 pts/58 00:00:00 /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/dovecot-core.postinst configure 1:2.2.13-6 ... killing 415 allowed the apt-get install process to continue... This problem persists as recently as today when I had time to look into it further. If I try to reinstall the problem is recreated. The only way to break it free is to kill 12128 below so that the process will error. UIDPID PPID C STIME TTY TIME CMD root 11008 12921 2 21:58 pts/60 00:00:01 /usr/bin/apt-get install --reinstall dovecot-core root 12127 11008 0 21:59 pts/63 00:00:00 /usr/bin/dpkg --status-fd 23 --configure dovecot-core:amd64 root 12128 12127 3 21:59 pts/63 00:00:00 /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/dovecot-core.postinst configure 1:2.2.13-8 root 12134 12128 0 21:59 pts/63 00:00:00 [dovecot-core.po] defunct What can I do to get more debug information for you? Bob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770695: Dovecot-core unable to finish its installation
Jaldhar H. Vyas wrote: Bob Proulx wrote: Setting up dovecot-core (1:2.2.13-7) ... Replacing config file /etc/dovecot/conf.d/10-ssl.conf with new version Starting IMAP/POP3 mail server: dovecot. ...hang...never returns... Have you tried -8? which I uploaded earlier today? I think (hope(pray)) that did finally fix the upgrade issue. Sorry. The above was captured by me with -7. But during my reinstall tests just a few minutes ago it was with the -8 package. No change. The ps listings I showed were from the -8 package. Here is more fresh detail. # apt-get install --reinstall dovecot-core Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 9 not upgraded. Need to get 0 B/2674 kB of archives. After this operation, 0 B of additional disk space will be used. (Reading database ... 602023 files and directories currently installed.) Preparing to unpack .../dovecot-core_1%3a2.2.13-8_amd64.deb ... Stopping IMAP/POP3 mail server: dovecot. Unpacking dovecot-core (1:2.2.13-8) over (1:2.2.13-8) ... Processing triggers for man-db (2.7.0.2-3) ... Setting up dovecot-core (1:2.2.13-8) ... Starting IMAP/POP3 mail server: dovecot. ...hang... ...take a clock timestamp... Wed, 03 Dec 2014 22:29:02 -0700 ...do other things for a few minutes... ...take a ps listing... root 23957 12921 2 22:28 pts/60 00:00:04 /usr/bin/apt-get install --reinstall dovecot-core root 24889 23957 0 22:28 pts/65 00:00:00 /usr/bin/dpkg --status-fd 23 --configure dovecot-core:amd64 root 24890 24889 0 22:28 pts/65 00:00:00 /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/dovecot-core.postinst configure 1:2.2.13-8 root 24896 24890 0 22:28 pts/65 00:00:00 [dovecot-core.po] defunct ...wait a while longer... ...Wed, 03 Dec 2014 22:48:41 -0700 ...it is really stuck... ...kill 24890... dpkg: error processing package dovecot-core (--configure): subprocess installed post-installation script was killed by signal (Terminated) Errors were encountered while processing: dovecot-core E: Sub-process /usr/bin/dpkg returned an error code (1) Bob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770695: Dovecot-core unable to finish its installation
Jaldhar H. Vyas wrote: Bob Proulx wrote: Sorry. The above was captured by me with -7. But during my reinstall tests just a few minutes ago it was with the -8 package. No change. The ps listings I showed were from the -8 package. Drat. :-) I know the feeling. 1. Which version were you originally upgrading from? $ zgrep dovecot-core /var/log/dpkg.log* | awk '$3==upgrade' /var/log/dpkg.log-20140401.gz:2014-03-11 11:17:53 upgrade dovecot-core:amd64 1:2.2.9-1 1:2.2.10-1 /var/log/dpkg.log-20140401.gz:2014-03-24 16:15:55 upgrade dovecot-core:amd64 1:2.2.10-1 1:2.2.12-2 /var/log/dpkg.log-20140501.gz:2014-04-23 12:30:58 upgrade dovecot-core:amd64 1:2.2.12-2 1:2.2.12-3 /var/log/dpkg.log-20140601.gz:2014-05-12 13:11:12 upgrade dovecot-core:amd64 1:2.2.12-3 1:2.2.13~rc1-1 /var/log/dpkg.log-20140601.gz:2014-05-26 15:44:46 upgrade dovecot-core:amd64 1:2.2.13~rc1-1 1:2.2.13-1 /var/log/dpkg.log-20140701.gz:2014-06-30 15:03:51 upgrade dovecot-core:amd64 1:2.2.13-1 1:2.2.13-2 /var/log/dpkg.log-20140801.gz:2014-07-21 09:35:13 upgrade dovecot-core:amd64 1:2.2.13-2 1:2.2.13-3 /var/log/dpkg.log-20140801.gz:2014-07-31 18:44:39 upgrade dovecot-core:amd64 1:2.2.13-3 1:2.2.13-4 /var/log/dpkg.log-20141001.gz:2014-09-08 10:41:33 upgrade dovecot-core:amd64 1:2.2.13-4 1:2.2.13-5 /var/log/dpkg.log-20141101.gz:2014-10-27 12:05:00 upgrade dovecot-core:amd64 1:2.2.13-5 1:2.2.13-6 /var/log/dpkg.log-20141201:2014-11-28 15:14:56 upgrade dovecot-core:amd64 1:2.2.13-6 1:2.2.13-7 /var/log/dpkg.log:2014-12-03 14:38:45 upgrade dovecot-core:amd64 1:2.2.13-7 1:2.2.13-8 /var/log/dpkg.log:2014-12-03 21:58:59 upgrade dovecot-core:amd64 1:2.2.13-8 1:2.2.13-8 /var/log/dpkg.log:2014-12-03 22:28:26 upgrade dovecot-core:amd64 1:2.2.13-8 1:2.2.13-8 2. Did you edit /etc/dovecot/conf.d/10-ssl.conf at all (from any version.) Not that I recall. I haven't done anything with the dovecot configuration for quite a while now. 3. Would you mind sending me the contents of that file? Attached. 4. During the upgrade do you remember seeing any message about updating that file? No. I pasted the output verbatim. 5. This is a long shot but...do you have the ucf package installed? Yes. It is required by other packages. $ dpkg --status ucf Package: ucf Status: install ok installed Version: 3.0030 ... Past my bedtime now but if you can answer these questions, I'll look into this tomorrow. Hmm... It appears to leave it in a state that reconfiguring again succeeds. # dpkg --configure -a Setting up dovecot-core (1:2.2.13-8) ... Starting IMAP/POP3 mail server: dovecot. I see this in the syslog. Dec 3 22:28:27 despair dovecot: master: Warning: Killed with signal 15 (by pid=24051 uid=0 code=kill) Dec 3 22:28:41 despair dovecot: master: Dovecot v2.2.13 starting up for imap (core dumps disabled) But again if I --reinstall then the problem is recreated. It is repeatable on my system. I would be happy to test candidate packages or hacks or patches directly if you provide them to me. Since I have a system in the victim state and can test. This is not a production system but is my own desktop that I use for exactly this type of testing so that we can catch problems before it releases. Get some sleep! :-) Bob ## ## SSL settings ## # SSL/TLS support: yes, no, required. doc/wiki/SSL.txt ssl = no # PEM encoded X.509 SSL/TLS certificate and private key. They're opened before # dropping root privileges, so keep the key file unreadable by anyone but # root. Included doc/mkcert.sh can be used to easily generate self-signed # certificate, just make sure to update the domains in dovecot-openssl.cnf #ssl_cert = /etc/dovecot/dovecot.pem #ssl_key = /etc/dovecot/private/dovecot.pem # If key file is password protected, give the password here. Alternatively # give it when starting dovecot with -p parameter. Since this file is often # world-readable, you may want to place this setting instead to a different # root owned 0600 file by using ssl_key_password = path. #ssl_key_password = # PEM encoded trusted certificate authority. Set this only if you intend to use # ssl_verify_client_cert=yes. The file should contain the CA certificate(s) # followed by the matching CRL(s). (e.g. ssl_ca = /etc/ssl/certs/ca.pem) #ssl_ca = # Require that CRL check succeeds for client certificates. #ssl_require_crl = yes # Directory and/or file for trusted SSL CA certificates. These are used only # when Dovecot needs to act as an SSL client (e.g. imapc backend). The # directory is usually /etc/ssl/certs in Debian-based systems and the file is # /etc/pki/tls/cert.pem in RedHat-based systems. #ssl_client_ca_dir = #ssl_client_ca_file = # Request client to send a certificate. If you also want to require it, set # auth_ssl_require_client_cert=yes in auth section. #ssl_verify_client_cert = no # Which field from certificate to use for username. commonName and # x500UniqueIdentifier are the usual choices. You'll
Bug#744921: spamassassin: Daily cron script wants to set a shared library world writable
Roger Dover wrote:
The script wants to set a shared library world writable.
This is a security risk.
Thank you for the report. However I am not sure this is actually a
problem. Also please say how you instrumented your system in order to
have received that error notification.
I believe the chmod you are referencing is not actually in sa-compile.
I think it is in Perl's Install.pm which is part of the perl-modules
package. It does this immediately before unlinking the target file.
In /usr/share/perl/5.14.2/ExtUtils/Install.pm file:
sub _unlink_or_rename { #XXX OS-SPECIFIC
my ( $file, $tryhard, $installing )= @_;
_chmod( 0666, $file );
my $unlink_count = 0;
while (unlink $file) { $unlink_count++; }
return $file if $unlink_count 0;
...
Therefore there isn't much way for an attacker to attack those files
since they are unlinked immediately afterward. However if there is
then this bug should be assigned to the perl-modules package owning
the Install.pm file.
It would be good if you as the issue reporter could verify this since
you have already instrumented your system for the test. I suggest
temporarily setting up the test by editing your local copy of the file
/usr/share/perl/5.14.2/ExtUtils/Install.pm to comment out the chmod
line note above. If after doing that you no longer see those
notifications then you have verified that the issue is the presense of
those lines in the Install.pm file. You can restore the original file
after the completion of the test.
Please report your findings.
Bob
signature.asc
Description: Digital signature
Bug#729019: chromium: Running without the SUID sandbox!
close 729019 forcemerge 728823 729019 thanks Charles Kroeger wrote: Reportbug says there's a newer version of Chromium available but when I do a apt-get update and dist-upgrade or apt-get -u upgrade chromium, I get the following error message: chromium is already the newest version. There is a newer version available. The above simply means that the mirror you are using has not sync'd yet and does not yet contain the new package. It will as soon as the mirror you are using syncs. Since this has already been reported and discussed in the other bug ticket which was closed with the upload I am going to close and merge this report. It is best to check the BTS for other reports to avoid duplicates. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728823 For any questions about versions it is good to check the PTS for package version status. Version 30.0.1599.101-3 was uploaded today. http://packages.qa.debian.org/c/chromium-browser.html Bob signature.asc Description: Digital signature
Bug#728846: chromium: Running without the SUID sandbox!
close 728846 forcemerge 728823 728846 thanks Léo Cavaillé wrote: I had the same problem tonight when upgrading to 30.0.1599.101-2. Version 30.0.1599.101-3 was uploaded at 2013-11-07 15:27:45 UTC today which fixed this bug. It may take some time for your mirror to sync so that it is available to you. I have installed it from the mirror I am using and it fixes the problem for me. I could see that the sandbox filename was changed in a recent commit, this quick-fixed the problem : root@stelar:/usr/lib/chromium# cp chromium-sandbox chrome-sandbox root@stelar:/usr/lib/chromium# chmod 4755 chrome-sandbox This is a serious bug as it breaks totally the launch of chromium.. Thanks for your help Please see this reference for the resolution. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728823#35 Since this has already been reported and discussed in the other bug ticket which was closed with the upload I am going to close and merge this report. Bob signature.asc Description: Digital signature
Bug#711236: RFC: reverting ruby-rack to 1.4.x with an epoch
Cédric Boutillier wrote: Antonio Terceiro wrote: I am planning to revert ruby-rack on unstable back to upstream version 1.4.x by using an epoch. ruby-rack 1.5.x breaks rails session management, and as a consequence, redmine. Thanks for taking care of this. ... About the epoch, as I said earlier on IRC, I think it might be better to go with a 1.5.2+really1.4.5-1 or something similar since: - it is supposed to be a temporary fix. Having to cope with an epoch indefinitely because of this issue would be a pity - packages depending on ruby-rack = 1.5 will be broken in unstable anyway with or without epoch. I also would also like to vote for 1.5.2+really1.4.5-1 rather than an epoch. This seems like a temporary transitional problem more suitable for a fancy version rather than an epoch. The current problem will eventually be past us but an epoch is forever. The epoch is really more suitable for when version schemes change significantly such as going to or from dates as versions and that type of thing which have no end and therefore require an epoch to correct. Bob signature.asc Description: Digital signature
Bug#718898: cut no longer works with newline as delimiter
Pádraig Brady wrote: Bob Proulx wrote: Was this change intentional or accidental? Intentional. The change in question, to treat each line independently was: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=51ce0bf8 to address: http://bugs.gnu.org/13498 Thanks for the details. Since this is an intentional change and the problematic usage isn't a normal use for cut I will suggest that the Debian bug be closed and a new one opened for the problematic use in the xen scripts. Thanks! Bob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718898: cut no longer works with newline as delimiter
severity 718898 important
reassign 718898 xen-utils-common
thanks
The behavior of the upstream GNU cut has changed. It is no longer
allows the usage of cutting lines as fields by setting a newline as
the delimiter. This has broken /etc/xen/scripts/vif-bridge which uses
it in this way.
This was originally reported by Volker Klasen against the coreutils
package. However with the information that this is an intentional
behavior change upstream in order to address other problems and with
the use being problematic I am reassigning this to the
xen-utils-common which owns the /etc/xen/scripts/vif-bridge script.
Here is a patch that I believe should fix the problem. I will also
attach it so that there won't be any mailer problems with the
transport of it.
--- vif-bridge.orig 2013-08-07 20:01:57.240366430 -0600
+++ vif-bridge 2013-08-07 20:03:06.664895507 -0600
@@ -37,8 +37,7 @@
if [ -z $bridge ]
then
- bridge=$(brctl show | cut -d
- -f 2 | cut -f 1)
+ bridge=$(brctl show | | awk 'NR==2{print$1}')
if [ -z $bridge ]
then
However although this is an exact replacement for the previous cut
behavior I am worried that the output of 'brctl show' will always
produce only one line of output. If there are multiple bridges this
will behave exactly as before and will only extract the first one.
Thank you for maintaining xen-utils-common!
Bob
--- vif-bridge.orig 2013-08-07 20:01:57.240366430 -0600
+++ vif-bridge 2013-08-07 20:03:06.664895507 -0600
@@ -37,8 +37,7 @@
if [ -z $bridge ]
then
- bridge=$(brctl show | cut -d
- -f 2 | cut -f 1)
+ bridge=$(brctl show | | awk 'NR==2{print$1}')
if [ -z $bridge ]
then
signature.asc
Description: Digital signature
Bug#718898: cut no longer works with newline as delimiter
Volker Klasen opened a bug in the Debian bug tracker concerning a change in behavior in cut. I have CC'd the bug on this message. I have manually set an appropriate Reply-To header. http://bugs.debian.org/718898 There has been a lot of improvements made to cut. But the issue is this one. In the older 8.13 this was the behavior: $ printf one\ntwo\n | cut -d -f2 two In the newer 8.21 this is the new behavior: $ printf one\ntwo\n | cut -d -f2 one two Was this change intentional or accidental? Bob P.S. Of course using cut is a terrible way to select the second line. I would use awk 'NR==2'. But that is a separate issue. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701684: [Pkg-libvirt-maintainers] Bug#701684: virt-viewer no longer contains virt-viewer
reopen 701684 thanks Luca Capello wrote: I just got it by this bug as well and IMHO the current solution (upgrading to the versions in experimental) is not fine: virt-viewer in sid is still broken and, after having visited the bug report, there is no ETA for a fixed version in sid. I am sure the upload to Experimental was just for the testing of a new package. A perfect place for Experimental. All good. In which case the closing of the bug in Sid I am sure was simply accidental dragged along since it doesn't fix the problem in Sid. Therefore I am adjusting the status to match the existing condition. When the package is moved to Sid fixing the problem there then the bug can be closed again. On a side note, the debian/changelog is a bit empty WRT the reasons for new uploads since 0.5.4-1 (and #684725 has not marked as fixed), which means that apt-listchanges for virt-viewer is useless: The changelog is rather sparse of content. :-( Bob signature.asc Description: Digital signature
Bug#695906: ifupdown: removal of /etc/network/interfaces is not preserved
Tollef Fog Heen wrote: rm /etc/network/interfaces apt-get --reinstall install ifupdown observe that /etc/network/interfaces exists. If I remove the file, that change should be preserved on upgrades. But /etc/network/interfaces is not an ifupdown conffile. Bob signature.asc Description: Digital signature
Bug#693211: coreutils: file conflict with realpath
forcemerge 693488 693211 thanks Ralf Treinen wrote: Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/bin/realpath /usr/share/man/man1/realpath.1.gz Thank you for the report. This was already reported in Bug#693488 and therefore I am merging the reports. The coreutils maintainer has already responded there saying that the next upload will address this problem. I am sure the problem will be fixed soon. Thanks, Bob signature.asc Description: Digital signature
Bug#693211: coreutils: file conflict with realpath
Bob Proulx wrote: Ralf Treinen wrote: /usr/bin/realpath /usr/share/man/man1/realpath.1.gz Thank you for the report. This was already reported in Bug#693488 and therefore I am merging the reports. Oops. While crosschecking the reports I reversed them and responded to the opposite one. Obviously my message should have gone to Bug#693337 and not Bug#693211 and I will correct that now but regardless the result is the same. Sorry or the noise. Bob signature.asc Description: Digital signature
Bug#693488: coreutils: fails to upgrade from 'testing' - trying to overwrite /usr/share/man/man1/realpath.1.gz
Andreas Beckmann wrote: dpkg: error processing /var/cache/apt/archives/coreutils_8.20-1_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/realpath.1.gz', which is also in package realpath 1.17 Thank you for the report. This was already reported in Bug#693211 and therefore I am merging the reports. The coreutils maintainer has responded there saying that the next upload will address this problem. I am sure the problem will be fixed soon. Thanks, Bob signature.asc Description: Digital signature
Bug#669651: login: failing to update utmp at console.
forcemerge 659957 669651 thanks Mats Erik Andersson wrote: The recent update of 'login' is no longer able to make an entry in /var/run/utmp for any user logging in via a virtual terminal, i.e., text console, on my linux-i386 system. Downgrading to 1:4.1.4.2+svn3283-3 restores this vital element of system management. Thank you for the report. Since this appears to be the same as Bug#659957 I am merging the reports. Bob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665816: php5-intl: postinst script broken
Beat Bolli wrote: effective solution: remove the two occurrences of the word local in php5-intl.postinst Thank you for your bug report. This problem has already been reported as Bug#664849 and been fixed by the upload of version 5.4.0-3. You may wish to refer to the package tracking system for this package to see when it transitions into Testing. http://packages.qa.debian.org/p/php5.html Bob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572648: unifdef: copyright file is out of date
severity 572648 normal quit Jonathan Nieder wrote: Severity: serious We are not violating any licenses as far as I can tell since the distributed unifdef.1 and /usr/bin/unifdefall reproduce the required notices. So I would prefer to call this minor (a documentation bug), but it is technically serious (I think) because of the policy for debian/copyright. No. This is normal only. Please do not overinflating bug importance. The debian/copyright file is AFAICT incomplete: The recent upstream changes have created some license complexity. I will try to sort them out. This will be addressed in a future upload. In the meantime: The original license was the 4-clause BSD license by the Regents of the University of California. They have authorized the removal of the advertising clause in any of their material bearing their 4-clause license. That allowed all distributors to distribute files with the 3-clause license. This is specifically allowed from the Regents of the University of California and does not cover other licensees distributing with the 4-clause license. Tony Finch has been removing old code and writing new code to replace it and has replaced the entirety of the previous with his own new code. Along with it he has replaced the copyright with his notice. He has chosen a 2-clause license. I released my code with an all permissive license. Tony's test harness has been released into the public domain. The entire project as a blanket has been placed under a 2-clause license. As stated in the project files all contributions are under the 2-clause license found in unifdef.c. Fortunately all of those are compatible free licenses. Bob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551949: phpmyadmin: Denial of Service Attack through setup.php
Michal Čihař wrote: Bob Proulx napsal(a): Package: phpmyadmin Version: 4:2.9.1.1-11 Severity: important Reporting a remote denial of service attack against phpmyadmin's setup.php interface. This is same as bugs #535044, #543460, which are fixed in unstable and if the fix won't cause any troubles we will push it to stable. Very good! And in my original report I forgot to say to the maintainers thank you very much for maintaining this package! Your hard work is much appreciated. Bob signature.asc Description: Digital signature
Bug#528126: coreutils: touch does not update timestamp
severity 528126 normal
tag 528126 + moreinfo unreproducible
thanks
steve downes wrote:
Touch does not update the timestamp in an existing file. This is
particularly relevant to me as it appears to have caused dpkg to fail
not fully update leaving a none updatable system. I tested this both
on the dpkg.log file on another file. I also checked it worked on
other hosts.
This seems very odd that the code would work correctly on everyone's
system except for yours. And even then it seems like it would be a
kernel problem with the utimesat call. Since this doesn't seem to be
widely a problem and because no other information has been provided
after Mike's follow-up I am marking this normal from severe.
Setting up dpkg (1.14.26) ...
touch: setting times of `/var/log/dpkg.log' : no such process
This comes from the dpkg.postinst script:
# Create log file and set default permissions if possible
create_logfile() {
logfile=/var/log/dpkg.log
touch $logfile
chmod 640 $logfile
chown root:adm $logfile 2/dev/null || chown 0:4 $logfile
}
Mike already responded that he was unable to reproduce the problem. I
am unable to reproduce this problem. I am afraid you will need to
debug it or provide more information. In particular what is the
output of the trace command?
strace -v -o touch.strace touch foo
I expect to see something like this:
open(foo, O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
dup2(3, 0) = 0
close(3)= 0
utimensat(0, NULL, NULL, 0) = 0
If the utimes et al system calls are failing then this is a kernel
problem and not an application problem.
Bob
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525048: sort: sefaults
Michael Stone wrote: Otavio Salvador wrote: Michael Stone wrote: you wrote: $: sort -um -o list list work I'll look at the segfault, but I'm not sure that was ever guaranteed to give a useful result (you're overwriting an input file). Yes, it works nicely in stable release (hence the notfound usage) so it qualifies as a regression IMO. I didn't say it didn't work, I said I'm not sure that was ever guaranteed to give a useful result. In this case it is guaranteed to provide a meaning result. Both traditional implementations and POSIX require -o to buffer output so that it can also be an input file. (I think that is virtually the entire reason for the -o instead of simply using output redirection.) http://www.opengroup.org/onlinepubs/009695399/utilities/sort.html -o output Specify the name of an output file to be used instead of the standard output. This file can be the same as one of the input files. In any case it shouldn't segfault. Bob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#462226: coreutils: FTBFS on mips: tests failed: rm/deep-1, rm/dangling-symlink, ...
Julien Cristau wrote: Maybe you could modify the build rules to cat the test logs in case of failure? Turning on debug for everything would create *HUGE* log files. Probably too big for routine use. That is why it is off by default. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380552: coreutils - FTBFS
Michael Stone wrote: Bastian Blank wrote: [...] FAIL: pwd-long Since this is the only failure listed, I'll assume it's the problem. Was there any actual diagnostic message in the part you snipped? Thanks for the report. If you can set the VERBOSE=yes variable and build again and report the detailed debugging output that would allow us to know more information about this problem. In the build directory: env VERBOSE=yes make -C tests/misc TESTS=pwd-long Or whatever you need to do to get VERBOSE=yes set for the pwd-long test. That will produce shell tracing output. Thanks Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374503: dpkg: md5sum doesn't exist upgrading to sid dpkg
Frank Lichtenheld wrote: Reinstalling coreutils (5.94-1) fixes the glitch. Do you know which versions of coreutils and dpkg you had installed before the upgrade? Do you have the full upgrade log available? Hint: /var/backups/dpkg.status.* may contain info on what was previously installed. Just in case memory is not enough. :-) Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.
Pierre Habouzit wrote: what is the point of not supporting tail +n syntax, does it breaks anything ? A conforming POSIX 1003.1-2001 implementation is supposed to treat arguments with a leading + as a file name, not as an option. Some people do actually start file names with a + sign. (Often used in GNU arch projects for one example.) There is no way to make everyone happy. printf one\ntwo\nthree\n ++foo tail ++foo tail: +: invalid suffix character in obsolescent option printf one\ntwo\nthree\n +1 tail +1 ...hang reading stdin instead of file +1... Both of those examples work with POSIX conforming implementations. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.
Zack Weinberg wrote: It has also been reported to be the case for various releases of HP-UX and AIX. On these systems, POSIX-2001 syntax like tail -n 1 simply *does not work*. Just a detail clarification... HP-UX 10.20, arguably the oldest HP-UX version still in active use anywhere, supports the 'tail -n#' syntax. It was released in 1996 and it was officially at end of life in mid 2003[1][2]. Bob [1] http://www.hp.com/softwarereleases/releases-media2/history/slide2.html [2] http://www.hp.com/softwarereleases/releases-media2/discon/0303.htm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.
Zack Weinberg wrote: Bob Proulx wrote: Just a detail clarification... HP-UX 10.20, arguably the oldest HP-UX version still in active use anywhere, supports the 'tail -n#' syntax. Are you absolutely certain that the version of tail in /bin or /usr/bin supports that syntax? Yes. I am absolutely certain. This was my main desktop for years and years and I still have it up and running today. printf one\ntwo\nthree\n | /usr/bin/tail -n2 two three uname -a HP-UX hpbox B.10.20 A 9000/785 2003339568 two-user license model 9000/785/C360 /usr/bin/tail -? Usage: tail [-f] [-b number] [file] tail [-f] [-c number] [file] tail [-f] [-n number] [file] Obsolescent usage: tail [+-[n][l|b|c]] [-f] [file] I have this dim memory that the situation was similar to Solaris - i.e. modern tools in /usr/something/bin, not in /usr/bin, portable scripts are still hosed. On HP-UX 10.01 and later /bin and /usr/bin were combined into /usr/bin and /bin is now a symlink to /usr/bin. Similarly for /lib which is now a symlink to /usr/lib. Theoretically use of /bin is deprecated there but obviously there needs to be /bin/sh or all #!/bin/sh scripts would be broken and so the /bin symlink can never go away. But this means there is only one main bin directory and that is /usr/bin with all programs in it. HP-UX does funny things with tools installed in /opt/package/bin where paths to those tools are listed in /etc/PATH and /etc/profile includes all /etc/PATH paths into your PATH at login time. This means that after installation you must log out and log back in to get your PATH set up correctly. That is an unfortunate design choice akin to some operating systems requiring a reboot after software installation. Note that RH also has a similar design problem with their use of /etc/profile.d/* scripts so this is not solely an HP-UX problem. Additionally there is /usr/ccs/bin which is where the native KR compiler and linker live. On HP-UX /usr/ccs/bin is required to be in PATH in addition to /usr/bin. But that is the old KR compiler and not the modern ANSI compiler. Included in /opt is /opt/ansic/bin which is where the c89 ANSI compiler lives if installed. But again in both cases the paths to them are included in the file /etc/PATH and are placed into the PATH by /etc/profile at login time. I don't prefer the design choice but it *is* functional as installed, just not pretty. Also note that on a minimum system only the old KR compiler is installed in /usr/ccs/bin and the c89 ANSI compiler is an additional optional product in /opt/ansic/bin which may not be installed at all. They certainly did do similar crazy things for the sake of backward compatibility, e.g. requiring you to add a special object to the link if you wanted your binaries to honor SIGXCPU, because SIGXCPU was only in Unix95... Yes. And the 'ps -H' as in 'ps -efH' option to sort by parent-child process relationship is only available if the UNIX95 variable is set. I have an alias ps='UNIX95=1 ps' just for that reason. And there are other things too. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328200: [debian-ntp] Bug#328200: Problems with ntp
Matthew Garrett wrote: Bdale Garbee [EMAIL PROTECTED] wrote: There are several files that are BSD with advertising clause, including libntp/memmove.c, libntp/mktime.c, libntp/random.c, libntp/strerror.c, libntp/strstr.c, ntpd/refclock_jupiter.c, and ntpd/refclock_mx4200.c. These should be referenced in debian/copyright. BSD with advertising isn't GPL compatible. The UCB advertising clause has been rescinded by the copyright owner. See this authorization. ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change The advertising clause is no longer required and is deleted. With all of the usual cautions about IANAL I believe it is enough to delete that clause from the copyright and reference that document. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#287201: [SECURITY] [DSA 631-1] New kdlibs packages fix arbitrary FTP command execution
Package: kdelibs
Debian Bug : 287201
...
For the stable distribution (woody) this problem has been fixed in
version 2.2.2-13.woody.13.
This fails to upgrade for me. It seems I don't have libarts
installed. This package introduces four new files and a change and
increase in dependencies to now include new libraries.
This breaks 'upgrade' semantics. It now requires a 'dist-upgrade'.
This surely was not intentional.
Here is what debdiff says.
debdiff kdelibs3_2.2.2-13.woody.12_i386.deb
kdelibs3_2.2.2-13.woody.13_i386.deb
Files in second .deb but not in first
-
/usr/lib/libgmcop.la
/usr/lib/libgmcop.so
/usr/lib/libgmcop.so.0
/usr/lib/libgmcop.so.0.0.0
The following lines in the control files differ (wdiff output format):
--
Version: [-4:2.2.2-13.woody.12-] {+4:2.2.2-13.woody.13+}
Depends: {+libarts (= 4:2.2.2-1) | libarts-alsa (= 4:2.2.2-1),+}
libbz2-1.0, libc6 (= 2.2.4-4), libfam0, {+libglib2.0-0 (= 2.0.1),+}
libjpeg62, libpcre3, libpng2(=1.0.12), libqt2 (= 3:2.3.1-1),
libstdc++2.10-glibc2.2 (= 1:2.95.4-0.010810), libtiff3g, libxml2 (=
2.4.19-4), libxslt1 (= 1.0.16), xlibs ( 4.1.0), zlib1g (= 1:1.1.4),
kdelibs3-bin | kdelibs-bin, xbase-clients
Installed-Size: [-23972-] {+24032+}
Should a new update with a correction be issued?
Bob
P.S. By the way, note the misspelled kdlibs in the subject.
signature.asc
Description: Digital signature
