trezor / data Goto Github PK

I and many other Trezor users have a problem with ElectrumSV.
Could we have a simple and clear instruction?

Something like this:

1. ElectrumSV does work only with Trezor firmware version 1.9.0
2. If you have a higher version you have to downgrade your Trezor firmware to version 1.9.0
3. The downgrading instruction is here: https://wiki.trezor.io/Firmware_downgrade
4. .bin file is here: https://........

I was unable to find the .bin file for version 1.9.0

I can not find any GPG pubkey and signature of binary installation package of Trezor Bridge.
Where can i find them or is there any other way to verify those binaries before installing on my system?

Now we have git-lfs, the repo itself is not big; but because we have all the old bridges at master, they all get downloaded anyway; and then they all get uploaded to our web server when releasing wallet. (they have around 1GB total)

Suggestion: Delete them from master and keep them in a separate branch old. Now that we have lfs, the old bridges won't get downloaded when cloning repo.

We do not wish to release the 2.0.31 as latest, however QA needed it (quite rarely but still) for some testing. More particular they were testing something related to Tor & web and we have allowed the Trezor onion domain in 2.0.30, which is present here but as we know it contained some bugs. I would like to add 2.0.31 here to avoid confusion. The latest will stay on 2.0.27.

@prusnak I believe you have to do this one as the signing via GPG is required.

cc @STew790

add t2b1 firmware and related stuff

When I try to send some ZEC from Trezor Suite the error "Transaction signing error: Unsupported input version v5" appears.

t1b1 -> T1B1
t2t1 -> T2T1

The internal names are not "symbols", they are constants, and as such are implicitly case sensitive.

If we are not using the new paths anywhere yet (@mroz22 please confirm), please rename.

The changelog shows 2.7.0, but the github does not. There is 2.7.0 translation data, but no binary there.

I guess they moved their firmware repo.

Trezor-bridge package for Linux has a dependency for systemd.

This means that distributions without systemd can not install trezor bridge.

• Devuan
• Gentoo, Arch or Parabola with openRC or other init system
• Void Linux
• And the BSDs (although not linux), OpenBSD, FreeBSD, NetBSD and DragonFly BSD.

Is there a work around for Unix like operating systems without systemd?

We forgot to bump bootloader versions for thne newest firmware here

https://github.com/trezor/webwallet-data/blob/2608ab89fbd124b114e58fbbfcab4dfa6537beb3/firmware/1/releases.json#L5

According to comment here, it should be set to 1.6.1.
https://github.com/trezor/trezor-mcu/blob/f684f4ad243abfed03c53946a85493e03d272ec7/firmware/bl_check.c#L46

Others appear to be fine

I've been trying to install trezor-bridge in Qubes' Fedora 33 for the past couple of days and I failed.

First thing I noticed is 2.0.27 is recommended on the trezor.io website, but the newest version in GitHub is 2.0.30. Why is that? Please update the website to point to the newest version.

I tried installing both versions (and every version in between) and failed. Fedora 33 requies the PGP keys used to sign the packages to be imported into the system first. That key was hard to find. I had to go to @prusnak personal website and download the PGP key from there, but that was just an assumption: it is not clearly stated what keys were used and how to obtain them. That key should be accessible and put on the website. Even after importing the key and checking if the package is signed ok (2.0.27) the installation fails:

[user@fedora-33]~/Downloads% rpmkeys -K -v trezor-bridge-2.0.27-1.x86_64.rpm 
trezor-bridge-2.0.27-1.x86_64.rpm:
    Header V4 RSA/SHA256 Signature, key ID b9a02a3d: OK
    Header SHA1 digest: OK
    V4 RSA/SHA256 Signature, key ID b9a02a3d: OK
    MD5 digest: OK
[user@fedora-33]~/Downloads% sudo dnf install trezor-bridge-2.0.27-1.x86_64.rpm 
Warning: Enforcing GPG signature check globally as per active RPM security policy (see 'gpgcheck' in dnf.conf(5) for how to squelch this message)
Last metadata expiration check: 0:36:39 ago on Sun May 30 14:50:33 2021.
Dependencies resolved.
===================================================================================================================================================================================================================
 Package                                               Architecture                                   Version                                           Repository                                            Size
===================================================================================================================================================================================================================
Installing:
 trezor-bridge                                         x86_64                                         2.0.27-1                                          @commandline                                         4.8 M

Transaction Summary
===================================================================================================================================================================================================================
Install  1 Package

Total size: 4.8 M
Installed size: 10 M
Is this ok [y/N]: y
Downloading Packages:
error: trezor-bridge-2.0.27-1.x86_64.rpm: open failed: No such file or directory
Traceback (most recent call last):
  File "/usr/bin/dnf", line 58, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 201, in user_main
    errcode = main(args)
  File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 67, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 106, in _main
    return cli_run(cli, base)
  File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 130, in cli_run
    ret = resolving(cli, base)
  File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 176, in resolving
    base.do_transaction(display=displays)
  File "/usr/lib/python3.9/site-packages/dnf/cli/cli.py", line 238, in do_transaction
    self.gpgsigcheck(install_pkgs)
  File "/usr/lib/python3.9/site-packages/dnf/cli/cli.py", line 278, in gpgsigcheck
    result, errmsg = self._sig_check_pkg(po)
  File "/usr/lib/python3.9/site-packages/dnf/base.py", line 1297, in _sig_check_pkg
    sigresult = dnf.rpm.miscutils.checkSig(ts, po.localPkg())
  File "/usr/lib/python3.9/site-packages/dnf/rpm/miscutils.py", line 90, in checkSig
    raise ValueError('Unexpected return value %r from hdr.sprintf when checking signature.' % siginfo)
