copy.copy broken for Ed25519PublicKey in 41.0.3 (works in 38.0.4)

[dkg]

Using python 3.11, with a venv containing python-cryptography 41.0.3 backed by OpenSSL 3.1.2, an attempt to copy an Ed25519PublicKey object yields this error:

  File "…/venv/lib/python3.11/site-packages/pgpy/packet/packets.py", line 1639, in pubkey
    self._extract_pubkey(pk)
  File ".../venv/lib/python3.11/site-packages/pgpy/packet/packets.py", line 1588, in _extract_pubkey
    pk.keymaterial._raw_pubkey = copy.copy(self.keymaterial._raw_pubkey)
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/copy.py" line 92, in copy
    rv = reductor(4)
         ^^^^^^^^^^^
TypeError: cannot pickle 'cryptography.hazmat.bindings._rust.openssl.ed25519.Ed25519PublicKey' object

This looks similar to the concerns in #7587.

You should be able to replicate this with:

import copy
from cryptography.hazmat.primitives.asymmetric import ed25519
privkey = ed25519.Ed25519PrivateKey.generate()
pubkey = privkey.public_key()
newpub = copy.copy(pubkey)

When i try it with python-cryptography 38.0.4 i do not see this failure. Is copy.copy meant to work, or should i be using something like the following instead?

pubkey.from_public_bytes(pubkey.public_bytes(serialization.Encoding.Raw, serialization.PublicFormat.Raw))

[alex]

We've never tested, documented, or intentionally supported using copy.copy on Ed25519PublicKey objects. It happened to work because of Python's built-in behavior of pickling and unpickling all objects. So I'm not surprised it broke.

That said, Ed25519PublicKey objects are immutable, so a correct __copy__ implementation is trivial: return self. I think it'd be reasonable to add it.

[dkg]

I'm assuming that the same is true for Ed448PublicKey, X25519PublicKey, and X448PublicKey objects (and maybe the corresponding PrivateKey objects too?). it'd be great to get them all sorted at once.

[alex]

Yup, all across the board, all immutable.

…

On Fri, Aug 11, 2023, 11:18 AM dkg ***@***.***> wrote: I'm assuming that the same is true for Ed448PublicKey, X25519PublicKey, and X448PublicKey objects (and maybe the corresponding PrivateKey objects too?). it'd be great to get them all sorted at once. — Reply to this email directly, view it on GitHub <#9403 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBGIRZG27N4WBMWGJODXUZELZANCNFSM6AAAAAA3M67GD4> . You are receiving this because you commented.Message ID: ***@***.***>