Arch Linux User Repository

Please note that in 3.2.0-4 state (CNID database, afp_signature.conf and afp_voluuid.conf) moved from /var/state/netatalk to /var/lib/netatalk which is more canonical path for application persistent data.

https://gist.github.com/fuhry/10d3a9d0cfed6d6463c5d6c10abaf1c0

Patch to build against libgcrypt 1.11, based on https://github.com/Netatalk/netatalk/pull/1132

When I try to update this package, I get an error saying could not find all required packages: libgcrypt <1.11.

I also see the below message.

:: Searching AUR for updates...
 -> No AUR package found for libgcrypt<1.11

Please note that in 3.2.0-4 state (CNID database, afp_signature.conf and afp_voluuid.conf) moved from /var/state/netatalk to /var/lib/netatalk which is more canonical path for application persistent data.

Hi, I started creating a package for netatalk2 (as netatalk 3.x doesn't support older Macs). I noticed a very unfortunate line in this PKGBUILD however:

replaces=('netatalk-git' 'netatalk2')

That is going to be an issue. It would be better to change that to a conflicts

I can confirm that the latest update to the AUR (3.1.13-3) does indeed work. This is the relevant fix:

@@ -1637,14 +1650,21 @@ void *ad_entry(const struct adouble *ad, int eid)
        size_t len = ad_getentrylen(ad, eid);
        bool valid;

+       if (bufsize == 0) {
+               bufsize = sizeof(ad->ad_data) - (off + len);
+       }
+
        valid = ad_entry_check_size(eid, bufsize, off, len);
        if (!valid) {

Which looks like it does fix the problem, but I'm really hoping upstream digs deeper and locates the initialization of ad where ad->valid_data_len is left at zero or the call site where it's changed to zero.

With the patch more complete patch from FreeBSD (just more logging info, no other logic changes from first patch), I get the following logs:

May 27 10:58:49.152479 afpd[18141] {ad_open.c:1639} (error:ad): ad_entry_check_size overflow (122 + 32 > 0)
May 27 10:58:49.152605 afpd[18141] {ad_open.c:1655} (error:ad): ad_entry: not valid

So, it would appear that ad->valid_data_len is 0 prior to ad_entry_check_size() getting called. I don't know enough about the code to say wether that's normal or not. :-/

Anywho, here's the patch for curious:

--- libatalk/adouble/ad_open.c.orig     2022-05-26 17:51:48.604464910 -0400
+++ libatalk/adouble/ad_open.c  2022-05-27 10:51:33.467798497 -0400
@@ -1574,6 +1574,8 @@
     uint32_t required_len;

        if (eid >= ADEID_MAX) {
+               LOG(log_error, logtype_ad, "ad_entry_check_size %d is greater than %d",
+                   eid, ADEID_MAX);
                return false;
        }
        if (got_len == 0) {
@@ -1585,6 +1587,7 @@
                 * Shouldn't happen: implicitly initialized to zero because
                 * explicit initializer missing.
                 */
+               LOG(log_error, logtype_ad, "ad_entry_check_size explicit initializer missing");
                return false;
        }
        if (ad_checks[eid].expected_len == -1) {
@@ -1594,6 +1597,8 @@
        if (ad_checks[eid].fixed_size) {
                if (ad_checks[eid].expected_len != got_len) {
                        /* Wrong size fo fixed size entry. */
+                       LOG(log_error, logtype_ad, "ad_entry_check_size wrong size to fixed size entry (%d != %d)",
+                           ad_checks[eid].expected_len, got_len);
                        return false;
                }
         required_len = got_len;
@@ -1604,12 +1609,16 @@
                                 * Too small for variable sized entry with
                                 * minimum size.
                                 */
+                               LOG(log_error, logtype_ad, "ad_entry_check_size too small for variable sized entry (%d < %d)",
+                                   got_len, ad_checks[eid].expected_len);
                                return false;
                        }
         required_len = got_len;
                } else {
                        if (got_len > ad_checks[eid].expected_len) {
                                /* Too big for variable sized entry. */
+                               LOG(log_error, logtype_ad, "ad_entry_check_size too big for variable sized entry (%d > %d)",
+                                   got_len, ad_checks[eid].expected_len);
                                return false;
                        }
             /*
@@ -1621,10 +1630,14 @@
        }
        if (off + required_len < off) {
                /* wrap around */
+               LOG(log_error, logtype_ad, "ad_entry_check_size wrap around (%d + %d < %d)",
+                   off, required_len, off);
                return false;
        }
        if (off + required_len > bufsize) {
                /* overflow */
+               LOG(log_error, logtype_ad, "ad_entry_check_size overflow (%d + %d > %d)",
+                   off, required_len, bufsize);
                return false;
        }
        return true;
@@ -1639,10 +1652,7 @@

        valid = ad_entry_check_size(eid, bufsize, off, len);
        if (!valid) {
-               return NULL;
-       }
-
-       if (off == 0 || len == 0) {
+               LOG(log_error, logtype_ad, "ad_entry: not valid");
                return NULL;
        }

Took the gist from here:

https://cgit.freebsd.org/ports/commit/?id=ad0b2e636d9ebf0bdcfdb30933fa0658fa657b17 (last hunk is what is relevant)

--- libatalk/adouble/ad_open.c.orig     2022-05-26 17:51:48.604464910 -0400
+++ libatalk/adouble/ad_open.c  2022-05-26 17:53:32.887798244 -0400
@@ -1639,10 +1639,7 @@

        valid = ad_entry_check_size(eid, bufsize, off, len);
        if (!valid) {
-               return NULL;
-       }
-
-       if (off == 0 || len == 0) {
+               LOG(log_error, logtype_ad, "ad_entry: not valid");
                return NULL;
        }

EDIT: WIP. It built fine, and produced the log message, but it looks like I need to add more of the logging that the FreeBSD patch had

Same problem on 3.1.13 - reverting back to 3.1.12-8 works fine.

+1 on 3.1.13 crashing on login, successfully reverted back to 3.1.12-8 as well. It's already been reported to the netatalk bug tracker, too (https://sourceforge.net/p/netatalk/bugs/)