Skip to content

nm: use netplan_netdef_get_output_filename() for connection file paths#583

Draft
rone-oliver wants to merge 6 commits intocanonical:mainfrom
rone-oliver:refactor/nm-use-netplan-netdef-get-output-filename
Draft

nm: use netplan_netdef_get_output_filename() for connection file paths#583
rone-oliver wants to merge 6 commits intocanonical:mainfrom
rone-oliver:refactor/nm-use-netplan-netdef-get-output-filename

Conversation

@rone-oliver
Copy link
Copy Markdown

@rone-oliver rone-oliver commented Apr 20, 2026

Description

Stacked on #580 — review commit 761b3ae only. The earlier
commits belong to PR #580 > and will disappear from this diff once
that PR merges and this branch is rebased.

Replaces the duplicate inline filename construction logic in
write_nm_conf_access_point() with a call to the centralized
netplan_netdef_get_output_filename() API, resolving the two TODO
comments left in the original fix.

The NAME_MAX overflow fix for multi-byte SSIDs (LP: #2147259) now lives
in exactly one place (src/util.c). nm.c no longer constructs,
escapes, or hashes filenames directly.

No behaviour change — all existing tests pass unchanged.

Checklist

  • Runs make check successfully.
  • Retains code coverage (make check-coverage).
  • New/changed keys in YAML format are documented. (N/A)

SSIDs containing multi-byte UTF-8 characters (e.g. emojis) are
percent-encoded by g_uri_escape_string(), expanding each byte to 3
characters. This causes the .nmconnection filename basename to exceed
NAME_MAX (255 bytes), crashing NetworkManager with "File name too long".

If the candidate basename exceeds NAME_MAX, replace the percent-encoded
SSID with a SHA-256 hex digest of the raw SSID bytes. This guarantees a
valid-length (91-byte), unique filename regardless of SSID content.

Apply the same fix in netplan_get_id_from_nm_filepath() so the reverse
lookup falls back to the hashed suffix when the escaped form is absent.

Fixes: LP: #2147259
Add test_write_wifi_long_ssid_uses_hash() to test_netplan_nm.c to
exercise the NAME_MAX overflow path in write_nm_conf_access_point().

A 20-emoji SSID in NM decimal-byte format (320 chars with semicolons)
produces a 507-byte candidate basename when percent-encoded, exceeding
NAME_MAX (255). The test verifies that _netplan_netdef_write_nm()
falls back to a SHA-256 digest filename and that the basename is
within NAME_MAX.

Closes the coverage gap introduced by LP: #2147259 fix.
The 'long_ssid' ctests used raw UTF-8 emoji bytes, but
g_uri_escape_string() with allow_utf8=TRUE passes valid UTF-8
sequences through unescaped (80 bytes → 107-byte basename, well
under NAME_MAX). Those tests never triggered the SHA-256 hash
fallback, leaving lines 649-651 and 690-691 of util.c uncovered.

Change the SSID in both tests to the NM decimal-byte format
("240;159;152;128;" × 20). Semicolons encode to '%3B', yielding a
480-char escaped SSID and a 507-byte candidate basename > NAME_MAX,
which correctly exercises the hash path.

Also add the expected-hash assertion to
test_netplan_netdef_get_output_filename_nm_with_long_ssid to verify
the SHA-256 digest (not the escaped form) appears in the filename.

Fix a missing LCOV_EXCL_LINE on the chown() failure branch in
_netplan_g_string_free_to_file_with_permissions (consistent with the
surrounding getpwnam/getgrnam failure lines already marked).
Replace the duplicate inline filename construction logic in
write_nm_conf_access_point() with a call to the centralized
netplan_netdef_get_output_filename() API, resolving two TODO comments.

The NAME_MAX overflow fix for multi-byte SSIDs (LP: #2147259) now lives
in exactly one place. nm.c no longer constructs or escapes filenames
directly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant