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

Bug#600465: marked as done (unblock: freeradius 2.1.10+dfsg-2)

Your message dated Wed, 17 Nov 2010 20:53:38 +0000
with message-id <1290027218.25995.466.camel@hathi.jungle.funky-badger.org>
and subject line Re: Bug#600465: unblock: freeradius 2.1.10+dfsg-1
has caused the Debian Bug report #600465,
regarding unblock: freeradius 2.1.10+dfsg-2
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

600465: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600465
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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.

--- End Message ---
--- Begin Message ---
On Sun, 2010-11-14 at 21:40 +0100, Josip Rodin wrote:
> On Sun, Nov 14, 2010 at 08:33:47PM +0100, Josip Rodin wrote:
> > > I'll get to it today. It'll also fix another logging regression that got
> > > reported in the meantime.
> > 
> > Argh, I just read the update, so I guess it's best to clarify, by pasting
> > the changelog entries of the new packages I've been testing and hashing out
> > for a while now: [...]
> I've completed my own basic regression testing, it looks good, and the
> upgrade properly fixed a broken logging and permissions setup where I had
> those issues (600 root:root radiusd.conf). I uploaded it just now.

2.1.10+dfsg-2 unblocked; thanks for your work.



--- End Message ---

Reply to: