Discussion:
[PATCH] add keyscript support to cryptsetup
(too old to reply)
David Härdeman
2012-06-28 22:56:04 UTC
Permalink
Debian's cryptsetup package supports the keyscript= option in /etc/crypttab

This patch is a first attempt at implementing support for the same option
in systemd. It is not at exact feature parity yet (environment variables
are missing and relative paths are not supported), but it's a start.

I'm not sure if the (somewhat complicated dance) with fds is considered
acceptable or if I should use something else?
---
src/cryptsetup/cryptsetup.c | 133 ++++++++++++++++++++++++++++++++++++++-----
1 file changed, 119 insertions(+), 14 deletions(-)

diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index b26fcca..3547a38 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -19,6 +19,11 @@
along with systemd; If not, see <http://www.gnu.org/licenses/>.
***/

+#include <unistd.h>
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <sys/stat.h>
+#include <fcntl.h>
#include <string.h>
#include <errno.h>
#include <sys/mman.h>
@@ -42,6 +47,7 @@ static unsigned opt_tries = 0;
static bool opt_readonly = false;
static bool opt_verify = false;
static bool opt_discards = false;
+static char *opt_keyscript = NULL;
static usec_t opt_timeout = DEFAULT_TIMEOUT_USEC;

/* Options Debian's crypttab knows we don't:
@@ -53,9 +59,86 @@ static usec_t opt_timeout = DEFAULT_TIMEOUT_USEC;
checkargs=
noearly=
loud=
- keyscript=
*/

