ebicsclient 1.3.1__tar.gz → 1.3.2__tar.gz

{ebicsclient-1.3.1 → ebicsclient-1.3.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ebicsclient
-Version: 1.3.1
+Version: 1.3.2
 Summary: Pure-Python client for the EBICS 3.0 (H005) banking protocol
 Project-URL: Homepage, https://github.com/schulluk/ebicsclient
 Project-URL: Repository, https://github.com/schulluk/ebicsclient
@@ -189,6 +189,17 @@ transaction_id = client.upload(PAIN_001, pain001_bytes)
 The **certificate-based ("mit Zertifikaten")** profile is a constructor option — see
 [docs/11-certificate-profiles.md](docs/11-certificate-profiles.md).
 
+> ### ⚠️ Loading EBICS identifiers from a config file? Quote them.
+>
+> EBICS IDs **can** carry leading zeros (a real Partner ID may look like `00123456`), and
+> ISO message versions look like `"08"`. Unquoted in YAML/JSON/TOML these parse as **numbers** —
+> the wrong type *and* silently stripped of their zeros (PyYAML even reads all-octal-digit
+> values as octal). Since 1.3.1 the library rejects non-string values immediately with an
+> explanatory error, but the correct fix is always **quoting the value in your config**
+> (`partner_id: "00123456"`, `message_version: "08"`) — never wrapping the parsed number in
+> `str()`, which would keep the wrong, zero-stripped identifier and talk to the bank as the
+> wrong subscriber. The same applies to digits-only keyring passphrases.
+
 ## Documentation index
 
 | Doc | Contents |

{ebicsclient-1.3.1 → ebicsclient-1.3.2}/README.md

@@ -71,6 +71,17 @@ transaction_id = client.upload(PAIN_001, pain001_bytes)
 The **certificate-based ("mit Zertifikaten")** profile is a constructor option — see
 [docs/11-certificate-profiles.md](docs/11-certificate-profiles.md).
 
+> ### ⚠️ Loading EBICS identifiers from a config file? Quote them.
+>
+> EBICS IDs **can** carry leading zeros (a real Partner ID may look like `00123456`), and
+> ISO message versions look like `"08"`. Unquoted in YAML/JSON/TOML these parse as **numbers** —
+> the wrong type *and* silently stripped of their zeros (PyYAML even reads all-octal-digit
+> values as octal). Since 1.3.1 the library rejects non-string values immediately with an
+> explanatory error, but the correct fix is always **quoting the value in your config**
+> (`partner_id: "00123456"`, `message_version: "08"`) — never wrapping the parsed number in
+> `str()`, which would keep the wrong, zero-stripped identifier and talk to the bank as the
+> wrong subscriber. The same applies to digits-only keyring passphrases.
+
 ## Documentation index
 
 | Doc | Contents |

{ebicsclient-1.3.1 → ebicsclient-1.3.2}/docs/06-engineering-conventions.md

@@ -91,6 +91,14 @@ specific return code on `ReturnCodeError`).
 - **Gathering** those values from env vars / a vault / Django settings is the **consumer's** job, never the
   library's. Explicit config is auditable; silent environment reads are a surprise and a leakage footgun on a
   money-moving codebase.
+- **Validate at the public boundary, with errors that teach the fix.** Every caller-supplied value is
+  type-checked where it enters the library (dataclass `__post_init__`, first line of a public function) —
+  never allowed to drift into `lxml`/`cryptography` and die there as a cryptic C-extension error. Learned
+  from the field: EBICS identifiers **can** carry leading zeros (`"00123456"`) and versions look like `"08"`;
+  unquoted in a consumer's YAML/JSON config they arrive as *numbers* — wrong type **and** silently
+  zero-stripped. The error message must therefore say "quote the value in your configuration", because the
+  obvious caller "fix" (`str(...)`) would keep a wrong, zero-stripped identifier and address the wrong
+  subscriber. See the README's quoting warning and `tests/test_input_validation.py`.
 
 ## Security (banking client — non-negotiable)
 

{ebicsclient-1.3.1 → ebicsclient-1.3.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "ebicsclient"
-version = "1.3.1"
+version = "1.3.2"
 description = "Pure-Python client for the EBICS 3.0 (H005) banking protocol"
 readme = "README.md"
 requires-python = ">=3.11"

{ebicsclient-1.3.1 → ebicsclient-1.3.2}/src/ebicsclient/models.py

@@ -13,7 +13,7 @@ from cryptography.hazmat.primitives.asymmetric import rsa
 
 
 def _require_identifier(field_name: str, value: object) -> None:
-    # EBICS identifiers frequently carry leading zeros (e.g. a Partner ID of "00705443").
+    # EBICS identifiers can carry leading zeros (e.g. a Partner ID of "00123456").
     # Loaded from an unquoted YAML/JSON/TOML config value they arrive as numbers — the wrong
     # type AND silently stripped of their zeros (PyYAML even reads all-octal-digit values as
     # octal). Failing here, with the fix in the message, beats a cryptic TypeError four

{ebicsclient-1.3.1 → ebicsclient-1.3.2}/tests/test_input_validation.py

@@ -5,7 +5,7 @@ value from an unquoted YAML/JSON config entry) slipping deep into a C extension
 surfacing as a cryptic error — as happened live with a numeric ``user_id`` reaching
 ``x509.NameAttribute`` (``TypeError: value argument must be a str``). Every boundary must
 fail immediately, with a message that teaches the fix. EBICS identifiers with leading
-zeros (``"00705443"``) also *lose their zeros* when parsed as numbers, so the messages
+zeros (``"00123456"``) also *lose their zeros* when parsed as numbers, so the messages
 point at quoting the config value, never at wrapping it in ``str()``.
 """
 
@@ -40,9 +40,9 @@ def keyring() -> Keyring:
 
 
 def test_user_rejects_a_numeric_id_with_a_teaching_message() -> None:
-    # The exact bug report: ZKB IDs like "00705443" unquoted in config arrive as ints.
+    # The exact bug report: ZKB IDs like "00123456" unquoted in config arrive as ints.
     with pytest.raises(TypeError) as caught:
-        User(partner_id="00705443", user_id=705443)  # type: ignore[arg-type]
+        User(partner_id="00123456", user_id=123456)  # type: ignore[arg-type]
     message = str(caught.value)
     assert "user_id must be a str" in message
     assert "int" in message
@@ -173,6 +173,6 @@ def test_the_original_bug_now_fails_at_construction_not_in_cryptography() -> Non
     # Regression for the live report: with a numeric user_id the failure must happen at
     # User(...) with our message — never reach x509.NameAttribute inside cryptography.
     with pytest.raises(TypeError) as caught:
-        User(partner_id=705443, user_id=705443)  # type: ignore[arg-type]
+        User(partner_id=123456, user_id=123456)  # type: ignore[arg-type]
     assert "value argument must be a str" not in str(caught.value)
     assert "leading zeros" in str(caught.value)

{ebicsclient-1.3.1 → ebicsclient-1.3.2}/uv.lock

@@ -281,7 +281,7 @@ wheels = [
 
 [[package]]
 name = "ebicsclient"
-version = "1.3.1"
+version = "1.3.2"
 source = { editable = "." }
 dependencies = [
     { name = "cryptography" },