Are you sure you're not just hitting the new(old at this point)
idiotic default of always failing after X failed attempts in Y time?
That would mean you mistyped the password a few times, but afterwards
it would not matter even if you typed it correctly.
Hello. This is a response not only to the
I noticed that pam 1.6.1-2 breaks sudo. Every time I tried to enter my
password with a sudo command, it tells me my password is incorrect. Of
course, it is not.
Similar to what was requested in the forum thread,⁽¹⁾ please provide
the output of `pacman -Qii sudo pambase`. 1.6.1-2 works here. Ch
On Sun, 2024-04-07 at 18:12 +, Arch Linux: Recent news updates:
Robin Candau wrote:
> The [vm.max_map_count][1] paramater will be increased from the
> default `65530` value to `1048576`.
>
> This change should help address performance, crash or start-up issues
> for a number of memory intensi
This is now released with pam 1.6.1 and shipped in Arch Linux.
Pretty sure it caused my issue here -
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3532
Will see how a rebooted system behaves now.
Martin
On Fri, Mar 15, 2024 at 12:09 AM Martin Rys wrote:
>
> That explains a lot, tha
On 2024-04-12 at 13:59:08 +0100,
Andy Pieters wrote:
> On Fri, 12 Apr 2024 at 13:53, Martin Rys wrote:
>
> > > It's common practice to not give an attacker more info than needed
> >
> > Which does not necessitate LYING to the user.
In the old days, login(1) used to try to be helpful by separat
On Friday, 12 April 2024 at 13:59 (+0100), Andy Pieters wrote:
The implementation of these timeouts don't provide a method for sending
an extra message to the user as to why their login attempt failed, but
Linux is open source, so feel free to submit proposals and pull
requests to make it more
On Fri, 12 Apr 2024 at 13:53, Martin Rys wrote:
> > It's common practice to not give an attacker more info than needed
>
> Which does not necessitate LYING to the user.
>
>
I think we're a bit over-reacting here. I've fallen foul of this myself
also, trying to log into my X not realising that my
> It's common practice to not give an attacker more info than needed
Which does not necessitate LYING to the user.
A static "Password wrong or login timeout in effect " would also be infinitely better.
Martin
On Fri, Apr 12, 2024 at 2:25 PM Georg Pfahler wrote:
>
> Hi there,
>
> On Fri, Apr 12
El jueves, 11 de abril de 2024 3:19:50 (CEST), Pocket escribió:
> In the qt5-* PKGBUILD most fail due to the wrong directory
>
> For example in qt5-tools:
>
> Build function
>
> qmake ../${_pkgfqn} CONFIG+=fat-static-lto
>
> should be
>
> qmake ../kde-${_pkgfqn} CONFIG+=fat-static-lto
Should
Hi there,
On Fri, Apr 12, 2024 at 11:36:43AM +0200, Martin Rys wrote:
> > FYI, the "idiotic default" may feel less annoying when you use the
> > documented solution
>
> Would be great if one got this as an error message when the logins
> start timing out.
>
> Unfortunately that's not the case, t
> FYI, the "idiotic default" may feel less annoying when you use the
documented solution
Would be great if one got this as an error message when the logins
start timing out.
Unfortunately that's not the case, the UX is beyond terrible, you get
the same identical error for a WRONG password as for
On Friday, 12 April 2024 at 10:10 (+0200), Martin Rys wrote:
Are you sure you're not just hitting the new(old at this point) idiotic
default of always failing after X failed attempts in Y time? That would
mean you mistyped the password a few times, but afterwards it would not
matter even if you
Are you sure you're not just hitting the new(old at this point)
idiotic default of always failing after X failed attempts in Y time?
That would mean you mistyped the password a few times, but afterwards
it would not matter even if you typed it correctly.
Rebooting will get you out of the timelock
13 matches
Mail list logo
