netatalk not built with encrypted auth support

[Brett Dikeman]

Netatalk "ships" with the default configuration, which not only allows
clear-text auth, but it is the ONLY auth mechanism available to MacOS clients
connecting. This is grossly insecure; the password is transmitted in
clear-text. Please mark this an urgent security bug.

This can most likely be fixed by recompiling netatalk with openssl/openssl-dev
installed and confirming the presence of:
uams_randnum.so
uams_dhx.so

in /usr/lib/netatalk/

(According to the netatalk build instructions, the encrypted auths are not built
if openssl is not installed.)

As a result, openssl obviously needs to be marked as a dependency for netatalk.

Additionally, I recommend the configuration for afpd.conf contain the default
line, but with the cleartext UAM --REMOVED-- and the random-number library
added. There are -extremely few- legitimate reasons admins would need
clear-text auth, and they should be required to enable it if they truly do need it.

[Sebastian Rittau (srittau)]

tag 191790 confirmed
# See mail sent to 190417:
tag 190417 wontfix
tag 188471 pending
tag 188040 pending
tag 186998 pending
tag 185685 confirmed
tag 182440 confirmed
tag 171355 confirmed
tag 168277 moreinfo
tag 162016 moreinfo
tag 160862 confirmed
tag 155924 confirmed
severity 155924 minor
tag 155752 confirmed
forward 155752 http://bugzilla.gnome.org/show_bug.cgi?id=95744
tag 155028 moreinfo
tag 151051 pending
tag 151050 pending
tag 149625 confirmed
severity 149625 important
tag 145482 confirmed
tag 144341 confirmed
severity 144341 wishlist
tag 141405 confirmed
tag 139906 unreproducible
tag 135669 pending
tag 134081 moreinfo
merge 132054 145482
tag 131331 confirmed

[David Wright (ichbin-shadlen)]

The disappearence of encryption is EXTREMELY unfortunate. I don't
understand this. Why is enryption incompatible with main?

1. U.S. has loosened encryption export restrictions.
2. The RSA patent has expired.
3. Other distros do it.

Is this about Debian's silly quarell with the OpenSSL license? Why not
just move to non-free, then? When 99% of the disto is in non-free, maybe
the zealots will get a clue; no, probably not. :-)

[Michael Przybylski (mikep-core)]

Package: netatalk
Version: 1.6.2-1
Followup-For: Bug #191790

'nuf said.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux core 2.4.20 #7 SMP Mon May 5 18:07:23 PDT 2003 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages netatalk depends on:
ii cracklib2 2.7-8.5 A pro-active password checker libr
ii libc6 2.3.1-16 GNU C Library: Shared libraries an
ii libdb3 3.2.9-17 Berkeley v3 Database Libraries [ru
ii libpam-modules 0.76-9 Pluggable Authentication Modules f
ii libpam0g 0.76-9 Pluggable Authentication Modules l
ii libwrap0 7.6-ipv6.1-3 Wietse Venema's TCP wrappers libra
ii netbase 4.09 Basic TCP/IP networking system
ii perl 5.8.0-17 Larry Wall's Practical Extraction

-- no debconf information

[Daniel Lakeland (dlakelan)]

The netatalk in main (instead of nonus) also has dhx authentication disabled.

At the very least DHX authentication and/or ssl enabling libraries
should be available in a seperate package netatalk-dhx and
netatalk-ssl from nonus. Preferrably the whole thing should go back to
nonus.

Sebastian: are you now in the US? is that why the package changed?

--
Daniel Lakeland
<email address hidden>
http://www.endpointcomputing.com

[Sebastian Rittau (srittau)]

On Fri, Aug 29, 2003 at 08:17:26AM -0700, Daniel Lakeland wrote:

> At the very least DHX authentication and/or ssl enabling libraries
> should be available in a seperate package netatalk-dhx and
> netatalk-ssl from nonus. Preferrably the whole thing should go back to
> nonus.
>
> Sebastian: are you now in the US? is that why the package changed?

It is not legally possible to reenable OpenSSL support at the moment.
This is due to the incompatible licenses of OpenSSL and Netatalk. (The
latter is under the GPL.) It is not related to the US export laws.

 - Sebastian

[Freek Dijkstra (debian-bugreport)]

I just spent a few hours figuring out why I could not log in to my AFP
server and why Mac OS X gave me a "Could not connect to the server because
the name or password is not correct" message. I tracked it down to missing
DHX and missing SSL support. I was able to manually compile it using

You state that it is not possible to either
A) move netatalk to non-US; or
B) make a netatalk-ssl package; or
C) make a netatalk-dhx package
Due to licensing incompatibility between OpenSSL and Netatalk.

