The incident report was published. Ping @tusker.
I will post an incident report later today detailing what went wrong and the lessons that were learned.
I fixed an issue that could cause this. Let me know if you still encounter this after the upcoming release.
Thanks for reporting! Fixed. Will try to follow up with another point release soon.
Thanks, added.
Downloads: https://featherwallet.org/download/
Airgapped signing with animated QR codes
This release features a major overhaul to the offline transaction signing UX and introduces animated QR codes as a way to quickly transfer data between devices.
The offline wallet has a new UI that takes away the clutter and shows only what's relevant to airgapped signing.
You will no longer need to click through menus to import / export files. A wizard was added that guides you through the process step by step. You can choose whether to transfer using files or animated QR codes.
Feather uses Blockchain Common's Uniform Resources library (UR for short) to chop up and encode binary data (such as an encrypted unsigned transaction) into URIs, which can then be presented as animated QR codes.
On the other side, a webcam can be used to scan the QR codes, which can then be reconstructed into the original binary data. Scanning can happen out of order, so if it 'misses' a QR it can pick it up in the next cycle. You just keep scanning until the progress bar fills up to 100%.
By default, each QR translates to roughly ~50 bytes of binary data and animates at 12.5 fps. This was chosen conservatively to allow even the worst webcams I tested with to scan easily. A signed 2-in/2-out transaction (~2.2 kb) takes roughly 3.4 seconds to display all fragments. With a decent webcam and a big enough screen, you can tweak these values to take as little as 280 ms. You can't plug in a flash drive that fast.
Key images are kept in sync as you spend, so you will only infrequently have to synchronize them manually. Typically this is only required when you send your first transaction or don't have enough outputs with known key images to construct a transaction. When you do need to synchronize, the wizard will guide you through the two extra steps.
A lot of effort went into making the process less prone to breakage, while keeping compatibility with other wallets. You shouldn't encounter issues when restoring from seed, wiping your wallet cache, using a partially restored view-only wallet, or switching to a different view-only wallet file.
Monero's current binary format for inputs, outputs, and (un)signed transactions makes implicit assumptions about the state of the wallet that imports the data, which works if everything is done correctly, but is very brittle in practice.
To work around this, the offline wallet no longer stores imported outputs or transaction records. It can't keep an accurate history because it is not connected to a node (and should never be), so why even try. This allows us take a more functional approach to airgapped signing. Given a set of outputs, it returns the associated key images. Given a unsigned transaction, it returns a signed transaction (if the user approves).
To learn how to set up an airgapped wallet and spend from it, follow the guide here.
A special thanks to r4v3r23 from ANONERO, an airgapped wallet for Android that implements UR, for brainstorming ideas and helping test compatibility.
Plugins
This release introduces a preliminary plugin system. Many features that are not essential wallet functions that were present in the previous release are now plugins.
To manage which plugins are enabled, go to Settings → Plugins. Currently, all plugins are enabled by default. If a plugin is disabled, its code is never instantiated.
The Home tab was divided into 5 plugins: Crowdfunding, Bounties, Reddit, Revuo and Tickers. If none of those plugins are enabled, the Home tab is removed completely. It won't even show up under 'View'.
Similarly, disabling the LocalMonero plugin removes the Exchanges tab. Other tabs that are now plugins are Calc and Mining.
The plugin system is a notable improvement over the current state:
- It may serve as a mechanism to introduce experimental features that we'd to like collect feedback and iterate on, before considering if they're useful enough to enable by default. Or allow us to ship niche features that are useful only to a small subset of users, without complicating the default UI.
- Users that enjoy a more minimal experience now have the option to completely disable features they don't use. It was already possible to "Hide" optional features, but this goes a step further by preventing the associated code from being executed.
- (Individual) plugins can easily be disabled during build time, in which case they will simply be absent from the app. This opens the possibility for a "minimal" Feather distribution in the future.
- Should a plugin cease to be relevant, it can be removed without requiring changes to other parts of the code.
Plugins can't (currently) be loaded dynamically. This means that there is no plugins folder to drop new plugins in. Only plugins that exist in Feather's source tree and that are included during the build process are available in the app.
There is an ongoing discussion on whether to allow third-party plugins or exchange integrations. I would like to hear your feedback on this. I will not accept new plugins until the plugin interface is finalized and we reach rough consensus on how to move forward on this.
Additional entropy from dice rolls
You can now optionally use dice rolls or coins flips to generate additional entropy for the creation of a Polyseed.
For usage information, check the documentation.
Receive tab
The Receive tab has a new options menu. It is accessible from the settings icon next to the search bar or by right-clicking the table header. Options are now persisted and the index and label columns can now be hidden.
You can now Pin an address to move it to the top of the table and keep it visible regardless of filter settings. This may be useful to keep a quick reference of an address that was given out to an exchange or a friend, or as a reminder to check up on expected payments.
Additions
- The CCS tab was renamed to "Crowdfunding". It now shows active funding campaigns from MAGIC Monero Fund in addition to the CCS. (Thanks to Rucknium for working on the API.)
- You can now configure the tickers shown in the Tickers plugin. To do this, select the Tickers plugin in the settings and click Configure.
- Added an option to obscure the seed entry when restoring a seed.
- Added Trezor Safe 3 to the list of supported hardware devices.
- The tables in the Bounties and Reddit plugins are now sort-able.
- Improved error messages when spendable balance is insufficient to pay for the transaction fee.
Bugfixes
- Failing to enter a valid password when opening a wallet should no longer prevent the program from exiting completely
- Fixed an issue that could prevent icons in table views from showing on Windows
- Fixed an issue that triggered a crash when Scan was pressed on the Send tab on Windows
- The Flatpak release should no longer fail to start the embedded Tor binary
- Feather should no longer fail to connect to the bundled Tor daemon after a crash
- Desktop files created with AppImage builds should now write the correct application path
- Fixed an edge-case where partial view-only wallet restores could show transaction history entries with unrealistic balance mutations
- Reduced the chance of transaction construction failing due to network issues in the later stages of construction
Maintenance
Updated OpenSSL to 3.2.0
Updated Qt to 6.6.1
Updated Tor to 0.4.8.9
How to help verify reproducible builds
Would you like to help users reach greater confidence that Feather is bit-by-bit reproducible across a wide range of systems? And, do you have access to a decent Linux machine?
Here is all you need to do to get builds running:
(0) System requirements
OS : any GNU/Linux distribution
Storage : 60 GB free
Cores : 4 or higher (recommended)
Memory : 2 GB per thread
You will also need a GitHub account and a GPG key to attest your builds.
(1) Install Guix
$ apt install guix
(or the equivalent for your package manager)
(2) Clone Feather
$ git clone https://github.com/feather-wallet/feather.git
$ cd feather
$ git checkout 2.6.0
(Don't forget to checkout the version you want to build!)
(3) Run the builds
$ ./contrib/guix/guix-build
This may take several hours depending on the speed of your CPU.
(4) Attest your build outputs
Follow the steps here: https://paste.debian.net/plainh/2457c02c
If you get stuck on any step or your hashes don't match, please let us know. Joining the Matrix/irc channel is best for this.
A special thanks to MoneroArbo and plowsof for submitting their signed build hashes before the release.
Documentation browser
Feather now has an offline documentation browser. It is accessible by pressing the 'Help' button in the wizard or by going to Help → Documentation.
Enter a keyword in the search bar to filter the list of articles and highlight matches.
If you spot an error or can't find what you're looking for, consider opening an issue on the feather-docs repo.
Improved error messages
In some cases error messages provide too little information to be helpful or too much and it becomes confusing. I recently came across this post, which highlighted this issue and prompted me to make a change.
Most error messages bubble up from the wallet library. It doesn't shy away from using internal terminology and often includes unnecessary information, like references to the source code. That's useful for developers, but not so much for users trying to understand what went wrong and what to do about it.
To address this, many error messages were rewritten for clarity and made more actionable. They should now adhere to a format that aims to answer the following questions:
- What action went wrong?
- Why did it go wrong?
- [What can I do about it?]
- [Where can I learn more?]
For instance, trying to send a transaction when the wallet has not yet finished synchronizing now shows:
Pressing 'Help' opens the docs browser with more information about wallet synchronization to help a curious user understand why the wallet must be synchronized in order to send a transaction.
Writing good documentation for every case is very much a work in progress. If you see a confusing error message, consider reporting it.
Seed recovery
A seed recovery tool was added that can help recover damaged or partial Polyseeds.
Occasionally, I get an e-mail from someone trying to restore a wallet from a backup seed, but they can't make out what some of the words are. Bad handwriting, a coffee stain, a picture that was badly cropped, etc. Too much information is missing to make it practical to go through by hand, but not enough to make recovery computationally infeasible.
The tool allows you to enter all information you do have about the seed phrase. Regex is supported for partial words. It will then iterate over all possible phrases given the (whole, partial or blank) words provided. Polyseeds include a 11-bit checksum, so only a subset of seed phrases are valid. An address associated with the wallet can optionally be provided to automatically check if any of the valid phrases produce a wallet that contains the address.
For information on how to access and use the tool, see the docs here.
Time machine bump
Feather releases are bootstrappable. This means that the tools used to build Feather are built from source, and the tools that build those tools are too, and the tools that build those tools are too, and so forth.
But surely, this can't go on forever and something can't come from nothing. At the root of the package graph sits a binary seed, a minimal set of binaries that can't be built from source. This used to be the ~60 MB Further Reduced Binary Seed.
With this release, our Guix time-machine was updated to a commit on May 15. Feather builds now benefit from the Full-Source Bootstrap. The root of the package graph is now a heavily annotated 357-byte program, known as hex0.
It's source code all the way down! Every step of the build process is auditable and we do not have to trust someone's potentially malicious binaries.
One important caveat is that while all packages are built from source, the driver that is used to build the initial packages is not. Eliminating this driver is the next step in bootstrappable builds.
(Work is underway to bring bootstrappable builds to the core Monero repo.)
Release attestation
Feather releases are reproducible. Anyone with a x64 Linux machine and Guix (the package manager) installed can create a bit-for-bit identical copy of all release artefacts by running a single command.
The only way to verify that a release is in fact reproducible is to build it multiple times, on different systems. While builds are done inside a container with a normalized build environment, non-determinism can still creep in from (among other things) properties of the build machine, like the kernel, CPU architecture or the bind-mounted filesystem. The more diverse the set of machines the software is built on, the more confident we can be that there are no undocumented requirements for reproduction.
This release adds release attestation, sometimes called verified reproduction. If you're familiar with Monero's reproducible build process, this works the same way as gitian.sigs. Anyone can build Feather, sign the hashes of the outputs and submit it to a common repository. The hashes can then be compared to verify that the builds are reproducible.
With release attestation, users that don't build from source can be more confident that releases are reproducible because multiple contributors will have independently produced identical binaries. Should non-determinism occur, it can be fixed before a release.
A special thanks to /u/MoneroArbo for helping verify reproduction of this release. Their first build (for 2.5.0) revealed an undocumented assumption about the host's umask, which leaks into the container and can introduce non-determinism when newly created files are archived.
If you would like to help verify this release, follow the instructions here to build Feather and create an attestation. We recommend using a machine with at least 8 cores and 32 GB of memory, though this is not a requirement.
Official Flatpak release
Feather now has an official Flatpak.
A lot of effort has gone into making sure that it has the same build security guarantees as our other releases. The Flatpak is bootstrappable and reproducible. It has no dependency on any third-party runtime and does not require trust in Flathub's infrastructure.
The repository is hosted on featherwallet.org and all commits are signed with our release signing key, allowing users to verify the authenticity.
It's also tiny compared to most Flatpaks, weighing in at only ~30 MB (compressed). That's the (empty) runtime + application. It only includes files that are necessary for the application to run, not even a shell or coreutils.
For more information about the considerations that went into this, see my post here.
To install the official Flatpak, simply run:
flatpak install --from https://featherwallet.org
and follow the instructions here to verify your download.
Bugfixes and improvements
- Feather now starts exactly one second faster
- Receive: added an option to show change addresses
- Wizard: automatically select the first wallet, if it exists
- Ledger: private viewkey is now available in Wallet -> Keys
- Node username/password are no longer forgotten upon restart
- Mining: allow adding additional command line options
- All files can now be selecting when importing (un)signed transactions
- Windows installer will now abort if it runs on an unsupported version of the OS
- Fixed an issue that could cause the History tab not to update on an incoming transaction
- Send: clear donate description if address was changed
- Fixed an issue that could lead to a crash
- Fixed a build issue on musl platforms
- Some cosmetic improvements for macOS
Other changes
Many (statically linked) dependencies were updated in this release. Including Monero to v0.18.3.1, Qt to 6.6.0, OpenSSL to 3.1.3, Boost to 1.83.0, and Tor to 0.4.7.15.
In anticipation of animated QR codes for offline transaction signing, the ZBar library, used for QR code scanning, was replaced with the faster and actively maintained ZXing-cpp library.
Our type2 AppImage runtime was updated to the latest version and now uses fuse3.
This does not resolve an issue with AppImageLauncher, which throws an error when trying to install the AppImage. Users are recommended to uninstall AppImageLauncher or remove the .AppImageextension from the file.
This release drops support for Qt 5, which has been EOL since May 26 and no longer receives public security updates. The minimum required Qt version to build Feather is now 6.3. Official releases already switched to Qt 6 in January.
Two documents were added to the repo:
- RELEASE.md describes the release process.
- MAINTENANCE.md outlines maintenance priorities and development goals.
Check out the last document if you're interested in learning more about where the project is headed.
macOS codesigning requirements
It is becoming increasingly difficult to ship non-codesigned applications for macOS.
Apps for Apple Silicon that target macOS 10.15 or later will not start if downloaded over the internet, even if they are ad-hoc codesigned which is what Feather does now.
A workaround involves removing an xattr using the terminal, but this is not something we can reasonably ask from non-technical users.
It is unfortunately not possible to obtain an Apple-issued Developer ID certificate without jeopardising my identity, which is not something I feel comfortable doing at this time.
If you are able to obtain an Apple-issued codesigning certificate and are willing to grant me access to it, please contact [email protected]. Any expenses and time incurred will be compensated in XMR.
Note: while current releases are not "codesigned" according to Apple's definition, all releases are GPG signed with our release signing key. To verify the authenticity of a release, follow the instructions in the installation guide.
Downloads: https://featherwallet.org/download/
Full changelog: https://github.com/feather-wallet/feather/compare/2.4.9...2.5.2
I can't reproduce this. The 10 block lock-time is a consensus rule, so the transaction would get rejected by the network. Is that what happened?