Discussion:
Thoughts about /etc/crypttab keyscript options
(too old to reply)
Marc Haber
2014-07-21 08:46:21 UTC
Permalink
Hi,

I was recently bitten by the issue that systemd does not support the
keyscript= option in /etc/crypttab. I don't know whether keyscript= is
a Debian extension, but the migration to systemd (which was pulled in
by some new version of - I think - Network Manager) broke my system's
boot process, leaving me with all my filesystems locked since already
the root fs used to be unlocked by a keyscript.

I have read the thread (from 2012?) where those things were discussed
here and I understand that I should replace my keyscript with a
passwort agent. Things would then work like this:

(1)
systemd would try to unlock the root file system and place a ask.xxx
file in /run/systemd/ask-password

(2)
All running PasswordAgents (including my, non-interactive one and
all interactive ones) would act on that ask.xxx file.

(3)
The interactive password agents would present an interactive password
request.

(4)
My PasswordAgent indicates taking responsibility by unlinking the
ask.xxx file from /run/systemd/ask-password. The interactive password
agents will remove their interactive requests then. The user will
therefore see the password request popping up for a very short period
of time, if at all.

(5)
Should my PasswordAgent need a password to act itself (like a PIN for
a hardware device, for example), it would place its own ask.xxx file
in /run/systemd/ask-password. The interactive PasswordAgents would
act on that, obtain the password/PIN interactively from the user and
return it to my PasswordAgent.

(6)
My PasswordAgent would then obtain the password for the file system
itself and return it to systemd which can now proceed to unlock the
file system.


Am I understanding things correctly so far?


If so, this leaves the task to write "my" PasswordAgent. I have found
some example code in python for a password agent.

To use this to unlock the root fs, an entire python installation would
need to go in my initramfs, right? And if I want to keep things
simple, the best idea would be to write my PasswordAgent in a compiled
language which would only need the binary and its libs in the
initramfs, right?

Is there code for an example PasswordAgent in C++ which I can use as a
template? I am quite reluctant to write a program which needs to to
complex string processing and is bound to run as root in C because my
C experience is somewhat lacking.

Can you please recommend a way to allow me to migrate to systemd?
Without keyscript= being supported in /etc/crypttab, I need to replace
my 50 line key script written in POSIX shell and would like to keep
things simple.

Thank you very much for your consideration.

Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
Marc Haber
2014-08-13 14:43:01 UTC
Permalink
Hi,

did I reach the wrong mailing list? Is there better forum to get
systemd working with something resembling my current setup?

Greetings
Marc
Subject: Thoughts about /etc/crypttab keyscript options
Date: Mon, 21 Jul 2014 10:46:21 +0200
User-Agent: Mutt/1.5.21 (2010-09-15)
Hi,
I was recently bitten by the issue that systemd does not support the
keyscript= option in /etc/crypttab. I don't know whether keyscript= is
a Debian extension, but the migration to systemd (which was pulled in
by some new version of - I think - Network Manager) broke my system's
boot process, leaving me with all my filesystems locked since already
the root fs used to be unlocked by a keyscript.
I have read the thread (from 2012?) where those things were discussed
here and I understand that I should replace my keyscript with a
(1)
systemd would try to unlock the root file system and place a ask.xxx
file in /run/systemd/ask-password
(2)
All running PasswordAgents (including my, non-interactive one and
all interactive ones) would act on that ask.xxx file.
(3)
The interactive password agents would present an interactive password
request.
(4)
My PasswordAgent indicates taking responsibility by unlinking the
ask.xxx file from /run/systemd/ask-password. The interactive password
agents will remove their interactive requests then. The user will
therefore see the password request popping up for a very short period
of time, if at all.
(5)
Should my PasswordAgent need a password to act itself (like a PIN for
a hardware device, for example), it would place its own ask.xxx file
in /run/systemd/ask-password. The interactive PasswordAgents would
act on that, obtain the password/PIN interactively from the user and
return it to my PasswordAgent.
(6)
My PasswordAgent would then obtain the password for the file system
itself and return it to systemd which can now proceed to unlock the
file system.
Am I understanding things correctly so far?
If so, this leaves the task to write "my" PasswordAgent. I have found
some example code in python for a password agent.
To use this to unlock the root fs, an entire python installation would
need to go in my initramfs, right? And if I want to keep things
simple, the best idea would be to write my PasswordAgent in a compiled
language which would only need the binary and its libs in the
initramfs, right?
Is there code for an example PasswordAgent in C++ which I can use as a
template? I am quite reluctant to write a program which needs to to
complex string processing and is bound to run as root in C because my
C experience is somewhat lacking.
Can you please recommend a way to allow me to migrate to systemd?
Without keyscript= being supported in /etc/crypttab, I need to replace
my 50 line key script written in POSIX shell and would like to keep
things simple.
Thank you very much for your consideration.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420
Lennart Poettering
2014-08-13 16:42:13 UTC
Permalink
Post by Marc Haber
Hi,
did I reach the wrong mailing list? Is there better forum to get
systemd working with something resembling my current setup?
No, this is the right place. But I just have a huge backlog of threads
to reply to on the ML. I am slowly working on catching up now, in
preparation for a new release.

