please build with SSL/TLS enabled

[Jeremy Jackson]

Binary package hint: freeradius

Without doing this, freeradius can't be used for WiFI Access point authentication, a fairly significant feature.

the debian/rules file has 2 lines you uncomment, and a couple other things, to enable TLS build.

I tried this on Gutsy amd64 and it works, no other changed needed.

[Paul Hampson (paul-hampson)]

On Tue, Aug 17, 2004 at 06:21:10AM +0200, GiGa wrote:
> Package: freeradius
> Version: 0.9.3-1
> Severity: wishlist

> There is no freeradius package available with the eap/tls module.
> This is a pity since it is more and more used by wifi ap.

That's correct, since the EAP/TLS module depends on OpenSSL but is
released under the GPL. As such, Debian cannot distribute this EAP
module in a binary form.

You may build yourself a copy from the upstream sources, if you so
wish. They are Debianised by myself, so should produce identically
packaged output.

--
Paul "TBBle" Hampson, <email address hidden>
7th year CompSci/Asian Studies student, ANU

Shorter .sig for a more eco-friendly paperless office.

[Jan Sechser (jsechser)]

I don't know, but this could satisfy the different licences.
maybe this will require a seperate build environment, though

Why the hell nowhere at freeradius.org is this mentioned ?

[William Enck (wenck)]

On Wed, Aug 25, 2004 at 04:15:24PM +0200, Jan Sechser wrote:
> I don't know, but this could satisfy the different licences.
> maybe this will require a seperate build environment, though
>
> Why the hell nowhere at freeradius.org is this mentioned ?

It's a hack, but attached is a patch I made. It creates
freeradius-eaptls_0.9.3-1_i386.deb

I'm sure it breaks license rules, but sometimes people just want to get
things working.

-Will

--
William Enck
<email address hidden>

[Steve Langasek (vorlon)]

On Sat, Aug 28, 2004 at 01:29:08PM -0400, William Enck wrote:
> On Wed, Aug 25, 2004 at 04:15:24PM +0200, Jan Sechser wrote:
> > I don't know, but this could satisfy the different licences.
> > maybe this will require a seperate build environment, though

> > Why the hell nowhere at freeradius.org is this mentioned ?

> It's a hack, but attached is a patch I made. It creates
> freeradius-eaptls_0.9.3-1_i386.deb

What advantage does this have over building packages from the upstream
tarball?

> I'm sure it breaks license rules, but sometimes people just want to get
> things working.

I'm not sure why that would belong in a Debian bug report, though.

--
Steve Langasek
postmodern programmer

[William Enck (wenck)]

On Sat, Aug 28, 2004 at 04:28:08PM -0700, Steve Langasek wrote:
> On Sat, Aug 28, 2004 at 01:29:08PM -0400, William Enck wrote:
> > On Wed, Aug 25, 2004 at 04:15:24PM +0200, Jan Sechser wrote:
> > > I don't know, but this could satisfy the different licences.
> > > maybe this will require a seperate build environment, though
>
> > > Why the hell nowhere at freeradius.org is this mentioned ?
>
> > It's a hack, but attached is a patch I made. It creates
> > freeradius-eaptls_0.9.3-1_i386.deb
>
> What advantage does this have over building packages from the upstream
> tarball?

Only advantage I see is that it is now managed by dpkg, and if I decide
to remove freeradius, I will also remove these files. This is why I like
the separate openssl-freeradius-module-eap-tls idea. The above was my
solution until a more formal method could be created. I wanted to share
it with others having the same problem. Now I'm leaving the realm of
Debian bug report, and I will stop.

> > I'm sure it breaks license rules, but sometimes people just want to get
> > things working.
>
> I'm not sure why that would belong in a Debian bug report, though.

Nope, doesn't. Sorry about that.

--
William Enck
<email address hidden>

[Steve Langasek (vorlon)]

On Sat, Aug 28, 2004 at 08:28:58PM -0400, William Enck wrote:
> On Sat, Aug 28, 2004 at 04:28:08PM -0700, Steve Langasek wrote:
> > On Sat, Aug 28, 2004 at 01:29:08PM -0400, William Enck wrote:
> > > On Wed, Aug 25, 2004 at 04:15:24PM +0200, Jan Sechser wrote:
> > > > I don't know, but this could satisfy the different licences.
> > > > maybe this will require a seperate build environment, though
> >
> > > > Why the hell nowhere at freeradius.org is this mentioned ?
> >
> > > It's a hack, but attached is a patch I made. It creates
> > > freeradius-eaptls_0.9.3-1_i386.deb
> >
> > What advantage does this have over building packages from the upstream
> > tarball?

