Delete attic leftover files Kdf.py and ChannelBinding.py in generated Flatbuffers WAMP bindings

[dcki]

Bug Description

Summary:

The autobahn Git repo has two paths that match on case insensitive filesystems, like APFS on Mac OS.

Separately from the Git issue, and more important for my purposes as a user, I have a script that I've been using for years that is broken with affected versions of autobahn installed. It attempts to use cp -r in a Docker container to copy a Python installation directory, including site-packages/autobahn/, to a different path that is bound to a directory outside the container, and it fails because of the matching files. Outside the container is a case-insensitive filesystem (APFS).

Expected Behavior:

No errors when using git clone with autobahn on a case-insensitive filesystem, like APFS on Mac OS.

Actual Behavior:

$ git clone git@github.com:crossbario/autobahn-python.git
Cloning into 'autobahn-python'...
...
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'src/autobahn/wamp/gen/wamp/proto/KDF.py'
  'src/autobahn/wamp/gen/wamp/proto/Kdf.py'

Environment

• Version: master Git branch and at least one recently released Python package version, including 25.12.2 but not 23.6.2
• Operating System: Mac OS

[dcki]

It looks to me like KDF.py is newer than Kdf.py and was added a month ago in d0ab7eb

It looks to me like Kdf.py was added in 2019 in 502ceb1

[oberstet]

Summary / explanation

