Only "string" can have "encrypt=2"

Bjørn Mork bjorn at
Mon Nov 21 14:48:10 CET 2011


I just stumbled across this which made me worry a bit:

commit f8f58e4bec03d832ad4480b90e7dd531ae0d787d
Author: Alan T. DeKok <aland at>
Date:   Wed Oct 19 17:20:37 2011 +0200

    Only "string" can have "encrypt=2"

diff --git a/src/lib/dict.c b/src/lib/dict.c
index f613664..bdf8065 100644
--- a/src/lib/dict.c
+++ b/src/lib/dict.c
@@ -906,6 +906,13 @@ static int process_attribute(const char* fn, const int line,
                                                    fn, line, key);
                                        return -1;
+                               if ((flags.encrypt == FLAG_ENCRYPT_ASCEND_SECRET) &&
+                                   (type != PW_TYPE_STRING)) {
+                                       fr_strerror_printf( "dict_init: %s[%d] Only \"string\" types can have the \"encrypt=2\" flag set.",
+                                                           fn, line);
+                                       return -1;
+                               }
                        } else if (strncmp(key, "array", 8) == 0) {
                                flags.array = 1;

The reason I'm worrying is dictionary.erx, where I know there are other
types (integer, octets and ipaddress) with "encrypt=2" set.  And these
are in fact in use, with encryption, by a number of Juniper JUNOS and
JUNOSe based devices.

And the second issue that made me worry: Why didn't I (and everybody
else) hit that by default in ictionary.erx?  Well, it seems that
FLAG_ENCRYPT_ASCEND_SECRET isn't really 2 as the above made me believe.
It is 3.   2 is of course FLAG_ENCRYPT_TUNNEL_PASSWORD.

But if it's a typo, then why repeat it in the commit message as well?
Was this an attempt to disable other encryption types that
FLAG_ENCRYPT_TUNNEL_PASSWORD for other attribute types that strings? Or
what exactly was the above trying to fix?

Anyway: Please don't disable tunnel-password encryption of non-string
attributes.  It works, and it *is* in use.

Bjørn (coloured confused)

More information about the Freeradius-Users mailing list