Re: [dev] [ANNOUNCE] slock-1.3

[hiro]

yes, even though i disagree with the abolition of files (in this case
just as a matter of convention over need), it's at least simpler than
the current mess. would serve my use case all right.

On 2/15/16, Anselm R Garbe  wrote:
> On 15 February 2016 at 11:13, Kamil Cholewiński 
> wrote:
>>> slock < password-file
>>
>> You now have a password in cleartext, which we know is a bad idea. It
>> would be better to hash it. Congrats, /etc/passwd & friends reinvented.
>
> Just adopt hmac_sha256[1] into slock.c and put your pw hash into
> config.h and deploy slock into your $HOME/bin if the system is shared,
> or do it globally if not.
>
> I don't see the need to rely on file or pipe access to read a password
> hash from.
>
> [1] http://www.aarongifford.com/computers/sha.html
>
> BR,
> Anselm
>
>

Re: [dev] [ANNOUNCE] slock-1.3

[Anselm R Garbe]

On 15 February 2016 at 11:13, Kamil Cholewiński  wrote:
>> slock < password-file
>
> You now have a password in cleartext, which we know is a bad idea. It
> would be better to hash it. Congrats, /etc/passwd & friends reinvented.

Just adopt hmac_sha256[1] into slock.c and put your pw hash into
config.h and deploy slock into your $HOME/bin if the system is shared,
or do it globally if not.

I don't see the need to rely on file or pipe access to read a password
hash from.

[1] http://www.aarongifford.com/computers/sha.html

BR,
Anselm

Re: [dev] [ANNOUNCE] slock-1.3

[hiro]

#!/bin/sh
capture-all-keyboard-shit-and-show-stupid-rainbows |
while read line
do
 if [ "$line" = `cat pass` ]
 then
   killall capture-all-keyboard-shit-and-show-stupid-rainbows
 else
   mpg123 fart.mp3
 fi
done

Tried to fit passwd hashing in there, but it would need something that
ensures sha1sum gets eof after one line and echo passwd | sha1sum is
insecure. Easier in C.

I personally don't need this password to be hashed. It's more
important to have multiple passwords for different escalations than to
have hashing. Chmod 700 is enough for my purposes.

On 2/15/16, Kamil Cholewiński  wrote:
>> slock < password-file
>
> You now have a password in cleartext, which we know is a bad idea. It
> would be better to hash it. Congrats, /etc/passwd & friends reinvented.
>

Re: [dev] [ANNOUNCE] slock-1.3

[Dimitris Papastamos]

On Mon, Feb 15, 2016 at 11:40:07AM +0100, FRIGN wrote:
> On Mon, 15 Feb 2016 10:55:45 +0100
> Markus Teich  wrote:
> 
> Hey Markus,
> 
> > This is an interesting idea. I would not use it for mainline (users don't 
> > want
> > to change their password in many places), but you can push a patch to the 
> > wiki.
> 
> Dimitris talked about a "third" way to handle passwords on a system, and we
> discussed plans on porting ubase to this new "platform", however, I forgot
> how it was called.
> It could be a way to simplify the slock code though, from what I remember.

http://www.openwall.com/tcb/

this is however outside the control of slock, there is no porting that
needs to be done for ubase to take advantage of this.

this is a system issue, assuming the system is configured to use tcb
and the libc supports it then all programs get it for free.

Re: [dev] [ANNOUNCE] slock-1.3

[FRIGN]

On Mon, 15 Feb 2016 10:55:45 +0100
Markus Teich  wrote:

Hey Markus,

> This is an interesting idea. I would not use it for mainline (users don't want
> to change their password in many places), but you can push a patch to the 
> wiki.

Dimitris talked about a "third" way to handle passwords on a system, and we
discussed plans on porting ubase to this new "platform", however, I forgot
how it was called.
It could be a way to simplify the slock code though, from what I remember.

Cheers

FRIGN

-- 
FRIGN 

Re: [dev] [ANNOUNCE] slock-1.3

[Martti Kühne]

On Mon, Feb 15, 2016 at 10:55 AM, Markus Teich
 wrote:
>> slock < password-file
>
> This is an interesting idea. I would not use it for mainline (users don't want
> to change their password in many places), but you can push a patch to the 
> wiki.
>


Essentially, password hashing is a thing that could be done through
another tool, maybe on fd 3?

I'd be interested whether hiro would also work with different fds for
optimal separation of conerns instead of the current solution. We
could split it up into several rather generally useful binaries.

cheers!
mar77i

Re: [dev] [ANNOUNCE] slock-1.3

