[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#600465: unblock: freeradius 2.1.10+dfsg-1

Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock


We had FreeRADIUS 2.0.4 in lenny, and this was an upstream point release
pretty much picked at random - it was what was happened to be packaged at
the time lenny froze. It wasn't nearly the last point release before the
cutoff date, I don't think.

People keep coming to the upstream freeradius-users mailing list asking for
help with 2.0.4, and they increasingly get funny looks because it's a
randomly ancient version, by the upstream people's standards.

Right now we have 2.1.8 in squeeze, and I sense the same scenario will
unfold, hence this request. This time at least we have roughly the last
upstream point release before the cutoff date, but at the same time:

* there is some packaging siliness that I really wouldn't want to become
  part of stable - though I have tested upgrades from all previous releases
  and they should all be working, thanks to a multitude of checks in
* there's one long-standing bug that affected a significant portion of
  FreeRADIUS module functionality that was fixed just by applying the right
  new libtool functions.
* the last upstream release, 2.1.10, has a few fixes that the security folks
  thought matter - but that's mostly because someone went through the
  trouble of generating a CVE number for the bugs in question.
  I've seen stuff like that get fixed in FreeRADIUS without CVEs before.
  I've also seen it not get fixed, yet nobody would have paid attention.
* in general, the package is still pretty much standalone and shouldn't
  affect anything else.

So hopefully God won't kill any kittens if you just let this one through :)

If it doesn't go through, no kittens should get harmed either, but the
current scheme of automatically pointing users at lenny-backports will
become commonplace in case of squeeze sooner rather than later, and for
no obvious benefit.

The changelog entries between the version currently in squeeze and the
requested one are:

freeradius (2.1.10+dfsg-1) unstable; urgency=medium

   * New upstream version, closes a bunch of reproducible SNAFUs,
     including two tagged as security issues, CVE-2010-3696, CVE-2010-3697,
     closes: #600176.
   * Build-depend on newer Libtool because of lt_dladvise_init(), also
     upstream now has a configure check so we no longer need a patch,
     yet we still don't want the old behaviour. Noticed by John Morrissey,
     closes: #584151.
   * Added the /etc/default/freeradius file as suggested by
     Rudy Gevaert and Matthew Newton, closes: #564716.
   * Stop symlinking /dev/urandom into /etc/freeradius/certs/random,
     it breaks grep -r in /etc. Instead, replace it inside eap.conf,
     both in the new shipped conffile and in postinst.

 -- Josip Rodin <joy-packages@debian.org>  Thu, 14 Oct 2010 21:51:51 +0200

freeradius (2.1.9+dfsg-1) unstable; urgency=low

   * New upstream version.
     + radclient (radtest) should now use IPv4 by default, closes: #569614.
   * Depend on ca-certificates explicitly, closes: #569601.
   * I mistook ca.pem for the locally selected acceptable CA, whereas that
     actually just happens to mean DebConf.org CA, and we want the former
     by default. That in turn is in /etc/ssl/certs/ca-certificates.crt.
     Obviously later the users can trivially change this, but this looks
     like a reasonably reliable default that doesn't involve a lot of magic
     that can delay or break postinst invocations. In the future, eap.conf
     will become modules/eap and this will not be so critical.
   * The private_key_file = ${certdir}/server.pem default doesn't get along
     with snakeoil, or common sense really (why would you keep a secret key
     in the same file as the non-secret certificate?), and could have broken
     upgrades if people accepted the conffile prompt, so adjusted the
     default conffile too, and adjusted the postinst upgrade logic as well.
   * Enable HAVE_LT_DLADVISE_INIT as it fixes the module symbol lookup
     errors from additional libraries, closes: #416266.
   * Explicate source format as 1.0.
   * Add ${misc:Depends} to all binary packages.
   * Update standards version to 3.8.4, no changes necessary.

 -- Josip Rodin <joy-packages@debian.org>  Sun, 30 May 2010 12:48:55 +0200 


     2. That which causes joy or happiness.

Reply to: