Warning: Only download Feather from featherwallet.org or our GitHub repo. Verify GPG signatures. is a phishing site, beware!

Feather: A Free Monero Desktop Wallet

Home | Download | Changelog | Screenshots | Docs | Help

[RSS]

2.7.0 changelog (2024-10-08)

2.6.8 changelog (2024-08-15)

Incident report: Denial-of-Service (28 April 2024) (2024-05-01)

Summary

Feather versions 2.6.5 and below are no longer able to send transactions. Upgrade Feather to 2.6.6 or above to fix the issue.

Users trying to construct a transaction on 2.6.5 and below are presented with the following error message: “Internal error: Unrealistic number of outputs in output distribution”.

The bug was triggered when the number of RingCT outputs on the blockchain exceeded 100 million. This caused a sanity check to fail during transaction construction, resulting in the error shown above.

For approximately 5 hours on April 28, 2024, all available versions were affected by the bug, effectively preventing anyone from transferring funds using Feather during that time.

Cause

On August 29, 2021, I committed a patch titled ‘Output distribution checks’ to Feather’s fork of the core Monero wallet library. This patch was first included in Feather beta-9, which was released on September 16, 2021.

The purpose of this patch was to provide better mitigations against an attack known as “output distribution poisoning”.

The output distribution is a histogram of RingCT outputs and affects how the wallet selects decoys for rings. When a transaction is constructed, the wallet requests the output distribution from the node it is connected to.

In the attack, a malicious remote node manipulates the output distribution in a way that reveals the true spend to the node with a high degree of certainty. One way a node could do this is by pretending there are significantly more outputs on the blockchain than there are in reality. This causes decoys, which are referenced by their global index, to skew towards this ‘unrealistic’ number.

Consider the following set of output indices which represent a ring, for which the wallet requests the associated public keys from the node:

{99655570, 50001410564, 50001585151, 50001818442, 50001853725, ...}

The node can clearly tell that the first output is the true spend, because it is the only ‘real’ output that exists on the blockchain.

This could allow the node to associate an output with an IP address. Note that, by default, Feather constructs transactions over Tor, and so the only information a node would learn is that “someone, using Tor, is currently trying to spend this output”. By default, Feather connects to a node from a list of nodes operated by known members of the community. If a node from this list was reported to be malicious, it can quickly be removed and the operator shunned.

In this naive approach, the transaction would be rejected by the network because the ring contains invalid indices. The user would receive an error message upon broadcasting the transaction and promptly switch to a different node.

A more sophisticated attacker could present the output distribution in a way where decoy selection is skewed such that the true spend is detectable, but does not result in an invalid transaction.

For instance, this transaction was constructed using a manipulated output distribution. Can you determine what the true spend is? Notice that all ring members are older than 1y 200d except for one 6-day-old output. Unless the user checks the ring on a block explorer and knows what to look out for, they would not notice that their transactions are being fingerprinted.

Even subtler manipulation may give the malicious node only a statistical edge to guess the true spend, but not noticeably fingerprint the transaction on-chain to a casual observer.

The patch attempted to mitigate this attack with two checks:

  1. It hashes the output distribution returned by a node up until a checkpoint height and compares it against a hardcoded hash. If the hashes don’t match, an error is returned. This prevents any tampering with the distribution before the check-pointed height.
  2. It checks if the total number of outputs in the distribution does not exceed a predefined limit. This ‘sanity check’ is what ultimately caused transaction construction to fail for everyone when the real number of outputs on the blockchain exceeded this limit.

Upon further review, the first check appears to be an effective measure, as long as it is updated with each release. It limits how much an attacker is able to skew decoy selection. The second check appears to be ineffective, as an informed attacker could still skew the distribution to just below the limit. It would only have caught an attacker that was unaware of the limit.

I initially stated that “a large number of outputs were added last month in a spam attack”, believing the patch was a more recent invention and thought the spam attack had contributed more significantly to expediting the timeline. After gathering the details, I found that the attack only contributed about 2.5 months' worth of outputs to the chain. Moreover, the possibility of such an attack should have been taken into account when considering if was a good idea to impose any such limit in the first place.

Plans to clean up Feather’s patchset with the goal of “upstreaming as much as possible” were on the agenda. I believe I would have removed the limit if I had worked on this sooner, however this obviously did not happen before the limit was reached. Following the CCS hack, I prioritised work to help ensure the continuity of the CCS, which included finalising support for offline transaction signing with animated QR codes and ongoing work to integrate multisig. This lead to delays in maintenance work.

I conclude that the sanity check should not have been added, and that my failure to properly document, monitor, and maintain the patch ultimately lead to the denial of service.

Response Timeline

2.6.6

20:40 - User miracloe joins the irc channel and is the first person to report that they encountered the error message.
20:46 - I am able to reproduce the error message by attempting to send a test transaction.

To prevent this from happening in the future, the sanity check is removed.

21:41 - The 2.6.6 release is tagged and building begins.
00:04 - The builds are finished and transferred to the release signing machine.
00:13 - Builds are signed and uploading begins.
01:15 - Uploading is finished and the release is available on the site and in the built-in updater.

Report ➛ Tag Tag ➛ Release Report ➛ Release
1h 1m 3h 34m 4h 35m

‘Report to Tag’ is the amount of time it took to reproduce, debug and fix the issue.
‘Tag to Release’ is the amount of time it took to release the update, which includes building, signing, and uploading the release artifacts and updating the website.

For most users this concluded the wait, others had to wait until 2.6.7.

2.6.7

01:49 - User rayven123 reports on irc they are unable to open 2.6.6 on Tails 5.
01:57 - I am able to reproduce the issue by attempting to open 2.6.6 on Tails 5.

This problem turned out to be related to a compiler upgrade, and was unrelated to the fix for the output distribution issue. It had existed in the master branch since March 18, but went unnoticed because the issue did not affect my development machine.

Since all versions prior to 2.6.5 were no longer able to send transactions and 2.6.6 did not run on some Linux machines, another release was needed.

During this period several other users reported that they are unable to start 2.6.6 on various Linux distributions, including Whonix and Fedora 40. Another user reported an issue with multi-destination transactions, which took a while to debug, but was ultimately unrelated to the release.

04:37 - The 2.6.7 release is tagged and building begins.
04:50 - Exhausted, I announce that I’m going to head off to get a few hours of sleep.
08:18 - I wake up, and begin uploading builds.
08:48 - The 2.6.7 release is now available on the site and in the built-in updater.

Report ➛ Tag Tag ➛ Release Report ➛ Release
2h 48m 4h 11m 6h 59m

Verifying reproducibility post-release

For typical releases, at least two people must submit a signed list of hashes, known as an attestation. This is done to verify that builds are reproducible. If the release is not reproducible, the release process can’t continue; all sources of nondeterminism must be removed and new release must be tagged.

For an emergency release, there is no time to wait for attestations from multiple people. The requirement was lifted for 2.6.6 and 2.6.7.

Luckily, both releases were verified to be reproducible post-release. At the time of writing, 2.6.6 was built by plowsof and me, and 2.6.7 was built by plowsof, MoneroArbo and me, with all hashes matching.

This begs the question as to what would have happened if the builds turned out to be non-reproducible post-release.

In simple cases, like where nondeterminism is trivially attributable to a benign source like an embedded timestamp, an erratum may be published in ERRATA.md. This document was introduced after 2.6.5, which contained an issue with the attestation script.

To describe the defect, a tool like diffoscope may be used to show the binary difference between two builds. This gives verifiers confidence that the release was built from its source code.

If the binary diff is too complex to describe in an erratum, a warning must be issued and the release must be pulled immediately after a new version is available.

Lessons learned

On sanity checks

The main takeaway is to never add sanity checks that may fail at some unknown time in the future, especially when that could prevent essential wallet functionality from working properly. To my knowledge, there are no checks like that in the latest version.

While this was not the intent of the sanity check, I do think it may be useful to have a built-in ‘expiration date’ for a release. Newer releases include bug fixes, improve privacy and security, and patch vulnerabilities (in Feather, Monero, or any of its statically linked dependencies). It is important that users keep the software up-to-date.

A warning could be shown if a fixed amount of time (e.g. 1 year) has passed since the release and prompt the user to consider updating. The user could choose to hide the warning, and continue using the wallet if they do not want to update for whatever reason.

On emergency releases

This was the first emergency release in Feather’s history.

Emergency releases are reserved for two scenarios:

Occasionally, there has been a need for ‘fast’ releases. Like, 2.6.3 which fixed an issue that prevented Feather from running properly on Tails 6, or 2.6.4 which fixed automatic fee adjustment during the aforementioned spam attack. In both cases, there was some sense of urgency, but the problems were not severe enough to qualify for an emergency release. Fast releases must still adhere to the release procedure, but may be announced ‘on the fly’ when a situation arises.

An emergency release should branch off from the previous release, and only include the critical fix and potentially other important fixes that were pending for the next release.

This minimizes the chance of introducing new bugs. Typical releases are tested before they are tagged to check if the complete set of changes does not create any new issues. While this must also happen for an emergency release to ensure that the fix actually works, there is not enough time to test all pending changes.

In case any build system changes or packages updates were pending to go into the next release, it also minimizes the chance of introducing nondeterminism into the build process.

Regrettably, I made the decision to base the 2.6.6 emergency release on master, instead of 2.6.5. The 2.6.6 release contained 20 commits since 2.6.5, which other than the critical fix were all pending changes for the next release and included build system changes, low to medium priority fixes, and a new feature that I had recently tested.

The critical fix removed three lines of code (including an empty line and a comment). Had only this fix been included, it would also have been easier for others to compare the source code of 2.6.5 and 2.6.6 and be confident that the emergency release wasn’t used as an opportunity to introduce malicious code into the source code.

The build system changes ended up causing the bug that resulted in the need for a second emergency release and could also have easily caused nondeterminism. Should an emergency release be needed in the future, I will not make this mistake again. On the upside, much requested fee changes made it into 2.6.6.

On the release procedure

Let’s break down how long each stage of the release procedure for 2.6.6 took and discuss ways in which this it can be optimized.

Building Signing Uploading Total
2h 23m 0h 9m 1h 2m 3h 34m

The total size of release artifacts for any release is about 1000 MB. Signed hashlists and signatures only make up 150 KB of that.

To maintain anonymity, releases are uploaded over Tor to the webserver from a dedicated “upload machine”. Uploading a gigabyte worth of data over Tor can take a while and upload speed can vary widely. The 2.6.6 release took over an hour to upload, and the 2.6.7 release ‘only’ took 30 minutes. If the Tor network has degraded performance, uploading a release could take hours or days. Clearly, in scenarios where time to release must be minimized, any added wait is undesirable.

When a release is tagged, a GitHub CI job begins building it. Thanks to reproducible builds, the artifacts produced by GitHub will match local builds bit-by-bit (unless a source of non-determinism was introduced).

It took the CI job 2h 20m to finish the builds, which is roughly the same amount of time it takes me to build locally. Despite the low thread count available to GitHub runners and lack of caching (due to storage constraints), it greatly benefits from parallelization by building each target on a different runner. In contrast, local builds are sequential, meaning one target is built after another. Any moment where the local build process is not able to utilize all available cores (e.g. during package configure stages) it loses out to parallelized builds.

To decrease the time it takes to complete the upload stage of the release process, only the signed hashlists and signatures could be uploaded to the webserver. It can then fetch the artifacts from GitHub and verify the signatures. Since it can do this over clearnet, this is expected to take only a minute or two. This would have saved nearly an hour on the time it took to get the 2.6.6 release out.

A lower bound of 2h 20m for Tag to Release still isn’t ideal. Breaking down the CI run for the slowest target, we find that time is spent on the following tasks:

Step Time Cacheable
Setting up the runner 0h 2m No
Setting up Guix 0h 12m Maybe
Building Guix derivations 1h 00m Yes
Building depends packages 0h 48m Yes
Building Feather 0h 18m No

Most time is spent re-building stuff that could have been cached. We should be able to fit all cached data within GitHub’s 10 GB cache limit, if we only keep caches for the latest tag. With caching, the lower bound becomes 20 - 44 minutes.

We can’t rely on GitHub solely for builds, so a way to parallelise local builds must also be developed. Typical releases would also benefit from this.

On communication

Information about the incident could have been communicated to users more effectively.

Here is where information could have been posted:

I did not have an automated way to quickly post an update across these channels and did not want to detract time from getting the release out, so I did not post an update everywhere. A script on the “upload machine” could have taken care of posting a short message to all channels, so I will work to set that up.

Thanks to SummerBreeze for creating a thread on monero.town and x011 for creating an issue on GitHub during the incident.

2.6.7 changelog (2024-04-29)

2.6.6 changelog (2024-04-28)

This is an emergency release to fix “Internal Error: Unrealistic number of outputs in output distribution” that prevented any transactions from being constructed.

The number of outputs on the blockchain exceeds a safety limit present in version 2.6.5 and below that was meant to mitigate output distribution poisoning. This caused a sanity check to fail during transaction construction.

Update your wallet to version 2.6.6 or later to resolve this issue.

Fixes and improvements

Maintenance

2.6.5 changelog (2024-03-14)

Fixes and improvements

Maintenance

2.6.4 changelog (2024-03-10)

Fixes and improvements

Maintenance

2.6.3 changelog (2024-02-28)

This release fixes Tails detection. Previous releases may be unable to connect to nodes and default to saving wallet files outside the persistent storage on Tails 6.0 or higher.

Fixes and improvements

Maintenance

2.6.2 changelog (2024-01-03)

Fixes and small suggestions.

2.6.1 changelog (2023-12-16)

Bugfix release:

2.6.0 changelog (2023-12-09)

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:

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

Bugfixes

Maintenance

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:

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.

Install Guix

$ apt install guix

(or the equivalent for your package manager)

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!)

Run the builds

$ ./contrib/guix/guix-build

This may take several hours depending on the speed of your *****U.

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.

2.5.2 changelog (2023-10-19)

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:

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, *****U 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

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-*****p 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:

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.

2.4.9 changelog (includes security fixes) (2023-05-24)

Security Advisory

This release includes a fix for a recently disclosed decoy selection vulnerability that was present in the Monero codebase before v0.18.2.2. For more details, see: https://github.com/monero-project/monero/issues/8872

Users are recommended to update as soon as possible.

Full list of changes: https://github.com/feather-wallet/feather/compare/2.4.5...2.4.9

2.4.5 changelog (2023-04-05)

Full list of changes: https://github.com/feather-wallet/feather/compare/2.4.4...2.4.5

2.4.4 changelog (2023-03-23)

2.4.3 changelog (2023-03-15)

Note: includes changes from 2.4.2, which was not released due to a reproducibility defect.

2.4.1 changelog (2023-02-15)

Bugfixes

2.4.0 changelog (2023-02-12)

Settings screen redesign

This release adds a few new options to the settings, with more planned in future releases. The old UI would have become a bit too cluttered, so settings are now conveniently categorized into Appearance, Network, Storage, Display, Transactions and Misc.

Note that Feather ships with reasonable defaults and most users do not need to mess with the settings at all. However, if you have a specific threat model, it should now be easier to find settings relevant to your concern.

Proxy settings

A proxy tab was added to the settings. This tab replaces the current Tor Info dialog, consolidating all network related settings into one place. Feather can be configured to route traffic over Tor, I2P, socks5 or no proxy at all.

By default, Feather will still route most traffic over Tor. But, if you’re unable to connect to the Tor network or would rather use a different proxy, you have the option to change the settings before any network connections are made when Feather is started for the first time (or after).

I2P support

With the new Proxy tab comes the option to configure Feather to route all traffic over I2P.

Feather is now “I2P-aware” and comes with a built-in list of I2P nodes. All wallet functionality, including the websocket connection (if enabled) as well as the built-in updater will continue to work if you switch to I2P.

Instructions on how to set up I2P and configure Feather can be found in the documentation.

The I2P network is currently under a DDoS attack and is very slow as a result. Expect very slow synchronization for now.

The site is now available on I2P as well: https://rwzulgcql2y3n6os2jhmhg6un2m33rylazfnzhf56likav47aylq.b32.i2p

Feather now supports Prestium, a privacy focused, I2P based live operating system. In an upcoming release Feather will be bundled with Prestium. For now, you can download the AppImage for Linux. Proxy settings are autoconfigured to use I2P when Feather is started for the first time on Prestium.

Other changes:

2.3.0 changelog (2023-01-31)

Thanks lovera for testing Feather on ARM64, and all the lovely people hanging out in #feather:monero.social.

PGP verification guides are now available for all supported operating systems (thanks maltfield for the issue):

See the sidebar in the docs for more.

The release signing key is now available in more places for out-of-band verification (^):

https://docs.featherwallet.org/guides/release-signing-key

The built-in updater was not enabled for versions 2.2.x by mistake. Manually download the latest version from https://featherwallet.org/download to upgrade.

2.2.3 changelog (2023-01-13)

Note for macOS users: Before upgrading an existing installation, rename the “feather” app in your Applications folder to “Feather” (capitalized).

2.2.2 changelog (2023-01-06)

Build system changes

This release introduces major changes to Feather’s build system. While this doesn’t affect any user-facing functionality, it does enable faster, more secure releases.

Feather Wallet releases are now bootstrappable. This means that we are able to build our entire toolchain and dependencies from their source code. By leveraging Guix, a reproducible build environment can be set-up on any Linux host in a matter of minutes. The depends build system makes it possible to build for all target platforms from a single machine through cross-compilation. This greatly reduces release engineering overhead and allows for much faster release cycles, which is especially useful for important bug fixes. It also reduces the risk of supply chain attacks, as all dependencies are pinned and upgrades can be thoroughly reviewed. All builds are bit-for-bit reproducible, and all third-party source code can be accessed indefinitely through fallback mechanisms, ensuring that Feather releases remain reproducible.

Additional resources:

New supported platforms

Starting with this release Feather supports Raspberry Pi and Linux ARM64. Support for RISC-V is planned. Linux ARM64 builds aren’t currently listed on the downloads page, but can be found here: https://featherwallet.org/files/releases/

Qt upgrade

Qt was upgraded from 5.15 to 6.4. You may notice some small visual differences compared to the previous version. We’re aware of some text cutoff happening in table headers in dark mode, this will be fixed soon.

macOS release

macOS builds now ship as a .dmg file. The installation instructions were updated to reflect this.

Webcam QR scanner

The webcam QR scanner now works on standalone Linux binaries. On Linux, the scanner no longer depends on GStreamer, but uses V4L2 directly. Considerable changes were made to Qt’s multimedia backend between 5.15 and 6.4, which may have fixed some bugs and introduced others.

Please let us know if you experience any issues with the scanner on this release.

Source tarballs

Signed source tarballs can now be downloaded from the downloads page. If you’re looking to package Feather for your distribution, please hop on #feather:monero.social for guidance.

Windows installer

The installer for Windows was ported from Inno Setup to NSIS. You can run the new installer to upgrade your current Feather installation without uninstalling the old version first.

Hardware wallets on Windows 11

This release fixes an issue that could cause Feather to be unable to access hardware wallets on Windows 11.

2.1.2 changelog (2022-12-20)

(This release is only available for AppImage builds)

Fix issue with embedded version number in previous release.

2.1.1 changelog (2022-12-20)

(This release is only available for AppImage builds)

2.1.0 changelog (2022-08-12)

Notes:

Windows users that installed Feather using the installer should update manually. Download the 2.1.0 installer from featherwallet.org/download and follow the installation procedure like normal.

MacOS builds are now cross-compiled and reproducible. Work on migrating the build system to Guix + depends was expedited due to a persistent issue with native non-static builds. This is a significant change and may inadvertently cause compatibility issues on some versions of macOS. If you were previously able to run Feather but are not able to run 2.1.0, please report it.

All release binaries except macOS were built using Docker. We will gradually phase out Docker builds in favor of bootstrappable Guix builds in future releases after additional testing.

Please note that all Feather versions 1.0.1 and lower will stop working after the August 13 hardfork. Make sure to update your wallet to 2.0.0 or later before contacting support.

Fixes:

Maintenance:

Known issues:

2.0.0 changelog (2022-07-08)

This release is ready for the August 13 hardfork.

Features:

Improvements:

Fixes:

Maintenance:

1.0.1 changelog (2021-11-02)

1.0.0 changelog (2021-10-29)

Beta-9 changelog (2021-09-19)

Beta-8 changelog (2021-06-11)

Features & Improvements:

Fixes:

Beta-7 changelog (2021-05-27)

Features:

Bugfixes:

Misc:

Beta-6 changelog (2021-05-05)

Ledger support:

Updater:

LocalMonero:

Tor networking improvements:

“Route all traffic over Tor, except traffic to node”

All traffic to the Monero Daemon RPC is routed over clearnet. This option is automatically enabled when Feather is connected to a local node.

“Route all traffic over Tor, except initial wallet synchronization”

This is the default. The wallet will sync over clearnet and automatically switch to a .torify.net node after this is finished. Synchronization requires a lot of data transfer is therefore very slow over Tor.

“Route all traffic over Tor”

This option is automatically enabled on Tails and Whonix or when Feather is started using Torsocks.

Misc:

Beta-5 changelog (2021-03-24)

Notice:

History page:

Transaction proofs:

Transaction info:

Receive page:

Send page:

Sweep output dialog:

Networking:

Multibroadcasting:

Wizard:

Portable mode:

Torsocks:

Misc:

Beta-4 changelog (2021-02-06)

Features:

Wallet:

UI:

Bugfixes:

Misc:

Beta-3 changelog (2020-12-25)

Features:

Wallet:

UI:

Misc:

Beta-2 changelog (2020-12-05)

Features:

Wallet:

UI:

Security:

Misc:

Clearnet | Onion | I2P