ValueError: Unexpected return value 'RSA/SHA256, Mon May 13 13:58:02 2019, Key ID 91f3b339b9a02a3d' from hdr.sprintf when checking signature.

I have no idea what the issue is. The installation fails for 2.0.27, 2.0.28 and 2.0.29. It seems that packages are somehow broken. Please see this RedHat issue: https://bugzilla.redhat.com/show_bug.cgi?id=1963732

I also tried to install the newest 2.0.30 version, but it's signed with different key which I haven't been able to find anywhere:

[user@fedora-33]~/Downloads% rpmkeys -K -v trezor-bridge-2.0.30-1.x86_64.rpm   
trezor-bridge-2.0.30-1.x86_64.rpm:
    Header V4 RSA/SHA256 Signature, key ID 62f0e7e2: NOKEY
    Header DSA signature: NOTFOUND
    Header SHA256 digest: OK
    Header SHA1 digest: OK
    Payload SHA256 digest: OK
    V4 RSA/SHA256 Signature, key ID 62f0e7e2: NOKEY
    DSA signature: NOTFOUND
    MD5 digest: OK

Even if I had that key I would probably encounter the same issue as above. I've run out of options here. Am I using the right key? Why the package installation fails? Why the website points to an old package? Why the newest package is signed with different key and where to find it?

Hi!

Any particular reson why latest bridge version point to 2.0.27 and not to 2.0.30? 2.0.27 is also offered on web wallet when no bridge is installed.

Suite landing page is currently part of Suite repository. With the upcoming new eshop we have discussed with @Hermez-cz that we would like to have trezor.io/suite part of the trezor.io ecosystem. Because of that it does not make much of a sense to maintain Suite LP as part of Suite, it will be done in the shop from scratch. This will also help that the LP will not be bound to Suite release cycle.

To inform about the latest version and offer download links we need to fetch the latest Suite release info via Github API. As Github throttles the download speed we do not want to fetch the binaries from there though.

My suggestion is to upload them to data.trezor.io/suite and simply replace the Github URL from https://github.com/trezor/trezor-suite/releases/download/v21.12.2/Trezor-Suite-21.12.2-linux-x86_64.AppImage to https://data.trezor.io/suite/v21.12.2/Trezor-Suite-21.12.2-linux-x86_64.AppImage (we can bikeshed the folder structure). Note that this would also help trezor/trezor-suite#4692.

We need to:

• Modify deployment jobs in Suite to start uploading Suite releases to data.trezor.io as well.

That's it?

In future I can imagine publishing firmware releases on firmware Github as well and mirroring them here instead of adding them manually. But that is for future.

cc @prusnak @vdovhanych @matejkriz

Add a brief README file to firmware folder explaining the folder structure. There is a link to that folder from Custom firmware feature in Suite so some users can get in there and a brief documentation would be useful for us as well.

The windows bridge installer should also install the INFs to associated the TREZOR device (vid:1209, pid:53c1, rev:0100, class:ff, mi:00) with the Microsoft WinUSB.sys driver. On some revisions of Windows this association is not made and the the device is left in error in the PNP database (aka. "yellow bang"). The Zadig installer can fix this and "unbang" the device, but does so by installing auto generated certificates into the user's certificate store.

Including an INF and signed CAT is standard for windows driver installations, even when said drivers are part of the base OS.

"One of the selected package failed to install correclty. More information is available in the detailed report."

Where can I at least find the detailed report on a rapsberry OS? I used the pi user to execute the install package

I tried installing udev rules as described here :
https://wiki.trezor.io/Udev_rules

but it didn't fix anything.

Also tried the 30 version as the one on the trezor site is 27 but same results.. Help would be very appreciate to set up the bridge as it is required for what I want to do.

thanks

Create a new folder structure for firmwares, organizing them based on internal model names instead of major versions. However, maintain the existing structure for backward compatibility. This preservation is necessary for trezorctl, the Suite FW hash check feature, and any possible direct links from the Internet.

current (preserve as is):
https://data.trezor.io/firmware/{major_version}/trezor-{fw_version}.bin
https://data.trezor.io/firmware/{major_version}/releases.json
e.g.
https://data.trezor.io/firmware/1/trezor-1.11.2.bin

new:
https://data.trezor.io/firmware/{internal_model}/trezor-{internal_model}-{fw_version}.bin
https://data.trezor.io/firmware/{internal_model}/releases.json
e.g.
https://data.trezor.io/firmware/t2b1/trezor-t2b1-1.11.2.bin

• Keep the names lowercase.
  • 1 -> t1b1
  • 2 -> t2t1
• copy&rename existing FWs in new folders and edit paths in new releases.json files

Given the current crackdown on Coinjoin Products, could the docs provide clearer info on how to download Suite without being dependent on GitHub (aka Microsoft)? I see mention of an S3 bucket that might hold these binaries, but failed to decipher the past Actions tasks that may have staged them.

Could we get a clear URL format for Suite. Something like:

https://data.trezor.io/suite/releases/v24.4.3/Trezor-Suite-24.4.3-win-x64.exe