In addition to what has already be said, here are a couple suggestions for you to consider:
Encapsulation
Your module has functions get_crc32_slow, list_rar used by your RarFile class and I am wondering why they are not be instance methods of RarFile. Even if you think that these functions might have applicability beyond their use by RarFile, since they are RAR file-related functions, wouldn't making then class methods at the very least be appropriate?
Why @dataclass?
The @dataclass decorator is adding many methods to your class that you do not seem to be using. At the same time it seems to me that a client of this class would most likely be always constructing an instance via the from_path class method and you might even want to make that the exclusive way of constructing instances. But with the class defined as is, there is no way of preventing someone from constructing via the __init__ method that @dataclass provides. Assuming you would prefer to discourage a client from directly using __init__, then this would be one way of doing it:
# No @dataclass decorator:
class RarFile:
def __init__(self):
raise RuntimeError('Construct this class using class method from_path')
@classmethod
def from_path(
cls, archive_path: pathlib.Path, password: str | None = None
) -> typing.Self:
...
#return cls(version, archive_path, files, password)
instance = cls.__new__(cls)
instance.version = version
instance.path = archive_path
instance.files = files
instance.pass = version
return instance