[Desktop-packages] [Bug 1996267] Re: [snap] Doesn't store encrypted passwords unless interface is connected
> .. i think the current password manager situation (all connected snaps sharing passwords) is kind of broken. Probably the same kind of broken like on a normal desktop, but snaps are supposed to sandboxed. In theory, sure. That doesn't mean it's defensible to not use it. There is a theory solution here, you can use the XDG Desktop Protal spec https://flatpak.github.io/xdg-desktop-portal/#gdbus- org.freedesktop.portal.Secret which supplies org.freedesktop.portal.Secrets and have containerized secret handling too. However, you'd still have to patch Chrome and it still sends the wrong signal to users that Snap refuses to use the systems keyring by default and so you're all vulnerable until the applications adopts the theoretical best practice available. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1996267 Title: [snap] Doesn't store encrypted passwords unless interface is connected Status in chromium-browser package in Ubuntu: Confirmed Bug description: In the Snap package of Chromium, Chromium is not protecting passwords with gnome-keyring (or KWallet). As a result, copying the Chromium profile directory from the snap directory gives access to all stored passwords. This is a HIGH security risk. Regular users who are used to storing their passwords in browsers are probably unaware of this. Note that Chromium is started with the command line option “--password-store=basic”. This hack should never have been released to the public. The Chromium documentation states: > --password-store=basic (to use the plain text store) https://chromium.googlesource.com/chromium/src/+/master/docs/linux/password_storage.md To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1996267/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1996267] Re: [snap] Doesn't store encrypted passwords unless interface is connected
I don't see how this debate is apropos. Whether or not the passwords are stored in the clear, or obscured with symmetric encryption using hard coded parameters in chrome is irrelevant. Both of these scenarios are entirely unacceptable. That said, the answer here afaik is they're stored with a key generated with pbkdf2 using a password of "peantus" and a salt of "saltysalt" and 1 iteration. I think that because I know 100% this is how the Cookies work having examined the source in OSCrypt which is in os_crypt_linux.cc which I assume handles passwords too. Ubuntu is the most popular Linux desktop. It's use is not unique from either OSX or Windows (which uses DPAPI). Both of which have entirely superior solutions to this problem and do not store passwords in clear text, or with hard-coded symmetric encryption. That's not the default anyway. That all said, I will extend https://github.com/EvanCarroll/xbrowser/ to support decoding passwords soon. So you'll have a tool you can run.. The command will be simple, xbrowser export chrome passwords And you'll be able to dump all the passwords. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1996267 Title: [snap] Doesn't store encrypted passwords unless interface is connected Status in chromium-browser package in Ubuntu: Confirmed Bug description: In the Snap package of Chromium, Chromium is not protecting passwords with gnome-keyring (or KWallet). As a result, copying the Chromium profile directory from the snap directory gives access to all stored passwords. This is a HIGH security risk. Regular users who are used to storing their passwords in browsers are probably unaware of this. Note that Chromium is started with the command line option “--password-store=basic”. This hack should never have been released to the public. The Chromium documentation states: > --password-store=basic (to use the plain text store) https://chromium.googlesource.com/chromium/src/+/master/docs/linux/password_storage.md To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1996267/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2038875] Re: Snap uses hardcoded key and salt for password and cookie encryption
*** This bug is a duplicate of bug 1996267 *** https://bugs.launchpad.net/bugs/1996267 I don't think this is an exact dupe but it's pretty damn close. That issue is about passwords; this one cookies. That issue is being mega distracted by whether or not passwords are stored clear, or through symmetric encryption. This one acknowledges that it's stored with symmetric encryption. I'll follow up with that one though, after I extend xbrowser to demonstrate the exploitation of the password side. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/2038875 Title: Snap uses hardcoded key and salt for password and cookie encryption Status in chromium-browser package in Ubuntu: Won't Fix Bug description: A working Ubuntu install includes Gnome which includes the gnome- keyring. The snap version of Ubuntu does not make use of it. On an install of Debian with Gnome, the key ring is used. However, with Ubuntu everything is encrypted with the static key of peanuts and the salt of saltysalt, and openly accessible as sqlite databases in ~/snap/chromium/common/chromium, including passwords from the browser and the cookies. This should probably be fixed. If a laptop is physically compromised it's trivial to decrypt this with a tool like xbrowser. You can verify that gnome-libcrypt isn't chosen by default with --enable-logging=stderr --v=1 redirect stderr to a log and look for Crypt. You can see /why/ gnome-libcrypt isn't chosen with chromium --password-store=gnome-libcrypt --enable-logging=stderr --v=1 and again looking for messages with Crypt. I don't think this is a vulnerability per se, Chrome ships in Debian with the ability to use a basic store too. But it's an undesirable configuration and a regression from Debian when it's run on a platform with gnome and libsecret, and only doesn't work because of snap. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2038875/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2038875] Re: Snap uses hardcoded key and salt for password and cookie encryption
That's a truly bizarre argument, but I've responded to it there. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/2038875 Title: Snap uses hardcoded key and salt for password and cookie encryption Status in chromium-browser package in Ubuntu: Won't Fix Bug description: A working Ubuntu install includes Gnome which includes the gnome- keyring. The snap version of Ubuntu does not make use of it. On an install of Debian with Gnome, the key ring is used. However, with Ubuntu everything is encrypted with the static key of peanuts and the salt of saltysalt, and openly accessible as sqlite databases in ~/snap/chromium/common/chromium, including passwords from the browser and the cookies. This should probably be fixed. If a laptop is physically compromised it's trivial to decrypt this with a tool like xbrowser. You can verify that gnome-libcrypt isn't chosen by default with --enable-logging=stderr --v=1 redirect stderr to a log and look for Crypt. You can see /why/ gnome-libcrypt isn't chosen with chromium --password-store=gnome-libcrypt --enable-logging=stderr --v=1 and again looking for messages with Crypt. I don't think this is a vulnerability per se, Chrome ships in Debian with the ability to use a basic store too. But it's an undesirable configuration and a regression from Debian when it's run on a platform with gnome and libsecret, and only doesn't work because of snap. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2038875/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2038875] Re: Snap uses hardcoded key and salt for password and cookie encryption
*** This bug is a duplicate of bug 1836616 *** https://bugs.launchpad.net/bugs/1836616 @Nathan That's not the same bug from my reading. That's about an upgrade. I'm saying on a totally fresh install the default behavior is not to use the OS keyring, despite it being available. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/2038875 Title: Snap uses hardcoded key and salt for password and cookie encryption Status in chromium-browser package in Ubuntu: New Bug description: A working Ubuntu install includes Gnome which includes the gnome- keyring. The snap version of Ubuntu does not make use of it. On an install of Debian with Gnome, the key ring is used. However, with Ubuntu everything is encrypted with the static key of peanuts and the salt of saltysalt, and openly accessible as sqlite databases in ~/snap/chromium/common/chromium, including passwords from the browser and the cookies. This should probably be fixed. If a laptop is physically compromised it's trivial to decrypt this with a tool like xbrowser. You can verify that gnome-libcrypt isn't chosen by default with --enable-logging=stderr --v=1 redirect stderr to a log and look for Crypt. You can see /why/ gnome-libcrypt isn't chosen with chromium --password-store=gnome-libcrypt --enable-logging=stderr --v=1 and again looking for messages with Crypt. I don't think this is a vulnerability per se, Chrome ships in Debian with the ability to use a basic store too. But it's an undesirable configuration and a regression from Debian when it's run on a platform with gnome and libsecret, and only doesn't work because of snap. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2038875/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2038875] Re: Snap uses hardcoded key and salt for password and cookie encryption
I'm pointing that when I add chromium on a fresh Ubuntu install it does not do configure itself to use the libsecret keyring. When I add chromium on a fresh Debian/Gnome Desktop install it does. This difference is in packaging, and presumably came when chromium was migrated to use snap. But I would think what should happen is the prior behavior, if you're on a gnome with libsecret, it by default should use the OS key ring. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/2038875 Title: Snap uses hardcoded key and salt for password and cookie encryption Status in chromium-browser package in Ubuntu: New Bug description: A working Ubuntu install includes Gnome which includes the gnome- keyring. The snap version of Ubuntu does not make use of it. On an install of Debian with Gnome, the key ring is used. However, with Ubuntu everything is encrypted with the static key of peanuts and the salt of saltysalt, and openly accessible as sqlite databases in ~/snap/chromium/common/chromium, including passwords from the browser and the cookies. This should probably be fixed. If a laptop is physically compromised it's trivial to decrypt this with a tool like xbrowser. You can verify that gnome-libcrypt isn't chosen by default with --enable-logging=stderr --v=1 redirect stderr to a log and look for Crypt. You can see /why/ gnome-libcrypt isn't chosen with chromium --password-store=gnome-libcrypt --enable-logging=stderr --v=1 and again looking for messages with Crypt. I don't think this is a vulnerability per se, Chrome ships in Debian with the ability to use a basic store too. But it's an undesirable configuration and a regression from Debian when it's run on a platform with gnome and libsecret, and only doesn't work because of snap. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2038875/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2038875] Re: Snap uses hardcoded key and salt for password and cookie encryption
The Chrome password manager does not mean it uses the Operating System's key ring. If the key ring is not available or the configuration doesn't detect it (as in the case of the snap) it will use key "peanuts" with salt "saltysalt". -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/2038875 Title: Snap uses hardcoded key and salt for password and cookie encryption Status in chromium-browser package in Ubuntu: New Bug description: A working Ubuntu install includes Gnome which includes the gnome- keyring. The snap version of Ubuntu does not make use of it. On an install of Debian with Gnome, the key ring is used. However, with Ubuntu everything is encrypted with the static key of peanuts and the salt of saltysalt, and openly accessible as sqlite databases in ~/snap/chromium/common/chromium, including passwords from the browser and the cookies. This should probably be fixed. If a laptop is physically compromised it's trivial to decrypt this with a tool like xbrowser. You can verify that gnome-libcrypt isn't chosen by default with --enable-logging=stderr --v=1 redirect stderr to a log and look for Crypt. You can see /why/ gnome-libcrypt isn't chosen with chromium --password-store=gnome-libcrypt --enable-logging=stderr --v=1 and again looking for messages with Crypt. I don't think this is a vulnerability per se, Chrome ships in Debian with the ability to use a basic store too. But it's an undesirable configuration and a regression from Debian when it's run on a platform with gnome and libsecret, and only doesn't work because of snap. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2038875/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2038875] Re: Snap uses hardcoded key and salt for password and cookie encryption
You know if you're using the insecure v10 cookies by looking at the first three bytes of encrypted data in the sqlite database. If it reads \x76\x31\x30 you've got v10.. literally. if the third byte is \x31 you've got v11 the desirable variant. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/2038875 Title: Snap uses hardcoded key and salt for password and cookie encryption Status in chromium-browser package in Ubuntu: New Bug description: A working Ubuntu install includes Gnome which includes the gnome- keyring. The snap version of Ubuntu does not make use of it. On an install of Debian with Gnome, the key ring is used. However, with Ubuntu everything is encrypted with the static key of peanuts and the salt of saltysalt, and openly accessible as sqlite databases in ~/snap/chromium/common/chromium, including passwords from the browser and the cookies. This should probably be fixed. If a laptop is physically compromised it's trivial to decrypt this with a tool like xbrowser. You can verify that gnome-libcrypt isn't chosen by default with --enable-logging=stderr --v=1 redirect stderr to a log and look for Crypt. You can see /why/ gnome-libcrypt isn't chosen with chromium --password-store=gnome-libcrypt --enable-logging=stderr --v=1 and again looking for messages with Crypt. I don't think this is a vulnerability per se, Chrome ships in Debian with the ability to use a basic store too. But it's an undesirable configuration and a regression from Debian when it's run on a platform with gnome and libsecret, and only doesn't work because of snap. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2038875/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2038875] [NEW] Snap uses hardcoded key and salt for password and cookie encryption
Public bug reported: A working Ubuntu install includes Gnome which includes the gnome- keyring. The snap version of Ubuntu does not make use of it. On an install of Debian with Gnome, the key ring is used. However, with Ubuntu everything is encrypted with the static key of peanuts and the salt of saltysalt, and openly accessible as sqlite databases in ~/snap/chromium/common/chromium, including passwords from the browser and the cookies. This should probably be fixed. If a laptop is physically compromised it's trivial to decrypt this with a tool like xbrowser. You can verify that gnome-libcrypt isn't chosen by default with --enable-logging=stderr --v=1 redirect stderr to a log and look for Crypt. You can see /why/ gnome-libcrypt isn't chosen with chromium --password- store=gnome-libcrypt --enable-logging=stderr --v=1 and again looking for messages with Crypt. I don't think this is a vulnerability per se, Chrome ships in Debian with the ability to use a basic store too. But it's an undesirable configuration and a regression from Debian when it's run on a platform with gnome and libsecret, and only doesn't work because of snap. ** Affects: chromium-browser (Ubuntu) Importance: Undecided Status: New ** Summary changed: - Snap does not use v11 encryption for cookie store + Snap uses hardcoded key and salt for password and cookie encryption -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/2038875 Title: Snap uses hardcoded key and salt for password and cookie encryption Status in chromium-browser package in Ubuntu: New Bug description: A working Ubuntu install includes Gnome which includes the gnome- keyring. The snap version of Ubuntu does not make use of it. On an install of Debian with Gnome, the key ring is used. However, with Ubuntu everything is encrypted with the static key of peanuts and the salt of saltysalt, and openly accessible as sqlite databases in ~/snap/chromium/common/chromium, including passwords from the browser and the cookies. This should probably be fixed. If a laptop is physically compromised it's trivial to decrypt this with a tool like xbrowser. You can verify that gnome-libcrypt isn't chosen by default with --enable-logging=stderr --v=1 redirect stderr to a log and look for Crypt. You can see /why/ gnome-libcrypt isn't chosen with chromium --password-store=gnome-libcrypt --enable-logging=stderr --v=1 and again looking for messages with Crypt. I don't think this is a vulnerability per se, Chrome ships in Debian with the ability to use a basic store too. But it's an undesirable configuration and a regression from Debian when it's run on a platform with gnome and libsecret, and only doesn't work because of snap. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2038875/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1600622] Re: Screen doesn't lock or go to sleep when certain Chrome tabs are open
Just found this, still having this bug -- with Reuters.
https://unix.stackexchange.com/q/451413/3285
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-session in Ubuntu.
https://bugs.launchpad.net/bugs/1600622
Title:
Screen doesn't lock or go to sleep when certain Chrome tabs are open
Status in gnome-session package in Ubuntu:
Confirmed
Bug description:
$ lsb_release -rd
Description: Ubuntu 16.04 LTS
Release: 16.04
$ apt-cache policy gnome-session-bin
gnome-session-bin:
Installed: 3.18.1.2-1ubuntu1.16.04.1
Candidate: 3.18.1.2-1ubuntu1.16.04.1
Version table:
*** 3.18.1.2-1ubuntu1.16.04.1 500
500 http://es.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
100 /var/lib/dpkg/status
3.18.1.2-1ubuntu1 500
500 http://es.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
I'm using gnome-session-flashback
What happens:
The screen doesn't lock when having certain pages in Chrome tabs
Expected:
The screen should lock after the configured timeout in settings.
I've been having this issue sice before 14.04, which I recently
upgraded (fresh install) to 16.04.
After fresh install, the screen would turn down and lock the computer
after 10 minutes (or whatever time I setup). At one point it stopped
working. The screen never shuts down unless I manually lock the
session with CTRL-ALT-L.
I've followed the steps in
https://wiki.ubuntu.com/DebuggingScreenLocking#Debugging_procedure
The culprit seems to be that Chrome issues some suspend inhibitions
through dbus when doing certain operations. Many people find this
problem when using Yahoo Mail. I can reproduce it with Odoo. I'm
pretty sure that Chrome is doing something else of what i've found
out.
1) Gnome screen saver works correctly. I can trigger it manually with:
$ gnome-screensaver-command -a
2) Gnome screen saver never receives the "session idle" status
callback.
3) When Chrome is not running, I can manually inhibit the idle status:
$ gnome-session-inhibit --app-id test --reason "manual idle inhibit"
--inhibit-only --inhibit idle:suspend
Inhibiting until Ctrl+C is pressed...
4) I can query the inhibitors:
$ dbus-send --print-reply --dest=org.gnome.SessionManager
/org/gnome/SessionManager org.gnome.SessionManager.GetInhibitorsmethod return
time=1468170482.066533 sender=:1.19 -> destination=:1.1315311 serial=1329103
reply_serial=2
array [
object path "/org/gnome/SessionManager/Inhibitor1686"
]
$ gdbus call --session --dest org.gnome.SessionManager --object-path
/org/gnome/SessionManager/Inhibitor1686 --method
org.gnome.SessionManager.Inhibitor.GetAppId
('test',)
$ gdbus call --session --dest org.gnome.SessionManager --object-path
/org/gnome/SessionManager/Inhibitor1686 --method
org.gnome.SessionManager.Inhibitor.GetReason
('manual idle inhibit',)
$ gdbus call --session --dest org.gnome.SessionManager --object-path
/org/gnome/SessionManager/Inhibitor1686 --method
org.gnome.SessionManager.Inhibitor.GetFlags
(uint32 12,)
12=4(suspend) + 8(idle)
5) When testing, I can inhibit for 70 seconds, idle timeout being 60
(1 minute). After these 70 seconds pass, the screen locks.
6) Regarding Chrome, this is the information I get when querying the
inhibitor:
GetAppId: ('/usr/bin/google-chrome-stable',)
GetReason: ('Uploading data to 10.200.0.163',)
GetFlags: (uint32 4,)
The flags just inhibits suspend, not locking or entering powersaving
mode.
This inhibitor seems to stay for 10-15 seconds, then goes away for
another 30-60 seconds. The screen NEVER locks when this tab is open.
No matter the inhibitor is present or not.
I'm not sure where to go on. If it's a Chrome bug it must be using
other mechanisms to prevent the idle timeout. Any ideas on what to
look for?
Julian.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1600622/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1532944] Re: flashplugin-installer shows a warning after downloading the file with apt 1.1.x
How is this not an error? Getting this in 16.10. If we can't write to the directory, why is that? We didn't do anything? Who set the perms wrong. And, if they are wrong why does the package proceed to tell us it worked... "Installing from local file" (when there file isn't there) and then "Flash Plugin installed." There is nothing in that directory. Nothing was installed. It didn't work. Status messages are not status messages when they assume success. Please reopen. This is a overzealous closing. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to flashplugin-nonfree in Ubuntu. https://bugs.launchpad.net/bugs/1532944 Title: flashplugin-installer shows a warning after downloading the file with apt 1.1.x Status in apt package in Ubuntu: Invalid Status in flashplugin-nonfree package in Ubuntu: Confirmed Bug description: I'm using Ubuntu 16.04 dev with apt 1.1.10 and on trying to install flashplugin-installer I'm always getting an error message after the file got downloaded. Here is an example output: root@ubuntu:~# apt-get install flashplugin-installer --reinstall Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: libapt-inst1.7 libapt-pkg4.16 Use 'apt autoremove' to remove them. 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 0 B/6838 B of archives. After this operation, 0 B of additional disk space will be used. debconf: delaying package configuration, since apt-utils is not installed (Reading database ... 99770 files and directories currently installed.) Preparing to unpack .../flashplugin-installer_11.2.202.559ubuntu1_amd64.deb ... Unpacking flashplugin-installer (11.2.202.559ubuntu1) over (11.2.202.559ubuntu1) ... Processing triggers for update-notifier-common (3.164) ... flashplugin-installer: downloading http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20151228.1.orig.tar.gz Get:1 http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20151228.1.orig.tar.gz [26.8 MB] Fetched 26.8 MB in 3min 8s (143 kB/s) W: Can't drop privileges for downloading as file '/var/lib/update-notifier/package-data-downloads/partial/adobe-flashplugin_20151228.1.orig.tar.gz' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) Installing from local file /var/lib/update-notifier/package-data-downloads/partial/adobe-flashplugin_20151228.1.orig.tar.gz Flash Plugin installed. Setting up flashplugin-installer (11.2.202.559ubuntu1) ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1532944/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1621753] Re: Google Cast no longer finds Chromecast device
Workaround for the problem found here http://askubuntu.com/a/825904/29097 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1621753 Title: Google Cast no longer finds Chromecast device Status in chromium-browser package in Ubuntu: Confirmed Bug description: After upgrading to latest chromium-browser version (52.0.2743.116-0ubuntu0.16.04.1.1250), the Google Cast extension no longer finds the Chromecast (v2) device. This used to work with the previous chromium version. Also, google-chrome-stable 53.0.2785.101-1 works fine on the same box, so the issue is with the chromium update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1621753/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1294899] Re: Import saved VPN connection has been Recently Broken
I assume I could follow the steps here: https://www.expressvpn.com/tutorials/expressvpn_linux and break apart the ovpn file to the separate cert/keys, but this importer should really do this. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager-applet in Ubuntu. https://bugs.launchpad.net/bugs/1294899 Title: Import saved VPN connection has been Recently Broken Status in The OpenVPN Virtual Private Network: Invalid Status in network-manager-applet package in Ubuntu: Fix Released Status in network-manager-openvpn package in Ubuntu: Invalid Status in network-manager-applet source package in Trusty: Fix Released Status in network-manager-openvpn source package in Trusty: Invalid Status in network-manager-applet source package in Utopic: Fix Released Status in network-manager-openvpn source package in Utopic: Invalid Status in network-manager-openvpn package in Debian: New Bug description: SRU Request: [Impact] Attempting to import a saved VPN connection file results in a segault. This is regression in Ubuntu 14.04 that worked correctly in previous versions. [Test Case] 1- install network-manager-openvpn and network-manager-openvpn-gnome 2- from the network-manager indicator, click on Edit Connections 3- Click on Add 4- Select Import a saved VPN configuration, and open the file in comment #28 Expected results: a window should appear with the imported information Current results: network-manager's connection editor segfaults [Regression potential] This SRU simply adds a couple of missing sections to the 11-user-connections.patch patch that went missing. If the fix is broken, either the vpn files won't import, or creating a new vpn connection could break completely. Original description: I believe recent changes have broken network-manager-openvpn feature that allows you to Import saved VPN connection. I've tested this feature with bundles that I've definitely imported successfully in the past. Now, not only does it not import, but it gives absolutely no feedback at all; the window just disappears as though I didn't just ask it to import a VPN.conf file. The folder (I'm importing the .conf file from) includes all the necessary supporting files. I'm very sure this is not a user error on my part. I've done this several times in the past and I'm certain that the files (that are currently being ignored without dialog feedback) are exactly the same as they were when I was able to import successfully a few weeks ago. I've tested this on multiple machines that have Ubuntu 14.04 installed and fully updated. And, even if the files were indeed corrupted (which I'm certain they are not), the fact that the UI just disappears, instead of showing an error, is a bug within itself. Also, I'd like to point out, that I was able to set up this VPN bundle manually. The point of this bug is to report that the ability to import via .conf files (so that you don't have to set things manually) has recently became nonfunctional. To manage notifications about this bug go to: https://bugs.launchpad.net/openvpn/+bug/1294899/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1294899] Re: Import saved VPN connection has been Recently Broken
This is still not working for me and others. When I try to import, all of the certs are empty and the option to Save is grayed out. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager-applet in Ubuntu. https://bugs.launchpad.net/bugs/1294899 Title: Import saved VPN connection has been Recently Broken Status in The OpenVPN Virtual Private Network: Invalid Status in network-manager-applet package in Ubuntu: Fix Released Status in network-manager-openvpn package in Ubuntu: Invalid Status in network-manager-applet source package in Trusty: Fix Released Status in network-manager-openvpn source package in Trusty: Invalid Status in network-manager-applet source package in Utopic: Fix Released Status in network-manager-openvpn source package in Utopic: Invalid Status in network-manager-openvpn package in Debian: New Bug description: SRU Request: [Impact] Attempting to import a saved VPN connection file results in a segault. This is regression in Ubuntu 14.04 that worked correctly in previous versions. [Test Case] 1- install network-manager-openvpn and network-manager-openvpn-gnome 2- from the network-manager indicator, click on Edit Connections 3- Click on Add 4- Select Import a saved VPN configuration, and open the file in comment #28 Expected results: a window should appear with the imported information Current results: network-manager's connection editor segfaults [Regression potential] This SRU simply adds a couple of missing sections to the 11-user-connections.patch patch that went missing. If the fix is broken, either the vpn files won't import, or creating a new vpn connection could break completely. Original description: I believe recent changes have broken network-manager-openvpn feature that allows you to Import saved VPN connection. I've tested this feature with bundles that I've definitely imported successfully in the past. Now, not only does it not import, but it gives absolutely no feedback at all; the window just disappears as though I didn't just ask it to import a VPN.conf file. The folder (I'm importing the .conf file from) includes all the necessary supporting files. I'm very sure this is not a user error on my part. I've done this several times in the past and I'm certain that the files (that are currently being ignored without dialog feedback) are exactly the same as they were when I was able to import successfully a few weeks ago. I've tested this on multiple machines that have Ubuntu 14.04 installed and fully updated. And, even if the files were indeed corrupted (which I'm certain they are not), the fact that the UI just disappears, instead of showing an error, is a bug within itself. Also, I'd like to point out, that I was able to set up this VPN bundle manually. The point of this bug is to report that the ability to import via .conf files (so that you don't have to set things manually) has recently became nonfunctional. To manage notifications about this bug go to: https://bugs.launchpad.net/openvpn/+bug/1294899/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1378438] Re: Printer dialog stuck on Getting printer information...
Did you kill the process after you `chmod -r`'d it? Or, did you restart? Don't forget to `killall scp-dbus-service.py` -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1378438 Title: Printer dialog stuck on Getting printer information... Status in “cups” package in Ubuntu: Confirmed Bug description: In GTK+3/gnome-3 apps (eg evince), when I select my network-discovered printer, the Status field changes to Getting printer information... and the mouse cursor goes into spinning icon, and the Print button stays disabled, so I cannot print. In Firefox, the status tells me the printer is low on toner, but allows me to print. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: cups 1.7.5-3ubuntu1 ProcVersionSignature: Ubuntu 3.16.0-18.25-generic 3.16.3 Uname: Linux 3.16.0-18-generic x86_64 NonfreeKernelModules: nvidia wl ApportVersion: 2.14.7-0ubuntu2 Architecture: amd64 CupsErrorLog: E [01/Oct/2014:13:52:31 -0700] systemd_checkin: Unable to get local address - Permission denied E [02/Oct/2014:08:11:27 -0700] systemd_checkin: Unable to get local address - Permission denied E [03/Oct/2014:08:02:08 -0700] systemd_checkin: Unable to get local address - Permission denied E [03/Oct/2014:08:11:49 -0700] systemd_checkin: Unable to get local address - Permission denied E [03/Oct/2014:08:22:30 -0700] systemd_checkin: Unable to get local address - Permission denied CurrentDesktop: GNOME Date: Tue Oct 7 09:29:43 2014 InstallationDate: Installed on 2014-02-24 (224 days ago) InstallationMedia: Ubuntu-GNOME 14.04 Trusty Tahr - Alpha amd64 (20140218) Lpstat: Error: command ['lpstat', '-v'] failed with exit code 1: lpstat: No destinations added. MachineType: Apple Inc. MacBookPro11,3 Papersize: letter ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-18-generic.efi.signed root=UUID=135fd833-3282-4f3b-8802-0a27ec2765b9 ro quiet splash init=/lib/systemd/systemd vt.handoff=7 SourcePackage: cups UpgradeStatus: Upgraded to utopic on 2014-08-17 (50 days ago) dmi.bios.date: 10/18/2013 dmi.bios.vendor: Apple Inc. dmi.bios.version: MBP112.88Z.0138.B02.1310181745 dmi.board.asset.tag: Base Board Asset Tag# dmi.board.name: Mac-2BD1B31983FE1663 dmi.board.vendor: Apple Inc. dmi.board.version: MacBookPro11,3 dmi.chassis.type: 10 dmi.chassis.vendor: Apple Inc. dmi.chassis.version: Mac-2BD1B31983FE1663 dmi.modalias: dmi:bvnAppleInc.:bvrMBP112.88Z.0138.B02.1310181745:bd10/18/2013:svnAppleInc.:pnMacBookPro11,3:pvr1.0:rvnAppleInc.:rnMac-2BD1B31983FE1663:rvrMacBookPro11,3:cvnAppleInc.:ct10:cvrMac-2BD1B31983FE1663: dmi.product.name: MacBookPro11,3 dmi.product.version: 1.0 dmi.sys.vendor: Apple Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1378438/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1378438] Re: Printer dialog stuck on Getting printer information...
I think these are two separate bugs then. I think Joe is experiencing something totally different. Joe does your tmp directory grow after you do this? Do you see a bunch of symlinks in it? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1378438 Title: Printer dialog stuck on Getting printer information... Status in “cups” package in Ubuntu: Confirmed Bug description: In GTK+3/gnome-3 apps (eg evince), when I select my network-discovered printer, the Status field changes to Getting printer information... and the mouse cursor goes into spinning icon, and the Print button stays disabled, so I cannot print. In Firefox, the status tells me the printer is low on toner, but allows me to print. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: cups 1.7.5-3ubuntu1 ProcVersionSignature: Ubuntu 3.16.0-18.25-generic 3.16.3 Uname: Linux 3.16.0-18-generic x86_64 NonfreeKernelModules: nvidia wl ApportVersion: 2.14.7-0ubuntu2 Architecture: amd64 CupsErrorLog: E [01/Oct/2014:13:52:31 -0700] systemd_checkin: Unable to get local address - Permission denied E [02/Oct/2014:08:11:27 -0700] systemd_checkin: Unable to get local address - Permission denied E [03/Oct/2014:08:02:08 -0700] systemd_checkin: Unable to get local address - Permission denied E [03/Oct/2014:08:11:49 -0700] systemd_checkin: Unable to get local address - Permission denied E [03/Oct/2014:08:22:30 -0700] systemd_checkin: Unable to get local address - Permission denied CurrentDesktop: GNOME Date: Tue Oct 7 09:29:43 2014 InstallationDate: Installed on 2014-02-24 (224 days ago) InstallationMedia: Ubuntu-GNOME 14.04 Trusty Tahr - Alpha amd64 (20140218) Lpstat: Error: command ['lpstat', '-v'] failed with exit code 1: lpstat: No destinations added. MachineType: Apple Inc. MacBookPro11,3 Papersize: letter ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-18-generic.efi.signed root=UUID=135fd833-3282-4f3b-8802-0a27ec2765b9 ro quiet splash init=/lib/systemd/systemd vt.handoff=7 SourcePackage: cups UpgradeStatus: Upgraded to utopic on 2014-08-17 (50 days ago) dmi.bios.date: 10/18/2013 dmi.bios.vendor: Apple Inc. dmi.bios.version: MBP112.88Z.0138.B02.1310181745 dmi.board.asset.tag: Base Board Asset Tag# dmi.board.name: Mac-2BD1B31983FE1663 dmi.board.vendor: Apple Inc. dmi.board.version: MacBookPro11,3 dmi.chassis.type: 10 dmi.chassis.vendor: Apple Inc. dmi.chassis.version: Mac-2BD1B31983FE1663 dmi.modalias: dmi:bvnAppleInc.:bvrMBP112.88Z.0138.B02.1310181745:bd10/18/2013:svnAppleInc.:pnMacBookPro11,3:pvr1.0:rvnAppleInc.:rnMac-2BD1B31983FE1663:rvrMacBookPro11,3:cvnAppleInc.:ct10:cvrMac-2BD1B31983FE1663: dmi.product.name: MacBookPro11,3 dmi.product.version: 1.0 dmi.sys.vendor: Apple Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1378438/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 164120] Re: file manager hangs when mounted nfs drive is no longer accessible
I don't think this bug has *anything* to do with nautilus. The after pulling the plug on the NFS drive anything that tries to access it crashes, here is the ltrace, bindtextdomain(util-linux, /usr/share/locale) = /usr/share/locale textdomain(util-linux) = util-linux strrchr(umount, '/') = nil umask(022) = 022 getopt_long(3, 0x7fff4f92f708, adfhlnrit:O:vV, 0x610460, nil) = 102 getopt_long(3, 0x7fff4f92f708, adfhlnrit:O:vV, 0x610460, nil) = -1 getuid() = 0 geteuid() = 0 __cxa_atexit(0x4057b0, 0, 0, -1) = 0 mnt_init_debug(0, 0x7f71b88abeb0, 2, 1) = 2 readlink(0x7fff4f92e4c0, 0x7fff4f92d4b0, 4096, 2310) = -1 __errno_location() = 0x7f71b8ef97e0 readlink(0x7fff4f92e4c0, 0x7fff4f92d4b0, 4096, -160 Seems as if it makes a call to readlink() which returns -1 indicating an error (3rd line to last), then it realizes that it has an error. And, does a readlink in the same fashion setting buffsize to -160, presumably in whatever handles the error.. I'm confused. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/164120 Title: file manager hangs when mounted nfs drive is no longer accessible Status in File Manager for KDE: Incomplete Status in Thunar file manager: Unknown Status in Thunar Virtual File System: Confirmed Status in “nautilus” package in Ubuntu: Confirmed Status in “nfs-utils” package in Ubuntu: Invalid Bug description: Binary package hint: nautilus I am using ubuntu 7.10, Gutsy 386 version. I am using a laptop which I use to in home and office. At home I am having network drive which mounted through nfs in home. I normally put my laptop to suspend and then bring over the same to work. When I access nautilus in this case, it just simply hangs it does not open any folder neither from Places or directly typing command nautilus. This is very annoying as I have to reboot the computer just for nautilus hanging. To manage notifications about this bug go to: https://bugs.launchpad.net/dolphin/+bug/164120/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 164120] Re: file manager hangs when mounted nfs drive is no longer accessible
Here is the strace, we can see the two calls to readlink which has the actual
path.. A simple `ls` in the directory fails /mnt hangs without even running
umount. This is what I assume is the core of the nautilus symptom people are
ranting about. I think this is also why nfs drives can't umount when
disconnected. I don't know why umount has to ls the parent directory to umount
the location. I can understand it doing so, but I'd expect it the -f option to
just purge the kernel's knowledge of the mount point and move on with life.
That `umount -f` issues an readlink() in cwd, and that an ls with failed mount
hangs is what I assume is the problem here.
,
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f2630b74000
read(3, nodev\tsysfs\nnodev\trootfs\nnodev\tr..., 1024) = 365
read(3, , 1024) = 0
close(3)= 0
munmap(0x7f2630b74000, 4096)= 0
open(/usr/lib/locale/locale-archive, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2919792, ...}) = 0
mmap(NULL, 2919792, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f262f61
close(3)= 0
umask(022) = 022
getuid()= 0
geteuid() = 0
readlink(/mnt, 0x7fff2a645120, 4096) = -1 EINVAL (Invalid argument)
readlink(/mnt/nfs,
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/164120
Title:
file manager hangs when mounted nfs drive is no longer accessible
Status in File Manager for KDE:
Incomplete
Status in Thunar file manager:
Unknown
Status in Thunar Virtual File System:
Confirmed
Status in “nautilus” package in Ubuntu:
Confirmed
Status in “nfs-utils” package in Ubuntu:
Invalid
Bug description:
Binary package hint: nautilus
I am using ubuntu 7.10, Gutsy 386 version.
I am using a laptop which I use to in home and office. At home I am
having network drive which mounted through nfs in home.
I normally put my laptop to suspend and then bring over the same to
work. When I access nautilus in this case, it just simply hangs it
does not open any folder neither from Places or directly typing
command nautilus.
This is very annoying as I have to reboot the computer just for
nautilus hanging.
To manage notifications about this bug go to:
https://bugs.launchpad.net/dolphin/+bug/164120/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1247621] Re: Search field doesn't works in ubuntu 13.10
I have this problem too. If I search in a multipage document for a term and I hit next it jumps in the view between the occurances on a single page, and in the pane on the left where it shows all occurrences in the documents it continues through the list. PG 1 a1 Foo a1 Bar a2 Foo PG 2 b1 Foo b1 Bar b2 Foo If I search for Foo the left pane will show a1 Foo a2 Foo b1 Foo b2 Foo If I hit enter the `a1 Foo` will be highlighted, if I hit enter again `a2 Foo` will be higlighted. If I hit enter a third time, `a1 Foo` will be highlighted but the left bar will highlight `b1 Foo`. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1247621 Title: Search field doesn't works in ubuntu 13.10 Status in “evince” package in Ubuntu: Incomplete Bug description: Since I've upgraded to ubuntu 13.10, and evince 3.10.0, the search field doesn't works. I can't type any text on it. ~~~ Ubuntu version: *** 3.10.0-0ubuntu2 0 500 http://fr.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages Evince version: *** 3.10.0-0ubuntu2 0 500 http://fr.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages ~~~ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1247621/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1198529] Re: Chromium PPA should be revoked.
Yea, definitely not trying to detour good people from doing good work, but the current state is confusing to users and is likely to cause needless grief. Just remove the old packages from it and put a note in the repo that it is reserved for forward-compat. Even that is a *huge* step in the right direction. ** Description changed: There is an official-sounding PPA called chromium-daily, * https://launchpad.net/~chromium-daily/+archive/ppa However it only has version 18 released. This is ultimately confusing to end users. Suffice it to adduce two facts, Ubuntu 13.04 ships with - version 25 and the timestamp of last maintence is 14 months old at the + version 25 (7 versions ahead of the chromium-daily ppa) and the + timestamp of last maintenance in chromium-daily is 14 months old at the time of this bug report. The inactive PPA should be shut down or maintained. It causes substantially more confusion than good. If no one wants to maintain it, shut it down pendining someone else picking up the job. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1198529 Title: Chromium PPA should be revoked. Status in “chromium-browser” package in Ubuntu: New Bug description: There is an official-sounding PPA called chromium-daily, * https://launchpad.net/~chromium-daily/+archive/ppa However it only has version 18 released. This is ultimately confusing to end users. Suffice it to adduce two facts, Ubuntu 13.04 ships with version 25 (7 versions ahead of the chromium-daily ppa) and the timestamp of last maintenance in chromium-daily is 14 months old at the time of this bug report. The inactive PPA should be shut down or maintained. It causes substantially more confusion than good. If no one wants to maintain it, shut it down pendining someone else picking up the job. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1198529/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1198529] [NEW] Chromium PPA should be revoked.
Public bug reported: There is an official-sounding PPA called chromium-daily, * https://launchpad.net/~chromium-daily/+archive/ppa However it only has version 18 released. This is ultimately confusing to end users. Suffice it to adduce two facts, Ubuntu 13.04 ships with version 25 and the timestamp of last maintence is 14 months old at the time of this bug report. The inactive PPA should be shut down or maintained. It causes substantially more confusion than good. If no one wants to maintain it, shut it down pendining someone else picking up the job. ** Affects: chromium-browser (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1198529 Title: Chromium PPA should be revoked. Status in “chromium-browser” package in Ubuntu: New Bug description: There is an official-sounding PPA called chromium-daily, * https://launchpad.net/~chromium-daily/+archive/ppa However it only has version 18 released. This is ultimately confusing to end users. Suffice it to adduce two facts, Ubuntu 13.04 ships with version 25 and the timestamp of last maintence is 14 months old at the time of this bug report. The inactive PPA should be shut down or maintained. It causes substantially more confusion than good. If no one wants to maintain it, shut it down pendining someone else picking up the job. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1198529/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1198529] Re: Chromium PPA should be revoked.
Also, all of these outdated PPAs are referenced by the Chromium project, https://launchpad.net/chromium-project -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1198529 Title: Chromium PPA should be revoked. Status in “chromium-browser” package in Ubuntu: New Bug description: There is an official-sounding PPA called chromium-daily, * https://launchpad.net/~chromium-daily/+archive/ppa However it only has version 18 released. This is ultimately confusing to end users. Suffice it to adduce two facts, Ubuntu 13.04 ships with version 25 and the timestamp of last maintence is 14 months old at the time of this bug report. The inactive PPA should be shut down or maintained. It causes substantially more confusion than good. If no one wants to maintain it, shut it down pendining someone else picking up the job. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1198529/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
