[gnutls-devel] [RFC] Relaxing cipher suite (priority) string requirements

Post by Jouko Orava
Hi!
GnuTLS is very, very picky about the cipher suite strings it accepts.
I wrote a test patch (attached), UNTESTED, that should relax the

Hello Jouko,

I think the idea of simplifying the rules is a nice one. Some comments
on the specific changes.

Post by Jouko Orava
- Make '+' prefix optional

Nice.

Post by Jouko Orava
- Allow full cipher names, adding/removing cipher, mac, and kx
(I suspect it would be better to add all three, but
when removing, only remove the cipher.
Currently the patch adds/removes all three.)

This is tricky. Although I don't think we are going to have a cipher
called SHA1, I was afraid of collisions and that's why we have this
awkward format. E.g. what does the +NULL mean? the NULL cipher? or
compression? How could you handle that?

Post by Jouko Orava
The patch also includes a change into lib/gnutls_priority.c:prio_remove(),
that instead of replacing the removed item with the final item in the
array, uses memmove() to shorten the array. For some reason I seem
to believe the order in these priority lists matter.

Indeed, even if it comes at the cost of memmove :(

regards,
Nikos

Jouko Orava

2013-01-26 05:38:44 UTC

Post by Nikos Mavrogiannopoulos
I think the idea of simplifying the rules is a nice one.

Thanks!

Perhaps the lib/gnutls_priority.c:prio_remove() and optional "+" in
priority strings should be separated into simpler patches for now?
Suggested but untested patches are attached.

I'll post a separate message expanding on my ideas for enhancing the
priority string parsing.

Post by Jouko Orava
- Allow full cipher names, adding/removing cipher, mac, and kx

No, I meant that users seem to expect being able to specify e.g.
TLS_RSA_AES_256_CBC_SHA1 as a priority string. The untested patch
is supposed to detect that string as it matches the name entry in
cs_algorithms[], and add the cipher, mac, and kx from that entry
to the respective priority lists.

In other words, priority string
TLS_RSA_AES_256_CBC_SHA1
should have the same effect as
+RSA:+AES_256_CBC:+SHA1
(This would be based on matching to a cs_algorithms[] name,
and using the cipher/mac/kx fields in that entry,
not splitting or parsing the string itself.)

I do keenly understand it is paramount to not change the
interpretation of existing valid GnuTLS priority strings.
I only wanted to add new, unambiguous strings the parser
would recognize, not change existing interpretations or
risk confusion.

Best regards,
Jouko

Nikos Mavrogiannopoulos

2013-01-26 10:24:38 UTC

Post by Nikos Mavrogiannopoulos
I think the idea of simplifying the rules is a nice one.

Thanks!
Perhaps the lib/gnutls_priority.c:prio_remove() and optional "+" in
priority strings should be separated into simpler patches for now?

Yes that would be great.

Post by Jouko Orava
Suggested but untested patches are attached.

Ouch. I cannot test them now (may take some time), but if you add a test
in tests/ would speed up things. The test can simply use gnutls-cli -l
--priority XXX, for few typical strings and some corner cases, and
verify that the expected values are present.

Post by Jouko Orava
I'll post a separate message expanding on my ideas for enhancing the
priority string parsing.

Post by Jouko Orava
- Allow full cipher names, adding/removing cipher, mac, and kx

That's dangerous. TLS_RSA_AES_256_CBC is very different from +TLS1.0
+RSA +AES-256-CBC. The latter sets the order for the individual ciphers
while the former only for that specific ciphersuite. The idea of setting
priorities for individual ciphers was to avoid even introducing the
notion of ciphersuites to the users/admins. They don't need to know and
everyone (hopefully) knows the individual ciphers.

However, setting specific ciphersuites was my reason for switching to
priority strings (even though it was never implemented). It needs some
work, but the main idea is to generate the list of ciphersuite numbers
in gnutls_priority_set(), and later be used in the handshake.

Now the current behavior is to generate the ciphersuite numbers during
the handshake.

So if ciphersuite names are to be allowed in the string, the above has
to be done.

regards,
Nikos

Jouko Orava

2013-01-26 11:43:50 UTC

Post by Nikos Mavrogiannopoulos
Ouch. I cannot test them now (may take some time), but if you add a test
in tests/ would speed up things. The test can simply use gnutls-cli -l
--priority XXX, for few typical strings and some corner cases, and
verify that the expected values are present.

Right. I did not test the patch yet, because I wanted to make sure the
approach is acceptable first.

I do not want to hurry, because including the optional '+' patch
might make the latter part of the overall task here harder.
Currently, the syntax of the priority strings GnuTLS accepts is
very strict; we still have the option to make it a lot more versatile,
while keeping full compatibility with existing valid strings.
Making '+' optional makes that a lot harder.

Post by Jouko Orava
In other words, priority string
TLS_RSA_AES_256_CBC_SHA1
should have the same effect as
+RSA:+AES_256_CBC:+SHA1

That's dangerous. TLS_RSA_AES_256_CBC is very different from +TLS1.0
+RSA +AES-256-CBC. The latter sets the order for the individual ciphers
while the former only for that specific ciphersuite.

Yes, exactly. That's why I don't think my suggested patch
(that is, perhaps excluding the remove_prio() fix and making '+' optional)
should be considered further at all.

Post by Nikos Mavrogiannopoulos
The idea of setting
priorities for individual ciphers was to avoid even introducing the
notion of ciphersuites to the users/admins. They don't need to know and
everyone (hopefully) knows the individual ciphers.

Unfortunately, in my experience -- meaning looking at what kind of issues
administrators I know are having -- users seems to be aware of
ciphersuites, whereas ciphers, message authentication codes, and key
exchange algorithms are just underlying details they find hard to grasp.

In other words, my experience is the exact opposite. They know the
ciphersuites, but not the individual ciphers or key exchange algorithms
or message authentication schemes, at all.

In practical terms, I see administrators wanting to specify something like
Use AES_256_CBC with RSA key exchange and SHA256 MAC
or AES_256_CBC with RSA key exchange and SHA1 MAC
or CAMELLIA_256_CBC with RSA key exchange and SHA1 MAC
or fail
Use TLS1.0 or TLS1.2 (and no other versions)
without compression
using x.509 certificates
with the cipher suites taken from recommendations, logs, or internal
documentation. The string they seem to start with looks something like
TLS_RSA_AES_256_CBC_SHA256:TLS_RSA_AES_256_CBC_SHA1:\
TLS_RSA_CAMELLIA_256_CBC_SHA1:TLSv1.0:TLSv1.2

Usually the reasons for restricting the cipher suite is not
cryptographical, but practical; related to implementation issues
or organizational politics. (Unfortunate, I know. Actual security
seems to rarely be a true priority; the appearance of security
seems to be enough.)

Post by Nikos Mavrogiannopoulos
However, setting specific ciphersuites was my reason for switching to
priority strings (even though it was never implemented). It needs some
work, but the main idea is to generate the list of ciphersuite numbers
in gnutls_priority_set(), and later be used in the handshake.
Now the current behavior is to generate the ciphersuite numbers during
the handshake.
So if ciphersuite names are to be allowed in the string, the above has
to be done.

Ah, I came to the same conclusion, I think.

Basically, the functionality of lib/algorithms/ciphersuites.c:
_gnutls_supported_ciphersuites() should be moved into
lib/gnutls_priority.c:gnutls_priority_init(), with
priority_st cipher;
priority_st mac;
priority_st kx;
in struct gnutls_priority_st replaced with
priority_st ciphersuite;

The ciphersuite integer keys could be e.g. 1 + index of cs_algorithm
entry, or perhaps (id[0] + 256*id[1]). I have no preference, but
I suspect the former will lead to cleaner code.

Right now, I'm still trying to write a set of logic rules how
the priority string should be parsed, so that it would be intuitive
and easy for users to understand, and construct, preferably
keeping the interpretation of current priority strings intact.
The code is straightforward to write after that.

Another option would be to revamp the priority string parsing
entirely, and move to one that allows reasonable compatibility
with OpenSSL priority strings. A lot of users would love that,
as it would reduce the configuration differences in applications
that can be linked against either one -- for example, OpenLDAP.

A third option would be to enhance the current priority string
parsing, but in a way that allows automatic conversion between
GnuTLS and OpenSSL priority strings, for example with a special
conversion tool. It might have to be linked against both libraries,
to be fully reliable, though, as it might have to examine the
internal data structures to find out if the two are really comparable.

Unless someone has already considered what the logical rules
for parsing the priority string (including cipher suite names)
should be, I shall try to cook some up, and report to the list.

Regards,
Jouko

Nikos Mavrogiannopoulos

2013-01-26 13:28:05 UTC

Yes, but for these people the priorities NORMAL, PERFORMANCE or SECURE
should be clearly advertised by the applications. Otherwise they are
going to search google on what to put on this priority string field and
end up with obscure strings that make no much sense (that is the
impression I get from watching people configure mod_ssl).

Post by Jouko Orava
In other words, my experience is the exact opposite. They know the
ciphersuites, but not the individual ciphers or key exchange algorithms
or message authentication schemes, at all.
In practical terms, I see administrators wanting to specify something like
Use AES_256_CBC with RSA key exchange and SHA256 MAC
or AES_256_CBC with RSA key exchange and SHA1 MAC
or CAMELLIA_256_CBC with RSA key exchange and SHA1 MAC

Do they want to specify that, or do they want to set a certain security
level? I think the reason they try to set that is because of how mod_ssl
expects things. As an administrator I wouldn't want to specify that
stuff. I'd like to specify a certain security level such as SECURE128 or
SECURE192.

[possibly in some later version of gnutls such priority strings should enforce

the acceptable certificate and DH key size - possibly using new strings]

Post by Nikos Mavrogiannopoulos
So if ciphersuite names are to be allowed in the string, the above has
to be done.

Ah, I came to the same conclusion, I think.
_gnutls_supported_ciphersuites() should be moved into
lib/gnutls_priority.c:gnutls_priority_init(), with
priority_st cipher;
priority_st mac;
priority_st kx;
in struct gnutls_priority_st replaced with
priority_st ciphersuite;
The ciphersuite integer keys could be e.g. 1 + index of cs_algorithm
entry, or perhaps (id[0] + 256*id[1]). I have no preference, but
I suspect the former will lead to cleaner code.

Yes. Note that during the handshake, the server and the client would
need to process this list and remove the ciphersuites that are not
compatible with their keys (but if an index is used as you propose that
would be pretty efficient).

Post by Jouko Orava
Another option would be to revamp the priority string parsing
entirely, and move to one that allows reasonable compatibility
with OpenSSL priority strings. A lot of users would love that,
as it would reduce the configuration differences in applications
that can be linked against either one -- for example, OpenLDAP.

No, openssl priority strings aren't any better (and are harder to
understand if you know what's going on). OpenLDAP with gnutls is a long
story. They use gnutls but they expect the openssl behavior and API.
Gnutls isn't an LGPL port of openssl. It's another library and I don't
think there is any reason to change that.

Post by Jouko Orava
A third option would be to enhance the current priority string
parsing, but in a way that allows automatic conversion between
GnuTLS and OpenSSL priority strings, for example with a special
conversion tool. It might have to be linked against both libraries,
to be fully reliable, though, as it might have to examine the
internal data structures to find out if the two are really comparable.

That would be interesting for programs that switched from openssl to
gnutls, but I think this no longer happens. Programs now either start
with gnutls or not. In any case, that again couldn't be part of gnutls.
It could be part of gnutls-openssl library or so.

Post by Jouko Orava
Unless someone has already considered what the logical rules
for parsing the priority string (including cipher suite names)
should be, I shall try to cook some up, and report to the list.

Thank you.

regards,
Nikos

Jouko Orava

2013-01-27 07:45:08 UTC

Post by Nikos Mavrogiannopoulos
Yes, but for these people the priorities NORMAL, PERFORMANCE or SECURE
should be clearly advertised by the applications.

Right, and that's what I too recommend for users. For example, for the
OpenLDAP bug I recently reported (libldap crashes in starttls if linked
against GnuTLS and given an invalid priority string), I suggest using
"SECURE256" in particular.

The problems with priority strings only occur when there are extraneous
requirements, for example to use a specific cipher suite, or to not use
a specific ciphers or cipher suites.
Often these are political, not technical.

Post by Nikos Mavrogiannopoulos
Do they want to specify that, or do they want to set a certain security
level? I think the reason they try to set that is because of how mod_ssl
expects things. As an administrator I wouldn't want to specify that
stuff. I'd like to specify a certain security level such as SECURE128 or
SECURE192.

A vast majority of users should ever use the level in the priority
strings, I agree.

However, when that is not sufficient, yes, the users do wish to specify
individual cipher suites.

A particular example is where an LDAP server has to support a large number
of cipher suites due to a wide variety of clients and connections.
(For example, some clients are known to be in a trusted part of a network,
others use e.g. wireless.)

Restricting the cipher suites on the server is not feasible,
so it has to be done on a per-client (per client type) basis.

Again, most of that is not really a security issue, but political.

For example, if an organization can configure all their workstations
connected wirelessly to use TLS_RSA_CAMELLIA_256_CBC_SHA1 on TLS1.0
connections only, it is simple to document, monitor (ie. only one cipher,
mac, kx, and TLS version to monitor for security advisories), and
report to non-technical pointy-haired bosses.

Let me reiterate: I find the levels extremely useful, and will always
use and recommend them myself. However, for the other cases,
like requiring a specific cipher suite, GnuTLS priority strings
are very complicated to get exactly right.

(For Ubuntu, which still uses GnuTLS-2.12, with the OpenLDAP StartTLS
bug when compiled against GnuTLS, I had to write a small ldapsearch-like
program that also accepts the priority string as a command line
parameter, to experimentally find a suitable priority string
for a colleague.)

Post by Nikos Mavrogiannopoulos
Yes. Note that during the handshake, the server and the client would
need to process this list and remove the ciphersuites that are not
compatible with their keys (but if an index is used as you propose that
would be pretty efficient).

My thoughts exactly.

gnutls_priority_init() would still have to internally keep cipher, mac,
and kx priority lists, in case the priority string specifies those,
and select applicable cipher suites added to the list.
That is not a problem, as it is just a variant of the code in
lib/algorithms/ciphersuites.c:_gnutls_supported_ciphersuites().

The only real problem I can see is in finding out a suitable set
of logical rules. For example, if the cipher suite specifies both
cipher suites, and cipher algorithms, how these interact?

I'm leaning towards adding cipher suites based on cipher-mac-kx separately
from named cipher suites, but removal being common, and operating only
up to that point in the priority string. It seems to feel most intuitive,
and lead to sane code.

Post by Jouko Orava
Another option would be to revamp the priority string parsing
entirely, and move to one that allows reasonable compatibility
with OpenSSL priority strings.

Yes, I'm not really in favour of that option myself, either.
I just wanted to state it, because it is an option often expressed in
bug reports and similar complaints with e.g. OpenLDAP.

I'd much rather have a clear set of logical rules,
that would be easy to use.

Post by Jouko Orava
A third option would be to enhance the current priority string
parsing, but in a way that allows automatic conversion between
GnuTLS and OpenSSL priority strings

I was thinking more about larger organizations, where most of the servers
tend to be of the RHEL/CentOS/ScientificLinux variety (using OpenSSL),
and workstations of the Debian/Ubuntu/Mint variety (using GnuTLS),
and keeping configurations compatible.

Given the configured priority string on one, the tool could describe
the effects in human-readable terms, and show compatible rule in the
other. Preferably with recommendations (like "PERFORMANCE" or "SECURE256"
for GnuTLS).

Best regards,
Jouko

Nikos Mavrogiannopoulos

2013-01-28 01:17:48 UTC

Post by Nikos Mavrogiannopoulos
Yes, but for these people the priorities NORMAL, PERFORMANCE or SECURE
should be clearly advertised by the applications.

SECURE256 is pretty high security for today's standards. Most probably
with such a priority string you wouldn't be able to connect to many servers.

Post by Jouko Orava
The only real problem I can see is in finding out a suitable set
of logical rules. For example, if the cipher suite specifies both
cipher suites, and cipher algorithms, how these interact?
I'm leaning towards adding cipher suites based on cipher-mac-kx separately
from named cipher suites, but removal being common, and operating only
up to that point in the priority string. It seems to feel most intuitive,
and lead to sane code.

It could be two different modes. One that you specify explicitly
ciphersuites, and the other that is like now (level+ciphers,macs etc.).

Does this make sense?

Post by Jouko Orava
A third option would be to enhance the current priority string
parsing, but in a way that allows automatic conversion between
GnuTLS and OpenSSL priority strings

I was thinking more about larger organizations, where most of the servers
tend to be of the RHEL/CentOS/ScientificLinux variety (using OpenSSL),
and workstations of the Debian/Ubuntu/Mint variety (using GnuTLS),
and keeping configurations compatible.
Given the configured priority string on one, the tool could describe
the effects in human-readable terms, and show compatible rule in the
other. Preferably with recommendations (like "PERFORMANCE" or "SECURE256"
for GnuTLS).

It sounds reasonable.

regards,
Nikos

Jouko Orava

2013-01-28 06:54:12 UTC

Post by Nikos Mavrogiannopoulos
It could be two different modes. One that you specify explicitly
ciphersuites, and the other that is like now (level+ciphers,macs etc.).
Does this make sense?

Absolutely, and that's also the reason I haven't yet tested the patches I
proposed earlier (making '+' optional, for example).

Here's the logic rules I've been considering.
I'm not entirely happy with it, and I think it needs further work.
It is quite possibly too complicated (for users).
(I do believe the implementation would be straightforward, though.)

"!" <ciphersuite>
"!" <protocol>
"!" <certificate>
"!" <compression>
"!" <signature>
"!" <cipher>
"!" <mac>
"!" <key exchange>
Completely disallow (ban).
Applies as if these were listed last in the string.

"!" <level>
Ban all cipher suites in <level>
from the current priority set.
(Other features of <level> are ignored.)

"-" <ciphersuite>
"-" <protocol>
"-" <certificate>
"-" <compression>
"-" <signature>
"-" "%" <option>
"-" <cipher>
"-" <mac>
"-" <key exchange>
Remove from the current priority set.
Applies only to the left in the string,
up to the last <level> encountered.

"-" <level>
Remove all cipher suites in <level> from
the current priority set.
(Other features of <level> are ignored.)

<level>
<ciphersuite>
<protocol>
<certificate>
<compression>
<signature>
"%" <option>
Add to current priority set.

<cipher>
<mac>
<key exchange>
Add to temporary priority lists.
At the end of string, or at the next full cipher
suite name (added, removed, or banned), the
temporary lists will be converted to cipher suites,
and added to the priority set.
(Cipher suites that match any of the "!" bans will
not be added to the priority sets, of course.)

All strings are case sensitive.

Instead of "-ALL" suffixes, catch-alls could use an asterisk "*".
For example, any TLSv1 protocol could be "TLSv1.*".

"NONE" should include "no compression". Compression can be required
by explicitly banning or removing "no compression".

To distinguish between the existing parsing, this format would
require a start marker, for example "@" or "New".
Anything not accepted by the existing parser would be acceptable.
As it would be at the beginning of the string, it would be very easy to
factor out the common (splitting) code but keep the other parsing
separate, making for cleaner code without unnecessary repetition.

Thoughts? Comments? Better ideas?

Best regards,
Jouko

Nikos Mavrogiannopoulos

2013-01-29 08:29:50 UTC

Post by Nikos Mavrogiannopoulos
It could be two different modes. One that you specify explicitly
ciphersuites, and the other that is like now (level+ciphers,macs etc.).
Does this make sense?

What is the purpose of being able to remove ciphersuites from a level?

Post by Jouko Orava
Instead of "-ALL" suffixes, catch-alls could use an asterisk "*".
For example, any TLSv1 protocol could be "TLSv1.*".

That is more intuitive and could be added to the old format as well, in
a backwards compatible way.

Post by Jouko Orava
"NONE" should include "no compression". Compression can be required
by explicitly banning or removing "no compression".

Why is that? None should be really none, so that you can specify exactly
what you need. That's how it is used now.

Post by Jouko Orava
To distinguish between the existing parsing, this format would
x <ciphersuite>
x <protocol>
x <certificate>
x <compression>
x <signature>
% <cmd>

x = + | " "

That is you'll choose the new format to specify ciphersuites, and use
the old format if you want to specify individual algorithms/levels.

I wouldn't like to have more than a way to do the same thing.

regards,
Nikos

Jouko Orava

2013-02-01 11:02:29 UTC

Consider
PERFORMANCE:-EXPORT
for those who really dislike the ciphers in the export level.

EXPORT isn't a subset of PERFORMANCE, so this string would pretty
much be identical to PERFORMANCE.

Ah, bad example, then. It just seems that
"Performant algorithms, but none of that export crap"
and similar configuration strings seem very intuitive for users.

I can see no downside in supporting that (assuming my view that users
do find that intuitive and useful is correct).

I don't know what you mean with a closed set here. In all types of the
supplied strings you must have one (at least one cipher/mac etc.).

I understand. I believe users see it differently, as an extra
option that can be added; not an integral feature.

At least it surprised the heck out of me when I realized I must
explicitly enable no compression. It just felt unexpected and
weird to me.

Nevertheless I understand that this is an complication for many, so
there could be a new level that contains it?

Right; that sounds much better than changing existing behaviour.
I feel a bit silly for not realizing that earlier .. :)