[Kamil Cholewiński]

> slock < password-file

You now have a password in cleartext, which we know is a bad idea. It
would be better to hash it. Congrats, /etc/passwd & friends reinvented.

Re: [dev] [ANNOUNCE] slock-1.3

[Markus Teich]

hiro wrote:
> Anyway, it would be more useful to concentrate on the password checking part,
> it segfaults commonly (which is fucking ridiculous!!) because ldap, linux,
> etc. suck.

Heyho hiro,

Same argument as for surf applies here: If you can't fix the suckyness, you have
to build a nice interface for it. If you would not abuse this segfault, I'd
recommend you debug it and send in a patch to fix it, but I have access to a
sucky LDAP setup as well, so I might be able to reproduce it myself…

> I suggest this very platform-independent alternative interface (you can remove
> special-casing for linux,bsd and such bullshit):
> 
> slock < password-file

This is an interesting idea. I would not use it for mainline (users don't want
to change their password in many places), but you can push a patch to the wiki.

--Markus

Re: [dev] [ANNOUNCE] slock-1.3

[Ben Woolley]

Did somebody say Kickstarter?

Sent from my iPhone

> On Feb 14, 2016, at 12:59 PM, v4hn  wrote:
> 
> get yourself a wooden box and lock your
> workstation in in when you leave the room

Re: [dev] [ANNOUNCE] slock-1.3

[hiro]

you agree it's at least one step i see

Re: [dev] [ANNOUNCE] slock-1.3

[v4hn]

On Sun, Feb 14, 2016 at 12:19:37AM +0100, hiro wrote:
> i.e. throw out all this platform dependent bullshit password checking code

This would still leave us with the platform dependent bullshit for screen 
locking.
Here's a refined proposal: lock your goddamn office instead of your screen,
or, in case you share your office: get yourself a wooden box and lock your
workstation in in when you leave the room.


v4hn


signature.asc
Description: PGP signature

Re: [dev] [ANNOUNCE] slock-1.3

[Markus Teich]

hiro wrote:
> How does your integrated execution of s2ram change that?  Your slock can still
> fail in just the same way.

Heyho hiro,

with the patch first the cover window is created and the keyboard and mouse are
grabbed. I consider this setup. If it fails, slock exits and does *not* execute
s2ram. If it succeeded, s2ram is executed and the loop handling user input is
entered. Of course there could be a crash inside that loop, but we cannot know
that in advance and we also cannot fork-exec s2ram at any later stage.

The most common case for slock failing was that the grabbing of input devices
failed when some other application still had a grab active. This failure is
fixed by the patch.

--Markus

Re: [dev] [ANNOUNCE] slock-1.3

[Martin Kühne]

stdout could print an api secret "[locked]" and the calling script could act 
upon that.

slock | {
  read
  if [[ "$REPLY" = "[locked]" ]]; then
    suspend
  else
    yell at user or power off for added security
  fi
}

cheers!
mar77i

Re: [dev] [ANNOUNCE] slock-1.3

[hiro]

Oh god no.

You guys must have some strange use cases.

When I run slock there's no way for me to miss whether it ran or not
(It is pretty visible all over my screen). So I have like 1 second to
notice this before my display shuts off for standby. In the unlikely
event of catastrophic X-Bullshit I can just wake up my computer or
throw it out the window and by this clear the RAM before the police
arrives.

Anyway, it would be more useful to concentrate on the password
checking part, it segfaults commonly (which is fucking ridiculous!!)
because ldap, linux, etc. suck.

As I'm lazy I've developed a habit of using this to my advantage. When
I get into my office I just press enter, every second time the network
is broken (because of networkmanager) and slock segfaults while trying
to check the password via ldap, thus i save a lot of time I'd
otherwise waste typing my super-secure password.

I would even do without *any* password, but it's company policy to screenlock.

I suggest this very platform-independent alternative interface (you
can remove special-casing for linux,bsd and such bullshit):

slock < password-file

Re: [dev] [ANNOUNCE] slock-1.3

[Carlos Torres]

you can already use xssstate to monitor the state of the screen and
the screensaver, why not use that to do both slock, and eventually
sleep?

--Carlos