Lennart
--
Lennart Poettering, Red Hat
Marc Haber
2014-08-14 09:20:13 UTC
Permalink
Post by Lennart Poettering
Post by Marc Haber
did I reach the wrong mailing list? Is there better forum to get
systemd working with something resembling my current setup?
No, this is the right place. But I just have a huge backlog of threads
to reply to on the ML. I am slowly working on catching up now, in
preparation for a new release.
Ok, I'll sit back quietly ;-) Maybe somebody else cares to comment?

Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420
Lennart Poettering
2014-08-14 17:44:59 UTC
Permalink
On Mon, 21.07.14 10:46, Marc Haber (mh+systemd-***@zugschlus.de) wrote:

Heya,
Post by Marc Haber
I have read the thread (from 2012?) where those things were discussed
here and I understand that I should replace my keyscript with a
There's currently no streamlined support for stacking password questions
really. You currently cannot "take possession" of specific password
questions.

Also note that we really should redesign the entire scheme around the
kernel keyring as only transport for the keys (and the bus for
signalling). I am a bit conservative in changing here too much for now,
because we really should figure out that bit first.
Post by Marc Haber
(4)
My PasswordAgent indicates taking responsibility by unlinking the
ask.xxx file from /run/systemd/ask-password. The interactive password
Well, so far it is the querier that removes the file, not the agent...
Post by Marc Haber
agents will remove their interactive requests then. The user will
therefore see the password request popping up for a very short period
of time, if at all.
(5)
Should my PasswordAgent need a password to act itself (like a PIN for
a hardware device, for example), it would place its own ask.xxx file
in /run/systemd/ask-password. The interactive PasswordAgents would
act on that, obtain the password/PIN interactively from the user and
return it to my PasswordAgent.
(6)
My PasswordAgent would then obtain the password for the file system
itself and return it to systemd which can now proceed to unlock the
file system.
Am I understanding things correctly so far?
Yes, this should indeed work.
Post by Marc Haber
If so, this leaves the task to write "my" PasswordAgent. I have found
some example code in python for a password agent.
To use this to unlock the root fs, an entire python installation would
need to go in my initramfs, right? And if I want to keep things
simple, the best idea would be to write my PasswordAgent in a compiled
language which would only need the binary and its libs in the
initramfs, right?
Yes. Correct. If you want to stick something into the initrd, I'd always
do things in C (or shell if you must), but nothing else.
Post by Marc Haber
Is there code for an example PasswordAgent in C++ which I can use as a
template? I am quite reluctant to write a program which needs to to
complex string processing and is bound to run as root in C because my
C experience is somewhat lacking.
Not aware of an C++ code. There's a vala one, and of course the one we
ship in systemd itself in C, but c++ i cannot help you with, sorry.
Post by Marc Haber
Can you please recommend a way to allow me to migrate to systemd?
Without keyscript= being supported in /etc/crypttab, I need to replace
my 50 line key script written in POSIX shell and would like to keep
things simple.
Thank you very much for your consideration.
I fear I don#t have an easy suggestion. What kind of device do you
actually want to make work here? some smartcard or so?

