python: Allow overriding some Trezor specific things #1449
Conversation
|
re supported vendors, minimum fw versions, also USB IDs in #1448, i would move in a slightly different direction: introduce something like a "DeviceModelDescriptor" that has a name, USB ID, vendor, and minimum FW version. This would be part of i'll try to implement this probably tomorrow; it is also practical for trezorlib internally, as it allows us to handle T1 vs TT split more nicely re message overrides: wondering why you think this is a better solution than inserting the overrides into |
Sounds good.
Since |
This keeps information about vendors and USB IDs in one place, and allows us to extend with model-specific information later. By default, this should be backwards-compatible -- TrezorClient can optionally accept model information, and if not, it will try to guess based on Features. It is possible to specify which models to look for in transport enumeration. Bridge and UDP transports ignore the parameter, because they can't know what model is on the other side. supersedes #1448 and #1449
This keeps information about vendors and USB IDs in one place, and allows us to extend with model-specific information later. By default, this should be backwards-compatible -- TrezorClient can optionally accept model information, and if not, it will try to guess based on Features. It is possible to specify which models to look for in transport enumeration. Bridge and UDP transports ignore the parameter, because they can't know what model is on the other side. supersedes #1448 and #1449
|
@achow101 would you mind looking at the current state of hwi-compat branch https://github.com/trezor/trezor-firmware/compare/hwi-compat, in particular commits 9caa667 and cab4ca9, and see if this works for your usecase? |
This keeps information about vendors and USB IDs in one place, and allows us to extend with model-specific information later. By default, this should be backwards-compatible -- TrezorClient can optionally accept model information, and if not, it will try to guess based on Features. It is possible to specify which models to look for in transport enumeration. Bridge and UDP transports ignore the parameter, because they can't know what model is on the other side. supersedes #1448 and #1449
|
closing in favor of #1967 |
This keeps information about vendors and USB IDs in one place, and allows us to extend with model-specific information later. By default, this should be backwards-compatible -- TrezorClient can optionally accept model information, and if not, it will try to guess based on Features. It is possible to specify which models to look for in transport enumeration. Bridge and UDP transports ignore the parameter, because they can't know what model is on the other side. supersedes #1448 and #1449
This keeps information about vendors and USB IDs in one place, and allows us to extend with model-specific information later. By default, this should be backwards-compatible -- TrezorClient can optionally accept model information, and if not, it will try to guess based on Features. It is possible to specify which models to look for in transport enumeration. Bridge and UDP transports ignore the parameter, because they can't know what model is on the other side. supersedes #1448 and #1449
This keeps information about vendors and USB IDs in one place, and allows us to extend with model-specific information later. By default, this should be backwards-compatible -- TrezorClient can optionally accept model information, and if not, it will try to guess based on Features. It is possible to specify which models to look for in transport enumeration. Bridge and UDP transports ignore the parameter, because they can't know what model is on the other side. supersedes #1448 and #1449
When working with Trezor clones, it is useful to use trezorlib over their forks of the library. As such, we need to be able to specify alternative vendors, minimum firmware versions, and alternative message classes to use for those devices. This PR adds attributes to
TrezorClientthat allow a caller to override those things.Specifically,
msg_type_to_class_overrideis a map of wire types to message classes. When decoding a message, the wire type is looked up in this message first before falling back to the default Trezor messages.vendorsis added for the vendors check. This defaults to theVENDORStuple, but can be overridden with another tuple by the caller. Lastlyminimum_versionsreplacesMINIMUM_FIRMWARE_VERSIONin theis_outdatedcheck. This defaults toMINIMUM_FIRMWARE_VERSIONbut can be overridden by the caller.