coy.hile@coyhile.com wrote:

Did the fixes for my issue #765 go in here?

Yes.

Will there be a 2.2.6 with those fixes as well sometime soon. I'd like to work on getting these pulled into pkgsrc.

Yes. We'll probably release 2.2.6 next week. Alan DeKok.

Hi Arran, On 09/10/2014 11:24 PM, Arran Cudbard-Bell wrote:

On 10 Sep 2014, at 11:59, Alan DeKok <aland@deployingradius.com> wrote:

...

We've release version 3.0.4. It has a long changelong from 3.0.3:

http://freeradius.org/version3.html

But the wait has been worth it, I think. Lots of minor fixes, and many new features.

The regex handling for strings has been fixed. This means that where it was hard / impossible to use regexes before, it's now simpler. The down-side is that you MAY have to update your regexes.

Specifically, if you were using attribute references:

if (&Attribute =~ /my regex/) {

}

The raw value of the attribute will be used without any pre-escaping.

This applies not just to regexes but all comparisons.

update request { Tmp-String-0 := '"foo"' }

Can now be matched with:

if (&Tmp-String-0 := '"foo"') {

Instead of:

if (&Tmp-String-0 := '\"foo\"') {

Using the raw value however means that values with embedded \0s can cause issues.

Most of the comparison code has been fixed, but there's still problems with regexes, due to the POSIX functions (regcomp, regexec), not taking a length argument.

There are non-POSIX extensions (regncomp, renexec), but they're not in the PCRE compatibility library, so we've got to consider what to do there.

If your strings/regexes don't contain/deal with unprintables or double quotes, no changes are required.

Thank you for describing the change. Still, can you provide more details? As this has potential of breaking user configurations, we (Red Hat) should try to be as specific as possible to help people avoid or quickly fix the issues. How was it working before and how is it working now? Am I right that some characters (double quote, perhaps backslash, what else?) were escaped in attribute values before comparison/regex matching? Which ones exactly? Am I right that nothing is escaped now? What do you think should be done to make a configuration compatible with the new version? Or, if there are particular pieces of changed code which are easy to list, I can try to understand what changed myself. Thank you. Nick

Hi Alan, On 09/11/2014 04:17 PM, Alan DeKok wrote:

Nikolai Kondrashov wrote:

...

Still, can you provide more details?

String comparisons were sometimes handled inconsistently. Let's take regular expressions as an example:

if (Filter-Id =~ /foo/) {

The previous code would print the value of the Filter-Id to a string, and then perform the regex check on the printed string. That meant that certain characters like ", ', etc. which were in the Filter-Id were escaped " --> \", etc. That escaping made it difficult to create a regex which matched.

The new behavior is that the regex checks are performed on the Filter-Id string, without any modifications. This means that " is just itself.

The good news is that this change should have minimal effect. The example Filter-Id regex above will work the same way, and won't have it's behavior change.

The ONLY change is for regexes, string compares, etc. which have embedded quotes, backslashes, etc. in them. Previously, the "special" characters had to be escaped. Now they don't.

Thank you for an extended explanation, it makes things clearer. Could you please point me in the general direction where I should look in the code, to see exactly which characters were escaped before? It's not so important, as none are escaped now, as I understand, but will still be useful.

...

As this has potential of breaking user configurations, we (Red Hat) should try to be as specific as possible to help people avoid or quickly fix the issues.

It would also help if RedHat upgraded their version of FreeRADIUS to something other than 2.1.12. That is causing ME problems for support. People keep coming here to complain about issues, because you shipping a version which is 4 years old.

I understand. I will be working on that in an upcoming RHEL6 release - that's the only way we can get a new package version in. Unfortunately, when I stepped into the package maintenance, the window for bringing new versions into the release being done at that time was closing and I was in no condition to advocate for an upgrade yet.

It works both ways. If you want us to help you, it would be polite to help us. So far, the only contributions we've seen from RedHat are bugs fixes for the RedHat builds, and complaints that we need to do more work.

I understand. I hope I wasn't heavy on the complaints personally. With regards for more help, I don't have much time allocated for maintenance, but as I get to know FreeRADIUS better, I hope my help will get more meaningful.

...

Or, if there are particular pieces of changed code which are easy to list, I can try to understand what changed myself.

The git history is publicly available.

Sure, it's just not easy to search through, not knowing what you're looking for. Now that you've given more details it will be easier, but otherwise a file name will help further. Thank you. Sincerely, Nick

On 09/11/2014 11:59 PM, Arran Cudbard-Bell wrote:

...

Thank you for an extended explanation, it makes things clearer.

Could you please point me in the general direction where I should look in the code, to see exactly which characters were escaped before?

fr_print_string

print.c:132

Thank you, Arran. For my own better understanding and perhaps to save time for others, here is my summary of the code. Control characters (< 0x20) and all bytes not making valid UTF-8 character sequences were escaped as \OOO (where O is an octal digit), with the exception of CR, LF and TAB which were escaped as '\r', '\n' and '\t' respectively. Also, '\' and '"' were escaped as '\\' and '\"' respectively. Nick

Stefan Paetow wrote:

Which SPEC was used to build the CentOS packages? The RHEL spec in the package source?

The "redhat" directory in the server source. It's not really RHEL, because RedHat doesn't want that... but it's a package which will work, and which follows the typical RedHat install. Alan DeKok.

On Fri, Sep 12, 2014 at 3:46 PM, Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> wrote:

On 09/10/2014 06:59 PM, Alan DeKok wrote:

...

We've release version 3.0.4. It has a long changelong from 3.0.3:

http://freeradius.org/version3.html

Congratulations on the release! There was surely a lot of work done on it.

I'm also happy to see it done in time to make it into the next RHEL7 release.

Can I ask to have it tagged in Git? It will make seeing which changes got in there and tracking further changes easier.

The tag is there since two days ago https://github.com/FreeRADIUS/freeradius-server/releases -- Fajar

Nikolai Kondrashov wrote:

I didn't notice it, because it didn't get pulled into my repo, and that is because it wasn't a part of any branch, which is unexpected and is somewhat an uncommon practice.

Hmm... Arran deleted the release branch from github. Alan DeKok.