I think in the long run we should somehow work towards the direction to
make things like that just work, for common devices like smartcards and
other auth tokens...

Lennart
--
Lennart Poettering, Red Hat
David Herrmann
2014-08-14 18:09:05 UTC
Permalink
Hi

On Thu, Aug 14, 2014 at 7:44 PM, Lennart Poettering
Post by Lennart Poettering
Heya,
Post by Marc Haber
I have read the thread (from 2012?) where those things were discussed
here and I understand that I should replace my keyscript with a
There's currently no streamlined support for stacking password questions
really. You currently cannot "take possession" of specific password
questions.
Also note that we really should redesign the entire scheme around the
kernel keyring as only transport for the keys (and the bus for
signalling). I am a bit conservative in changing here too much for now,
because we really should figure out that bit first.
The hack you describe here should work, however, it's really an ugly
hack. One thing you really need to take care of is to not cause
recursive loops. That is, if your agent places a new *.ask file, it
will be called on it again and *must* ignore it. Otherwise, you end up
with an endless loop.

Anyhow, I don't think we should support stacked agents. Agents are
meant as an API to interact with users. They should not employ any
logic/rules regarding the query itself. They're solely meant as GUI.
That is, to solve your problem, I'd recommend to make systemd allow
external scripts like "keyscript=" before placing *.ask files (or some
other hookup or configuration, if scripts are not suitable for that).
I have never worked with crypttab, though. I have to refer to Lennart
here to tell whether that makes sense. I just want to make clear that
once you query the ask-password tool, you will inevitably end up
forwarding that request unchanged to an UI.

Polkit provides .rule scripts for that. We don't have any equivalent
for ask-password. I'm not sure whether that would make sense.

Thanks
David
Marc Haber
2014-08-14 18:15:16 UTC
Permalink
Hi,
Post by David Herrmann
That is, to solve your problem, I'd recommend to make systemd allow
external scripts like "keyscript=" before placing *.ask files (or some
other hookup or configuration, if scripts are not suitable for that).
If systemd would support keyscript=, migration would be painless. I am
absolutely in favor of that ;-)

Greetings
Marc, unfortunately too bad a C programmer to write a patch
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420
Marc Haber
2014-08-14 18:10:48 UTC
Permalink
Hi Lennart,

thanks for your thoughts.
Post by Lennart Poettering
Post by Marc Haber
(4)
My PasswordAgent indicates taking responsibility by unlinking the
ask.xxx file from /run/systemd/ask-password. The interactive password
Well, so far it is the querier that removes the file, not the agent...
I see. What would happen if I remove the file myself?
Post by Lennart Poettering
Post by Marc Haber
To use this to unlock the root fs, an entire python installation would
need to go in my initramfs, right? And if I want to keep things
simple, the best idea would be to write my PasswordAgent in a compiled
language which would only need the binary and its libs in the
initramfs, right?
Yes. Correct. If you want to stick something into the initrd, I'd always
do things in C (or shell if you must), but nothing else.
Post by Marc Haber
Is there code for an example PasswordAgent in C++ which I can use as a
template? I am quite reluctant to write a program which needs to to
complex string processing and is bound to run as root in C because my
C experience is somewhat lacking.
Not aware of an C++ code. There's a vala one, and of course the one we
ship in systemd itself in C, but c++ i cannot help you with, sorry.
Is it possible to write a PasswordAgent in shell? Example code please ;)
Post by Lennart Poettering
Post by Marc Haber
Can you please recommend a way to allow me to migrate to systemd?
Without keyscript= being supported in /etc/crypttab, I need to replace
my 50 line key script written in POSIX shell and would like to keep
things simple.
Thank you very much for your consideration.
I fear I don#t have an easy suggestion. What kind of device do you
actually want to make work here? some smartcard or so?
That's the vision, yes. At the moment, my keyscript unlocks a small
LUKS partition on the disk and takes the key for the root fs from
there. That's just a placeholder for a future more complicated setup.

