add SRP user authentication method

[rdmark]

Implement the SRP (Secure Remote Password) UAM for AFP, as used by Apple Time Capsule.
The protocol uses SRP-6a with SHA-1, MGF1 KDF, and RFC 5054 group #2 (1536-bit).

afppasswd is modified to operate on SRP storage file by default, which stores per-user salts and verifiers, while retaining the legacy RandNum functionality activated with the -r flag.

An additional breaking change is that afppasswd -a now takes username as argument rather than previous positional username arugment.

The containers now use SRP for authentication by default.

[augmentcode]

🤖 Augment PR Summary

Summary: This PR adds SRP (Secure Remote Password) authentication support for AFP, matching the SRP-6a/SHA-1 behavior used by Apple Time Capsule/macOS.

Changes:

• Adds a new UAM plugin uams_srp.so implementing the SRP handshake and mutual proofs (M1/M2).
• Introduces a new global config option srp passwd file and plumbs it through afpd’s UAM option interface.
• Extends afppasswd to manage an SRP verifier store by default (afppasswd.srp), keeping legacy RandNum behavior behind -r.
• Updates build definitions (Meson) to define the default SRP verifier path and to build/install the SRP UAM.
• Adjusts Docker and macOS spectest setup to initialize both RandNum and SRP credential stores.
• Updates docs (afppasswd(1), afp.conf(5), Authentication manual) and the Webmin module to expose the new SRP password file path.

Technical Notes: SRP verifier file format is username:hex_salt:hex_verifier using RFC 5054 group #2 (1536-bit) with SHA-1 and MGF1-derived session keys.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 5 suggestions posted.

Comment augment review to trigger a new review at any time.

[rdmark]

while SRP auth works afpfs-ng -> netatalk, it doesn't work macOS -> netatalk yet so we have a bug somewhere

false alarm, it works when you use the correct password 😅

[augmentcode]

Review completed. 3 suggestions posted.

Comment augment review to trigger a new review at any time.

[NJRoadfan]

Tested and working here.

[andylemin]

Very cool! Well done indeed.. I'll do a proper code review in the next couple of days

[andylemin]

QR review shows this is a high quality PR 🙂 This looks to be a well-engineered implementation of the SRP-6a protocol.
The cryptographic primitives are correct, sensitive data is properly cleaned up, the code follows established codebase patterns, error handling is thorough, and the documentation is comprehensive. RFC 5054 N prime constants look good.

Minor comments;
Remove unused SRP_AUTH_FAILURE macro if not planned for future use.
Consider constant-time comparison for M1 verification (memcmp → custom ct_memcmp) as a defense-in-depth measure.

LGTM - Impressive work! 🚀

[rdmark]

@andylemin thanks for the review!

Remove unused SRP_AUTH_FAILURE macro if not planned for future use.

I have been going back and forth about this; SRP_AUTH_FAILURE (-6754) is what I observed the Time Capsule AFP server returned when the M1 proof is invalid (both incorrect crypto as well as incorrect user password), however this error code is not defined in he AFP spec. Right now I'm using AFPERR_NOTAUTH (-5023) consistently to match the other UAMs which the macOS AFP client doesn't seem to mind.

Do you have any advice here, whether to emulate Time Capsule fully or attempt to adhere to the AFP spec where appropriate?

[andylemin]

@andylemin thanks for the review!

Remove unused SRP_AUTH_FAILURE macro if not planned for future use.

I have been going back and forth about this; SRP_AUTH_FAILURE (-6754) is what I observed the Time Capsule AFP server returned when the M1 proof is invalid (both incorrect crypto as well as incorrect user password), however this error code is not defined in he AFP spec. Right now I'm using AFPERR_NOTAUTH (-5023) consistently to match the other UAMs which the macOS AFP client doesn't seem to mind.

Do you have any advice here, whether to emulate Time Capsule fully or attempt to adhere to the AFP spec where appropriate?

I think we have seen enough examples of Apple not complying with the AFP spec themselves, so I think we should go with what is required for Time Capsule and just acknowledge any spec violations?

[rdmark]

I think we have seen enough examples of Apple not complying with the AFP spec themselves, so I think we should go with what is required for Time Capsule and just acknowledge any spec violations?

let's go with this! I updated the PR so that srp_logincont() returns SRP_AUTH_FAILURE when the M1 comparison fails (e.g. password doesn't match)

Consider constant-time comparison for M1 verification (memcmp → custom ct_memcmp) as a defense-in-depth measure.

done! added a ct_memcmp() function for this purpose. does this match what you were imagining? @andylemin

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
3.5% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🔥 Spectest (AFP 3.4) - Flamegraph (AFP_ASSERT active)

Commit: c3ac6a7bec03cc41407a0f2cfc76a327cfbe62a5
Profiling: On-CPU sampling @ 1009 Hz (prime), DWARF call-graph, x86_64
Build: debugoptimized (-O2 -g -fno-omit-frame-pointer)
Total Runtime: 67s, Netatalk Code-time: 7.3%,
Stacks: 1230, SVG size: 800K

🔥 Open interactive Flamegraph (SVG)

📥 Download from artifacts →

🔝 Top 10 leaf functions

Function	Samples
_raw_spin_unlock_irqrestore	327056400
do_syscall_64	124876080
__cp_end	82259640
dircache_process_deferred_chain	44598600
dircache_remove_children	40634280
srso_alias_safe_ret	38652120
__syscall_cp_c	33696720
finish_task_switch.isra.0	28741320
find_get_block_common	21803760
tcp_sendmsg_locked	17839440

[rdmark]

as a side note, I acquired a 2010 MacBook running OSX 10.7.5 and can confirm that the AFP client is able to authenticate with netatalk's SRP UAM, so we know now that SRP is at least included since Lion in 2011