Question regarding Debian packaging and external dependencies

[sorenstoutner]

Debian usually wants to build a package using upstream copies of all third-party projects instead of using embedded copies. The primary motivation for doing this is that it simplifies addressing security vulnerabilities, because the upstream project can be updated once and all the programs that incorporate them can be rebuilt automatically. However, if there are compelling reasons not to do so, exceptions can be made.

From what I can tell, Feather wallet has three levels of external dependencies.

1. Polyseed and bc-ur in src/third-party.
2. Monero in monero.
3. Boost, liblmdb, easylogging++, miniupnp, qrcodegen, randomx, rapidjson, and supercop in monero/external.

I read in your feature comparison documentation that some changes are made to your Monero fork (item 2). My questions are:

1. I assume it is OK to replace these files with system packages as the build code looks for a system copies before using the bundled ones. But I wanted to check to be sure (I noticed you are using an older release of Polyseed).
2. Because you have already stated in your documentation that you are modifying the Monero code, I would assume that it would not be safe to build against the upstream Monero code. Are your changes something you expect to eventually be incorporated upstream, or do you expect to maintain them indefinitely?
3. Have you made any modifications to monero/external? Bastian, my fellow packager, maintains the Monero Debian package. He has replaced the majority of the contents of monero/external with system packages without issue, but I wanted to make sure Feather Wallet isn't using them in a different way that could be problematic.

FYI, there is a fair amount of information about the Monero Debian package at:

https://tracker.debian.org/pkg/monero

Thanks for being willing to help us with the packaging. I really appreciate it.

[tobtoht]

1. These are OK.
2. We apply dozens of non-trivial patches on top of Monero. Building against upstream will simply not work. While most patches get incorporated upstream eventually, we expect to maintain a significant patch-set indefinitely.

• miniupnp, randomx, qrcodegen: these dependencies are not used in Feather. I will remove the submodules.
• Boost headers and liblmdb, should not be unvendored. Doing so will break wallet file compatibility.
• easylogging++ is heavily modified and should not be unvendored.
• supercop and rapidjson can be unvendored.

What you need to know about packaging Monero-related software:

Nearly every Monero and Feather release contains security and privacy fixes. The Monero version in Debian stable (v0.18.0.0) is dangerously out of date and contains numerous vulnerabilities. Specific vulnerabilities are not always disclosed. You can infer if a release includes security fixes by looking at the "recommended version" in the Scheduled software upgrades table in the Monero README. In practice, network participants are expected to run the latest version at all times. Monero may hard-fork on months' notice, rendering all prior versions of the software useless, including wallet applications. If you decide to package Feather, I would wish for more active maintenance going forward. Failing to do so puts user funds and privacy at risk. If Debian release policy does not allow you to keep the software up-to-date, I strongly recommend against packaging Feather and to discontinue packaging Monero.

[sorenstoutner]

1. These are OK.

ACK.

2. We apply dozens of non-trivial patches on top of Monero. Building against upstream will simply not work. While most patches get incorporated upstream eventually, we expect to maintain a significant patch-set indefinitely.

ACK.

3.
* `miniupnp`, `randomx`, `qrcodegen`: these dependencies are not used in Feather. I will remove the submodules.

* Boost headers and `liblmdb`, should not be unvendored. Doing so will break wallet file compatibility.

* `easylogging++` is heavily modified and should not be unvendored.

* `supercop` and `rapidjson` can be unvendored.

ACK. Please let me know if things change in the future and it is no longer safe to unvendor supercop and rapidjson. It would be sufficient to simply mention it in the changelog, which I always read before packaging a new version.

What you need to know about packaging Monero-related software:

Nearly every Monero and Feather release contains security and privacy fixes. The Monero version in Debian stable (v0.18.0.0) is dangerously out of date and contains numerous vulnerabilities. Specific vulnerabilities are not always disclosed. You can infer if a release includes security fixes by looking at the "recommended version" in the Scheduled software upgrades table in the Monero README. In practice, network participants are expected to run the latest version at all times. Monero may hard-fork on months' notice, rendering all prior versions of the software useless, including wallet applications. If you decide to package Feather, I would wish for more active maintenance going forward. Failing to do so puts user funds and privacy at risk. If Debian release policy does not allow you to keep the software up-to-date, I strongly recommend against packaging Feather and to discontinue packaging Monero.

I agree that the Debian Monero package is not in good shape. If you had said above in (2) that is was OK to build Feather Wallet against the upstream Monero package, the first thing I would have done would have been to involve myself in that package, update it to the current version, and maintain it updated.

A good indication of my packaging track record is the Debian Electrum package.

https://tracker.debian.org/pkg/electrum

I package new versions on a monthly basis and more often if needed, which I make sure enters unstable, testing, and stable-backports (which means that every supported Debian user has easy access to them). In the case of the recent Lightning security bugs, I coordinated with upstream via secure channels before their release and had fixed versions prepared ahead of time so that when the embargo lifted on the security fix the Debian package was uploaded at the same time as upstream published their fixed version.

GHSA-9gpc-prj9-89x7
GHSA-8r85-vp7r-hjxf
https://security-tracker.debian.org/tracker/TEMP-1052200-1C589C

[sorenstoutner]

Looking more closely at Supercop, it doesn't look like it is a good candidate for a Debian package at the present moment because it currently requires part of the greater Monero project to build. I will keep my eye on it and package it for Debian if that ever changes (the documentation indicates that might be changed in a future release).

[bgermann]

A note on undisclosed security issues: You cannot expect them to be fixed in Debian or any other downstream. The security tracker for the monero package does not show any issue affecting the software in any active release.

[sorenstoutner]

Yes, as a matter of good security practice, I would recommend that all known security bugs be disclosed.

[tobtoht]

A note on undisclosed security issues: You cannot expect them to be fixed in Debian or any other downstream. The security tracker for the monero package does not show any issue affecting the software in any active release.

Security Issues that affect users are usually communicated in a blog post or implied in the changelog. Users are advised to always run the latest version of the software. Issues that affect network stability (such as denial-of-service attacks) are typically only disclosed on a need-to-know basis.

If you can't package the latest version, then don't package the software at all. Monero is not stable software, so perhaps you should reconsider whether it belongs in a stable distribution.

Debian 11 was stable until 10 June 2023. It ships Monero v0.17.2.0, which is no longer able to connect to the Monero network as of 13 August 2022. For 10 months and until users upgraded to Debian 12, the stable package was rendered useless (i.e. daemon can't synchronize, CLI wallet can't send or receive transactions).

Why was the package never updated? And how will you prevent a repeat of this? We are aiming to hard-fork again next year. This will affect Feather, too. This upgrade will introduce Rust as a build dependency. You will need to package the upgrade in months' notice or the software stops working.

[bgermann]

You are right, there should have been a stable upload in Debian 11. At that time I was not involved with packaging Monero. And usually, I run unstable systems, so will rely on users to report their (old)stable software not working. There is no such bug report, so I have not catered to it yet.

[sorenstoutner]

Let me provide a bit of insight into Debian's repository architecture (because the naming doesn't automatically communicate the actual usage)

Debian has three main repositories:

1. unstable (codename sid, who is the kid who breaks toys in Toy Story)
2. testing (currently codenamed trixie, with each release being named after a character in the Toy Story franchise)
3. stable (currently codenamed bookworm)

New packages are always added to unstable. After 5 days with no serious bug reports (2 days if they have autopkgtests that run without errors), they propagate to testing. Every two years, testing freezes and becomes stable. Unstable is always called sid, but the code names of testing and stable change with each release of a new stable, with the current testing codename becoming the new stable codename.

Unstable and testing are rolling releases. They update multiple times per day. Stable is designed for systems that don't change. Specifically, updates to stable generally are not supposed to add new features to a program, only bug fixes. For feature updates to stable, there is a special repository called stable-backports, which backports new releases from testing to stable. Users on stable can choose whether they want to install updates from stable-backports or not.

The above is over-simplified, but gives a general idea. Some people, like bgermann, run unstable on their main production systems. I personally run testing, which is probably the most "stable" rolling release of Linux anywhere on the internet. Some people run stable. Good coverage for a program like Monero or Feather Wallet should include timely updates to unstable, which propagate to testing, and are then rebuilt for stable-backports.