With Debian's initramfs, unlocking the small LUKS partition works
transparently even with plymouth. This is real functionality being
lost in the systemd migration.
Post by Lennart Poettering
I think in the long run we should somehow work towards the direction to
make things like that just work, for common devices like smartcards and
other auth tokens...
First step to do that would be to implement support for the keyscript=
option in /etc/crypttab as this is the canonical place to hook into on
non-system systems. At least it's the case on Debian, I don't know
about Red Hat, Fedora and other distributions.

The PasswordAgent stuff is really neat, but complicated due to the
socket communication, and it's far from being a drop-in replacement.

Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420
Lennart Poettering
2014-08-14 18:18:10 UTC
Permalink
Post by Marc Haber
Post by Lennart Poettering
Not aware of an C++ code. There's a vala one, and of course the one we
ship in systemd itself in C, but c++ i cannot help you with, sorry.
Is it possible to write a PasswordAgent in shell? Example code please ;)
Probably possible, after all bash allows you to talk to unix sockets and
stuff. And you could probably put the protocol together with carefully
crafted echo lines, but I know of nobody who has done that so far...
Post by Marc Haber
Post by Lennart Poettering
I fear I don#t have an easy suggestion. What kind of device do you
actually want to make work here? some smartcard or so?
That's the vision, yes. At the moment, my keyscript unlocks a small
LUKS partition on the disk and takes the key for the root fs from
there. That's just a placeholder for a future more complicated setup.
Not following. You place a key for a LUKS partition on another LUKS
partition? What's the benefit of that? Inception? ;-)
Post by Marc Haber
With Debian's initramfs, unlocking the small LUKS partition works
transparently even with plymouth. This is real functionality being
lost in the systemd migration.
Haven't understood your setup yet I must say, before I can agree that
this is "real functionality"...
Post by Marc Haber
Post by Lennart Poettering
I think in the long run we should somehow work towards the direction to
make things like that just work, for common devices like smartcards and
other auth tokens...
First step to do that would be to implement support for the keyscript=
option in /etc/crypttab as this is the canonical place to hook into on
non-system systems. At least it's the case on Debian, I don't know
about Red Hat, Fedora and other distributions.
Well, I am really not convinced that this is a well-defined
interface. Even in your case you have to wait for two devices at least,
right? a synchronous shell callout won't solve that for you since
there's no guarantee that the second LUKS device has already shown up,
or am I missing something?

Shell callouts always appear simply or powerful, but when it comes to
waiting for devices, and executing things as things pop up its often
really not the right tool.

As mentioned we really should redesign the whole thing around the kernel
keyring anyway, I am really conservative in adding support for Debian's
keyscript thingy upstream now. (That of course shouldn't stop Debian
from adding this downstream)
Post by Marc Haber
The PasswordAgent stuff is really neat, but complicated due to the
socket communication, and it's far from being a drop-in replacement.
Well, it's really easy in C I figure, but admittedly not in shell...

Lennart
--
Lennart Poettering, Red Hat
Marc Haber
2014-08-15 10:56:59 UTC
Permalink
Post by Lennart Poettering
Post by Marc Haber
Post by Lennart Poettering
Not aware of an C++ code. There's a vala one, and of course the one we
ship in systemd itself in C, but c++ i cannot help you with, sorry.
Is it possible to write a PasswordAgent in shell? Example code please ;)
Probably possible, after all bash allows you to talk to unix sockets and
stuff. And you could probably put the protocol together with carefully
crafted echo lines, but I know of nobody who has done that so far...
There is also the daemonizing and inotify part...
Post by Lennart Poettering
Post by Marc Haber
Post by Lennart Poettering
I fear I don#t have an easy suggestion. What kind of device do you
actually want to make work here? some smartcard or so?
That's the vision, yes. At the moment, my keyscript unlocks a small
LUKS partition on the disk and takes the key for the root fs from
there. That's just a placeholder for a future more complicated setup.
Not following. You place a key for a LUKS partition on another LUKS
partition? What's the benefit of that? Inception? ;-)
It's actually part of a two-factor-authentification for the poor. The
part to know is the key to the LUKS parition, the part to have is an
USB key.