+#define PIPE_READ 0
+#define PIPE_WRITE 1
+
+static int crypt_activate_by_keyscript(struct crypt_device *cd, const char *name,
+ const char *keyscript, const char *key_file,
+ size_t keyfile_size, uint32_t flags)
+{
+ int pipefd[2];
+ int k;
+ pid_t pid;
+
+ if (pipe(pipefd)) {
+ log_error("Failed to call pipe: %m");
+ return -errno;
+ }
+
+ /* exec the keyscript and temporarily set its stdout as stdin */
+ pid = fork();
+ if (pid < 0) {
+ k = -errno;
+ log_error("Failed to fork: %m");
+ close(pipefd[PIPE_READ]);
+ close(pipefd[PIPE_WRITE]);
+ return k;
+
+ } else if (pid > 0) {
+ int tmpfd;
+
+ close(pipefd[PIPE_WRITE]);
+ tmpfd = dup(STDIN_FILENO);
+ if (tmpfd < 0) {
+ k = -errno;
+ close(pipefd[PIPE_READ]);
+ waitpid(pid, NULL, 0);
+ return k;
+ }
+
+ if (dup2(pipefd[PIPE_READ], STDIN_FILENO) < 0) {
+ k = -errno;
+ close(pipefd[PIPE_READ]);
+ waitpid(pid, NULL, 0);
+ return k;
+ }
+
+ close(pipefd[PIPE_READ]);
+
+ k = crypt_activate_by_keyfile(cd, name, CRYPT_ANY_SLOT, "-", keyfile_size, flags);
+
+ waitpid(pid, NULL, 0);
+
+ dup2(tmpfd, STDIN_FILENO);
+ close(tmpfd);
+
+ } else if (pid == 0) {
+ const char *args[3];
+
+ close(pipefd[PIPE_READ]);
+ if (dup2(pipefd[PIPE_WRITE], STDOUT_FILENO) < 0)
+ _exit(EXIT_FAILURE);
+ close(pipefd[PIPE_WRITE]);
+
+ close(STDIN_FILENO);
+ if (open("/dev/null", O_RDWR) < 0)
+ _exit(EXIT_FAILURE);
+ if (dup2(STDIN_FILENO, STDERR_FILENO) < 0)
+ _exit(EXIT_FAILURE);
+
+ args[0] = keyscript;
+ args[1] = key_file;
+ args[2] = NULL;
+
+ execv(args[0], (char **)args);
+ _exit(EXIT_FAILURE);
+ }
+
+ return k;
+}
+
static int parse_one_option(const char *option) {
assert(option);

@@ -88,6 +171,22 @@ static int parse_one_option(const char *option) {
free(opt_hash);
opt_hash = t;

+ } else if (startswith(option, "keyscript=")) {
+ char *t;
+
+ if (!option[10] || !path_is_absolute(option+10)) {
+ log_error("keyscript= path is invalid, ignoring.");
+ free(opt_keyscript);
+ opt_keyscript = NULL;
+ return 0;
+ }
+
+ if (!(t = strdup(option+10)))
+ return -ENOMEM;
+
+ free(opt_keyscript);
+ opt_keyscript = t;
+
} else if (startswith(option, "tries=")) {

if (safe_atou(option+6, &opt_tries) < 0) {
@@ -263,20 +362,23 @@ int main(int argc, char *argv[]) {
goto finish;
}

- if (argc >= 5 &&
- argv[4][0] &&
- !streq(argv[4], "-") &&
- !streq(argv[4], "none")) {
-
- if (!path_is_absolute(argv[4]))
- log_error("Password file path %s is not absolute. Ignoring.", argv[4]);
- else
- key_file = argv[4];
- }
-
+ /* Options are parsed first as they can influence later parsing */
if (argc >= 6 && argv[5][0] && !streq(argv[5], "-"))
parse_options(argv[5]);

+ if (argc >= 5) {
+ if (opt_keyscript)
+ key_file = argv[4]; /* used as arg to keyscript */
+ else if (argv[4][0] &&
+ !streq(argv[4], "-") &&
+ !streq(argv[4], "none"))
+ /* do nothing */;
+ else if (!path_is_absolute(argv[4]))
+ log_error("Password file path %s is not absolute. Ignoring.", argv[4]);
+ else
+ key_file = argv[4];
+ }
+
/* A delicious drop of snake oil */
mlockall(MCL_FUTURE);

@@ -461,8 +563,10 @@ int main(int argc, char *argv[]) {
crypt_get_volume_key_size(cd)*8,
argv[3]);

- if (key_file)
- k = crypt_activate_by_keyfile(cd, argv[2], CRYPT_ANY_SLOT, key_file, keyfile_size, flags);
+ if (opt_keyscript)
+ k = crypt_activate_by_keyscript(cd, argv[2], opt_keyscript, key_file, keyfile_size, flags);
+ else if (key_file)
+ k = crypt_activate_by_keyfile(cd, argv[2], CRYPT_ANY_SLOT, key_file, keyfile_size, flags);
else {
char **p;

@@ -522,6 +626,7 @@ finish:
if (cd)
crypt_free(cd);

+ free(opt_keyscript);
free(opt_cipher);
free(opt_hash);
Lennart Poettering
2012-07-09 20:49:56 UTC
Permalink
Post by David Härdeman
Debian's cryptsetup package supports the keyscript= option in /etc/crypttab
This patch is a first attempt at implementing support for the same option
in systemd. It is not at exact feature parity yet (environment variables
are missing and relative paths are not supported), but it's a start.
I'm not sure if the (somewhat complicated dance) with fds is considered
acceptable or if I should use something else?
Humpf. So I am really not convinced that supporting this is really such
a good idea. I am not a fan at all of this scriptlogic. (Starting with
the fact that this is called keyscript=, i.e. as if this really needs to
be a script...).

I wonder what the precise usecases for this are, and whether we can't
find better solutions for these usecases... I mean, we already have the
password agent logic, that is asynchronous, and way more powerful:

http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents

Lennart
--
Lennart Poettering - Red Hat, Inc.
Tollef Fog Heen
2012-07-09 21:14:19 UTC
Permalink
]] Lennart Poettering
Post by Lennart Poettering
I wonder what the precise usecases for this are, and whether we can't
find better solutions for these usecases... I mean, we already have the
It's also much harder to write something for.

A use case for keyscript is something like
https://github.com/tfheen/ykfde/blob/master/helper which (while not
really a keyscript as it is) implements integration with Yubikeys. Doing
that with the full password agent proposal is much, much harder and
doesn't really gain us anything in this case.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Lennart Poettering
2012-07-09 21:56:51 UTC
Permalink
Post by Tollef Fog Heen
]] Lennart Poettering
Post by Lennart Poettering
I wonder what the precise usecases for this are, and whether we can't
find better solutions for these usecases... I mean, we already have the
It's also much harder to write something for.
A use case for keyscript is something like
https://github.com/tfheen/ykfde/blob/master/helper which (while not
really a keyscript as it is) implements integration with Yubikeys. Doing
that with the full password agent proposal is much, much harder and
doesn't really gain us anything in this case.
Well, but this script is very racy as it expects yubikeys to be
instantly available at boot. This really needs to be async and watch
both for yubikeys as they are plugged in and for new passwords as they
are queired. Also this script expects an interactive console, which is
extra racy...