Could you explain, or point me to a legal source?

Obviously, I am allowed to compile it myself by first installing libssl-dev
and compiling netatalk from source.
So the culprit must be in the agreement how to distribute the binary code.

Reading the agreement from openssl at
http://www.openssl.org/source/license.html, it lists a.o.:
 * 2. Redistributions in binary form must reproduce the above copyright
 * notice, this list of conditions and the following disclaimer in
 * the documentation and/or other materials provided with the
 * distribution.

 * 6. Redistributions of any form whatsoever must retain the following
 * acknowledgment:
 * "This product includes software developed by the OpenSSL Project
 * for use in the OpenSSL Toolkit (http://www.openssl.org/)"

Given the current licence of netatalk, at
http://packages.debian.org/changelogs/pool/main/n/netatalk/netatalk_1.6.4-1/
copyright

What exactly limits you from adding the above (openSSL) copyright notice(s)
plus the licence file in the docs?

Kind regards,
Freek Dijkstra

PS: In the mean time, whoever reads this report, I am interested in a good
howto, for how to compile netatalk with DHX support myself, using apt-get (I
did it manually). That is a useful work-around as long as the distribution
licensing is not solved.

[Jonas Smedegaard (js-debian)]

Freek Dijkstra wrote:

> You state that it is not possible to either
> A) move netatalk to non-US; or
> B) make a netatalk-ssl package; or
> C) make a netatalk-dhx package
> Due to licensing incompatibility between OpenSSL and Netatalk.
>
> Could you explain, or point me to a legal source?

Search Google for openssl and gpl.

I am not the maintainer, so I am only speaking for myself here - I just
assume those threads are very much related and may answer your question...

> PS: In the mean time, whoever reads this report, I am interested in a good
> howto, for how to compile netatalk with DHX support myself, using apt-get (I
> did it manually). That is a useful work-around as long as the distribution
> licensing is not solved.

With the latest release you should be able to simply do the following:

DEB_BUILD_OPTIONS=ssl debuild

(or even more automation with apt-source but I have no experience with
that).

The section about SSL in README.Debian should probably be updated to
include this info.

  - Jonas

--
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: [phone] Website: http://dr.jones.dk/

  - Enden er nær: http://www.shibumi.org/eoti.htm

[Sebastian Rittau (srittau)]

On Sat, Jan 31, 2004 at 02:18:10AM +0100, Freek Dijkstra wrote:

> You state that it is not possible to either
> A) move netatalk to non-US; or
> B) make a netatalk-ssl package; or
> C) make a netatalk-dhx package
> Due to licensing incompatibility between OpenSSL and Netatalk.
>
> Could you explain, or point me to a legal source?

It seems that the participants of debian-legal are of the opinion that
linking OpenSSL against GPLed code and distributing the result is against
the OpenSSL license, mainly because of the following sentence:

  The licence and distribution terms for any publically available version or
  derivative of this code cannot be changed. i.e. this code cannot simply be
  copied and put under another distribution licence
  [including the GNU Public Licence.]

I personally see no problems with this, but I have to follow the
interpretation of debian-legal.

> PS: In the mean time, whoever reads this report, I am interested in a good
> howto, for how to compile netatalk with DHX support myself, using apt-get (I
> did it manually). That is a useful work-around as long as the distribution
> licensing is not solved.

Short version (assuming bash as shell):

  Make sure you have the packages fakeroot and dpkg-dev installed
  export DEB_BUILD_OPTIONS=ssl
  apt-get source netatalk
  cd netatalk-x.y.z
  dpkg-buildpackage -rfakeroot -uc -us
  Install resulting package in the parent directory

I will update the section about OpenSSL support in the README
accordingly.

 - Sebastian

[Freek Dijkstra (debian-bugreport)]