As I understand from your previous description, you add the
ciphersuite name in addition to all existing options, plus some
changes regarding the '+'? Couldn't this be added over the current
priority string format?

Lets see.

Assume we keep the current behaviour regarding priority strings,
but with cipher, key exchange, and MAC priority lists converted
to cipher suite priority list at the end of gnutls_priority_init().

Make "+" prefix optional, so we have
<add-prefix> ::= "+" | nothing
<del-prefix> ::= "-" | "!"

Allow
<del-prefix> <level>
to remove cipher suites present in <level>,
making it easier for users to combine levels.

(Even if the levels do not overlap, it may be useful
in non-technical terms for the user to be able to
specify that. For example, using "PERFORMANCE:!EXPORT"
you can unequivocably state to pointy-haired-bosses that
weak export-grade ciphers are not used,
even if technically "PERFORMANCE" by itself already does that.)

Allow
<add-prefix> <cipher-suite>
<del-prefix> <cipher-suite>
to add and remove cipher suites.

Thus far this looks excellent to me.

One issue remains: How should the
<del-prefix> <cipher>
<del-prefix> <mac>
<del-prefix> <key exchange>
interact with the cipher suites?
I think I have a workable suggestion:

When removing a cipher, mac, or key exchange,
apply the removal directly to BOTH the internal
priority list, and existing cipher suite list.

