hi,

So they still distribute 3.0.12, but with everything fixed.

no. not everything fixed. everythign fixed would be eg 3.0.15 - I still dont understand why they dont just upgrade the version rather than do backports.

This way of incorporating security-related bug fixes into source is interesting in a number of ways: - Sometimes it's simpler: For the TLS-Cache issue with 3.0.12, they simply changed the default config by removing the entire cache {} section from the eap config file. --> quick, simple, and non-disruptive (could only hamper performance in special cases)

ummm, okay - so for any sites doing lots of EAP, performance sucks. those people then come to the list and we tell them to 'just enable the cache option in eap module - et voila! now server insecure because the version in use was not patched! their solution is awful! :(

- For the fuzzing issues found in 3.0.14, they incorporated the fixes into their 3.0.12 source tree -- but it took them 11 days in this case. This includes extensive tests, though.

..why not just use 3.0.14? what a waste of their time/resources . :/ sorry, if someone says they are using 3.0.12 then I can only assume its the same code as I know/see - if someone else has been playing around with it, removing things, changing things then who knows what else is broken or not working? fundamentally, there are more issues/errors than just some security issues - theres a reason why 3.0.15 exists, for example, and why we say people should use it - many other things , many other fixes/features. no break on upgrade. alan

Am 07.09.2017 um 15:06 schrieb Alan DeKok:

So removing security checks is just not going to happen. Yeah, I actually wanted to second that.

But since everyone including FR relies on the dynamically linked libraries (SSL here), this specific security check boils down to checking the exact version, right? I thought the discussion started by Rui is about this snippet from debian/rules: ---------------------------------------------------------------------------------------------------- # Add dependency on distribution specific version of openssl that fixes Heartbleed (CVE-2014-0160). ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes) SUBSTVARS = -Vdist:Depends="libssl1.0.0 (>= 1.0.1f-1ubuntu2)" else SUBSTVARS = -Vdist:Depends="libssl1.0.0 (>= 1.0.1e-2+deb7u5)" endif ----------------------------------------------------------------------------------------------------- Or have I missed some additional checks?

...

So they still distribute 3.0.12, but with everything fixed. No. 3.0.15 would be "everything fixed". correct myself: They still distribute 3.0.12, but with security holes fixed in default config.

I find it hard to judge the Debian approach to security patches. Clinging to a particular version like that often means overdoing things. On the other hand, AFAIR with Heartbleed, they did a real good job by very quickly delivering a bugfix-only update. But as things are, I will continue compiling FR myself. Just good you provide all the prerequites. I do appreciate scurity-bugfix-only updates, though ;-) Cheers, Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg

And missing lots of other fixes, documentation updates, etc.

IMO, there one good idea in the Debian approach: Treat security fixes sperately from any functional changes. No matter what improvements a new version brings, you almost always want to have a stable, secure environment you can build your next enhancement on. E.g. Debian packaging was broken at least twice in the FR 3.0.x series. I don't complain about that at all, but having an intermediate, (security-)bugfix-only release would give all the production sites out there a very clear and simple path to *quickly* cope with security issues. Just a suggestion, though, and surely not a new idea. Cheers, Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg

On Sep 8, 2017, at 11:24 AM, Martin Pauly <pauly@hrz.uni-marburg.de> wrote:

IMO, there one good idea in the Debian approach: Treat security fixes sperately from any functional changes. No matter what improvements a new version brings, you almost always want to have a stable, secure environment you can build your next enhancement on.

That's fine... but the result is that *we* take the hit of supporting their users who refuse to upgrade. There are people who complain about bugs, get told they're already fixed in newer versions, and then complain that they MUST use the upstream distribution. Well, if you won't upgrade and they won't support you, why is it *my* problem? Don't complain to me if you stapled your feet to the floor.

E.g. Debian packaging was broken at least twice in the FR 3.0.x series. I don't complain about that at all, but having an intermediate, (security-)bugfix-only release would give all the production sites out there a very clear and simple path to *quickly* cope with security issues.

Just a suggestion, though, and surely not a new idea.

It's what most distributions do... and it creates problems for us. They don't care, because they're not affected by it. Alan DeKok.

On Sep 9, 2017, at 12:11 AM, Fajar A. Nugraha <list@fajar.net> wrote:

