[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
*** This bug is a duplicate of bug 1996267 *** https://bugs.launchpad.net/bugs/1996267 That is a good target for a duplicate, marking it accordingly, thanks for the heads-up. ** This bug has been marked a duplicate of bug 1996267 [snap] Doesn't store encrypted passwords unless interface is connected -- 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 appears to be related with Bug LP:1996267. -- 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
Well true, I'm removing the duplicate mark, however it does explain why we cannot do this: https://forum.snapcraft.io/t/auto-connecting-the-cups-control-and- password-manager-service-interfaces-for-the-chromium-snap/4592/6 ** This bug is no longer a duplicate of bug 1836616 [snap] Upgrade from deb to snap forgets saved passwords ** Changed in: chromium-browser (Ubuntu) Status: New => Won't Fix -- 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
*** This bug is a duplicate of bug 1836616 *** https://bugs.launchpad.net/bugs/1836616 Found the duplicate target; See there that the interface auto-connection was denied by Snap Store. ** This bug has been marked a duplicate of bug 1836616 [snap] Upgrade from deb to snap forgets saved 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/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
** Tags added: password-storage -- 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
Re: [Desktop-packages] [Bug 2038875] Re: Snap uses hardcoded key and salt for password and cookie encryption
If password-manager-service is connected with snap connect chromium:password-manager-service then it uses the operating system's key ring. So are you pointing out that Chromium ought to use gnome-libcrypt instead of basic when no key ring is detected? -- 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
Re: [Desktop-packages] [Bug 2038875] Re: Snap uses hardcoded key and salt for password and cookie encryption
Hi Evan, thank you for the thorough report. Are you aware of Chromium having the password-manager-interface? Then it will use the keyring. -- 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
