February 2016 - Freeradius-Devel - lists.freeradius.org

Commit report for v3.1.x branch
by announce＠freeradius.org 06 Feb '16

06 Feb '16

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Complaints about required things are errors Alan T. DeKok@2016-02-06T00:30:11Z Files modified: * src/modules/rlm_chap/rlm_chap.c * src/modules/rlm_eap/types/rlm_eap_md5/rlm_eap_md5.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/4084fd8a6f8801a577be… ====== -- This commit summary was generated @2016-02-07T00:00:01Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

Commit report for v3.0.x branch
by announce＠freeradius.org 06 Feb '16

06 Feb '16

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Complaints about required things are errors Alan T. DeKok@2016-02-06T00:29:51Z Files modified: * src/modules/rlm_chap/rlm_chap.c * src/modules/rlm_eap/types/rlm_eap_md5/rlm_eap_md5.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/46b96f9184c406d6f86d… ====== note recent changes Alan T. DeKok@2016-02-06T00:29:20Z Files modified: * doc/ChangeLog Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/0e774e27225165ae7b63… ====== -- This commit summary was generated @2016-02-07T00:00:01Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

Commit report for v3.0.x branch
by announce＠freeradius.org 05 Feb '16

05 Feb '16

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Document =~ and !~ for filtering Alan T. DeKok@2016-02-05T14:48:53Z Files modified: * man/man5/unlang.5 Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/8c57c01f6bbccb5526d9… ====== DHCP strings decoding Header fields of type "string" are null terminated strings, decode them as such Nicolas C (via Alan T. DeKok)@2016-02-05T14:29:09Z Files modified: * src/modules/proto_dhcp/dhcp.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/5a73b60017f58c4f7ac7… ====== Print out extra information only in debug3 Alan T. DeKok@2016-02-05T00:08:28Z Files modified: * src/main/version.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/1b7194bfc0aa7922daf6… ====== Print out the server version number. When starting in debug mode Alan T. DeKok@2016-02-05T00:08:27Z Files modified: * src/main/version.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/4e812d00542be8c46aa5… ====== -- This commit summary was generated @2016-02-06T00:00:02Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

Commit report for v3.1.x branch
by announce＠freeradius.org 05 Feb '16

05 Feb '16

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Merge pull request #1526 from nchaigne/3.1.x-dhcp-hstr [3.1.x] DHCP strings decoding Alan DeKok@2016-02-05T14:28:01Z Files modified: * src/modules/proto_dhcp/dhcp.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/af9a2eca2ebf670d7ed6… ====== [3.1.x] DHCP strings decoding Header fields of type "string" are null terminated strings, decode them as such Nicolas C@2016-02-05T09:35:20Z Files modified: * src/modules/proto_dhcp/dhcp.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/a402e19c26a06f62d655… ====== Print out the server version number. When starting in debug mode Alan T. DeKok@2016-02-05T02:36:05Z Files modified: * src/main/version.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/0dad6a530e8515d06876… ====== Print out extra information only in debug3 Alan T. DeKok@2016-02-05T02:35:53Z Files modified: * src/main/version.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/af3cfa3a2cc3b24722a6… ====== -- This commit summary was generated @2016-02-06T00:00:02Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

DHCP decoder handling of header string fields
by Chaigneau, Nicolas 05 Feb '16

05 Feb '16

Hello, I've noticed that FreeRADIUS DHCP decoder is handling strings from the DHCP header fields a bit oddly. Basically, it allocates a value pair buffer with the maximum field length (64 or 128 octets, for DHCP-Server-Host-Name and DHCP-Boot-Filename respectively) + 1, and memcpy the data then add a '\0'. But RFC 2131 explicitly states that these DHCP fields are null terminated strings. So why not handle them as such ? Current code from "fr_dhcp_decode" function: case PW_TYPE_STRING: q = talloc_array(vp, char, dhcp_header_sizes[i] + 1); memcpy(q, p, dhcp_header_sizes[i]); q[dhcp_header_sizes[i]] = '\0'; fr_pair_value_strsteal(vp, q); if (vp->vp_length == 0) fr_pair_list_free(&vp); break; How about something like this instead ? (copy a string, but do not trust the DHCP field to be actually null terminated) case PW_TYPE_STRING: if (*p != '\0') { uint8_t *end; int len; end = memchr(p, '\0', dhcp_header_sizes[i]); len = end ? end - p : dhcp_header_sizes[i]; q = talloc_array(vp, char, len + 1); memcpy(q, p, len); q[len] = '\0'; fr_pair_value_strsteal(vp, q); } if (vp->vp_length == 0) fr_pair_list_free(&vp); break; This would avoid having things like: DHCP-Server-Host-Name = "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000" DHCP-Boot-Filename = "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000" (I can do a pull request for 3.1.x if you wish) Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

3 2