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 
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:
- 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.
- 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
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