Consider, for example:
SECURE256:!AES_256_CBC:TLS_RSA_AES_256_CBC_SHA1
This would result in allowing TLS_RSA_AES_256_CBC_SHA1,
but not allowing any other cipher suite using AES_256_CBC cipher.
Very logical and intuitive, in my opinion.

Better yet, this can be proven to not change the interpretation
of current configurations!

I would be happy to write a more detailed logical spec of this
to the list, if you think this is a possible avenue to go forward
with. Do you prefer BNF, or free-form/human readable?

Best regards,
Jouko

Nikos Mavrogiannopoulos

2013-02-01 13:36:09 UTC

Consider
PERFORMANCE:-EXPORT
for those who really dislike the ciphers in the export level.

EXPORT isn't a subset of PERFORMANCE, so this string would pretty
much be identical to PERFORMANCE.

Ah, bad example, then. It just seems that
"Performant algorithms, but none of that export crap"
and similar configuration strings seem very intuitive for users.
I can see no downside in supporting that (assuming my view that users
do find that intuitive and useful is correct).

[...]

Post by Jouko Orava
(Even if the levels do not overlap, it may be useful
in non-technical terms for the user to be able to
specify that. For example, using "PERFORMANCE:!EXPORT"
you can unequivocably state to pointy-haired-bosses that
weak export-grade ciphers are not used,
even if technically "PERFORMANCE" by itself already does that.)

I do believe that this will cause more confusion with the currently
available levels, but could be useful when we have more levels that
act more like a group of ciphers.

Let's then rename level to cipher-group (or ciphersuite-group) to
signify better it's purpose.

Post by Jouko Orava
One issue remains: How should the
<del-prefix> <cipher>
<del-prefix> <mac>
<del-prefix> <key exchange>
interact with the cipher suites?
When removing a cipher, mac, or key exchange,
apply the removal directly to BOTH the internal
priority list, and existing cipher suite list.
SECURE256:!AES_256_CBC:TLS_RSA_AES_256_CBC_SHA1
This would result in allowing TLS_RSA_AES_256_CBC_SHA1,
but not allowing any other cipher suite using AES_256_CBC cipher.
Very logical and intuitive, in my opinion.

Indeed.

Post by Jouko Orava
I would be happy to write a more detailed logical spec of this
to the list, if you think this is a possible avenue to go forward
with. Do you prefer BNF, or free-form/human readable?

I think the best would be a description that could be part of the
manual (so that there is no double work to port it there). However,
would you be interested in implementing it? I could help with that if
needed.

regards,
Nikos

Jouko Orava

2013-02-01 17:55:45 UTC