{
  "id": 10540434,
  "title": "Your Signature String Depends on Your Dependency Version",
  "url": "https://urgent.news/2026/09/28/your-signature-string-depends-on-your-dependency-version",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-28T21:47:22.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/minia2a/your-signature-string-depends-on-your-dependency-version-2b75"
  },
  "original_language": "en",
  "account": "A Python library named hexbytes has a version-dependent behavior that affects the creation of EIP-712 signatures. The library can be instantiated as HexBytes, which has a hex() method returning a hex string representation of the underlying bytes. However, the behavior of this method varies depending on the version of hexbytes installed.\n\nPrior to version 1.2.0, hexbytes 0.3.x had an override of the .hex() method that returned a 0x-prefixed hex string (132 characters long), while hexbytes 1.0.0 and 1.1.0 removed this override. Starting from version 1.2.0, hexbytes again returned the raw hex string (130 characters long) without the prefix.\n\nWhen generating an EIP-712 signature, the length of the hex string must be exactly 130 characters. The source material demonstrates running the .hex() method on four versions of hexbytes. The results show that hexbytes 0.3.1 produces a 134-character string, which is too long and fails the server's regex validation. In contrast, hexbytes 1.1.0 and 1.2.0 return the correct 132-character string.\n\nTo create a valid signature, the source suggests using a function called hex_signature that takes raw bytes as input. The function creates a HexBytes object, then retrieves the hex string representation using the appropriate method (to_0x_hex() if available, otherwise hex()). The resulting string is validated to ensure it starts with 0x, and if not, the prefix is manually added.\n\nThe issue highlights the importance of verifying the shape of values exchanged between different environments (e.g., client and server) rather than solely relying on version numbers. The source recommends asserting the expected format of the signature at the boundary where it is generated or consumed. This approach ensures that any discrepancy in version-dependent behavior is detected and handled appropriately, preventing potentially malicious signatures from being accepted by the server.",
  "summary": "A server you're calling validates a request header with something like this: re . fullmatch ( r \" 0x[0-9a-fA-F]{130} \" , signature_header_value ) That is the shape of an EIP-712 signature as a hex string: 0x plus 130 hex characters (65 bytes). Nothing exotic. The client-side code that produces it is one line. And whether that line satisfies the regex depends on which version of a library you…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}