Update to FreeRADIUS 1.1.6: Apart from bug fixes, the only additions are three new dictionaries. SECURITY ISSUE - There is a security issue fixed in 1.1.6, which is a potential DoS due to a memory leak in the EAP-TTLS code. Anyone using EAP-TTLS should upgrade to this version. More information at http://www.freeradius.org/security.html#1.1.5. (I do intend to submit a VuXML entry - but if anyone wants to do this for me, they're welcome!) Other changes in this version of the port: chmod -R g-w,o-rwx ${PREFIX}/etc/raddb on install - FreeRADIUS will probably complain if the configuration files in raddb don't have these permissions from version 1.1.5 onwards. Modify CONFLICTS to take account of the likelihood that FreeRADIUS 2 will be released reasonably soon. Move to handling NOPORTDOCS using the new --without-docdir option to configure. [1] Fix handling of (NO)PORTDOCS in pkg-plist. Unnecessary patches that add ${CFLAGS} to 'libtool --mode=link' steps deleted. [2] If anyone gives a good reason as to why ${CFLAGS} are needed in a link step, these patches may be considered for incorporation into FreeRADIUS - see http://lists.freeradius.org/pipermail/freeradius-users/2007-March/061372.html A further patch that fixed a Makefile bug is now redundant, as it's been fixed in the upstream release. [3] Remove unnecessary DICTS= and related code from Makefile (FreeRADIUS' install routine does the job perfectly well without this). General tidy up of post-patch and post-install targets in Makefile. I hope that the deleted patches will make future maintenance much easier! Fix: Note: files/patch-raddb-Makefile-1.1.4_bug [3] files/patch-doc::Makefile [1] files/patch-src::module::rlm_sql::rules.mak [2] files/patch-src-main-Makefile.in [2] files/patch-src::module::rules.mak [2] are all deleted. Patch attached with submission follows:
Responsible Changed From-To: freebsd-ports-bugs->stas I'll take it.
Hi Stanislav, In message <20070413220443.b59e2a77.stas@FreeBSD.org>, Stanislav Sedov <stas@FreeBSD.org> writes >I've tweaked patch a bit to fit standard 80-column layout and exclude >unnecessary steps. What do you think about it? I've diffed your version of the port against mine to review your changes. The 80 column stuff - mostly this relates to parts of the Makefile that I inherited, but I'm grateful for your clean up. In the post-patch target of the Makefile, I had considered passing -i "" to ${REINPLACE_CMD}. In fact, I would argue for ${SED} -i "" because ${REINPLACE_CMD} is defined in bsd.port.mk as ${SED} -i.bak and two -i parameters could lead to undefined results. It's important to make sure that no spurious files land up in doc/, otherwise they get installed as documentation - that's the whole point of either not generating or deleting Makefile(\.in)?\.bak files. Including Makefile(\.in)?\.orig in the same step was a defence against any Makefiles that were patched with files/patch... files - as doc/Makefile was up until this version when --without-docdir became available as a parameter to configure. The man page for sed(1) warns against -i "" because of undesired side-effects in some admittedly rare cases. With that warning in mind, I deliberately chose the safer two step process in my version of the Makefile. If you feel the two step process is undesirable, then I think the right answer is (untested): @${FIND} -E ${WRKSRC} -regex '.*/Makefile(\.in)?$$' -exec ${SED} -i "" \ -e "s:\$$(R)\$$(raddbdir):${EXAMPLESDIR}/raddb:g" {} \; My strong preference is to stay with what I had for the sake of safety both bearing in mind the warning with sed -i and possible future needs to patch Makefiles, especially doc/Makefile. I don't believe the second step adds too much to the overhead of the post-patch target - I have optimised it further in this patch compared to previous versions by moving to the use of "find ... -delete". >Also I changed NOPERL option to PERL. NOPERL seems to be not very good >name for me. I understand your thinking - though I've three arguments against it. Argument 1: Having an option that is worded as disabling something (with a warning) helps to distinguish this from the regular "do I want LDAP support or not", "do I want MySQL support or not" sort of choices. Your version is slightly less strong. It's very important not to build FreeRADIUS without Perl unless you know what you're doing - some FreeRADIUS functionality isn't guaranteed to work without Perl. In fact, this option isn't "Use perl" as you worded it (or "Don't use perl" as I had it) - it's something a bit more subtle. See later. Argument 2: The option was NOPERL because the option was introduced before the recent change in bsd.port.mk that enhances the tests allowed against OPTIONS. My original choice for the option was PERL, but bsd.port.mk at the time didn't set WITHOUT_PERL appropriately. Rather than dealing with that, I went for NOPERL and tested for WITH_NOPERL which worked fine. This also kept the default of all options as off, which meant turning any option on was a deliberate decision to configure away from the default. Argument 3: Previous versions of the port have had the NOPERL option, and I'd rather not reverse the sense of an existing option, particularly one that is so important. How many users - especially anyone still on 4.x who doesn't have the new logic in bsd.port.mk to display the OPTIONS when they change from version to version are going to do the wrong thing if it's changed now? Argument 1 is very weak and I'll happily concede it. Argument 2 is rather weak. Maybe I should have stuck with PERL and used ".if !(WITH_PERL)" - but I didn't. Meanwhile, I don't want to rely on new features in bsd.port.mk post 4.x EOL because particularly the embedded users of this port may still be on FreeBSD 4.x. It's for that reason I haven't yet ripped out 4.x support, though I'm not personally testing on 4.x Argument 3 is, I think, compelling - it has been NOPERL for a couple of versions already. I accept your argument that the naming of the option is messy and not entirely orthogonal, but don't see a good reason to change things now, especially as it's so important that people don't turn off the dependency on Perl unless they understand the consequences. As I said in argument 1, NOPERL isn't actually a "don't use perl" option. It disables the port's dependency on perl, which is precisely how I worded the existing NOPERL option. It also instructs configure not to build rlm_perl - but there are other features in FreeRADIUS that use perl, particularly Simultaneous-Use. Unfortunately there's no argument to tell configure to ignore perl completely. With the NOPERL set (or, if we change it, PERL unset) configure will still notice perl on the system if it's there, and will use it, even though the resulting port doesn't have a run-time dependency on perl (which is undesirable). Maybe the port should fail to build with an error if NOPERL is set and perl is detected via the PATH, but, apart from the building of rlm_perl, the dependency on Perl may be a run time rather than a build time dependency. Without deeper investigation I don't know exactly what happens if Perl isn't detected by configure (or if I patched configure to allow me to disable the test for perl in the case when NOPERL was set), but is available at run time. In other words, NOPERL (or PERL if we reverse the sense of the option) isn't a "Don't use perl" or "Use perl" option. It's "Don't require perl on the system to build and the port" - not quite the same thing. As I said, this was introduced in response to a specific request from someone to be able to disable the port's dependency on Perl without patching the port so that he could build packages for use on Soekris boards. Only a user in this specific situation should change this option away from the default - and even then, they should satisfy themselves that not having Perl on their system doesn't compromise FreeRADIUS for their use. To that end, I felt that the warning I had attached to the option was sufficient rather than putting a lot of effort into a full analysis of the side-effects of removing the Perl dependency. A full analysis will probably lead to changes either to the port and/or configure to make the behaviour more circumspect in this rare case. In summary, as it has been NOPERL for a while, I'd rather it stayed as NOPERL. If you insist it's changed to PERL, I would want to be sure of no unwanted consequences for those upgrading, particularly for those who want to maintain the recommended dependency on Perl. In doing this, I want to keep in mind those users still on 4.x who can't use a version of bsd.port.mk with the most recent upgrades in OPTIONS handling which should mean that make config runs when upgrading if the OPTIONS have changed. Many thanks for your review and comments, David -- David Wood david@wood2.org.uk
On Fri, 13 Apr 2007 22:18:42 +0100 David Wood <david@wood2.org.uk> mentioned: > In the post-patch target of the Makefile, I had considered passing -i "" > to ${REINPLACE_CMD}. In fact, I would argue for ${SED} -i "" because > ${REINPLACE_CMD} is defined in bsd.port.mk as ${SED} -i.bak and two -i > parameters could lead to undefined results. > Well, my fault... I was thinking about modifying REINPLACE_ARGS to set it to '-i ""' but ended up by passing -i directly to REINPLACE_CMD. Sorry for noise. I believe, the correct solution should be REINPLACE_ARGS= -i "" in Makefile. > As I said, this was introduced in response to a specific request from > someone to be able to disable the port's dependency on Perl without > patching the port so that he could build packages for use on Soekris > boards. Only a user in this specific situation should change this option > away from the default - and even then, they should satisfy themselves > that not having Perl on their system doesn't compromise FreeRADIUS for > their use. > > To that end, I felt that the warning I had attached to the option was > sufficient rather than putting a lot of effort into a full analysis of > the side-effects of removing the Perl dependency. A full analysis will > probably lead to changes either to the port and/or configure to make the > behaviour more circumspect in this rare case. > > > In summary, as it has been NOPERL for a while, I'd rather it stayed as > NOPERL. > > If you insist it's changed to PERL, I would want to be sure of no > unwanted consequences for those upgrading, particularly for those who > want to maintain the recommended dependency on Perl. In doing this, I > want to keep in mind those users still on 4.x who can't use a version of > bsd.port.mk with the most recent upgrades in OPTIONS handling which > should mean that make config runs when upgrading if the OPTIONS have > changed. > Thanks for such a long explanation, now I see your reasons. What about stripping the NOPERL off the OPTIONS and leaving it as configuration variable only for users who know what they're doing? This will work on 4.x and will not mess ordinary users? Probably not now, but in future upgrades... -- Stanislav Sedov ST4096-RIPE
stas 2007-04-14 10:01:29 UTC FreeBSD ports repository Modified files: net/freeradius Makefile distinfo pkg-plist Removed files: net/freeradius/files patch-doc::Makefile patch-raddb-Makefile-1.1.4_bug patch-src-main-Makefile.in patch-src::modules::rlm_sql::rules.mak patch-src::modules::rules.mak Log: - Update to 1.1.6 - Set correct permissions to ${PREFIX}/etc/raddb on install - Modify CONFLICTS to take account of the likelihood that FreeRADIUS 2 will be released reasonably soon - Move to handling NOPORTDOCS using the new --without-docdir option to configure - Fix handling of (NO)PORTDOCS in pkg-plist - Remove unnecessary patches and simplify makefile PR: ports/111521 Submitted by: David Wood<david@wood2.org.uk> (maintainer) Revision Changes Path 1.56 +32 -60 ports/net/freeradius/Makefile 1.20 +3 -3 ports/net/freeradius/distinfo 1.6 +0 -18 ports/net/freeradius/files/patch-doc::Makefile (dead) 1.2 +0 -11 ports/net/freeradius/files/patch-raddb-Makefile-1.1.4_bug (dead) 1.6 +0 -14 ports/net/freeradius/files/patch-src-main-Makefile.in (dead) 1.3 +0 -13 ports/net/freeradius/files/patch-src::modules::rlm_sql::rules.mak (dead) 1.4 +0 -11 ports/net/freeradius/files/patch-src::modules::rules.mak (dead) 1.29 +4 -0 ports/net/freeradius/pkg-plist _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: open->closed Committed. Thanks!