the 'nad' tool that's part of the #netatalk toolsuite is getting a fun new feature: the ability to encode and decode MacBinary (.bin) and BinHex (.hqx)

if you were a Mac user back in the days you should be familiar: these two were portable formats that allowed you to store Mac files and applications in pure binary form for transmission over the network or onto "foreign" file systems without losing the precious resource fork and other metadata common on old school Mac OS

in the next stable release, 'nad' will get four new subcommands: bin, hex, unbin, unhex

these will encode and decode the data accordingly, and store the Mac OS metadata in Netatalk's AppleDouble sidecar or xattr, depending on your settings

in practice, this means you can fetch an old .bin or .hqx file off of an internet archive somewhere, pop it into a Netatalk AFP volume on your server, run the nad command, and get intact Classic Mac OS files extracted onto the modern file system for access from a vintage AFP client (and vice versa for archiving old Mac files off of a Netatalk shared volume)

as a historical note, the MacBinary/BinHex code is built on an older tool called 'megatron' by Charles Clark, which was distributed with Netatalk from ca. 1991 to 2011 -- but dropped from distribution with Netatalk v3.0

now it's back... but transformed =)

after a substantial development cycle, #netatalk v4.5.0 is now out of beta and ready for daily use

this the most feature-packed release from this project in a decade; to loosely quote the release notes:

making Finder search (i.e. Spotlight) usable out of the box, rebuilding the AFP directory cache for much larger and faster workloads, and tightening security across authentication, filesystem handling, parsers, and build defaults, bringing a new SRP authentication UAM, a pluggable Spotlight backend architecture, a modernized afpstats interface, and many portability improvements for Unix-like platforms like NetBSD and OpenBSD...

...and an additional 22 CVEs fixed

there is too much to list here, so check out the release notes for all the details:

https://netatalk.io/4.5/ReleaseNotes4.5.0

breaking news: #netatalk 4.4.3 is available, to which you should upgrade your deployments as soon as possible

this project has been hit recently by 4 security researchers independently filing (AI assisted) security vulnerabilities in quick succession; out of what ended up as 38 CVEs, we have decided to patch 20 of them in the stable branch.

the rest are either spurious or not exploitable / security sensitive at all

release notes: https://netatalk.io/4.4/ReleaseNotes4.4.3

security advisories: https://netatalk.io/security

Now that I have #netatalk compiled for the Raspberry Pi, I'm now struggling to get any folder shared and advertised over AppleTalk, or AFP, for that matter. This is for #GlobalTalk.

edit : GOD DAMN IT. The documentation fails to mention that I should be editing THIS file:

/usr/local/etc/afp.conf.

I spent hours editing /etc/netatalk/afp.conf, and thought I was going insane.

I've been over the netatalk documentation multiple times last night. I tried setting log level to "default:debug9" but the journal isn't being spammed with events like I expect. So I don't even know where to start troubleshooting - permissions, an incorrect setting, etc.

The RPi is registered on my AppleTalk network just fine; I can see the device from my AIR Mac. It has a valid network number, and I can send AppleTalk echo packets to it with MacPing Pro (AT, not TCP).

Suggestions?

#GlobalTalk I cannot get meson setup to build #netatalk 4.4.2 because it thinks there's no database system available. I have installed both sqlite3 and mysql/mariadb, and I can't tell if Berkeley DB (dbd) is installed or even possible on this platform.

What am I missing?

Is this a known problem on Raspberry Pi's? I have a 3B+ running the latest Pi OS 13 (Trixie), released April 21. Is there a compatibility issue? Should I try an older version of Netatalk (4.3) or the 4.5 beta? Or is the OS too new and something broke the Netatalk build process? Or do I really need to configure a fully functional database ?

We had a fun breakthrough in #netatalk in recent days: the SRP (Secure Remote Password) user authentication method is now reverse engineered and supported by the open source AFP server.

Apple quietly added SRP to the AFP protocol some time in 2010 (our testing indicates OSX 10.7 Lion) but never acknowledged or documented it.

SRP caught my eye since it would offer roughly twice as strong encryption as DHX2 which is the final "official" UAM from Apple.

Luckily, SRP is an open standard and not an Apple proprietary technology: described in RFCs 2945 and 5054. So the reverse engineering was straight-forward, using consumer products that are known to support SRP, then brute force a few dozen potential parameters afforded by RFC 5054.

I did this write-up about the protocol and cryptographic mechanism as a sort of community specification.

https://netatalk.io/spec/SRP_UAM

The upcoming Netatalk v4.5 will support SRP!

#netatalk 4.5.0 beta is now available for adventurous users

https://netatalk.io/4.5/ReleaseNotes4.5.0beta

we have introduced advanced ARC cache and a wide range of deep optimizations that speed up file operations, especially noticeably when you enumerate a large number of files, i.e. when browsing a remote volume

see the new manual chapter on caching for instructions to to configure optimal cache for your deployment

https://github.com/Netatalk/netatalk/blob/main/doc/manual/Dircache.md

this is also the version where the friendly new color volume icons for Classic Mac OS announced a few weeks ago are fully functional

we've made a lot of changes under the hood, therefore this beta release to give you all a chance to poke around with it before we roll out a production ready version 🤞🏼