The key script hashes part of the key found on the USB key and part of
the key found on the LUKS partition on the hard disk together to build
the actual key to unlock the root fs. I use this scheme for so long
that I don't even remember why I implemented it this way, but I guess
it was because the logic to unlock a LUKS fs from initramfs was
already in place and could be used as-is to unlock the
key-part-holding LUKS partition instead of the actual root fs that it
was intended for.

But I also know of people who use a keyscript to unlock LUKS file
systems with the key stored in the system's TPM or on a crypto card. I
have never looked into the details of those implementations (having
that saved for a long winter night), but I guess that those people
will also be pretty hosed on a systemd-based Debian.
Post by Lennart Poettering
Post by Marc Haber
First step to do that would be to implement support for the keyscript=
option in /etc/crypttab as this is the canonical place to hook into on
non-system systems. At least it's the case on Debian, I don't know
about Red Hat, Fedora and other distributions.
Well, I am really not convinced that this is a well-defined
interface. Even in your case you have to wait for two devices at least,
right? a synchronous shell callout won't solve that for you since
there's no guarantee that the second LUKS device has already shown up,
or am I missing something?
It may be possible that /etc/crypttab is processed sequentially which
would obviously not be the case with systemd. So you have a point here.
Post by Lennart Poettering
As mentioned we really should redesign the whole thing around the kernel
keyring anyway, I am really conservative in adding support for Debian's
keyscript thingy upstream now. (That of course shouldn't stop Debian
from adding this downstream)
It didn't occur to me that /etc/crypttab's keyscript= option was a
Debianism. I educated myself in the mean time. I'm going to yell at
the Debian systemd team now ;-)
Post by Lennart Poettering
Post by Marc Haber
The PasswordAgent stuff is really neat, but complicated due to the
socket communication, and it's far from being a drop-in replacement.
Well, it's really easy in C I figure, but admittedly not in shell...
It would be significantly easier if there were boilerplate code to
derive from. To a non-adept programmer, adapting the boilerplate would
probably lead to enough buffer overflow vulnerabilities anyway ;-)

Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420
Lennart Poettering
2014-08-15 11:30:32 UTC
Permalink
Post by Marc Haber
Post by Lennart Poettering
Post by Marc Haber
Is it possible to write a PasswordAgent in shell? Example code please ;)
Probably possible, after all bash allows you to talk to unix sockets and
stuff. And you could probably put the protocol together with carefully
crafted echo lines, but I know of nobody who has done that so far...
There is also the daemonizing and inotify part...
Post by Lennart Poettering
Post by Marc Haber
Post by Lennart Poettering
I fear I don#t have an easy suggestion. What kind of device do you
actually want to make work here? some smartcard or so?
That's the vision, yes. At the moment, my keyscript unlocks a small
LUKS partition on the disk and takes the key for the root fs from
there. That's just a placeholder for a future more complicated setup.
Not following. You place a key for a LUKS partition on another LUKS
partition? What's the benefit of that? Inception? ;-)
It's actually part of a two-factor-authentification for the poor. The
part to know is the key to the LUKS parition, the part to have is an
USB key.
The part to have is trivially easy to copy, so why do the excercise
at all? Sounds more like theatre to me...
Post by Marc Haber
But I also know of people who use a keyscript to unlock LUKS file
systems with the key stored in the system's TPM or on a crypto card. I
have never looked into the details of those implementations (having
that saved for a long winter night), but I guess that those people
will also be pretty hosed on a systemd-based Debian.
I think supporting TPM or smartcards out of the box is very desirable to
have upstream. I am not convinced though that Debian's keyscript= logic
is really that well designed that I want to update it upstream. (But
again, Debian can ship such a patch downstream)
Post by Marc Haber
Post by Lennart Poettering
Post by Marc Haber
First step to do that would be to implement support for the keyscript=
option in /etc/crypttab as this is the canonical place to hook into on
non-system systems. At least it's the case on Debian, I don't know
about Red Hat, Fedora and other distributions.
Well, I am really not convinced that this is a well-defined
interface. Even in your case you have to wait for two devices at least,
right? a synchronous shell callout won't solve that for you since
there's no guarantee that the second LUKS device has already shown up,
or am I missing something?
It may be possible that /etc/crypttab is processed sequentially which
would obviously not be the case with systemd. So you have a point here.
Modern design probing really doesn't work that way anymore. You never
know when all devices have shown up. If you want to implement something
like your USB key thing, then you'd have to explicitly wait for both
devices.

On old Debian and the other sysv distros, boot scripts generally
included an "udev settle" call, which was supposed to wait until "all"
devices have shown up. But that's not actually something that could work
at all on many of the newer tehcnologies where the probing time is
basically unbounded. One of those busses is actually USB, where there's
no restriction made at all, when devices have to have told the OS about
the storage devices they want to provide (and this fact is used by
android phones, where you need to press OK on the phone before a USB
device pops up in the system, after you connected the cable).

So, nowadays no sane distribution uses "udev settle" anymoer, since it
cannot deliver what people assume it delivers, and in particular not on
USB, which you are looking for.

Anyway, long story short: what you are doing worked mostly out of luck,
not out of correctness..
Post by Marc Haber
Post by Lennart Poettering
Post by Marc Haber
The PasswordAgent stuff is really neat, but complicated due to the
socket communication, and it's far from being a drop-in replacement.
Well, it's really easy in C I figure, but admittedly not in shell...
It would be significantly easier if there were boilerplate code to
derive from. To a non-adept programmer, adapting the boilerplate would
probably lead to enough buffer overflow vulnerabilities anyway ;-)
Well, we have examples in our code, but really only in C, and they are
not minimalist examples, but real code...

Lennart
--
Lennart Poettering, Red Hat
Marc Haber
2014-08-15 11:51:04 UTC
Permalink
Post by Lennart Poettering
Post by Marc Haber
Post by Lennart Poettering
Post by Marc Haber
Is it possible to write a PasswordAgent in shell? Example code please ;)
Probably possible, after all bash allows you to talk to unix sockets and
stuff. And you could probably put the protocol together with carefully
crafted echo lines, but I know of nobody who has done that so far...
There is also the daemonizing and inotify part...
Post by Lennart Poettering
Post by Marc Haber
Post by Lennart Poettering
I fear I don#t have an easy suggestion. What kind of device do you
actually want to make work here? some smartcard or so?
That's the vision, yes. At the moment, my keyscript unlocks a small
LUKS partition on the disk and takes the key for the root fs from
there. That's just a placeholder for a future more complicated setup.
Not following. You place a key for a LUKS partition on another LUKS
partition? What's the benefit of that? Inception? ;-)
It's actually part of a two-factor-authentification for the poor. The
part to know is the key to the LUKS parition, the part to have is an
USB key.
The part to have is trivially easy to copy, so why do the excercise
at all? Sounds more like theatre to me...
Because I still hope to have that in a more secure way in the near
future.
Post by Lennart Poettering
Post by Marc Haber
But I also know of people who use a keyscript to unlock LUKS file
systems with the key stored in the system's TPM or on a crypto card. I
have never looked into the details of those implementations (having
that saved for a long winter night), but I guess that those people
will also be pretty hosed on a systemd-based Debian.
I think supporting TPM or smartcards out of the box is very desirable to
have upstream.
Yes, and that should be done in a modular way so that even exotic (or
broken) schemes can be plugged in.
Post by Lennart Poettering
I am not convinced though that Debian's keyscript= logic is really
that well designed that I want to update it upstream.
You don't need to. I falsely thought that this was general
functionality and not a Debianism.

Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420
Continue reading on narkive:
Loading...