[Touch-packages] [Bug 1927796] Re: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix
By following the same test procedure done in #18 and #19, the Hirsute build of pam_faillock was successfully validated. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1927796 Title: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix Status in pam package in Ubuntu: Fix Committed Status in pam source package in Bionic: Fix Committed Status in pam source package in Focal: Fix Committed Status in pam source package in Groovy: Fix Committed Status in pam source package in Hirsute: Fix Committed Status in pam source package in Impish: Fix Committed Bug description: [IMPACT] There is a known issue in pam_tally2 which may cause an account to be lock down even with correct password, in a busy node environment where simultaneous logins takes place (https://github.com/linux-pam/linux-pam/issues/71). There are already two customer cases from Canonical clients complaining about this behavior (00297697 and 00303806). Also, potentially, this will cause further problems in the future, since both STIG benchmarks and CIS benchmarks rely on pam_tally2 to lock accounts when wrong passwords are used. And both benchmarks - but specially STIG - requires use of a lot of audit rules, which can lead to the busy node environment. The issue impacts all pam_tally2 versions distributed in all currently supported Ubuntu versions and also the next unreleased one. Note that, according to https://github.com/linux-pam/linux-pam/issues/71, there is no plan to fix this issue! [FIX] This fix proposes to add pam_faillock module to the PAM package, so users of pam_tally2 having issues can migrate to pam_faillock. We also plan to modify the current STIG benchmarks to rely on pam_faillock instead of pam_tally2, but in order to do so, we need the pam_faillock module to be available. Note that we don't propose to remove pam_tally2, since not every user of this module is affected. [TEST] Tested on a VM installed with Focal server iso and on another with Bionic server iso. Enabled pam_faillock module as recommeded by its man page. Then tried to log over ssh with an incorrect password, until the account got locked. Waited for the configured grace time to unlock and logged in using the correct password. Note that, since the pam_tally2 issue is caused by a racing condition, with a hard to recreate environment (we could not even reproduce it with pam_tally2), we could not reproduce the conditions to test pam_faillock with. [REGRESSION POTENTIAL] The regression potential for this is small, since we're not removing the old pam_tally2 module, just adding another one. So anyone still using pam_tally2 will be able to do so. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1927796/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1927796] Re: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix
By following the same test procedure done in #18 and #19, the Groovy build of pam_faillock was successfully validated. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1927796 Title: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix Status in pam package in Ubuntu: Fix Committed Status in pam source package in Bionic: Fix Committed Status in pam source package in Focal: Fix Committed Status in pam source package in Groovy: Fix Committed Status in pam source package in Hirsute: Fix Committed Status in pam source package in Impish: Fix Committed Bug description: [IMPACT] There is a known issue in pam_tally2 which may cause an account to be lock down even with correct password, in a busy node environment where simultaneous logins takes place (https://github.com/linux-pam/linux-pam/issues/71). There are already two customer cases from Canonical clients complaining about this behavior (00297697 and 00303806). Also, potentially, this will cause further problems in the future, since both STIG benchmarks and CIS benchmarks rely on pam_tally2 to lock accounts when wrong passwords are used. And both benchmarks - but specially STIG - requires use of a lot of audit rules, which can lead to the busy node environment. The issue impacts all pam_tally2 versions distributed in all currently supported Ubuntu versions and also the next unreleased one. Note that, according to https://github.com/linux-pam/linux-pam/issues/71, there is no plan to fix this issue! [FIX] This fix proposes to add pam_faillock module to the PAM package, so users of pam_tally2 having issues can migrate to pam_faillock. We also plan to modify the current STIG benchmarks to rely on pam_faillock instead of pam_tally2, but in order to do so, we need the pam_faillock module to be available. Note that we don't propose to remove pam_tally2, since not every user of this module is affected. [TEST] Tested on a VM installed with Focal server iso and on another with Bionic server iso. Enabled pam_faillock module as recommeded by its man page. Then tried to log over ssh with an incorrect password, until the account got locked. Waited for the configured grace time to unlock and logged in using the correct password. Note that, since the pam_tally2 issue is caused by a racing condition, with a hard to recreate environment (we could not even reproduce it with pam_tally2), we could not reproduce the conditions to test pam_faillock with. [REGRESSION POTENTIAL] The regression potential for this is small, since we're not removing the old pam_tally2 module, just adding another one. So anyone still using pam_tally2 will be able to do so. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1927796/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1927796] Re: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix
By following the same test procedure done in #18 and #19, the Focal build of pam_faillock was successfully validated. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1927796 Title: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix Status in pam package in Ubuntu: Fix Committed Status in pam source package in Bionic: Fix Committed Status in pam source package in Focal: Fix Committed Status in pam source package in Groovy: Fix Committed Status in pam source package in Hirsute: Fix Committed Status in pam source package in Impish: Fix Committed Bug description: [IMPACT] There is a known issue in pam_tally2 which may cause an account to be lock down even with correct password, in a busy node environment where simultaneous logins takes place (https://github.com/linux-pam/linux-pam/issues/71). There are already two customer cases from Canonical clients complaining about this behavior (00297697 and 00303806). Also, potentially, this will cause further problems in the future, since both STIG benchmarks and CIS benchmarks rely on pam_tally2 to lock accounts when wrong passwords are used. And both benchmarks - but specially STIG - requires use of a lot of audit rules, which can lead to the busy node environment. The issue impacts all pam_tally2 versions distributed in all currently supported Ubuntu versions and also the next unreleased one. Note that, according to https://github.com/linux-pam/linux-pam/issues/71, there is no plan to fix this issue! [FIX] This fix proposes to add pam_faillock module to the PAM package, so users of pam_tally2 having issues can migrate to pam_faillock. We also plan to modify the current STIG benchmarks to rely on pam_faillock instead of pam_tally2, but in order to do so, we need the pam_faillock module to be available. Note that we don't propose to remove pam_tally2, since not every user of this module is affected. [TEST] Tested on a VM installed with Focal server iso and on another with Bionic server iso. Enabled pam_faillock module as recommeded by its man page. Then tried to log over ssh with an incorrect password, until the account got locked. Waited for the configured grace time to unlock and logged in using the correct password. Note that, since the pam_tally2 issue is caused by a racing condition, with a hard to recreate environment (we could not even reproduce it with pam_tally2), we could not reproduce the conditions to test pam_faillock with. [REGRESSION POTENTIAL] The regression potential for this is small, since we're not removing the old pam_tally2 module, just adding another one. So anyone still using pam_tally2 will be able to do so. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1927796/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1927796] Re: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix
Additional tests done on bionic: after changing the parameters set in /etc/security/faillock.conf to: deny=2 unlock_time=20 By trying to authenticate with the wrong password 2 times, it was verified that the account was locked for the amount of time set to the unlock_time parameter (20s). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1927796 Title: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix Status in pam package in Ubuntu: Fix Committed Status in pam source package in Bionic: Fix Committed Status in pam source package in Focal: Fix Committed Status in pam source package in Groovy: Fix Committed Status in pam source package in Hirsute: Fix Committed Status in pam source package in Impish: Fix Committed Bug description: [IMPACT] There is a known issue in pam_tally2 which may cause an account to be lock down even with correct password, in a busy node environment where simultaneous logins takes place (https://github.com/linux-pam/linux-pam/issues/71). There are already two customer cases from Canonical clients complaining about this behavior (00297697 and 00303806). Also, potentially, this will cause further problems in the future, since both STIG benchmarks and CIS benchmarks rely on pam_tally2 to lock accounts when wrong passwords are used. And both benchmarks - but specially STIG - requires use of a lot of audit rules, which can lead to the busy node environment. The issue impacts all pam_tally2 versions distributed in all currently supported Ubuntu versions and also the next unreleased one. Note that, according to https://github.com/linux-pam/linux-pam/issues/71, there is no plan to fix this issue! [FIX] This fix proposes to add pam_faillock module to the PAM package, so users of pam_tally2 having issues can migrate to pam_faillock. We also plan to modify the current STIG benchmarks to rely on pam_faillock instead of pam_tally2, but in order to do so, we need the pam_faillock module to be available. Note that we don't propose to remove pam_tally2, since not every user of this module is affected. [TEST] Tested on a VM installed with Focal server iso and on another with Bionic server iso. Enabled pam_faillock module as recommeded by its man page. Then tried to log over ssh with an incorrect password, until the account got locked. Waited for the configured grace time to unlock and logged in using the correct password. Note that, since the pam_tally2 issue is caused by a racing condition, with a hard to recreate environment (we could not even reproduce it with pam_tally2), we could not reproduce the conditions to test pam_faillock with. [REGRESSION POTENTIAL] The regression potential for this is small, since we're not removing the old pam_tally2 module, just adding another one. So anyone still using pam_tally2 will be able to do so. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1927796/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1927796] Re: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix
Tested pam_faillock module for pam on bionic.
Test consisted on setting up pam_faillock with the following
configuration, as described in the man page:
/etc/security/faillock.conf file example:
deny=4
unlock_time=1200
silent
/etc/pam.d/config file example:
auth required pam_faillock.so preauth
# optionally use requisite above if you do not want to prompt for the password
# on locked accounts
auth sufficient pam_unix.so
auth [default=die] pam_faillock.so authfail
auth required pam_deny.so
account required pam_faillock.so
# if you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures
account required pam_unix.so
A new user 'joas' was created and its password set. Then, initially, 4
logins were made through ssh and terminal, using the correct password.
All were successful.
User 'joas' was, then, logged out and 4 attempts to login with incorrect
password were made. Since pam_faillock module was set to lock on the 4th
incorrect attempt, another try was done, this time with the correct
password.
After confirming that the 'joas' account was locked, by trying, with the
correct password, additional times, the superuser account was used to
display the account stats ('faillock --user joas') and then used to
unlock the 'joas' account ('faillock --user joas --reset').
Then, again 4 logins were made using the correct password, in order to
check it was successfully authenticating.
Another test consisted on typing the wrong password 3 times, then typing
the correct one, to make sure the PAM module was properly resetting the
counter.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/1927796
Title:
[SRU]pam_tally2 can cause accounts to be locked by correct password.
pam_faillock use is the recommended fix
Status in pam package in Ubuntu:
Fix Committed
Status in pam source package in Bionic:
Fix Committed
Status in pam source package in Focal:
Fix Committed
Status in pam source package in Groovy:
Fix Committed
Status in pam source package in Hirsute:
Fix Committed
Status in pam source package in Impish:
Fix Committed
Bug description:
[IMPACT]
There is a known issue in pam_tally2 which may cause an account to be lock
down even with correct password, in a busy node environment where simultaneous
logins takes place (https://github.com/linux-pam/linux-pam/issues/71).
There are already two customer cases from Canonical clients
complaining about this behavior (00297697 and 00303806).
Also, potentially, this will cause further problems in the future,
since both STIG benchmarks and CIS benchmarks rely on pam_tally2 to
lock accounts when wrong passwords are used. And both benchmarks - but
specially STIG - requires use of a lot of audit rules, which can lead
to the busy node environment.
The issue impacts all pam_tally2 versions distributed in all currently
supported Ubuntu versions and also the next unreleased one. Note that,
according to https://github.com/linux-pam/linux-pam/issues/71, there
is no plan to fix this issue!
[FIX]
This fix proposes to add pam_faillock module to the PAM package, so users of
pam_tally2 having issues can migrate to pam_faillock. We also plan to modify
the current STIG benchmarks to rely on pam_faillock instead of pam_tally2, but
in order to do so, we need the pam_faillock module to be available.
Note that we don't propose to remove pam_tally2, since not every user
of this module is affected.
[TEST]
Tested on a VM installed with Focal server iso and on another with Bionic
server iso. Enabled pam_faillock module as recommeded by its man page. Then
tried to log over ssh with an incorrect password, until the account got locked.
Waited for the configured grace time to unlock and logged in using the correct
password.
Note that, since the pam_tally2 issue is caused by a racing condition,
with a hard to recreate environment (we could not even reproduce it
with pam_tally2), we could not reproduce the conditions to test
pam_faillock with.
[REGRESSION POTENTIAL]
The regression potential for this is small, since we're not removing the old
pam_tally2 module, just adding another one. So anyone still using pam_tally2
will be able to do so.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1927796/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1927796] [NEW] [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix
Public bug reported: [IMPACT] There is a known issue in pam_tally2 which may cause an account to be lock down even with correct password, in a busy node environment where simultaneous logins takes place (https://github.com/linux-pam/linux-pam/issues/71). There are already two customer cases from the US Army complaining about this behavior (https://canonical.lightning.force.com/lightning/r/Case/5004K03vkq4QAA/view and https://canonical.lightning.force.com/lightning/r/Case/5004K03tkbmQAA/view). Also, potentially, this will cause further problems in the future, since both STIG benchmarks and CIS benchmarks rely on pam_tally2 to lock accounts when wrong passwords are used. And both benchmarks - but specially STIG - requires use of a lot of audit rules, which can lead to the busy node environment. The issue impacts all pam_tally2 versions distributed in all currently supported Ubuntu versions and also the next unreleased one. Note that, according to https://github.com/linux-pam/linux-pam/issues/71, there is no plan to fix this issue! [FIX] This fix proposes to add pam_faillock module to the PAM package, so users of pam_tally2 having issues can migrate to pam_faillock. We also plan to modify the current STIG benchmarks to rely on pam_faillock instead of pam_tally2, but in order to do so, we need the pam_faillock module to be available. Note that we don't propose to remove pam_tally2, since not every user of this module is affected. [TEST] Tested on a VM installed with Focal server iso and on another with Bionic server iso. Enabled pam_faillock module as recommeded by its man page. Then tried to log over ssh with an incorrect password, until the account got locked. Waited for the configured grace time to unlock and logged in using the correct password. Note that, since the pam_tally2 issue is caused by a racing condition, with a hard to recreate environment (we could not even reproduce it with pam_tally2), we could not reproduce the conditions to test pam_faillock with. [REGRESSION POTENTIAL] The regression potential for this is small, since we're not removing the old pam_tally2 module, just adding another one. So anyone still using pam_tally2 will be able to do so. ** Affects: pam (Ubuntu) Importance: Undecided Status: New ** Tags: pam-faillock pam-tally2 ** Attachment added: "Zip file containg debdiffs of all PAM packages for current supported and for the next distro" https://bugs.launchpad.net/bugs/1927796/+attachment/5495607/+files/debdiffs.tgz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1927796 Title: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix Status in pam package in Ubuntu: New Bug description: [IMPACT] There is a known issue in pam_tally2 which may cause an account to be lock down even with correct password, in a busy node environment where simultaneous logins takes place (https://github.com/linux-pam/linux-pam/issues/71). There are already two customer cases from the US Army complaining about this behavior (https://canonical.lightning.force.com/lightning/r/Case/5004K03vkq4QAA/view and https://canonical.lightning.force.com/lightning/r/Case/5004K03tkbmQAA/view). Also, potentially, this will cause further problems in the future, since both STIG benchmarks and CIS benchmarks rely on pam_tally2 to lock accounts when wrong passwords are used. And both benchmarks - but specially STIG - requires use of a lot of audit rules, which can lead to the busy node environment. The issue impacts all pam_tally2 versions distributed in all currently supported Ubuntu versions and also the next unreleased one. Note that, according to https://github.com/linux-pam/linux-pam/issues/71, there is no plan to fix this issue! [FIX] This fix proposes to add pam_faillock module to the PAM package, so users of pam_tally2 having issues can migrate to pam_faillock. We also plan to modify the current STIG benchmarks to rely on pam_faillock instead of pam_tally2, but in order to do so, we need the pam_faillock module to be available. Note that we don't propose to remove pam_tally2, since not every user of this module is affected. [TEST] Tested on a VM installed with Focal server iso and on another with Bionic server iso. Enabled pam_faillock module as recommeded by its man page. Then tried to log over ssh with an incorrect password, until the account got locked. Waited for the configured grace time to unlock and logged in using the correct password. Note that, since the pam_tally2 issue is caused by a racing condition, with a hard to recreate environment (we could not even reproduce it with pam_tally2), we could not reproduce the conditions to test pam_faillock with. [REGRESSION POTENTIAL] The regression
[Touch-packages] [Bug 1885562] Re: [fips] freebl_fipsSoftwareIntegrityTest fails in FIPS mode
Reviewed patches and they look good to me. However, in the future, we should consider another possibility: disable FIPS mode for libNSS3 by default, since that lib isn't FIPS-certified. This can prevent customers from mistakenly think the opposite. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nss in Ubuntu. https://bugs.launchpad.net/bugs/1885562 Title: [fips] freebl_fipsSoftwareIntegrityTest fails in FIPS mode Status in nss package in Ubuntu: In Progress Status in nss source package in Bionic: In Progress Bug description: In FIPS mode there are some additional checks performed. They lead to verifying binaries signatures. Those signatures are shipped in the libnss3 package as *.chk files installed in /usr/lib/$(DEB_HOST_MULTIARCH)/nss. Along with those files are the libraries themselves (libfreebl3.so libfreeblpriv3.so libnssckbi.so libnssdbm3.so libsoftokn3.so). Those libraries are symlinked to be present in /usr/lib/$(DEB_HOST_MULTIARCH): ls -l /usr/lib/x86_64-linux-gnu/libfreeblpriv3.so lrwxrwxrwx 1 root root 21 Jun 10 18:54 /usr/lib/x86_64-linux-gnu/libfreeblpriv3.so -> nss/libfreeblpriv3.so The client binaries are linked against the symlinks, so when the verification happens (lib/freebl/shvfy.c) the mkCheckFileName function takes path to the symlink to the shlib and replaces the .so extension with .chk. Then it tries to open that file. Obviosly it fails, because the actual file is in /usr/lib/$(DEB_HOST_MULTIARCH)/nss. [Test case] sudo apt install chrony sudo chronyd -d chronyd: util.c:373 UTI_IPToRefid: Assertion `MD5_hash >= 0' failed. Potential solutions: Solution A: Drop the /usr/lib/$(DEB_HOST_MULTIARCH)/nss directory and put all signatures and libs in /usr/lib/$(DEB_HOST_MULTIARCH). Solution B: Create symlinks to *.chk files in /usr/lib/$(DEB_HOST_MULTIARCH) (like it is done for *.so). Solution C: Implement and upstream NSS feature of resolving symlinks and looking for *.chk where the symlinks lead to. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1885562/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1885562] Re: [fips] freebl_fipsSoftwareIntegrityTest fails in FIPS mode
** Changed in: nss (Ubuntu) Assignee: (unassigned) => Richard Maciel Costa (richardmaciel) ** Changed in: nss (Ubuntu Bionic) Assignee: (unassigned) => Richard Maciel Costa (richardmaciel) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nss in Ubuntu. https://bugs.launchpad.net/bugs/1885562 Title: [fips] freebl_fipsSoftwareIntegrityTest fails in FIPS mode Status in nss package in Ubuntu: New Status in nss source package in Bionic: New Bug description: In FIPS mode there are some additional checks performed. They lead to verifying binaries signatures. Those signatures are shipped in the libnss3 package as *.chk files installed in /usr/lib/$(DEB_HOST_MULTIARCH)/nss. Along with those files are the libraries themselves (libfreebl3.so libfreeblpriv3.so libnssckbi.so libnssdbm3.so libsoftokn3.so). Those libraries are symlinked to be present in /usr/lib/$(DEB_HOST_MULTIARCH): ls -l /usr/lib/x86_64-linux-gnu/libfreeblpriv3.so lrwxrwxrwx 1 root root 21 Jun 10 18:54 /usr/lib/x86_64-linux-gnu/libfreeblpriv3.so -> nss/libfreeblpriv3.so The client binaries are linked against the symlinks, so when the verification happens (lib/freebl/shvfy.c) the mkCheckFileName function takes path to the symlink to the shlib and replaces the .so extension with .chk. Then it tries to open that file. Obviosly it fails, because the actual file is in /usr/lib/$(DEB_HOST_MULTIARCH)/nss. [Test case] sudo apt install chrony sudo chronyd -d chronyd: util.c:373 UTI_IPToRefid: Assertion `MD5_hash >= 0' failed. Potential solutions: Solution A: Drop the /usr/lib/$(DEB_HOST_MULTIARCH)/nss directory and put all signatures and libs in /usr/lib/$(DEB_HOST_MULTIARCH). Solution B: Create symlinks to *.chk files in /usr/lib/$(DEB_HOST_MULTIARCH) (like it is done for *.so). Solution C: Implement and upstream NSS feature of resolving symlinks and looking for *.chk where the symlinks lead to. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1885562/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