> Only advantage I see is that it is now managed by dpkg, and if I decide
> to remove freeradius, I will also remove these files. This is why I like
> the separate openssl-freeradius-module-eap-tls idea. The above was my
> solution until a more formal method could be created. I wanted to share
> it with others having the same problem. Now I'm leaving the realm of
> Debian bug report, and I will stop.

If you *build packages* from the upstream tarball, they will also be
managed by dpkg.

--
Steve Langasek
postmodern programmer

[Paul Hampson (paul-hampson)]

tags 266229 +help
Thankyou Mr Bug Control Robot

On Wed, Aug 25, 2004 at 04:15:24PM +0200, Jan Sechser wrote:
> I don't know, but this could satisfy the different licences.
> maybe this will require a seperate build environment, though

This doesn't satisfy the license problem at all, since the EAP/TLS
module itself is GPL'd.

> Why the hell nowhere at freeradius.org is this mentioned ?

The FreeRADIUS website does not distribute binaries, so it's not an
issue for them. And of course, if they did, they own the copyright on
the GPL'd code, so they are free to distribute a binary in any fashion
they see fit, should it come to it.

I'll leave this bug open, for the record's sake, and tag it 'help' in
case someone feels like making a gnuTLS patch for FreeRADIUS...

Just to reiterate, I'm looking for help converting (or even a useful
guide to doing so... Google was singularly unhelpful last time I looked)
the eap/TLS (or eap/Peap for that matter) module to use GnuTLS.

Given the code changes, I can massage them to not break the usage of
OpenSSL in the configure scripts if needed. I just found the GnuTLS
instructions really hard to read.

--
Paul "TBBle" Hampson, <email address hidden>
7th year CompSci/Asian Studies student, ANU

Shorter .sig for a more eco-friendly paperless office.

[Paul Hampson (paul-hampson)]

reopen 266229
Thankyou Mr Bug Control Robot

I said 'leave open' not 'mark done'. Sorry 'bout that.
--
Paul "TBBle" Hampson, <email address hidden>
7th year CompSci/Asian Studies student, ANU

Shorter .sig for a more eco-friendly paperless office.

[Paul Hampson (paul-hampson)]

severity 289253 wishlist
merge 289253 266229
Thankyou Mr Bug Control Robot.

Gah. Try merging things of the _same_ severity, eh?
Weird, I thought control wrote back when you sent it
stupid things... I musta skimmed the reply. >_<

--
Paul "TBBle" Hampson, <email address hidden>
7th year CompSci/Asian Studies student, ANU

Shorter .sig for a more eco-friendly paperless office.

[=?ISO-8859-1?Q?=22Jan_Henrik_Helmuth_L=FChr=22?= (jluehr)]

Greetings,

if you cannot distribute this module in binary, why not doing a source
distribution, like sl-modem is doing with sl-modem-source?

For instance:
If you ship just the sources of this module, every user is free to type
install-freerad-eap-tls , and build it's own binary.

Adv:
- No user has download the source and do it by themself
- The whole installing-process can be automatic, apart from suggesting the
user to type a certain command.
- No legal problems due to actually not shipping any binary.
- No one has to patch for gnutls.

Dis-Adv:
- Depencies of dev-packages
(Can be removed anyway)
- Quite a dirty hack.
(But better than nothing)

Anyway, I suggest it.

Keep smiling
yanosz

--
Handyrechnung zu hoch? Tipp: SMS und MMS mit GMX
Seien Sie so frei: Alle Infos unter http://www.gmx.net/de/go/freesms

[Paul Hampson (paul-hampson)]

On Tue, Apr 05, 2005 at 01:04:16PM +0200, "Jan Henrik Helmuth Lühr" wrote:
> Greetings,

> if you cannot distribute this module in binary, why not doing a source
> distribution, like sl-modem is doing with sl-modem-source?

> For instance:
> If you ship just the sources of this module, every user is free to type
> install-freerad-eap-tls , and build it's own binary.

> Adv:
> - No user has download the source and do it by themself
> - The whole installing-process can be automatic, apart from suggesting the
> user to type a certain command.
> - No legal problems due to actually not shipping any binary.
> - No one has to patch for gnutls.

> Dis-Adv:
> - Depencies of dev-packages
> (Can be removed anyway)
> - Quite a dirty hack.
> (But better than nothing)