I am fully aware that writing proper agents is harder than scripting things,
but it is also, well, much more correct.

Given that I actually own a yubikey (which i don't use), I am actually
tempted to fix this properly. Would be really cool to use that for LUKS
decryption.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Tollef Fog Heen
2012-07-10 05:36:17 UTC
Permalink
]] Lennart Poettering
Post by Lennart Poettering
Post by Tollef Fog Heen
]] Lennart Poettering
Post by Lennart Poettering
I wonder what the precise usecases for this are, and whether we can't
find better solutions for these usecases... I mean, we already have the
It's also much harder to write something for.
A use case for keyscript is something like
https://github.com/tfheen/ykfde/blob/master/helper which (while not
really a keyscript as it is) implements integration with Yubikeys. Doing
that with the full password agent proposal is much, much harder and
doesn't really gain us anything in this case.
Well, but this script is very racy as it expects yubikeys to be
instantly available at boot. This really needs to be async and watch
both for yubikeys as they are plugged in and for new passwords as they
are queired. Also this script expects an interactive console, which is
extra racy...
It's run in the initramfs, so no, it's not racy at all.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Lennart Poettering
2012-07-10 08:56:34 UTC
Permalink
Post by Tollef Fog Heen
Post by Lennart Poettering
Post by Tollef Fog Heen
A use case for keyscript is something like
https://github.com/tfheen/ykfde/blob/master/helper which (while not
really a keyscript as it is) implements integration with Yubikeys. Doing
that with the full password agent proposal is much, much harder and
doesn't really gain us anything in this case.
Well, but this script is very racy as it expects yubikeys to be
instantly available at boot. This really needs to be async and watch
both for yubikeys as they are plugged in and for new passwords as they
are queired. Also this script expects an interactive console, which is
extra racy...
It's run in the initramfs, so no, it's not racy at all.
That has little to do with where it is run. The simple fact is that
there is no time limit in which USB hw has to be appeared, as kernel
driver probing is entirely asynchronous these days and the USB devices
can take any time they want to initialize.

In older versions of Linux people placed "udevadm settle" and
"/sbin/rmmod scsi_wait_scan ; /sbin/modprobe scsi_wait_scan ;
/sbin/rmmod scsi_wait_scan" in everywhere in an attempt to introduce
some point where all storage hw was probed. But that never worked for
USB hw anyway, slows down the boot immensly, and is also terribly
ugly. One of the big steps forward in systemd is actually that we
cleaned all this up, and devices are now used as they appear and we only
delay boot exactly as long as we need to find the devices we need, but
don't attempt to wait till the point in time "where all devices" have
shown up.

It doesn't work at all for yubikeys.

So what you do is racy, sorry.

Lennart
--
Lennart Poettering - Red Hat, Inc.
David Härdeman
2012-07-10 08:35:51 UTC
Permalink
Post by Lennart Poettering
Post by David Härdeman
Debian's cryptsetup package supports the keyscript= option in /etc/crypttab
This patch is a first attempt at implementing support for the same option
in systemd. It is not at exact feature parity yet (environment variables
are missing and relative paths are not supported), but it's a start.
I'm not sure if the (somewhat complicated dance) with fds is considered
acceptable or if I should use something else?
Humpf. So I am really not convinced that supporting this is really such
a good idea. I am not a fan at all of this scriptlogic. (Starting with
the fact that this is called keyscript=, i.e. as if this really needs to
be a script...).
The name of the option (keyscript) doesn't mean that it needs to be e.g.
a bash script, it could be any executable.
Post by Lennart Poettering
I wonder what the precise usecases for this are, and whether we can't
find better solutions for these usecases...
I originally implemented the keyscript= support in Debian, and the way I
see it there are two different usecases depending on your point of view.

As a package maintainer, or in this case systemd maintainer, the
keyscript= functionality was a good way of keeping bloat out of the
cryptsetup scripts (granted, some would probably say that the cryptsetup
scripts in Debian are already bloated, but without this functionality
they would be even more so).

Whenever a user comes up with another scheme for storing keys (you've
already seen some...like storing keys between the MBR and first
partition using the keyfile-offset= parameter), it is possible to ask
them to use a keyscript= instead of extending the cryptsetup logic.
Lennart Poettering
2012-07-10 14:25:50 UTC
Permalink
Post by David Härdeman
Post by Lennart Poettering
I wonder what the precise usecases for this are, and whether we can't
find better solutions for these usecases...
I originally implemented the keyscript= support in Debian, and the way I
see it there are two different usecases depending on your point of view.
As a package maintainer, or in this case systemd maintainer, the
keyscript= functionality was a good way of keeping bloat out of the
cryptsetup scripts (granted, some would probably say that the cryptsetup
scripts in Debian are already bloated, but without this functionality
they would be even more so).
Well, but for that we already have the agent logic...
Post by David Härdeman
Whenever a user comes up with another scheme for storing keys (you've
already seen some...like storing keys between the MBR and first
partition using the keyfile-offset= parameter), it is possible to ask
them to use a keyscript= instead of extending the cryptsetup logic.
Well, but if this is all dependent on some other hw then the synchronous
nature of keyscript= doesn't work anyway... (see other mail about that)
Frederic Crozat
2012-07-10 15:07:26 UTC
Permalink
3) systemd specific solution
Converting keyscript= scripts to password agents introduce a strong
dependency on systemd. I realize that you don't consider it to be a
problem but I'm guessing it wouldn't be acceptable to Debian (where
systemd is not mandatory).
Well, it's currently a Debian-init scripts specific solution...
I have similar request from keyscript users (coming from Debian) in
SUSE ;)
--
Frederic Crozat <***@suse.com>
SUSE
Lennart Poettering
2012-07-10 15:48:13 UTC
Permalink
Post by Frederic Crozat
3) systemd specific solution
Converting keyscript= scripts to password agents introduce a strong
dependency on systemd. I realize that you don't consider it to be a
problem but I'm guessing it wouldn't be acceptable to Debian (where
systemd is not mandatory).
Well, it's currently a Debian-init scripts specific solution...
I have similar request from keyscript users (coming from Debian) in
SUSE ;)
Then my strong suggestion would be to hack up an agent that implements a
keyscript compatible iface. This would be much nicer in many ways, for
example, because you could then cleanly depend on udev-settle.service
and the scsi wait scan modprobing madness from the agent service.

Lennart
--
Lennart Poettering - Red Hat, Inc.
David Härdeman
2012-07-11 07:29:55 UTC
Permalink
On Tue, 10 Jul 2012 16:25:50 +0200, Lennart Poettering
Post by Lennart Poettering
Post by David Härdeman
Whenever a user comes up with another scheme for storing keys (you've
already seen some...like storing keys between the MBR and first
partition using the keyfile-offset= parameter), it is possible to ask
them to use a keyscript= instead of extending the cryptsetup logic.
Well, but if this is all dependent on some other hw then the synchronous
nature of keyscript= doesn't work anyway... (see other mail about that)
I think you're making a much bigger issue out of the "synchronous nature"
than warranted.

In the current systemd solution, the systemd-native cryptsetup binary will
request a password using a /run/systemd/ask-password/ask.foobar file, then
wait until it gets one or more answers back via a socket. If some password
agent used e.g. a USB smartcard reader, it would naturally wait (exactly
how it waits is not that important) until said reader is available before
it could theoretically provide said answer. If the partition is necessary
for booting the system, the boot will wait until the key is provided and
the partition is mounted.

In the Debian cryptsetup init scripts, the keyscript will be executed and
the cryptsetup binary will wait until it gets an answer back.

Having keyscripts check and wait for certain /dev files to be present is
not much of an issue and it makes very little difference in the
"asynchronous" nature of the solution. The scsi_wait module and/or commands
like udevadm settle, etc, are not strictly necessary in a keyscript.

So, neither solution is, as far as I can tell, more "asynchronous".
Post by Lennart Poettering
Both yubikeys and most smartcard readers are USB devices, so you always
have the enumeration issues, which means a synchronous solution wouldn't
work wihtout races anyway and the async agent stuff is much preferable.
See above.
Post by Lennart Poettering
Post by David Härdeman
Post by Lennart Poettering
http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents
I also dislike additional complexity and realize that systemd is an
excellent oppurtinity of providing some much needed spring cleaning in
distribution-specific boot scripts - but there are a few problems with
Well, the complexity comes for a reason: correctness.
I think you misunderstood me. I wasn't referring to systemd password
agents when I said "complexity", I was referring to the legacy features
such as "keyscript=".
Post by Lennart Poettering
Post by David Härdeman
1) Backwards compatibility
"keyscript" has been supported by the Debian cryptsetup package for a
long time and people already have keyscripts. Some of these are used
for
Post by Lennart Poettering
Post by David Härdeman
boot-critical partitions. Just telling everyone to rewrite whatever
they
Post by Lennart Poettering
Post by David Härdeman
have as passwordagents is unlikely to be accepted.
We do take the liberty to break compatibility in some cases, where we
believe the previous choice was broken or where we have really good
reasons to. We do document them though (for example
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities) so
maybe that's one of those things where we should break the compat and
document it?
That's fine by me. I understand that systemd has some ambitious goals wrt.
cruft removal and distribution consolidation, both of which I applaud. As
long a some other scheme is in place which allows similar functionality.
Post by Lennart Poettering
Note that if compat is really that important it should be possible to
write an agent that can invoke keyscripts like this. If you did that you
would gain, among other things the ability to query for passwords at the
same time via different methods. With a bit of C code it should be
fairly easy to hack up an agent that just invokes a keyscript.
The biggest question in my mind right now is how the "keyscript" password
agent should be implemented and how it should interact with the other
agents.

Imagine the scenario where crypsetup wants to set up a partition using a
binary key from a smartcard, which in turn requires a PIN to be entered:

1) Following the current logic, the systemd cryptsetup binary would ask
for the key to the partition using /run/systemd/ask-password/ask.foo. (That
file could potentially be extended to add something like an "Options="
field where we could provide additional information about the password
request to the agents).

2a) The "keyscript" agent would read the ask.foo file and determine that
it can provide the requested key from a smartcard (I assume this knowledge
comes from some config file)

2b) At the same time, the other agents provide normal password input
prompt(s) to the user (e.g. on the tty)...which are pointless since a
binary key is expected.

3) Soon afterwards, the "keyscript" agent in turn uses
/run/systemd/ask-password/ask.bar to request the PIN for the smartcard.

4) The user would be confronted with two passphrase prompts. One
(pointless) one to provide a binary key using the keyboard, and one (real)
prompt for the PIN to the smartcard.

I'm not sure what kind of changes to the password agent scheme you're
envisioning to accommodate a scheme like this?
Post by Lennart Poettering
Post by David Härdeman
2) PasswordAgents can't handle binary strings
keyscripts typically generate the key for the device and pass it to
stdout. PasswordAgents can't handle binary strings which contain NUL
characters (for example).
Well, the proto would actually allow binary passphrases. We could
relatively easily fix this if people really have a need for this.
I've already provided an example where there is a need: smartcards - they
usually provide the key blob (after the correct PIN has been entered) and
not some passphrase which needs to be further hashed, etc. The same goes
for any keyscript solution which fetches a key (from somewhere, anywhere)
rather than a passphrase.

But yes, the password agent protocol could be extended to support binary
passphrases (right now, a leading '+' or '-' is expected, a binary
passphrase would just have to have a different leading character).
Post by Lennart Poettering
Post by David Härdeman
3) systemd specific solution
Converting keyscript= scripts to password agents introduce a strong
dependency on systemd. I realize that you don't consider it to be a
problem but I'm guessing it wouldn't be acceptable to Debian (where
systemd is not mandatory).
Well, it's currently a Debian-init scripts specific solution...
Yep, but it's a useful solution. Right now you have no way of supporting
e.g. smartcards or other interesting sources of key material which might
come along down the line. Such functionality should be supported (not
necessarily by using keyscript= of course).

