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
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
conf
#!/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 sha1su
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 th
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 s
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 c
> 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.
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 interf
Martin Kühne wrote:
> 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
> }
Heyho Martin,
thats basically the
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
you agree it's at least one step i see
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
i.e. throw out all this platform dependent bullshit password checking
code and replace it with simple string comparison (string from text
file).
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
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 t
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
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
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
s2r
> 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.
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
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 ve
- 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,
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 resolu
23 matches
Mail list logo