> Anyway, I suggest it.

Thankyou for your suggestion. I'll consider it, but it seems unlikely to
me to happen for the following reasons:

 - building modules outside of the build process is completely untested
   by me. I'm not even sure _how_ to do it, given we don't distribute
   the bits needed to do so. (Header files et. al.) Once libradius has a
   package of its own, and a -dev package to go with it, this will be
   easier to organise.

 - I'm hoping someone will give in, and contribute a gnuTLS patch. The
   1.1.0 release will have a rearchitectured EAP module set, which means
   only one place to convert from OpenSSL to gnuTLS.

 - I'm trying to not futz with things too much due to the upcoming Sarge
   release. I'd rather a missing feature than a broken feature being
   locked into Sarge for years.

 - The script would have to either produce its own package, or somehow
   install into /usr/local/ somewhere. The former is more work, and the
   latter is rather unappealing.

--
Paul "TBBle" Hampson, <email address hidden>
7th year CompSci/Asian Studies student, ANU

Shorter .sig for a more eco-friendly paperless office.

[Paul Hampson (paul-hampson)]

On Thu, Mar 23, 2006 at 12:14:16PM -0500, Matthew Carpenter wrote:
> On Thursday 23 March 2006 02:52, Paul TBBle Hampson wrote:
>> The short answer is OpenSSL/GPL incompatibility, local build with a
>> couple of small changes to the source (see the top of debian/rules) will
>> solve it.

> I'm afraid I don't understand why the OpenSSL and GPL licenses are an issue in
> this case. FreeRadius is "based on" OpenSSL. OpenSSL is a BSD license, much
> less restrictive than GPL. That's why BSD code ended up in Windows. So why
> is the license and issue?

OpenSSL's not under the BSD license, it's under the OpenSSL license,
which is very similar to the problematic BSD four-clause license, which
is known to be incompatible with the GPL, for example. You're thinking
of the three-clause (no advertising clause) BSD license, which pretty
much exists to allow interaction with the GPL.

In short, the GPL forbids extra restrictions on distribution of GPL'd
code beyond what the GPL contains. The BSD four-clause license adds an
extra restriction, that you must include certain text in any advertising
or feature-listing of the product.

Anyway, how do you know BSD code ended up in Windows? Because the BSD
four-clause license it was under (this is WinSock, right?) required that
Microsoft advertise that they use it. On the other hand, there's no
GPL'd code in Windows, or they'd be required to distribute the source
code with it. ^_^