On Sat, Feb 13, 2016 at 3:57 PM, hiro <23h...@gmail.com> wrote:
> Oh god no.
>
> You guys must have some strange use cases.
>
> When I run slock there's no way for me to miss whether it ran or not
> (It is pretty visible all over my screen). So I have like 1 second to
> notice this before my display shuts off for standby. In the unlikely
> event of catastrophic X-Bullshit I can just wake up my computer or
> throw it out the window and by this clear the RAM before the police
> arrives.
>
> Anyway, it would be more useful to concentrate on the password
> checking part, it segfaults commonly (which is fucking ridiculous!!)
> because ldap, linux, etc. suck.
>
> As I'm lazy I've developed a habit of using this to my advantage. When
> I get into my office I just press enter, every second time the network
> is broken (because of networkmanager) and slock segfaults while trying
> to check the password via ldap, thus i save a lot of time I'd
> otherwise waste typing my super-secure password.
>
> I would even do without *any* password, but it's company policy to screenlock.
>
> I suggest this very platform-independent alternative interface (you
> can remove special-casing for linux,bsd and such bullshit):
>
> slock < password-file
>

Re: [dev] [ANNOUNCE] slock-1.3

[FRIGN]

On Sat, 13 Feb 2016 21:57:14 +0100
hiro <23h...@gmail.com> wrote:

Hey hiro,

> When I run slock there's no way for me to miss whether it ran or not
> (It is pretty visible all over my screen). So I have like 1 second to
> notice this before my display shuts off for standby. In the unlikely
> event of catastrophic X-Bullshit I can just wake up my computer or
> throw it out the window and by this clear the RAM before the police
> arrives.

If not for the help of slock, I would be getting 15 years to life for
all the illegal stuff I have on my computer.
Thanks to the slock-safety, the police has _nothing_! *evil_laugh* /s

> Anyway, it would be more useful to concentrate on the password
> checking part, it segfaults commonly (which is fucking ridiculous!!)
> because ldap, linux, etc. suck.

Can you elaborate on that a bit more? :) If you desire more error-checking,
I could put it on my TODO.

Cheers

FRIGN

-- 
FRIGN 

Re: [dev] [ANNOUNCE] slock-1.3

[hiro]

i.e. throw out all this platform dependent bullshit password checking
code and replace it with simple string comparison (string from text
file).

[dev] [ANNOUNCE] slock-1.3

[Markus Teich]

Heyho,

I am happy to announce the release of slock version 1.3. slock is a simple X
display locker.

You can download it at: http://dl.suckless.org/tools/slock-1.3.tar.gz

The changes since version 1.2 are:
- bugfix: The cover window now resizes correctly when new screens are added or
  the resolution is changed while the lock is active.
- new: slock now has a third color. The three colors are used for startup,
  typing and failed login attempt.
- new: slock now allows to run any command after the screen has been locked, for
  example suspending to ram.
- slock now has a man page.
- a few small fixes and code style updates to make it more consistent with the
  rest of the suckless projects.

--Markus

Re: [dev] [ANNOUNCE] slock-1.3

[Markus Teich]

hiro wrote:
>  - new: slock now allows to run any command after the screen has been
> locked, for
>example suspending to ram.
> 
> how come you can't just run slock from a shell script instead?

Heyho hiro,

you don't know when the screen is locked, since slock does not fork itself. If
you want to run `echo` after the screen is unlocked, you can just do `slock;
echo`, and if you want to run it before the screen gets locked the other way
around. But there was no possibility to run something after the screen got
locked and while it is still locked. The s2ram example from the man page is a
good one:

If you run it beforehand, then the screen is at least visible for a moment after
resuming from sleep and in the worst case slock fails to start correctly and you
don't know that in advance. Running s2ram afterwards is obviously a stupid idea
as well and using a backgrounded `sleep 5; s2ram` before starting slock also is
kind of stupid if slock fails to start up correctly.

If you have a better solution, let me know, I would be happy to reduce code
complexity again by reverting that commit.

--Markus

Re: [dev] [ANNOUNCE] slock-1.3

[hiro]

> as well and using a backgrounded `sleep 5; s2ram` before starting slock also
> is
> kind of stupid if slock fails to start up correctly.

How does your integrated execution of s2ram change that?
Your slock can still fail in just the same way.

Re: [dev] [ANNOUNCE] slock-1.3

[hiro]

 - new: slock now allows to run any command after the screen has been
locked, for
   example suspending to ram.

how come you can't just run slock from a shell script instead?

Re: [dev] [ANNOUNCE] slock-1.3

[Eric Pruitt]

On Sat, Feb 13, 2016 at 12:54:26AM +0100, hiro wrote:
> how come you can't just run slock from a shell script instead?

I haven't looked at the code, but if I had to guess, it's probably
because of race conditions. If you ran the program in a shell script,
you'd have to query some X11 program to verify the screen was locked or
do something like "sleep" and hope the screen is actually locked. With
the functionality inside slock itself, you don't need to worry about
these things.

Eric