Thanks for the report. This is not a Git or repository issue, and the referenced gen/* files are not part of the Autobahn source tree by design.

Autobahn uses FlatBuffers and vendors flatc; all Python bindings under autobahn/wamp/gen/** are generated at build / install time, not checked into Git.

See eg https://github.com/crossbario/autobahn-python/blob/master/src/autobahn/wamp/flatbuffers/auth.fbs

The observed problem is caused by the FlatBuffers Python code generator in combination with case-insensitive filesystems (macOS default, Windows):

• The schema defines an enum named KDF (all-caps acronym, valid and intentional).
• flatc --python generates two Python modules for this enum:
  • KDF.py (enum constants)
  • Kdf.py (object-API wrapper)
• On case-sensitive filesystems (Linux), these coexist without issue.
• On case-insensitive filesystems, these filenames collide, leading to missing/overwritten files.

This is a known limitation/bug in FlatBuffers’ Python generator: acronym enum names can result in case-colliding generated filenames when the object API is enabled. Autobahn’s schemas and repository layout are correct; the collision arises only in generated build artifacts on certain platforms.

At the moment, resolving this properly would require changes in FlatBuffers itself (e.g. different name normalization, warnings, or generator options). Workarounds in Autobahn would either change public schema names or disable required generated APIs, neither of which is desirable.

For now, this means:

• Autobahn builds correctly on case-sensitive filesystems.
• On macOS, a case-sensitive filesystem or alternative install approach is required.

[oberstet]

Reality check (for tooling authors, 2025)

Platform / FS	Default FS	Case-sensitive	Case-preserving	Notes
Linux	ext4, xfs	✅ Yes	✅ Yes	Filename case is significant; KDF.py ≠ Kdf.py
Linux (ZFS)	ZFS	✅ Yes (default)	✅ Yes	Can be configured case-insensitive, but rarely is
macOS	APFS	❌ No (default)	✅ Yes	Case-sensitive APFS exists, but discouraged and uncommon
macOS (legacy)	HFS+	❌ No (default)	✅ Yes	Same semantics as APFS
Windows	NTFS	❌ No (default)	✅ Yes	Case sensitivity opt-in per directory (WSL), not assumed
WSL (Linux on Windows)	NTFS	⚠️ Mixed	✅ Yes	Case-sensitive per directory if explicitly enabled
FreeBSD	UFS	✅ Yes	✅ Yes	Traditional Unix semantics
FreeBSD (ZFS)	ZFS	✅ Yes (default)	✅ Yes	Same as Linux ZFS
Containers	overlayfs	✅ Yes	✅ Yes	Inherits Linux semantics

Definitions

• Case-sensitive: foo, Foo, FOO are distinct files
• Case-preserving: the filesystem remembers the original case even if comparisons ignore it

[oberstet]

FWIW, of course the C standard doesn’t guarantee anything. The ISO C standard says:

“A filename is a string whose interpretation is host-environment-defined.”

So while in C, these are different string literals:

const char *a = "KDF.py";
const char *b = "Kdf.py";

what happens when you pass them to a POSIX API

FILE *f = fopen("KDF.py", "r");
FILE *g = fopen("Kdf.py", "r");

is implementation defined!

which is why we are in this mess;)

It may:

• open two different files
• open the same file
• fail
• succeed inconsistently

All are compliant behaviors.

POSIX saying “filenames are opaque byte sequences” is about the API contract. Case-preserving vs case-insensitive is about the filesystem’s equivalence relation, which POSIX intentionally leaves undefined.

So the moment you ask:

“Are D and d the same?”

You are already outside POSIX and inside filesystem policy.

So POSIX does not say: “These bytes must refer to different files”

Nor does it say: “These bytes must refer to the same file”

Both are valid POSIX systems. Tooling authors think:

• “If POSIX allows it, it must be safe”
• “Linux behavior == POSIX behavior”
• “Case-only filename differences are fine”

All three are false. POSIX compatibility ≠ portability ≠ sanity.

Wow, what did these guys smoke in the 70s? ;)

Why Unix people get tripped up by this - Historically:

• Unix filesystems happened to be case-sensitive
• POSIX codified Unix APIs, not Unix semantics
• Many developers incorrectly assume POSIX == Unix behavior
• But POSIX very intentionally does not mandate Unix filesystem semantics.
• Linux ≠ POSIX default behavior
• Linux merely implements one valid POSIX interpretation

To be fair:

POSIX prioritized ecosystem inclusion (of broken systems) over semantic rigor. That decision enabled portability (somewhat), but at the cost of allowing filesystem behaviors that break fundamental namespace invariants. Tooling that assumes Unix-like semantics is therefore non-portable, even when POSIX-compliant.

FlatBuffers is just the latest victim.

[dcki]

all Python bindings under autobahn/wamp/gen/** are generated at build / install time, not checked into Git.

I'm not sure if I understand what you're saying correctly, but when I clone the repo (on a case sensitive filesystem) there are already many files in that directory, including KDF.py and Kdf.py.

For example, I can do the following on Mac OS with Docker Desktop installed:

$ docker run -it --rm debian bash
$$ apt update
$$ apt install -y git
$$ git clone https://github.com/crossbario/autobahn-python.git
$$ cd autobahn-python/
$$ ls src/autobahn/wamp/gen/wamp/proto/ | grep K
KDF.py
Kdf.py

[dcki]

I'm not sure if deleting one of the files from Git tracking will fix the later problem with my script, but it seems like it would be a correct first step.

[oberstet]

had time to look again, and deeper this time.

indeed, Kdf.py can and should be deleted! you are right!

in fact, there are two leftover files which should be deleted!

Old File	Issue	Current Replacement
Kdf.py	Old naming + different enum values	KDF.py
ChannelBinding.py	Enum renamed in schema	TLSChannelBinding.py

autobahn-python/src/autobahn/wamp/flatbuffers/auth.fbs

Line 57 in 5e4f7e0

enum KDF: uint8

autobahn-python/src/autobahn/wamp/flatbuffers/auth.fbs

Line 37 in 5e4f7e0

enum TLSChannelBinding: uint8

I apparently at some point:

• renamed enum Kdf to enum KDF (or used a different flatc version no longer enforcing camel/pascal case) and changed the enum values (!)
• renamed enum ChannelBinding to TLSChannelBinding

in the Flatbuffers schema, didn't clean up right away. my fault!

even on Linux with proper case-sensitive filesystems, these leftover files are not used anywhere in autobahn (or crossbar).

I've also dug out the relevant sections in the WAMP protocol spec to check/verify against:

https://wamp-proto.org/wamp_latest_ietf.html#name-salted-challenge-response-a
https://wamp-proto.org/wamp_latest_ietf.html#section-13.3-96

=> argon2id13 or pbkdf2

https://wamp-proto.org/wamp_latest_ietf.html#channelbinding

=> tls-unique or tls-exporter