I think the problem arise because users see the debian directory, and expect to build it successfully (i.e. following https://wiki.freeradius.org/building/Debian-and-Ubuntu). But that fails for debian 9.

I can't feel overly responsible for distributions which break application software. There's really no other way to describe this. They've added patches to Debian after 3.0.15 was released, and those patches break *all* versions of FreeRADIUS.

IMHO some possible options are: (a) add some instructions (e.g. on https://wiki.freeradius.org/building/Debian-and-Ubuntu), something like 'if you're absolutely sure you're using patched/non-vulnerable versions of openssl, then you can edit these files manually, but don't complain if it's broken", and so on. And point any debian-package-related queries there. OR

I've pushed patches to v3.0.x which should help. I'll see if I can add notes to the wiki.

(b) someone who cares-enough about having latest FR runs on debian need to find better check methods (e.g. add versions known as safe, etc). Possibly still include some instructions on the wiki (if user still need to edit config files manually to remove additional version checks). OR

We'll try to get automated builds set up... right now, we're up to a backlog of ~10-20 systems that people want.

(c) a volunteer steps up to maintain latest (unofficial) FR packages for debian, to make it easier for other debian users. You could even use github to host the repository, so no need to maintain your own server. You'd basically just need time to maintain it.

People don't care about RADIUS. :( Maybe that will change once we add DNS to the server in v4. Alan DeKok.

Alan DeKok wrote:

On Sep 8, 2017, at 11:24 AM, Martin Pauly <pauly@hrz.uni-marburg.de> wrote:

...

IMO, there one good idea in the Debian approach: Treat security fixes sperately from any functional changes. No matter what improvements a new version brings, you almost always want to have a stable, secure environment you can build your next enhancement on.

That's fine... but the result is that *we* take the hit of supporting their users who refuse to upgrade.

There are people who complain about bugs, get told they're already fixed in newer versions, and then complain that they MUST use the upstream distribution.

Well, if you won't upgrade and they won't support you, why is it *my* problem? Don't complain to me if you stapled your feet to the floor.

Yes. I'm also fed up by Linux distribution packagers blaming me for making new releases. This is a problem many open source projects have. And it really gets bizarre when people are insisting on using binary packages because they already pay for a support contract for an enterprise distribution but then blame upstream developers for not providing a specific solution at no charge. Ciao, Michael.

Alan,

That's fine... but the result is that*we* take the hit of supporting their users who refuse to upgrade.

There are people who complain about bugs, get told they're already fixed in newer versions, and then complain that they MUST use the upstream distribution.

Well, if you won't upgrade and they won't support you, why is it*my* problem? Don't complain to me if you stapled your feet to the floor.

I'm afraid you got me a bit wrong here. I have understood that the Debian approach is basically broken from the main developer's view (didn't really know it this bad before this discussion, though). I am not asking for "distribution pampering" here. I am asking for a seperation of security-relevant fixes from functional changes in the official releases. Actually, the 3.0.15 release already comes pretty close to this. From the release notes I read 4 feature improvements, but 26 bugfixes, at least 15 of which are security-relevant. So if you had funneled the bugfixes into some extra release, it would not have made much of a difference, right? So far, so good. But immediately the question arises what to to with older versions. There will always be people asking for a security-only release for their old version. So even if you adopted this idea, you would have to impose a practical limit. In the simplest form, you could do it only for the current version. In practice I would suggest going back to some point _you_ decide, e.g. 3.0.12 in this example. Why would this help? There's quite a number of people out there who run FR with very limited resources, especially when it comes to software and network skills. Like it or not, this is reality. Many IT departments are understaffed or underfunded or both. On the other hand, most installations use only a very limited subset of FR's huge functionality. So once you'vo got it to do what you need, you want to change as little as possible to address a particular security issue. Other functional improvements can easily be postponed, security fixes cannot in general. Thanks for listening Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg

On Sep 11, 2017, at 3:42 AM, Martin Pauly <pauly@hrz.uni-marburg.de> wrote:

I'm afraid you got me a bit wrong here.

That was more of a general rant against bad practice, and not against you in particular.

I have understood that the Debian approach is basically broken from the main developer's view (didn't really know it this bad before this discussion, though). I am not asking for "distribution pampering" here. I am asking for a seperation of security-relevant fixes from functional changes in the official releases.

The security fixes are all broken out in git, as patches.

Actually, the 3.0.15 release already comes pretty close to this. From the release notes I read 4 feature improvements, but 26 bugfixes, at least 15 of which are security-relevant. So if you had funneled the bugfixes into some extra release, it would not have made much of a difference, right?

We only have so much time in a day. If you're willing to pull all of the security fixes back into 3.0.14, 3.0.13, 3.0.12, etc, that would be nice.

So far, so good. But immediately the question arises what to to with older versions. There will always be people asking for a security-only release for their old version. So even if you adopted this idea, you would have to impose a practical limit. In the simplest form, you could do it only for the current version. In practice I would suggest going back to some point _you_ decide, e.g. 3.0.12 in this example.

Feel free to do so.

Why would this help? There's quite a number of people out there who run FR with very limited resources,

Like me, and the other developers.

especially when it comes to software and network skills. Like it or not, this is reality. Many IT departments are understaffed or underfunded or both. On the other hand, most installations use only a very limited subset of FR's huge functionality. So once you'vo got it to do what you need, you want to change as little as possible to address a particular security issue. Other functional improvements can easily be postponed, security fixes cannot in general.

That's all nice. But... it involves *me* doing more work because other people don't want to do more work. Which isn't a very appealing request. Alan DeKok.

Am 09.09.2017 um 17:56 schrieb Michael Ströder:

...

No matter what improvements a new version brings, you almost always want to have a stable, secure environment you can build your next enhancement on.

quite pracitcal: my current, well running instance minus newly discovered security issues. Cf. my other post about why selective security-only updates would make sense for many productive sites. Cheers, Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg

On Sep 11, 2017, at 4:39 AM, Michael Ströder <michael@stroeder.com> wrote:

Martin Pauly wrote Upstream developers often do provide minimal updates but distributions (especially Debian) fall way behind the releases which leads to insanely large update gaps.

In the interest of being "stable", they ship software with known bugs... and then create work for us by making us support their users. Who are using versions which are 5 years out of date. It's ridiculous.

They try to "fix" that by back-porting patches claiming that these old but patched releases are more "stable" (without giving a clear definition of "stable").

For them, "stable" means: - we shipped something 5 years ago and don't want to change it - we put in only the patches which would embarrass us if they weren't added (mainly security fixes) - we ignore customer requests to fix bugs which affect their systems - we ignore upstream requests to update to a newer version of the software

IMO this approach neither is stable nor secure. Repeating this "stable" claim over and over does not make it become true. And it wastes a lot of time.

Absolutely. Alan DeKok.