On 01-02-2004 21:53, "Sebastian Rittau" <email address hidden> wrote:

> On Sat, Jan 31, 2004 at 02:18:10AM +0100, Freek Dijkstra wrote:
>
>> You state that it is not possible to either
>> A) move netatalk to non-US; or
>> B) make a netatalk-ssl package; or
>> C) make a netatalk-dhx package
>> Due to licensing incompatibility between OpenSSL and Netatalk.
>>
>> Could you explain, or point me to a legal source?
>
> It seems that the participants of debian-legal are of the opinion that
> linking OpenSSL against GPLed code and distributing the result is against
> the OpenSSL license, mainly because of the following sentence:
>
> The licence and distribution terms for any publically available version or
> derivative of this code cannot be changed. i.e. this code cannot simply be
> copied and put under another distribution licence
> [including the GNU Public Licence.]
>
> I personally see no problems with this, but I have to follow the
> interpretation of debian-legal.

Agreed. What a hassle; in particular since both ARE open source.

I just read a few threads on debian-legal (I ought to have looked for that
first). Particularly interesting is the FAQ at OpenSSL
http://www.openssl.org/support/faq.html#LEGAL2 which almost takes the other
turn, and seems to suggest that GPL is the thing that is restricting use of
code under other licences, instead that the OpenSSL licence restricts the
use of code under other licences (like the GPL). Oh well, I don't know
anymore. Maybe they are right (wasn't that why there is a LGPL?).

Thanks for the howto!

Regards and also a big thanks for putting time in the community by being a
package maintainer!
Freek Dijkstra

[Jonas Smedegaard (js-debian)]

Freek Dijkstra wrote:

> I just read a few threads on debian-legal (I ought to have looked for that
> first). Particularly interesting is the FAQ at OpenSSL
> http://www.openssl.org/support/faq.html#LEGAL2 which almost takes the other
> turn, and seems to suggest that GPL is the thing that is restricting use of
> code under other licences, instead that the OpenSSL licence restricts the
> use of code under other licences (like the GPL). Oh well, I don't know
> anymore. Maybe they are right (wasn't that why there is a LGPL?).

GPL restricts the code from being used in closed-source environments
(because then the author is not given proper credit).

BSD code is free to be hidden in closed-source project.

GPL is restricted to free projects.

So yes, GPL can be said to be "less free" than BSD.

But this is all not specific to this bugreport, so let's continue
somewhere else if needed, ok? :-)

  - Jonas

--
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: [phone] Website: http://dr.jones.dk/

  - Enden er nær: http://www.shibumi.org/eoti.htm

[Freek Dijkstra (debian-bugreport)]

Thanks Jonas, I took this licence question to the netatalk-devel mailing
lists (the upstream source). See
http://sourceforge.net/mailarchive/forum.php?forum_id=4958
(it should show up there soon)

[Jonas Smedegaard (dr)]

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

severity 190417 important
merge 191790 190417
thanks

- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: [phone] Website: http://dr.jones.dk/

~ - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFBL+Sgn7DbMsAkQLgRAlH9AJ9T2kqhSf3DiLNFgIpsvDol8fAXrwCXSWkc
10zfC1fvqps1nrCu7YB6Ag==
=ZUXs
-----END PGP SIGNATURE-----

[Freek Dijkstra (debian-bugreport)]

Package: netatalk
Version: 1.6.4-1
Followup-For: Bug #191790

After a long and heated discussion on debian-legal, I concluded that
indeed it is not possible to combine OpenSSL and netatalk. In short: if
netatalk is linked against OpenSSL, the combination of the two is
considered a combined program, which must be under the same licence. The
OpenSSL and GPL are unfortunately incompatible (GPL does not allow the
additional restriction that you MUST add the acknowledgement "This
product includes software developed by the OpenSSL Project for use in
the OpenSSL Toolkit"). I still think it is odd, since both are open
source and the binary of netatalk does NOT include any OpenSSL code (it
is dynamically linked). However, after 48 mails, even *I* got the point
;-)

I got an interesting suggestion though: link netatalk with GnuTLS
instead of OpenSSL. GnuTLS is OpenSSL-redone-from-scratch (also open
source, but now GPL-compatible), just to avoid this small
incompatibility thing (whoever said Open Source would eliminate needless
rewrites of software, please reconsider -- I got angry because of it).

I decided that instead of making the changes here, I will attempt to
make them upstream. However, I'm not so experienced, so help is
appreciated. For now I will only look to the 2.0 version of netatalk,
and ignore the 1.6 branch (these changes will not make it into sarge
anyway, and I think in a couple of months 2.0 will becomes stable
upstream).

As for the code, a quick glance showed that:
* netatalk does specifically link against OpenSSL, since the
  configure scripts looks for the file "include/openssl/cast.h".
* <a href="http://www.gnu.org/software/gnutls/">GnuTLS</a>
  does not come with the cast.h header file (mainly openssl.h)
* An other, public domain package, <a href="http://
  cryptopp.com/">crypto++</a>, does come with the cast.h
  headers.

I haven't looked into things, but this may be promosing. My next
goal is to adjust the configure file to (a) recognize the path of the
GnuTLS and Crypto++ header files, and thus the library; (b) add a
switch to the configure script to allow selection of either OpenSSL
(default) or GnuTLS/Crypto++ for linking; and (c) link against
these libraries instead of OpenSSL.

However, I am not very familiar with make scripts (I only use
them, never created them). So I'd appreciate help on dealing with
the the configure.in and aclocal.m4 files, and the autoconf tool (I
currently don't even know if I need automake as well)

If you like to help (I would very much appreciate it!), please refer to
feature request #10355455 at Sourceforge:
http://sourceforge.net/tracker/index.php?func=detail&aid=1035455&group_id=8642&atid=358642

[Brett Dikeman (brett-cloud9)]

Netatalk "ships" with the default configuration, which not only allows
clear-text auth, but it is the ONLY auth mechanism available to MacOS clients
connecting. This is grossly insecure; the password is transmitted in
clear-text. Please mark this an urgent security bug.

This can most likely be fixed by recompiling netatalk with openssl/openssl-dev
installed and confirming the presence of:
uams_randnum.so
uams_dhx.so

in /usr/lib/netatalk/

(According to the netatalk build instructions, the encrypted auths are not built
if openssl is not installed.)

As a result, openssl obviously needs to be marked as a dependency for netatalk.

Additionally, I recommend the configuration for afpd.conf contain the default
line, but with the cleartext UAM --REMOVED-- and the random-number library
added. There are -extremely few- legitimate reasons admins would need
clear-text auth, and they should be required to enable it if they truly do need it.

[Sebastian Rittau (srittau)]

severity 336490 important
merge 336490 191790
thanks

[Carthik Sharma (carthik)]

assigning to MOTUs.

[Daniel Robitaille (robitaille)]

netatalk doesn't have SSL support due to a license issue. The bug report in Debian BTS has more details.

[n8gray (n8gray)]

If you feel that you can't distribute netatalk with uams_dhx.so then that's fine, but for goodness sake, MAKE IT OBVIOUS TO THE END USER! I just spent hours trying to figure out why the configuration that should have been working according to every howto and man page I could find was causing failures with a cryptic numerical error code (error -35). I would have needed NO time to figure this out had there been a note in the /etc/netatalk/afpd.conf file and/or the /etc/default/netatalk file saying "for licensing reasons, uams_dhx.so is unavailable in Ubuntu/Debian."

[Jonas Smedegaard (dr)]

forcemerge 336490 351305
thanks

--
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: [phone] Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm

[Rob Caskey (rcaskey)]

This one is ugly, looks like netatalk is practically unusable for file-sharing until this gets fixed. Looks like the only reasonable way around it is to rewrite about 6 or 7 different chunks of encryption code ~ 20 lines each, to use gnutls + gnucrypt instead of openssl, and I just don't have the chops to do that. I'd really like to see this bug get confirmed and upgraded in priority.

[didier (did447-deactivatedaccount)]

Where is DES in gnutls?

Anyway I will commit the boilerplate: you can link netatalk with openSSL tada, tada..

[Siegfried (siegzeit)]

I agree that it should be made better visible to the end user that the debian/ubuntu versions of netatalk don't support encrypted auth. Most people use this authentication type so spending hours trying to diagnose such problems is really a hassle. Until it gets fixed I suggest to do something along the lines what n8gray suggested.

[Fredrik Bränström (branstrom)]

This one is immensely annoying. I had the same journey as n8gray... Anyway, I'll try to refrain from whining.

Is this one moving at all? didier said he would commit the boilerplate, has anything happened since then?

[benchang (ben-bcchang)]

Can netatalk be moved to Multiverse, or another version of it with SSL be put in Multiverse? Here's my logic - the reason you would want Netatalk is primarily to run a file server in a heterogeneous network environment with Mac clients. But, Macs of any recent vintage won't connect to an AFP server without SSL. So, the whole package is not usable for its primary purpose without the SSL. The license issue is less serious than with other highly useful packages, like dvdcss, LAME, the nVidia and ATI video card drivers, etc. So wouldn't just compiling it with SSL and moving it to Multiverse or some such be ok?

[Michael Bienia (geser)]

No, as netatalk linked with openssl wouldn't be redistributable, which is a main requirement for inclusion in multiverse.

One option is to convince netatalk upstream to add a openssl exception to the license.
An other option is to try if netatalk builds and works with gnutls.

[benchang (ben-bcchang)]

Hi,

thanks for the reply. I spent some time scratching my head over this
and delving into the weird world of incompatible free software
licenses. It seems strange that we have here a piece of free
software, which relies on another piece of free software; we can
distribute both of them, but we can't distribute them connected, so we
can only distribute something that is effectively crippled. From the
end-user perspective it seems like this should be solvable - we can
find a way to distribute many other things which are much more
incompatible with free software as a whole :) I also thought that
multiverse was where things go which have license incompatibilities
anyway.

But, from a strict standpoint, it does make sense. If I understand it
correctly, the apache license has stricter requirements regarding
patents than GPL v2, but is more compatible with GPL V3 ... or
something?

Out of curiousity I started reading all the licenses for all the other
packages I have installed. Is the exception you mention just as
simple as what's in the license for CUPS, for example? Such as

" xxx. OpenSSL Toolkit License Exception;

 a. Research Systems Unix Group at the University of Michigan
explicitly allows the
    compilation and distribution of the CUPS software
    with Netatalk"

Is there a petition we can sign, or can I just call them up and ask, maybe?

Here's my argument for why this is important: It's important that
linux (in our case, ubuntu) be able to interoperate on a network with
other OS's. If you use a Mac, AFP is the sanest option. Apple
doesn't have all that much market share, but it does have a lot at
least in schools and universities in the US and in creative and design
businesses. These are places where Ubuntu could be a great addition,
and being able to share files between osx and linux is a critical part
of making that work.

I say that from spending the last 7 years running a linux lab in a
100% Mac art school. Having netatalk and avahi working well is
really, really, important. :)

