[Touch-packages] [Bug 1792857] [NEW] Mouse pointer is the wrong size after resuming from suspend
Public bug reported: After resuming from suspend, but mouse pointer is the wrong size when located in some parts of the screen. Specifically, when mousing over the left or top bars of the UI (not the desktop or any running programs), the pointer is too large. A workaround is to open display settings, pick any other resolution, click apply, then click revert. When the original resolution is restored, the pointer size returns to normal. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.15.0-33.36-generic 4.15.18 Uname: Linux 4.15.0-33-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.3 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Sun Sep 16 20:46:42 2018 DistUpgraded: 2018-05-28 17:09:21,096 ERROR got error from PostInstallScript ./xorg_fix_proprietary.py (g-exec-error-quark: Failed to execute child process "./xorg_fix_proprietary.py" (No such file or directory) (8)) DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: virtualbox, 5.2.10, 4.15.0-33-generic, x86_64: installed virtualbox, 5.2.10, 4.15.0-34-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo HD Graphics 5500 [17aa:2227] InstallationDate: Installed on 2016-04-27 (872 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) MachineType: LENOVO 20BSCTO1WW ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-33-generic root=/dev/mapper/ubuntu-root ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to bionic on 2018-05-29 (111 days ago) dmi.bios.date: 08/13/2015 dmi.bios.vendor: LENOVO dmi.bios.version: N14ET32W (1.10 ) dmi.board.asset.tag: Not Available dmi.board.name: 20BSCTO1WW dmi.board.vendor: LENOVO dmi.board.version: 0B98417 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN14ET32W(1.10):bd08/13/2015:svnLENOVO:pn20BSCTO1WW:pvrThinkPadX1Carbon3rd:rvnLENOVO:rn20BSCTO1WW:rvr0B98417WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 3rd dmi.product.name: 20BSCTO1WW dmi.product.version: ThinkPad X1 Carbon 3rd dmi.sys.vendor: LENOVO version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1 version.libdrm2: libdrm2 2.4.91-2 version.libgl1-mesa-dri: libgl1-mesa-dri 18.0.5-0ubuntu0~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 18.0.5-0ubuntu0~18.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 xserver.bootTime: Mon May 28 16:18:25 2018 xserver.configfile: default xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id1049 vendor LGD xserver.version: 2:1.18.4-0ubuntu0.7 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic ubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1792857 Title: Mouse pointer is the wrong size after resuming from suspend Status in xorg package in Ubuntu: New Bug description: After resuming from suspend, but mouse pointer is the wrong size when located in some parts of the screen. Specifically, when mousing over the left or top bars of the UI (not the desktop or any running programs), the pointer is too large. A workaround is to open display settings, pick any other resolution, click apply, then click revert. When the original resolution is restored, the pointer size returns to normal. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.15.0-33.36-generic 4.15.18 Uname: Linux 4.15.0-33-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.3 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Sun Sep 16 20:46:42 2018 DistUpgraded: 2018-05-28 17:09:21,096 ERROR got error from PostInstallScript ./xorg_fix_proprietary.py (g-exec-error-quark: Failed to execute child process "./xorg_fix_proprietary.py" (No such file or directory) (8)) DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: virtualbox, 5.2.10, 4.15.0-33-generic, x86_64: installed virtualbox, 5.2.10,
[Touch-packages] [Bug 1773860] [NEW] package ca-certificates 20180409 failed to install/upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 24
Public bug reported: I'll let someone else figure out if this is a duplicate with the other "failed to install/upgrade" bugs ProblemType: Package DistroRelease: Ubuntu 18.04 Package: ca-certificates 20180409 ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17 Uname: Linux 4.15.0-22-generic x86_64 ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 Date: Mon May 28 16:47:29 2018 ErrorMessage: installed ca-certificates package post-installation script subprocess returned error exit status 24 InstallationDate: Installed on 2016-04-27 (761 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) PackageArchitecture: all Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3 PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.1 SourcePackage: ca-certificates Title: package ca-certificates 20180409 failed to install/upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 24 UpgradeStatus: Upgraded to bionic on 2018-05-29 (0 days ago) ** Affects: ca-certificates (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1773860 Title: package ca-certificates 20180409 failed to install/upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 24 Status in ca-certificates package in Ubuntu: New Bug description: I'll let someone else figure out if this is a duplicate with the other "failed to install/upgrade" bugs ProblemType: Package DistroRelease: Ubuntu 18.04 Package: ca-certificates 20180409 ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17 Uname: Linux 4.15.0-22-generic x86_64 ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 Date: Mon May 28 16:47:29 2018 ErrorMessage: installed ca-certificates package post-installation script subprocess returned error exit status 24 InstallationDate: Installed on 2016-04-27 (761 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) PackageArchitecture: all Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3 PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.1 SourcePackage: ca-certificates Title: package ca-certificates 20180409 failed to install/upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 24 UpgradeStatus: Upgraded to bionic on 2018-05-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1773860/+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 1691314] Re: Completions should be paged through PAGER when `page-completions` is off
** Description changed: When tab completion sends output through a pager, it seemed to use more. - Because less is better than more, I wanted it to use more instead, + Because less is better than more, I wanted it to use less instead, particularly so I can scroll in both directions. I initially made /bin/more a symlink to less (which would trigger its more-emulation mode, but that's still better than actual more), but this had no effect. As a result, I consulted the man page for bash. In the section on readline, there is a setting `page-completions` which says that when on (the default), readline will use a built-in more-like pager to page the results. This doesn't specify what happens when it is turned off, but I expected that instead of the built-in pager, it would use an external on, specifically the one specified in the PAGER environment variable. However, it instead simply dumps the results in the terminal. Please add some way to use PAGER as the pager for completion results. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: bash 4.3-14ubuntu1.1 ProcVersionSignature: Ubuntu 4.4.0-75.96-generic 4.4.59 Uname: Linux 4.4.0-75-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity Date: Tue May 16 18:42:43 2017 InstallationDate: Installed on 2016-04-27 (384 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: bash UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1691314 Title: Completions should be paged through PAGER when `page-completions` is off Status in bash package in Ubuntu: New Bug description: When tab completion sends output through a pager, it seemed to use more. Because less is better than more, I wanted it to use less instead, particularly so I can scroll in both directions. I initially made /bin/more a symlink to less (which would trigger its more-emulation mode, but that's still better than actual more), but this had no effect. As a result, I consulted the man page for bash. In the section on readline, there is a setting `page-completions` which says that when on (the default), readline will use a built-in more- like pager to page the results. This doesn't specify what happens when it is turned off, but I expected that instead of the built-in pager, it would use an external on, specifically the one specified in the PAGER environment variable. However, it instead simply dumps the results in the terminal. Please add some way to use PAGER as the pager for completion results. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: bash 4.3-14ubuntu1.1 ProcVersionSignature: Ubuntu 4.4.0-75.96-generic 4.4.59 Uname: Linux 4.4.0-75-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity Date: Tue May 16 18:42:43 2017 InstallationDate: Installed on 2016-04-27 (384 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: bash UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1691314/+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 1691314] [NEW] Completions should be paged through PAGER when `page-completions` is off
Public bug reported: When tab completion sends output through a pager, it seemed to use more. Because less is better than more, I wanted it to use more instead, particularly so I can scroll in both directions. I initially made /bin/more a symlink to less (which would trigger its more-emulation mode, but that's still better than actual more), but this had no effect. As a result, I consulted the man page for bash. In the section on readline, there is a setting `page-completions` which says that when on (the default), readline will use a built-in more-like pager to page the results. This doesn't specify what happens when it is turned off, but I expected that instead of the built-in pager, it would use an external on, specifically the one specified in the PAGER environment variable. However, it instead simply dumps the results in the terminal. Please add some way to use PAGER as the pager for completion results. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: bash 4.3-14ubuntu1.1 ProcVersionSignature: Ubuntu 4.4.0-75.96-generic 4.4.59 Uname: Linux 4.4.0-75-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity Date: Tue May 16 18:42:43 2017 InstallationDate: Installed on 2016-04-27 (384 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: bash UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: bash (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1691314 Title: Completions should be paged through PAGER when `page-completions` is off Status in bash package in Ubuntu: New Bug description: When tab completion sends output through a pager, it seemed to use more. Because less is better than more, I wanted it to use more instead, particularly so I can scroll in both directions. I initially made /bin/more a symlink to less (which would trigger its more-emulation mode, but that's still better than actual more), but this had no effect. As a result, I consulted the man page for bash. In the section on readline, there is a setting `page-completions` which says that when on (the default), readline will use a built-in more- like pager to page the results. This doesn't specify what happens when it is turned off, but I expected that instead of the built-in pager, it would use an external on, specifically the one specified in the PAGER environment variable. However, it instead simply dumps the results in the terminal. Please add some way to use PAGER as the pager for completion results. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: bash 4.3-14ubuntu1.1 ProcVersionSignature: Ubuntu 4.4.0-75.96-generic 4.4.59 Uname: Linux 4.4.0-75-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity Date: Tue May 16 18:42:43 2017 InstallationDate: Installed on 2016-04-27 (384 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: bash UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1691314/+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 1308265] Re: First password letter not registered in lockscreen if screen off
Is this actually being worked on? The regression has been there a while now, and is still present in the most recent release. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity in Ubuntu. https://bugs.launchpad.net/bugs/1308265 Title: First password letter not registered in lockscreen if screen off Status in Unity: In Progress Status in Unity 7.2 series: In Progress Status in unity package in Ubuntu: In Progress Bug description: With the new lockscreen, if my screen is off, I just start typing, every time my password is too short. It looks like the first key only triggers the screen on and does not go to the input field. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unity 7.2.0+14.04.20140414.1-0ubuntu1 ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 NonfreeKernelModules: wl nvidia ApportVersion: 2.14.1-0ubuntu2 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CurrentDesktop: Unity Date: Tue Apr 15 23:59:08 2014 SourcePackage: unity UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1308265/+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 138654] Re: Annoying and useless delays on password entry errors
(Just a reminder that when combined with bug 1308265, it can get pretty annoying. This is worth fixing.) -- 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/138654 Title: Annoying and useless delays on password entry errors Status in Ubuntu: Invalid Status in pam package in Ubuntu: Triaged Bug description: Binary package hint: sudo Hello! This is about Ubuntu Gutsy, though it applies to the other versions as well. My problem is that every password-entry that requires the user's log- in password has an annoying little delay of a few seconds when entering a mistaken password before asking again for it. (I linked sudo above, but this applies to the login on the console and on the GDM screen, the screen-savers, gksu I think, and I'm sure I forget some. SSH does this too, I think, but I've been using public-key logins for too long and I forget.) Example: run sudo ls in a terminal, type a wrong password, and watch how you're forced to wait before being told it's wrong and asked to try again. I think this is supposed to be a security feature attempting to discourage brute-forcing a password. However, it's annoyingly intrusive, and I doubt it's that effective or useful in many cases. (Though I must agree it's relatively simple.) First of all, this isn't really as effective a security measure as it might seem: For most cases it's very simple to get around this by attempting a password, killing the process after 100ms if it doesn't answer and retrying. This effectively reduces the time cost for an attempt to $PROCESS_START_TIME+$PASSWORD_ENTRY_TIME+100ms, which is typically much less than the three or so seconds sudo forces a user to wait. For instance, if I'd try to use sudo to brute force a password I'd run sudo echo 'found it' (to make sure I get the answer quickly) in a loop, killing the process 100ms after entering a password attempt and not receiving any output. Granted, there's the added time cost of re-starting the process, but every password entry fails after three errors, so simply removing the delay would decrease the brute-force time by at most a factor of three. Which isn't really much, is it? First proposal: given the above attack, I suggest lowering the delay to about half a second. This would make brute force about five time easier than it is now (which I believe isn't a great concern), and would be almost unnoticeable by a normal user. Second proposal: the system should keep for each password a global count of recent failures. Any anti-brute-force measures should be activated only when the number of consecutive failures grows. The counter would be reset on success, and would decay in time. This second proposal is I think optimal. It sounds a bit complicated. However, I believe all the programs above actually make use of common PAM modules (also, I think the delay is controlled by those), so this would be easy to implement just once. Note that every element of the second proposal is important: the counters must be per-machine global, not per-process or per-session (so an attacker can't just kill a process and retry), and there must be separate counters for each password (so you can't reset it by entering a known password, and an attempt to brute-force one user's password doesn't inconvenience other users). Note also that this scheme is both more protective and convenient: (a) the delay can grow with the number of attempts, eg. 3 secs after three failures, 10 secs after twenty failures, one minute and a big nasty warning after a hundred consecutive failures. (This way, a legitimate user would notice something is amiss instead of just resetting the counter.) (b) the measures are activated even if the attacker tries to use the technique above. Even if he kills the process, he'll still get the delay _even for the first attempt_ after several errors. (c) users don't have to wait each time they make a typo in a password entry field. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/138654/+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 1308265] Re: First password letter not registered in lockscreen if screen off
When combined with bug 138654, this gets super annoying, so it is worth fixing. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity in Ubuntu. https://bugs.launchpad.net/bugs/1308265 Title: First password letter not registered in lockscreen if screen off Status in Unity: In Progress Status in Unity 7.2 series: In Progress Status in unity package in Ubuntu: In Progress Bug description: With the new lockscreen, if my screen is off, I just start typing, every time my password is too short. It looks like the first key only triggers the screen on and does not go to the input field. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: unity 7.2.0+14.04.20140414.1-0ubuntu1 ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 NonfreeKernelModules: wl nvidia ApportVersion: 2.14.1-0ubuntu2 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CurrentDesktop: Unity Date: Tue Apr 15 23:59:08 2014 SourcePackage: unity UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1308265/+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 138654] Re: Annoying and useless delays on password entry errors
Is this actually going to get fixed? There hasn't been a meaningful update in a year and a half. -- 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/138654 Title: Annoying and useless delays on password entry errors Status in Ubuntu: Invalid Status in pam package in Ubuntu: Triaged Bug description: Binary package hint: sudo Hello! This is about Ubuntu Gutsy, though it applies to the other versions as well. My problem is that every password-entry that requires the user's log- in password has an annoying little delay of a few seconds when entering a mistaken password before asking again for it. (I linked sudo above, but this applies to the login on the console and on the GDM screen, the screen-savers, gksu I think, and I'm sure I forget some. SSH does this too, I think, but I've been using public-key logins for too long and I forget.) Example: run sudo ls in a terminal, type a wrong password, and watch how you're forced to wait before being told it's wrong and asked to try again. I think this is supposed to be a security feature attempting to discourage brute-forcing a password. However, it's annoyingly intrusive, and I doubt it's that effective or useful in many cases. (Though I must agree it's relatively simple.) First of all, this isn't really as effective a security measure as it might seem: For most cases it's very simple to get around this by attempting a password, killing the process after 100ms if it doesn't answer and retrying. This effectively reduces the time cost for an attempt to $PROCESS_START_TIME+$PASSWORD_ENTRY_TIME+100ms, which is typically much less than the three or so seconds sudo forces a user to wait. For instance, if I'd try to use sudo to brute force a password I'd run sudo echo 'found it' (to make sure I get the answer quickly) in a loop, killing the process 100ms after entering a password attempt and not receiving any output. Granted, there's the added time cost of re-starting the process, but every password entry fails after three errors, so simply removing the delay would decrease the brute-force time by at most a factor of three. Which isn't really much, is it? First proposal: given the above attack, I suggest lowering the delay to about half a second. This would make brute force about five time easier than it is now (which I believe isn't a great concern), and would be almost unnoticeable by a normal user. Second proposal: the system should keep for each password a global count of recent failures. Any anti-brute-force measures should be activated only when the number of consecutive failures grows. The counter would be reset on success, and would decay in time. This second proposal is I think optimal. It sounds a bit complicated. However, I believe all the programs above actually make use of common PAM modules (also, I think the delay is controlled by those), so this would be easy to implement just once. Note that every element of the second proposal is important: the counters must be per-machine global, not per-process or per-session (so an attacker can't just kill a process and retry), and there must be separate counters for each password (so you can't reset it by entering a known password, and an attempt to brute-force one user's password doesn't inconvenience other users). Note also that this scheme is both more protective and convenient: (a) the delay can grow with the number of attempts, eg. 3 secs after three failures, 10 secs after twenty failures, one minute and a big nasty warning after a hundred consecutive failures. (This way, a legitimate user would notice something is amiss instead of just resetting the counter.) (b) the measures are activated even if the attacker tries to use the technique above. Even if he kills the process, he'll still get the delay _even for the first attempt_ after several errors. (c) users don't have to wait each time they make a typo in a password entry field. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/138654/+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
