New dispute for snap litecoin-core

I’d like to open a name dispute for the litecoin-core snap (https://snapcraft.io/litecoin-core).

Current state of the snap

  • Publisher: Jared Rice Sr. (arisebank)
  • Last updated: 2017-09-11
  • Version: 0.52.2, available only on the latest/beta and latest/edge channels
  • The Snap Store itself already flags it: “This snap hasn’t been updated in a while. It might be unmaintained and have stability or security issues.”
  • Per its own description, the snap builds from a repository called “GitChains”, described as “powered by AriseBank” — not from the official litecoin-project/litecoin source.

Why I don’t think this should stay with the current publisher

The publisher, Jared Rice Sr., was the co-founder of AriseBank, which the SEC halted in 2018 for running a fraudulent ~$600M initial coin offering (unregistered securities, false claims of FDIC insurance). He subsequently pleaded guilty to felony theft and tampering with government records in a related case.

(As a new forum user I’m limited to two links per post, so these are in code format:)

  • SEC litigation release: https://www.sec.gov/enforcement-litigation/litigation-releases/lr-24088
  • SEC complaint (PDF): https://www.sec.gov/files/litigation/complaints/2018/compa24088.pdf
  • SEC press release: https://www.sec.gov/newsroom/press-releases/2018-8
  • DOJ press release (guilty plea): https://www.justice.gov/usao-ndtx/pr/cryptocurrency-ceo-pleads-guilty-securities-fraud-4-million-crypto-scheme

Combined with the snap being unmaintained for nine years and pointing at a non-upstream source repo, I don’t think this is a reasonable state for a snap that handles users’ cryptocurrency wallets and private keys.

What I’m requesting

Transfer of the litecoin-core name so I can publish a properly maintained snap that:

  • Downloads the official, GPG-signed release binaries from download.litecoin.org (not a third-party source), verifying both the detached PGP signature and the SHA256 checksums before anything is installed.
  • Runs the upstream test suite (test_litecoin) as part of every build.
  • Tracks new upstream Litecoin Core releases going forward.

Proof of work already done

I’ve already built and tested this as a working snap locally (strict confinement, core22 base) against the current Litecoin Core release (v0.21.5.5): daemon, CLI, and GUI (litecoin-qt) all verified working. Packaging source: https://github.com/MichielBruijn/litecoin-core-snap

I’ve also reached out to the Litecoin Core maintainers. Loshan T (losh11, Litecoin Core maintainer) confirmed on the project’s GitHub:

“This dispute is made with awareness of the Litecoin Core dev team.”

See litecoin-core snap · Issue #1098 · litecoin-project/litecoin · GitHub — the team has additionally asked me to document the snap release process so they can incorporate it into their own maintainer workflow going forward.

Happy to provide anything else that would help evaluate this.

Hello,

This seems like a reasonable case to move forward with. One clarification, you’ve filed a dispute but are asking for a transfer. You may be aware but there is a subtle distinction between the two.

I can revoke the name for the current owner and grant it to you; note, however, that because of how snaps work, this will create an entirely new snap ID (32-character identifier) with the same name (SNAP) but since most snap operations actually are keyed on the snap ID, this means it will be effectively a different snap; the implication here is that any current users of SNAP will be stuck with their current revision and not receive updates, unless they uninstall and then reinstall the snap (which is actually removing the old SNAP and installing the new SNAP).

The other thing I can do is a transfer, where I move the existing snap with its current name and ID over to you; this way, users stay “connected” to the snap and don’t need to do anything; they will receive updates and continue working as they did previously. If the old snap was set up for your organization and you just want to recover control of it, this might be the best option.

Let me know how you’d like to proceed.

Hi,

Thanks — and yes, that distinction matters here, so I appreciate you spelling it out.

I’d like to go with the transfer (same snap ID), for one reason above all: the existing users are the people this request is actually about. Anyone currently running litecoin-core is running a 2017 build, from a non-upstream source, that handles private keys and wallet files. A revoke-and-grant leaves exactly those users stranded on revision 7 indefinitely, and realistically most of them will never find out there was a reason to reinstall. The transfer is the only option that actually reaches them.

To be clear about what I’m claiming: this was never my organisation’s snap, so this isn’t a case of recovering control of something that was mine. It is genuinely a change of hands. I’m asking for the transfer purely because of the continuity for existing users and expanding on my hobbies :slight_smile:

One question, if you don’t mind: after a revoke-and-grant, does the previous owner retain the ability to push new revisions to the old snap ID for its existing users, or are they frozen at revision 7? It doesn’t change my preference for the transfer, but I’d like to understand what the alternative would leave behind.

Happy to proceed whenever you are.

Revoke and grant would not allow the previous owner to push new revisions. The users would be frozen at the previous revision.

I’ve revoked your dispute claim, and have transferred the snap in question to your account.

Thanks.

1 Like

Thanks again for handling the transfer — that part went through fine.

I have run into a follow-up problem though, and since it may be related to the transfer I wanted to flag it here as well. Every change to this snap’s text metadata is rejected as a Store terms of service violation. It does not appear to depend on what I write: changing the summary to “Peer-to-peer network node and wallet” is refused just as fast as anything else, while screenshot changes save without any complaint. Uploads are also being held, with the revision page showing manual_review_policy: allow.

Since the name was transferred rather than revoked and regranted, the snap ID was preserved — so I am wondering whether restrictions attached to it under the previous publisher came along with it.

I have sent the details to help@snapcraft.io rather than repeating them here. Posting mainly so it lands with someone who already has the context.

Hello,

Apologies I forgot that we’re restricting crypto/finance snaps to verified publishers. In order to unblock you temporarily, I’ve manually approved the revision you upload. However, I would encourage you to have the litecoin-core team apply to be a verified publisher and that should unblock future edits and uploads.

Thanks, Melvin

Hi Melvin,

Thank you — that explains everything. I had been trying different wordings for the summary, which of course was never going to help if the restriction is on the category rather than on the text. Good to know.

I will ask the Litecoin Core team about applying for verified publisher status. To make sure I take the right route, two questions:

  1. Verification applies to the publisher account rather than to an individual snap, correct? I ask because I would rather not be the verified party here. I am not a member of the Litecoin project (yet) and I do not want to give the impression that I speak for it. What I do is packaging and administration: the snap ships the official release binaries from download.litecoin.org unmodified, verified against David Burkett’s signature at build time, and compiles nothing of its own.

So my assumption is that the right end state is a verified Litecoin publisher account owning the snap, with me kept on as a collaborator so I can continue doing the packaging work. Would you agree that is the route to take, and would another name transfer be the mechanism for it? The last transfer preserved the snap ID, which is what matters for existing users.

  1. In the meantime, could I ask for one more manual approval? I have an arm64 build ready. There has never been an arm64 build of this snap, so those users currently have nothing at all. Both architectures pass review-tools locally and both contain the official binaries, verified against the signed SHA256SUMS from upstream:

amd64 2e7d3f6b7438e2201d50651ff955f2394f21b79a9655d338a43c07e4b6df4c8d arm64 b57a2ceca18165157bff792fa67c0807568d18f2ad02f1adee01da285a0d5790

I would also like to get revision 11 released. Revision 10, which is what is on stable now, is missing the desktop entry for the GUI, so the graphical wallet does not appear in users’ application menus. Revision 11 fixes that and is otherwise identical.

Thanks again for unblocking this.

Michiel Bruijn

  1. Yes, that is right. I agree that ideally the Litecoin Core team is the party that applies to be a verified publisher, and you can be a collaborator to help them along here. Once they’ve applied and are verified we can initiate a transfer to them
  2. I’ve approved revision 11 as well

Thanks Melvin — revision 11 is on stable and the listing is editable again, so the amd64 side is fully in order now.

The arm64 build I mentioned is uploaded, as revision 12, and it is held. If you could approve that one as well I would appreciate it: there has never been an arm64 build of this snap, so those users have nothing at all today. It is the same upstream release as revision 11, built for arm64 from the same packaging, with the hash I posted above.

The hold comes back as manual_review_policy: allow again — the automated checks pass and are then set aside. Am I right that this flag sits on the snap rather than on the publisher account? If so it would survive both verification and a transfer, and every future release would still need a human. Worth knowing before we go through the trouble, and if it can be lifted once the snap is owned by a verified publisher, that would be the thing to aim for.

Meanwhile I have put the verified publisher request to the Litecoin Core team. I will follow up here once they have an account and have applied.

Michiel