Quoting Michael Bienia <email address hidden>:

> No, as netatalk linked with openssl wouldn't be redistributable, which
> is a main requirement for inclusion in multiverse.
>
> One option is to convince netatalk upstream to add a openssl
> exception to the license.
> An other option is to try if netatalk builds and works with gnutls.
>
> --
> netatalk not built with encrypted auth support
> https://bugs.launchpad.net/bugs/26452
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Rachel Greenham (rachel-strangenoises)]

excuse me if this is a silly question, but why is it ok for openssh-client/openssh-server and apache2.2-common to depend on libssl and not netatalk?

[Keith Matthews (keith-matthews-themegroup)]

With the increasing deployment of MacOS Leopard this issue is rapidly becoming critical since Leopard insists on using encryption.

It is made worse by licence issues in debuild preventing local rebuild from source.

Leopard also requires a suitable entry in /etc/avahi/services. While it is easy to find the relevant details they should really be in the default package.

[Siegfried (siegzeit)]

I wholeheartedly agree with Keith Matthews here. This problem makes interoperability with Mac OS X systems much more difficult for users.

[Pavek (avezzandrog)]

In order to let netatalk work with my Leopard system, I had to rebuild the package following this guide.

http://www.kremalicious.com/2008/06/ubuntu-as-mac-file-server-and-time-machine-volume/

