Re: [hackers] [slock][patch] Prevent shift key from toggling to failed state
On Aug 27 18:34, Markus Teich wrote: > There's also https://git.suckless.org/slock/file/config.def.h.html#l12 which > you > may set to 0. > > --Markus > > > Am 2018-08-27 18:01, schrieb Carlos Torres: > > Hello, > > > > On Mon, Aug 27, 2018 at 8:53 PM Michael Spradling > > wrote: > > > I thought I would push my patch, but didn't know exactly how the > > > developers of slock would like it fixed. Or even if they did. > > > > Since the other fix is a patch, i doubt this version will be > > mainlined. put it on the wiki :) > > > > --Carlos > Wow, can't believe I missed this. Yes, this fixes the patch for me. The patch does ignore more than just the shift key, but it does what I want. Thanks, Michael
Re: [hackers] [slock][patch] Prevent shift key from toggling to failed state
There's also https://git.suckless.org/slock/file/config.def.h.html#l12 which you may set to 0. --Markus Am 2018-08-27 18:01, schrieb Carlos Torres: Hello, On Mon, Aug 27, 2018 at 8:53 PM Michael Spradling wrote: I thought I would push my patch, but didn't know exactly how the developers of slock would like it fixed. Or even if they did. Since the other fix is a patch, i doubt this version will be mainlined. put it on the wiki :) --Carlos
Re: [hackers] [slock][patch] Prevent shift key from toggling to failed state
On Aug 27 21:01, Carlos Torres wrote: > Hello, > > On Mon, Aug 27, 2018 at 8:53 PM Michael Spradling wrote: > > I thought I would push my patch, but didn't know exactly how the > > developers of slock would like it fixed. Or even if they did. > > Since the other fix is a patch, i doubt this version will be > mainlined. put it on the wiki :) > > --Carlos > I figured this was more than just a preference, but more of a flaw since it could give a hint at your password. However, I will submit it to the wiki if preferred. Thanks, Michael
Re: [hackers] [slock][patch] Prevent shift key from toggling to failed state
Hello, On Mon, Aug 27, 2018 at 8:53 PM Michael Spradling wrote: > I thought I would push my patch, but didn't know exactly how the > developers of slock would like it fixed. Or even if they did. Since the other fix is a patch, i doubt this version will be mainlined. put it on the wiki :) --Carlos
Re: [hackers] [slock][patch] Prevent shift key from toggling to failed state
On Aug 27 17:38, Eric Pruitt wrote:
> On Tue, Aug 28, 2018 at 10:24:43AM +1200, David Phillips wrote:
> > The patch Michael Buch linked should work for you. For background, I
> > created it because previous discussion hereabout 2 years ago showed
> > that the community rather keep slock extremely paranoid and ready to
> > trip to the failed state at any keypress in order to indicate any
> > form of tampering.
>
> I wrote a patch (attached) for similar reasons, but instead of
> completely ignoring shift, it waits until it's released to change the
> screen. The patch won't apply cleanly because it depends on another
> patch I wrote, but it's a relatively simple change.
>
> Eric
> Title: Improved Modifier Handling
> Author: Eric Pruitt (https://www.codevat.com/, https://github.com/ericpruitt/)
>
> With this patch, modifier keys only cause the screen to display the failure
> color when they are released without pressing a complementary key.
>
> This patch depends on "slock-00-pam-authentication.diff".
>
> --- a/slock.c
> +++ b/slock.c
> @@ -226,6 +226,7 @@ readpw(struct xrandr *rr, int nscreens, const char *hash)
> unsigned int len, color;
> KeySym ksym;
> XEvent ev;
> + int seenkeypress = 0;
>
> len = 0;
> running = 1;
> @@ -233,9 +234,14 @@ readpw(struct xrandr *rr, int nscreens, const char *hash)
>* utility. This way the user can easily set a customized DPMS
>* timeout. */
> while (running && !XNextEvent(dpy, &ev)) {
> - if (ev.type == KeyPress) {
> + if (ev.type == KeyPress || ev.type == KeyRelease) {
> explicit_bzero(&buf, sizeof(buf));
> num = XLookupString(&ev.xkey, buf, sizeof(buf), &ksym,
> 0);
> + seenkeypress |= ev.type == KeyPress;
> + if ((ev.type == KeyRelease && (num || !seenkeypress)) ||
> + (ev.type == KeyPress && !num)) {
> + continue;
> + }
> if (IsKeypadKey(ksym)) {
> if (ksym == XK_KP_Enter)
> ksym = XK_Return;
Great, this is another way to solve the problem. Wait until shift
key is released before showing the failure screen. Either way works.
I thought I would push my patch, but didn't know exactly how the
developers of slock would like it fixed. Or even if they did.
Re: [hackers] [slock][patch] Prevent shift key from toggling to failed state
On Aug 28 10:24, David Phillips wrote:
> On Mon, Aug 27, 2018 at 02:16:38PM -0400, Michael Spradling wrote:
> > Currently if the first character pressed is the shift key, slock moves
> > to the failed state. The failed state can modify the display and
> > provide incorrect feedback to the user and also gives away that your
> > first character required the shift key.
> > ---
> > slock.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/slock.c b/slock.c
> > index 5ae738c..e9dd1ad 100644
> > --- a/slock.c
> > +++ b/slock.c
> > @@ -154,7 +154,9 @@ readpw(Display *dpy, struct xrandr *rr, struct lock
> > **locks, int nscreens,
> > IsKeypadKey(ksym) ||
> > IsMiscFunctionKey(ksym) ||
> > IsPFKey(ksym) ||
> > - IsPrivateKeypadKey(ksym))
> > + IsPrivateKeypadKey(ksym) ||
> > + ksym == XK_Shift_L ||
> > + ksym == XK_Shift_R)
> > continue;
> > switch (ksym) {
> > case XK_Return:
> > --
> > 2.18.0
> >
>
> The patch Michael Buch linked should work for you. For background, I
> created it because previous discussion hereabout 2 years ago showed
> that the community rather keep slock extremely paranoid and ready to
> trip to the failed state at any keypress in order to indicate any
> form of tampering.
>
> The control-clear patch tones that down a bit for those users who
> don't need this fine a trigger.
>
> Thanks,
> David
>
This patch is slightly different than Michael Buch's patch. I am
ignoring the shift key when pressed. I created this patch because a
coworker was able to determine if my password started with an uppercase
or lowercase based off of the feedback of pushing just the single shift
key. This is not a huge security issue, but I thought I would still fix
it.
Thanks,
Michael
Re: [hackers] [slock][patch] Prevent shift key from toggling to failed state
On Tue, Aug 28, 2018 at 10:24:43AM +1200, David Phillips wrote:
> The patch Michael Buch linked should work for you. For background, I
> created it because previous discussion hereabout 2 years ago showed
> that the community rather keep slock extremely paranoid and ready to
> trip to the failed state at any keypress in order to indicate any
> form of tampering.
I wrote a patch (attached) for similar reasons, but instead of
completely ignoring shift, it waits until it's released to change the
screen. The patch won't apply cleanly because it depends on another
patch I wrote, but it's a relatively simple change.
Eric
Title: Improved Modifier Handling
Author: Eric Pruitt (https://www.codevat.com/, https://github.com/ericpruitt/)
With this patch, modifier keys only cause the screen to display the failure
color when they are released without pressing a complementary key.
This patch depends on "slock-00-pam-authentication.diff".
--- a/slock.c
+++ b/slock.c
@@ -226,6 +226,7 @@ readpw(struct xrandr *rr, int nscreens, const char *hash)
unsigned int len, color;
KeySym ksym;
XEvent ev;
+ int seenkeypress = 0;
len = 0;
running = 1;
@@ -233,9 +234,14 @@ readpw(struct xrandr *rr, int nscreens, const char *hash)
* utility. This way the user can easily set a customized DPMS
* timeout. */
while (running && !XNextEvent(dpy, &ev)) {
- if (ev.type == KeyPress) {
+ if (ev.type == KeyPress || ev.type == KeyRelease) {
explicit_bzero(&buf, sizeof(buf));
num = XLookupString(&ev.xkey, buf, sizeof(buf), &ksym, 0);
+ seenkeypress |= ev.type == KeyPress;
+ if ((ev.type == KeyRelease && (num || !seenkeypress)) ||
+(ev.type == KeyPress && !num)) {
+continue;
+ }
if (IsKeypadKey(ksym)) {
if (ksym == XK_KP_Enter)
ksym = XK_Return;
Re: [hackers] [slock][patch] Prevent shift key from toggling to failed state
On Mon, Aug 27, 2018 at 02:16:38PM -0400, Michael Spradling wrote:
> Currently if the first character pressed is the shift key, slock moves
> to the failed state. The failed state can modify the display and
> provide incorrect feedback to the user and also gives away that your
> first character required the shift key.
> ---
> slock.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/slock.c b/slock.c
> index 5ae738c..e9dd1ad 100644
> --- a/slock.c
> +++ b/slock.c
> @@ -154,7 +154,9 @@ readpw(Display *dpy, struct xrandr *rr, struct lock
> **locks, int nscreens,
> IsKeypadKey(ksym) ||
> IsMiscFunctionKey(ksym) ||
> IsPFKey(ksym) ||
> - IsPrivateKeypadKey(ksym))
> + IsPrivateKeypadKey(ksym) ||
> + ksym == XK_Shift_L ||
> + ksym == XK_Shift_R)
> continue;
> switch (ksym) {
> case XK_Return:
> --
> 2.18.0
>
The patch Michael Buch linked should work for you. For background, I
created it because previous discussion hereabout 2 years ago showed
that the community rather keep slock extremely paranoid and ready to
trip to the failed state at any keypress in order to indicate any
form of tampering.
The control-clear patch tones that down a bit for those users who
don't need this fine a trigger.
Thanks,
David
Re: [hackers][sbase][PATCH] Fix build errors on some ARM64 Linux systems
On Mon, Aug 27, 2018 at 09:21:33PM +0200, Hiltjo Posthuma wrote: > On Mon, Aug 27, 2018 at 09:37:24PM +0300, Platon Ryzhikov wrote: > > These changes are required on Arch Linux ARM to build sbase. This does not > > affect x86 build. > > --- > > ls.c | 1 + > > tar.c | 1 + > > 2 files changed, 2 insertions(+) > > > > diff --git a/ls.c b/ls.c > > index b716aba..9e79fcb 100644 > > --- a/ls.c > > +++ b/ls.c > > @@ -1,6 +1,7 @@ > > /* See LICENSE file for copyright and license details. */ > > #include > > #include > > +#include > > > > #include > > #include > > diff --git a/tar.c b/tar.c > > index a6ead2e..9359bfd 100644 > > --- a/tar.c > > +++ b/tar.c > > @@ -1,6 +1,7 @@ > > /* See LICENSE file for copyright and license details. */ > > #include > > #include > > +#include > > > > #include > > #include > > -- > > 2.18.0 > > > > As reported before this is wrong and probably Linux and glibc-specific. > > Also sort the include names. > > -- > Kind regards, > Hiltjo How does my updated patch from Jul 8 on the previous report for this bug look? Thanks, David
Re: [hackers] [slock][patch] Prevent shift key from toggling to failed state
Hey,
Wouldn't follwing patch solve your problem?:
https://tools.suckless.org/slock/patches/control-clear
Regards,
Michael
Am Mo., 27. Aug. 2018 um 20:18 Uhr schrieb Michael Spradling
:
>
> Currently if the first character pressed is the shift key, slock moves
> to the failed state. The failed state can modify the display and
> provide incorrect feedback to the user and also gives away that your
> first character required the shift key.
> ---
> slock.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/slock.c b/slock.c
> index 5ae738c..e9dd1ad 100644
> --- a/slock.c
> +++ b/slock.c
> @@ -154,7 +154,9 @@ readpw(Display *dpy, struct xrandr *rr, struct lock
> **locks, int nscreens,
> IsKeypadKey(ksym) ||
> IsMiscFunctionKey(ksym) ||
> IsPFKey(ksym) ||
> - IsPrivateKeypadKey(ksym))
> + IsPrivateKeypadKey(ksym) ||
> + ksym == XK_Shift_L ||
> + ksym == XK_Shift_R)
> continue;
> switch (ksym) {
> case XK_Return:
> --
> 2.18.0
>
>
Re: [hackers][sbase][PATCH] Fix build errors on some ARM64 Linux systems
On Mon, Aug 27, 2018 at 09:37:24PM +0300, Platon Ryzhikov wrote: > These changes are required on Arch Linux ARM to build sbase. This does not > affect x86 build. > --- > ls.c | 1 + > tar.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/ls.c b/ls.c > index b716aba..9e79fcb 100644 > --- a/ls.c > +++ b/ls.c > @@ -1,6 +1,7 @@ > /* See LICENSE file for copyright and license details. */ > #include > #include > +#include > > #include > #include > diff --git a/tar.c b/tar.c > index a6ead2e..9359bfd 100644 > --- a/tar.c > +++ b/tar.c > @@ -1,6 +1,7 @@ > /* See LICENSE file for copyright and license details. */ > #include > #include > +#include > > #include > #include > -- > 2.18.0 > As reported before this is wrong and probably Linux and glibc-specific. Also sort the include names. -- Kind regards, Hiltjo
[hackers][ubase][PATCH] Fix build errors on some ARM64 Linux systems
These changes are required on Arch Linux ARM to build ubase. This does not affect x86 build. --- libutil/tty.c | 1 + mknod.c | 1 + mountpoint.c | 1 + stat.c| 3 ++- 4 files changed, 5 insertions(+), 1 deletion(-) diff --git a/libutil/tty.c b/libutil/tty.c index bceb01e..8a2cd73 100644 --- a/libutil/tty.c +++ b/libutil/tty.c @@ -1,6 +1,7 @@ /* See LICENSE file for copyright and license details. */ #include #include +#include #include #include diff --git a/mknod.c b/mknod.c index 8de35c7..27f91e0 100644 --- a/mknod.c +++ b/mknod.c @@ -1,6 +1,7 @@ /* See LICENSE file for copyright and license details. */ #include #include +#include #include #include diff --git a/mountpoint.c b/mountpoint.c index 8f205a2..fd3a133 100644 --- a/mountpoint.c +++ b/mountpoint.c @@ -1,6 +1,7 @@ /* See LICENSE file for copyright and license details. */ #include #include +#include #include #include diff --git a/stat.c b/stat.c index 220a659..3f91566 100644 --- a/stat.c +++ b/stat.c @@ -1,6 +1,7 @@ /* See LICENSE file for copyright and license details. */ #include #include +#include #include #include @@ -86,4 +87,4 @@ main(int argc, char *argv[]) } return ret; -} \ No newline at end of file +} -- 2.18.0
[hackers][sbase][PATCH] Fix build errors on some ARM64 Linux systems
These changes are required on Arch Linux ARM to build sbase. This does not affect x86 build. --- ls.c | 1 + tar.c | 1 + 2 files changed, 2 insertions(+) diff --git a/ls.c b/ls.c index b716aba..9e79fcb 100644 --- a/ls.c +++ b/ls.c @@ -1,6 +1,7 @@ /* See LICENSE file for copyright and license details. */ #include #include +#include #include #include diff --git a/tar.c b/tar.c index a6ead2e..9359bfd 100644 --- a/tar.c +++ b/tar.c @@ -1,6 +1,7 @@ /* See LICENSE file for copyright and license details. */ #include #include +#include #include #include -- 2.18.0
[hackers] [slock][patch] Prevent shift key from toggling to failed state
Currently if the first character pressed is the shift key, slock moves
to the failed state. The failed state can modify the display and
provide incorrect feedback to the user and also gives away that your
first character required the shift key.
---
slock.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/slock.c b/slock.c
index 5ae738c..e9dd1ad 100644
--- a/slock.c
+++ b/slock.c
@@ -154,7 +154,9 @@ readpw(Display *dpy, struct xrandr *rr, struct lock
**locks, int nscreens,
IsKeypadKey(ksym) ||
IsMiscFunctionKey(ksym) ||
IsPFKey(ksym) ||
- IsPrivateKeypadKey(ksym))
+ IsPrivateKeypadKey(ksym) ||
+ ksym == XK_Shift_L ||
+ ksym == XK_Shift_R)
continue;
switch (ksym) {
case XK_Return:
--
2.18.0
