dmark

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

@smallsco@oldbytes.space @nikdoof@social.doofnet.uk @theirongiant@hachyderm.io it's a fair criticism, the reason for the split is more technological than anything else -- one is (a mirror of) a wiki and the other static pages, there's no clear cut way to combine them see also https://github.com/Netatalk/netatalk/issues/2942

@smallsco@oldbytes.space @theirongiant@hachyderm.io @nikdoof@social.doofnet.uk indeed, editing the wrong config file is a recurring pitfall (that I myself have fallen into more often than I like to admit) which is why I made sure there was a section on this in the Troubleshooting guide the #netatalk build system does default to /usr/local/etc for config files, because this is the FHS compliant location for user installed software, and this has been the case since at least netatalk v3.2.0 (when we moved to meson) a downstream packager can then customize this location to comply with the filesystem scheme of their particular OS distribution, which Debian does for example with /etc/netatalk this is why you typically get totally different software installation paths with a binary package vs. building from source code, which can be obnoxious but an unavoidable quirk of Unix-like operating systems that you have to get used to if you take a look at the Netatalk Compilation guide: https://netatalk.io/compilation the Debian build example includes "-Dwith-pkgconfdir-path=/etc/netatalk" so that you get the customary config file path on that particular OS HTH!

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!

@pitz@mastodon.social I would say that PiSCSI is in hibernation, noone is actively developing it. However I'm personally monitoring incoming PRs. Happy to review & merge contributions.

#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 🤞🏼

@nulleric@mastodon.social @smallsco@oldbytes.space I dug into icon data (assisted by Claude) and could conclude that the main difference in this case, is that in OS 8.5 the icon resources are stored internally in an 'icns' container which in turn contains the traditional icon resources (ICN#, icl4, icl8 etc.) while the OS 7.x data has the equivalent icon resources individually at different offsets.

In conclusion, the actual icon data isn't different in this case, just how they're packaged internally.

I want to do a bit more of digging into the way netatalk stores the data to make sure it's not a quirk in our code before documenting it.

@jimluther amazing story, thanks for saving the world countless cumulative hours of headaches with your hard work! As a developer/maintainer of #netatalk I use the final OS9 AppleShare client as my reference point when making sure we don’t break AFP 2.2. We’ve had to do a multitude of workarounds for bugs in earlier “classic” versions of the AppleShare client. It’s been an emotional roller coaster ride. :)