It's so bad Ubuntu can't find a way to promote file sharing with such a huge number of machines running MacOS X Leopard. :-(

[Tommy Trussell (tommy-trussell)]

I followed the link above to the Debian bug, then scrolled to the end and followed the links to a discussion at Sourceforge http://sourceforge.net/tracker/index.php?func=detail&aid=1035455&group_id=8642&atid=358642 someone used a compatible library that can be included in the 2.0.4 version of netatalk (which is in Jaunty). Has anyone tried netatalk in Jaunty to see if this has been addressed in that version?

[mathew (meta23)]

The netatalk distributed with jaunty is still broken. It looks as if the configure script hasn't been updated to know about the GNUTLS_DHX #define used to select GNU libraries instead of OpenSSL.

[mathew (meta23)]

It's stated at <URL:http://sourceforge.net/tracker/index.php?func=detail&aid=1035455&group_id=8642&atid=358642>
that the problem is fixed in netatalk 2.0.4.

I note that Debian is distributing 2.0.4 release candidates in testing
and unstable.

So... at least for Debian testing/unstable, can we now have DHX2
encryption turned on by default via #defining GNUTLS_DHX please?

mathew

[Jonas Smedegaard (dr)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On Thu, Jun 11, 2009 at 05:32:39PM -0500, mathew wrote:
>It's stated at
><URL:http://sourceforge.net/tracker/index.php?func=detail&aid=1035455&group_id=8642&atid=358642>
>that the problem is fixed in netatalk 2.0.4.
>
>I note that Debian is distributing 2.0.4 release candidates in testing
>and unstable.
>
>So... at least for Debian testing/unstable, can we now have DHX2
>encryption turned on by default via #defining GNUTLS_DHX please?

DHX2 is enabled in current Debian packaging releases.

DHX still requires OpenSSL, so still cannot be enabled in Debian.

Hope that helps.

  - Jonas

- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: [phone] Website: http://dr.jones.dk/

  [x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREDAAYFAkoyZUEACgkQn7DbMsAkQLhtVQCfVUvxkaeVCIZRgkVpM1ZDIHPQ
3KwAoKFRWPbEOu4wQ90waktY+LqJ0HP0
=wLdD
-----END PGP SIGNATURE-----

[Mikel Pérez (mikelpr)]

Still broken in Karmic.

[franklahm (franklahm-googlemail)]

Since Netatalk 2.0.4 encrypted auth is available with the authentication module DHX2 which uses libgcrypt.

[Craig Ringer (ringerc)]

... however, dhx2 doesn't work with Mac OS 9 clients. 'cleartext' auth doesn't support password lengths > 8 chars, so if you have a users with longer passwords they'll be locked out.

Those of us unfortunate enough to be supporting such dinosaurs can get NetATalk to build against OpenSSL quite easily thanks to the thoughtful package maintainers. Just:

$ cd debtmp
$ mkdir debtmp
$ apt-get source netatalk
$ apt-get install libcups2-dev
$ apt-get build-dep netatalk
$ cd netatalk-2.0.4~beta2
$ DEB_BUILD_OPTIONS=openssl fakeroot debian/rules binary
$ sudo dpkg -i ../netatalk_2.0.4~beta2-5ubuntu2_i386.deb

(Versions may need adapting as appropriate).

This rebuilds NetATalk against OpenSSL, restoring the uams_dhx_pam and uams_dhx_randnum modules.

[BlackSmile[FR] (thomasclaessen)]

What I can't understand is why you couldn't give the package compiled but any user can compil it at home ?
Really need a workaround !

[Rachel Greenham (rachel-strangenoises)]

Er, hasn't this been fixed in lucid? ISTR just installing netatalk and it worked out of the box with my macs, which was all I ever wanted... I'd presumed someone got over themselves and let it in. :-)

[Darik Horn (dajhorn)]

It looks like somebody wrote the gnutls replacement for netatalk. Also, from the changelog:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565969

[pklaus (pklaus)]

@Darik: What do you mean by that? I can't find any reference to **GnuTLS** on the debian bug page. Also a Google search didn't reveal anything.

I think the encrypted authentication now works with lucid. My /etc/netatalk/afpd.conf contains at the end the uncommented line:
- -transall -uamlist uams_dhx.so,uams_dhx2.so -nosavepassword
So i think cleartext passwords are not allowed, it should use dhx2 instead. Am I right? How can find it out? Using Wireshark?