Regards,
David
Mike Kazantsev
2012-07-30 07:40:51 UTC
Permalink
On Wed, 11 Jul 2012 09:29:55 +0200
Post by David Härdeman
Post by Lennart Poettering
Note that if compat is really that important it should be possible to
write an agent that can invoke keyscripts like this. If you did that you
would gain, among other things the ability to query for passwords at the
same time via different methods. With a bit of C code it should be
fairly easy to hack up an agent that just invokes a keyscript.
The biggest question in my mind right now is how the "keyscript" password
agent should be implemented and how it should interact with the other
agents.
Imagine the scenario where crypsetup wants to set up a partition using a
1) Following the current logic, the systemd cryptsetup binary would ask
for the key to the partition using /run/systemd/ask-password/ask.foo. (That
file could potentially be extended to add something like an "Options="
field where we could provide additional information about the password
request to the agents).
2a) The "keyscript" agent would read the ask.foo file and determine that
it can provide the requested key from a smartcard (I assume this knowledge
comes from some config file)
2b) At the same time, the other agents provide normal password input
prompt(s) to the user (e.g. on the tty)...which are pointless since a
binary key is expected.
3) Soon afterwards, the "keyscript" agent in turn uses
/run/systemd/ask-password/ask.bar to request the PIN for the smartcard.
4) The user would be confronted with two passphrase prompts. One
(pointless) one to provide a binary key using the keyboard, and one (real)
prompt for the PIN to the smartcard.
I'm not sure what kind of changes to the password agent scheme you're
envisioning to accommodate a scheme like this?
With systemd password agent, I think it can be solved in the following
way:

1) /run/systemd/ask-password/ask.foo is created and
systemd-ask-password-console pops up a prompt for it.

2) At the same time, systemd-smartcard-password agent detects the
created file and reads it, then check for a smartcard device, waiting
for it to appear.

3) If/when proper smartcard device appears (and is recognized by
middleware), it unlinks /run/systemd/ask-password/ask.foo and prompts
for PIN.

4) systemd-ask-password-console detects query-file removal and hides
it's prompt, leaving only query for PIN.

5) If PIN provided to systemd-smartcard-password is incorrect (or
smartcard disappears, or user times out), it provides systemd with
empty password (emulating it being incorrect) or "request cancelled"
response.

Does it make any sense?
Post by David Härdeman
Post by Lennart Poettering
3) systemd specific solution
Converting keyscript= scripts to password agents introduce a strong
dependency on systemd. I realize that you don't consider it to be a
problem but I'm guessing it wouldn't be acceptable to Debian (where
systemd is not mandatory).
Well, it's currently a Debian-init scripts specific solution...
Yep, but it's a useful solution. Right now you have no way of supporting
e.g. smartcards or other interesting sources of key material which might
come along down the line. Such functionality should be supported (not
necessarily by using keyscript= of course).
While probably exactly not what you seek, but I've actually implemented
smartcard / systemd / cryptsetup glue about a year ago.

It doesn't work purely on systemd-level though, as dracut had to get
the key first, and I didn't have systemd in it at that moment.

To get the key for LUKS slot, udev rule is generated by dracut (if
proper cmdline flag was present), which runs a script once smartcard
is detected, which extracts the key (as necessary) and just puts it
into /run/initramfs (with strict root-only permissions).

After that, both dracut (with a bit patched "crypt" module) and custom
systemd password agent try to satisfy password requests (for
popping-up encrypted lvm partitions) from that cache-file.

Specal .service removes that file After=local-fs.target.

Not sure if this description is useful to you, but that's one (still
working flawlessly, btw, though maybe by accident) way to support that
feature.

Agent implementation can be found here:
https://github.com/mk-fg/systemd-password-agent/blob/master/systemd_password_cache.py

A post describing the process in (maybe) a bit more detail:
http://blog.fraggod.net/2011/10/dm-crypt-password-caching-between-dracut-and-systemd-systemd-password-agent
Post by David Härdeman
Regards,
David
--
Mike Kazantsev // fraggod.net
Alexander E. Patrakov
2012-07-11 08:32:26 UTC
Permalink
Post by Lennart Poettering
Well, but if this is all dependent on some other hw then the synchronous
nature of keyscript= doesn't work anyway... (see other mail about that)
Continue reading on narkive:
Loading...