And of course Windows is considered an operating system, so you can use
GPL'd code on Windows even though it depends on operating-system
components not compatibly licensed, as long as the GPL'd code isn't part
of the OS. (MS's licenses mean that this forbids Internet Explorer or
Windows Media Player from containing GPL'd code, as they are part of the
OS. But addon modules that depend on either (ie. using iBrower or
iMediaPlayer controls) in GPL'd code is fine.

You might find if you want to research further, "GPL considered harmful"
may be enlightening. Also, the GPL vs OpenSSL license FAQ is
specifically relevant. (or in fact FAQs, the FSF has one, the OpenSSL
Project has one, and Debian uses another one [2]. Obviously in Debian we
follow the Debian one's conclusions.)

Of course, you've got to take everyone's conclusions with a grain or two
of salt. The only thing that's actually reliable is the license itself,
and clarifying public statements by the parties that don't conflict with
the license itself.

ie If you agree to a license that states the moon is made of cheese,
(see clause 17 of the GPL) statements by the FSF that the moon is
actually a hole in the sky through which one can see heaven have no
legal standing.

>> Now I look at it, I completely forgot the idea of doing a -src package
>> for people to build... I'll throw that back in my TODO pile.

> Thank you! I appreciate it!

> Could you even put together an add-on package? Perhaps I'm just not grasping
> the issue. I mean if Ubuntu can package up NVidia's 3d graphics driver, I'm
> interested to hear what the issue is between two OSS licenses and Ubuntu
> inclusion. (Then again, I guess I should ask if you even have anything to do
> with the Ubuntu folks)

I'v...

[Frederik Schüler (fs-debian)]

tag 266229 + fixed

quit

This message was generated automatically in response to a
non-maintainer upload. The .changes file follows.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 20 May 2006 15:21:12 +0000
Source: beagle
Binary: beagle python-beagle beagle-dev beagle-backend-evolution libbeagle0
Architecture: source amd64 all
Version: 0.2.6-1.1
Distribution: unstable
Urgency: low
Maintainer: Jose Carlos Garcia Sogo <email address hidden>
Changed-By: Frederik Schüler <email address hidden>
Description:
 beagle - indexing and search tool for your personal data
 beagle-backend-evolution - evolution data backend for beagle
 beagle-dev - library for accessing beagle (development files)
 libbeagle0 - library for accessing beagle (development files)
 python-beagle - python bindings for beagle
Closes: 266229
Changes:
 beagle (0.2.6-1.1) unstable; urgency=low
 .
   * Non-Maintainer upload.
   * Add Build-depends: libmono-sharpzip0.6-cil and
     libmono-sqlite1.0-cil (Closes: #266229)
Files:
 c4f949ea9b3cb62d1d402d7812115edc 1095 gnome optional beagle_0.2.6-1.1.dsc
 52a767ef259c48d8618337bae95443f3 35482 gnome optional beagle_0.2.6-1.1.diff.gz
 54c2585659cd42daf3f96dab246d3b88 59850 gnome optional beagle-backend-evolution_0.2.6-1.1_all.deb
 e688a1d48b5752853666fd05a356afc1 1386886 gnome optional beagle_0.2.6-1.1_amd64.deb
 e89b1aec19ee5ad572a10422989673a9 60732 gnome optional libbeagle0_0.2.6-1.1_amd64.deb
 7e42c825a2a77f0943ddf6109817c184 78290 gnome optional beagle-dev_0.2.6-1.1_amd64.deb
 80283fd5e4fb701f69bbcda3bc8c0991 46070 gnome optional python-beagle_0.2.6-1.1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEcHt96n7So0GVSSARAkAQAJ4mBPWXI3JIk+Sg6OBu3j0dDfn0KQCgk5cY
5F04fU0v4darL04yBGas6WU=
=O/ll
-----END PGP SIGNATURE-----

[Frederik Schüler (fs-debian)]

tags 266229 -fixed
thanks

very embarassing, I closed the wrong bug.

My apologies
Frederik Schueler

--
ENOSIG

[Marcus Better (mbetter)]

This should have been documented in README.Debian, and preferably also
in the example configuration files. Really. It's not funny to configure
the stuff only to find out it's not supported...

Thanks,

Marcus

[Stephen Gran (sgran)]

This one time, at band camp, Marcus Better said:
> This should have been documented in README.Debian, and preferably also
> in the example configuration files. Really. It's not funny to configure
> the stuff only to find out it's not supported...

Fair enough. We have done some rewoking of debian/rules to make it
easier to build modules like eap-tls and postgres. I will add a note to
README.Debian as well.

Take care,
--
 -----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : <email address hidden> |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
 -----------------------------------------------------------------

[Jeremy Jackson (jerj)]

Binary package hint: freeradius

Without doing this, freeradius can't be used for WiFI Access point authentication, a fairly significant feature.

the debian/rules file has 2 lines you uncomment, and a couple other things, to enable TLS build.

I tried this on Gutsy amd64 and it works, no other changed needed.

[Chuck Short (zulcss)]

Unfortunatetly due to license of openssl we cannot ship a version of freeradius with openssl turned on. If someone has a patch with gnutls then it would not pe a problem.

Thanks
chuck

[Jason Costomiris (jcostom)]

For those, who like me, come across this report while searching for a build as requested here, there's a pretty simple solution.

The current shipping freeradius version is 2.0.4, which includes a debian/ directory, all nicely populated and ready to rock && roll.

You'll need to have build-essential, plus the rest of what's called for in the debian/control file:

Build-Depends: debhelper (>= 5), dpatch (>= 2), dpkg-dev (>= 1.13.19), autotools-dev, libtool (>= 1.5), libltdl3-dev, libpam0g-dev, libmysqlclient15-dev | libmysqlclient-dev, libgdbm-dev, libldap2-dev, libsasl2-dev, libiodbc2-dev, libkrb5-dev, libperl-dev, libpcap-dev, python-dev, snmp, libsnmp9-dev | libsnmp-dev, libpq-dev, libssl-dev

But that stuff's all easily remedied with some apt-get action.

From the top-level source directory, run "debian/rules binary" and wait. Your packages will be ready in a few minutes. Got me back up & running in a few minutes with some slight config tweaks from my old 1.1.6 server that ran on Gutsy. Speaking of which, what gives with the ripping out the optional functionality in the debian/* files to add tls support on one's own??

[Chris AtLee (chris-atlee)]

I'm assuming that this bug is still open since freeradius isn't built
with OpenSSL support.

Can you please add a note to this effect in README.Debian? I just
wasted a few hours trying to get freeradius up and running for my
wireless network, and then realized it doesn't have PEAP support.

[Henrique de Moraes Holschuh (hmh)]

It *is* possible to ammend the GPL locally to allow for OpenSSL linking.

http://www.gnome.org/~markmc/openssl-and-the-gpl.html

Was this possibility talked about with freeradius upstream? It is usually a
non-issue to get people to agree with it, since the software remains GPL,
and they added code to allow it to link to OpenSSL in the first place, so
they are not opposed to such linking...

Here's the relevant text of that URI:

One recommended way around this GPL incompatibility is to add an OpenSSL
exemption when you license your code under the GPL. See this mail from
debian-legal to a developer which suggests the following wording for the
exemption:

 * In addition, as a special exception, the copyright holders give
 * permission to link the code of portions of this program with the
 * OpenSSL library under certain conditions as described in each
 * individual source file, and distribute linked combinations
 * including the two.
 * You must obey the GNU General Public License in all respects
 * for all of the code used other than OpenSSL. If you modify
 * file(s) with this exception, you may extend this exception to your
 * version of the file(s), but you are not obligated to do so. If you
 * do not wish to do so, delete this exception statement from your
 * version. If you delete this exception statement from all source
 * files in the program, then also delete it here.

(links to the emails, etc. are available in the gnome.org page linked
above).

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[Daniel Pocock (daniel-pocock)]

I completely understand the Debian position on this issue. It is likely
that issues like this will continue to come up in future, not just in
FreeRADIUS.

What would be really nice is to have `optional' components in
debian/rules. A user would be able to specify which `options' they want
when running dpkg-buildpackage. The package maintainer would then be
able to provide an official way of building the binary that he is unable
to distribute.

This could be done now by providing some additional targets in
debian/rules, e.g. a deb-eap target. If this was implemented, someone
could potentially type:

  apt-get source freeradius
  cd freeradius.....
  debian/rules deb-eap

To make it even more useful, it would be nice to be able to pass options
to apt-get. If apt-get couldn't find a binary built with the desired
option, it would build one for you.

Finally, the dpkg database should remember the options chosen for a
given package, so that if the package is automatically upgraded (e.g.
apt-get upgrade), the options can be preserved by rebuilding on each
upgrade.

Regards,

Daniel

[Mark Hymers (mhy)]

# Automatically generated email from bts, devscripts version 2.10.6~etch1
tags 266229 + wontfix

[Vladislav Kurz (vladislav-kurz)]

Hello,

I have also run into the need of recompiling freeradius to get EAP-TLS
support. Did anyone speak to upstream about the possibility of adding the
exemption to link with OpenSSL as suggested by Henrique a couple of months
ago? Did they answer? I think that ammending the licence is the easiest way
to get this "bug" fixed.

--
Regards
        Vladislav Kurz

[Stephen Gran (sgran)]

This one time, at band camp, Vladislav Kurz said:
> Hello,
>
> I have also run into the need of recompiling freeradius to get EAP-TLS
> support. Did anyone speak to upstream about the possibility of adding the
> exemption to link with OpenSSL as suggested by Henrique a couple of months
> ago? Did they answer? I think that ammending the licence is the easiest way
> to get this "bug" fixed.

See the discussion starting here:
http://lists.cistron.nl/pipermail/freeradius-devel/2009-January/012726.html

It looks like work is underway.

Cheers,
--
 -----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : <email address hidden> |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
 -----------------------------------------------------------------

[Jim Ancona (jimancona)]

Any reason the source package can't have a simple switch that a user could uncomment to build with openssl? Compared to the 1.x version this one seems a bit draconian.

[Josip Rodin (joy-debbugs)]

tag 266229 - wontfix
--
     2. That which causes joy or happiness.

[Bjørn Mork (bmork)]

I guess you will notice this, but I thought I might document it in the
bug report as well: FreeRADIUS just got an excemption allowing it to be
distributed in binary form with the modules using OpenSSL:
http://github.com/alandekok/freeradius-server/blob/2800ea81e6c8ea0c188415483ad000ffd7d3a335/src/LICENSE.openssl

Could we please have FreeRADIUS 2.1.8 with EAP in Squeeze? Thanks

Bjørn

[Josip Rodin (joy-debbugs)]

On Mon, Dec 21, 2009 at 01:20:15PM +0100, Bj??rn Mork wrote:
> I guess you will notice this, but I thought I might document it in the
> bug report as well: FreeRADIUS just got an excemption allowing it to be
> distributed in binary form with the modules using OpenSSL:
> http://github.com/alandekok/freeradius-server/blob/2800ea81e6c8ea0c188415483ad000ffd7d3a335/src/LICENSE.openssl
>
> Could we please have FreeRADIUS 2.1.8 with EAP in Squeeze? Thanks

Way ahead of you :) The eap modules that require no extra dependencies
will be in the next package.

--
     2. That which causes joy or happiness.

[Josip Rodin (joy)]

Source: freeradius
Source-Version: 2.1.8+dfsg-1

We believe that the bug you reported is fixed in the latest version of
freeradius, which is due to be installed in the Debian FTP archive:

freeradius-common_2.1.8+dfsg-1_all.deb
  to main/f/freeradius/freeradius-common_2.1.8+dfsg-1_all.deb
freeradius-dbg_2.1.8+dfsg-1_amd64.deb
  to main/f/freeradius/freeradius-dbg_2.1.8+dfsg-1_amd64.deb
freeradius-dialupadmin_2.1.8+dfsg-1_all.deb
  to main/f/freeradius/freeradius-dialupadmin_2.1.8+dfsg-1_all.deb
freeradius-iodbc_2.1.8+dfsg-1_amd64.deb
  to main/f/freeradius/freeradius-iodbc_2.1.8+dfsg-1_amd64.deb
freeradius-krb5_2.1.8+dfsg-1_amd64.deb
  to main/f/freeradius/freeradius-krb5_2.1.8+dfsg-1_amd64.deb
freeradius-ldap_2.1.8+dfsg-1_amd64.deb
  to main/f/freeradius/freeradius-ldap_2.1.8+dfsg-1_amd64.deb
freeradius-mysql_2.1.8+dfsg-1_amd64.deb
  to main/f/freeradius/freeradius-mysql_2.1.8+dfsg-1_amd64.deb
freeradius-postgresql_2.1.8+dfsg-1_amd64.deb
  to main/f/freeradius/freeradius-postgresql_2.1.8+dfsg-1_amd64.deb
freeradius-utils_2.1.8+dfsg-1_amd64.deb
  to main/f/freeradius/freeradius-utils_2.1.8+dfsg-1_amd64.deb
freeradius_2.1.8+dfsg-1.diff.gz
  to main/f/freeradius/freeradius_2.1.8+dfsg-1.diff.gz
freeradius_2.1.8+dfsg-1.dsc
  to main/f/freeradius/freeradius_2.1.8+dfsg-1.dsc
freeradius_2.1.8+dfsg-1_amd64.deb
  to main/f/freeradius/freeradius_2.1.8+dfsg-1_amd64.deb
freeradius_2.1.8+dfsg.orig.tar.gz
  to main/f/freeradius/freeradius_2.1.8+dfsg.orig.tar.gz
libfreeradius-dev_2.1.8+dfsg-1_amd64.deb
  to main/f/freeradius/libfreeradius-dev_2.1.8+dfsg-1_amd64.deb
libfreeradius2_2.1.8+dfsg-1_amd64.deb
  to main/f/freeradius/libfreeradius2_2.1.8+dfsg-1_amd64.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Josip Rodin <email address hidden> (supplier of updated freeradius package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sat, 02 Jan 2010 20:22:47 +0100
Source: freeradius
Binary: freeradius freeradius-common freeradius-utils libfreeradius2 libfreeradius-dev freeradius-krb5 freeradius-ldap freeradius-postgresql freeradius-mysql freeradius-iodbc freeradius-dialupadmin freeradius-dbg
Architecture: source amd64 all
Version: 2.1.8+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Josip Rodin <email address hidden>
Changed-By: Josip Rodin <email address hidden>
Description:
 freeradius - a high-performance and highly configurable RADIUS server
 freeradius-common - FreeRADIUS common files
 freeradius-dbg - debug symbols for the FreeRADIUS packages
 freeradius-dialupadmin - set of PHP scripts for administering a FreeRADIUS server
 freeradius-iodbc - iODBC module for FreeRADIUS server
 freeradius-krb5 - kerberos module for FreeRADIUS server
 freeradius-ldap - LDAP mo...

[Chuck Short (zulcss)]

SSL support has been added to freeradius 1.2.8 for lucid.

Regards
chuck