You should report it on the snap's listing page. You can also escalate the issue by posting to the #snap category of [the Snapcraft Forum](https://forum.snapcraft.io/t/another-crypto-wallet-has-been-in-the-store-for-days/39682/16).
The snap has been taken down. Sorry that happened to you.
I was really hoping that this issue would have gone away now that Canonical has to approve each new snap, but I guess not.
Just about when flatpak gains all the features in snap. Among them would need to be support for command line applications. How is flatpak to rollback versions?
Is this actually a design goal for flatpak / on their roadmap?
I like flats and it would be awesome if cli was supported but thought the general attitude there towards anything cli was "we don't do that here" rather than "maybe someday". Was I wrong?
> Is this actually a design goal for flatpak / on their roadmap?
No, in fact they specifically state in their FAQ that Flatpak is intended for graphical *desktop* apps, not CLI.
Do you have a link where one of the devs / leads actually said they are purposely not intending to support CLI though?
From what I remember, it was more that Flatpak did not have support for *services* in particular (IIRC bc then they would need to get into the territory of either needing to lose portability - like how snap only works on systemd - or else deal with a complex logistics nightmare - hooking into multiple possible host init-systems - which would add a significant maintenance burden). On top of that, I think some system utilities like `fdisk` / `mount` etc that don't use services are already included on most distros and it could be that putting them in a bubblewrap sandbox while still granting the permissions needed to actually be useful is challenging? (I don't know on that last one, I'm just spitballing)
Anyway, if you look in the github issues for flatpak, there are few comments on various tickets mentioning that vim is supported as a cli app. And it would make sense to me given how a) there are several front-ends on Linux actually just interact with a cli-backend and b) for any app that does not hook into services / other system innards, then a programmatic perspective, cli should require *less* permissions than their graphical counterparts, not more
> Do you have a link where one of the devs / leads actually said they are purposely not intending to support CLI though?
I don't think it is so much that they are purposefully seeking to exclude CLI apps. If you look at flatpaks design model, and some of the design decisions, and the docs, it seems quite clear that flatpak is focused on and oriented towards desktop applications, in practice almost all of which are GUI applications.
There is this from the [FAQ](https://flatpak.org/faq/):
> ***Flatpak is designed to run inside a desktop session*** and relies on certain session services, such as a D-Bus session bus and, optionally, a systemd `--user` instance. ***This makes Flatpak not a good match for a server.***
And from the [docs](https://docs.flatpak.org/en/latest/introduction.html):
> Flatpak: a system for building, distributing, and running sandboxed ***desktop applications*** on Linux...
> Target Audience: Flatpak can be used by *all kinds of* ***desktop*** *applications* \[...\] The only technical requirements made by Flatpak are that applications follow a small number of Freedesktop standards, in order to enable desktop integration
But both of these statements are more focused on Desktop vs non-Desktop, not specifically GUI vs CLI. There is considerable overlap, but those are somewhat different questions.
Apart from that, there was a comment on the flatpak mailing list made by flatpak's original author (Alex Larsson) where he alludes to Flatpak not being a good fit for shell scripts that need access to the host system or CLI applications.
> This is not really the target usecase for flatpak, but it could very well work \[...\] running the scripts will be somewhat painful \[...\] hardly ideal for CLI use
He's also [described](https://www.youtube.com/watch?v=xIjxNtIwcBA) flatpak in the past as 'iOS or Android style apps for the Linux desktop' which seems as if it suggests GUI apps (but maybe that is a wrong assumption on my part).
Overall, here is a summary of the main reasons I've heard why CLI applications are not typically packaged as flatpaks:
* Flatpak apps are meant to be self-contained, bundled, and sandboxed. CLI apps typically follow the unix philsophy (do one thing and do it well) and are meant to be small and to interoperate with other small CLI tools. The two design philosophies are conceptually at opposite ends of the spectrum. [(link)](https://discussion.fedoraproject.org/t/how-to-install-cli-flatpak-apps/81785/5)
* Flatpak is designed around unprivileged, rootless containers, sandboxed from the system. Whereas many CLI applications expect or require root privileges. [(link)](https://www.reddit.com/r/flatpak/comments/10w1lxq/comment/j7kx07i/)
* Flatpak containers are restricted from accessing many system directories on the host system. [(link)](https://www.reddit.com/r/flatpak/comments/zx4sp6/comment/ks4f26p/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)
* Flatpak syntax is a little painful and quite tedious and unintuitive from the command line.
None of these reasons seem like reasons you absolutely positively can't package CLI tools in any context. But I do think these reasons, go a long way towards explaining why its very rare to see CLI tools packaged as flatpaks, and demonstrate why it is often said that flatpak is designed with desktop GUI apps in mind.
TL;DR, I don't think the developers are particularly *opposed* to CLI applications as flatpaks, its more that the design is just specifically focused on desktop user applications, and design decisions have been made with this in mind.
I'm not technically informed enough to have a strong opinion on what would need to happen to make flatpak more suitable for typical CLI apps, or if doing so would negatively impact their primary focus and goals.
Thanks for expanding on that. I hadn't considered some of those particularly the bit about
> shell scripts that need access to the host system or CLI applications.
though it absolutely makes sense. I guess the real moral of the story is like you say not cli vs gui but whether whatever app is actually a good candidate for being self-contained (e.g. does not requires dependencies, special privileges, host daemons/services, etc) and that there is a stronger interest in packaging graphical apps that fit these requirements. And within the scope of what's technically possible, the trends will probably align closely with common interests.
It is great that you are able to rollback to any version you want. But it shouldn't be required.
For example, a simple ``flatpak rollback appName`` should return you to the previously installed version. If you want to go back to a specific version, then the command should be something like ``flatpak rollback appName --version=hashValue``.
As it currently stands, imagine this scenario. An app you use updates and suddenly crashes on every launch. To rollback the version, you need to start googling how to find the list of hash values for the app you use or look at man pages or ``flatpak --help`` pages. Then once you find the hash you want, you type the command. Or imagine if you could just do ``flatpak rollback appName`` and avoid that extra effort.
really it should allow version to be a a version tag, like it works in git. so you can say 1.5.2 . perhaps with a magic value like previous for your suggestion.
And/or let you pass some flag to use an interactive mode?
I think if it just prompted you that would also be fine for (non-scripted) scenarios. Like during install if you request an ambiguous package, it will ask you to select which one... Why not make it just does something similar about rollbacks where it shows a list of available versions and has you select a number from a list. Seems like that could be a pretty user friendly solution.
I don't like it when command line applications go accidentally interactive. It makes them harder to script. I'd rather it be more explicit with a flag like --interactive , or alternatively, split it into 2 separate commands, one meant for users and one meant to be scriptable.
What do you mean? Flatpaks either package dependencies with the package itself, or they use common dependencies from a certain runtime. You can have several runtimes installed at the same time without conflicting.
I think I might have run into something like this once due to 2 apps requiring different versions of the same dependency but don't remember the specifics. Anyway, I assumed at the time that it was a case of me not knowing wtf I was doing rather than a design problem... Don't remember which apps but more than likely I just went the "fuck this, Imma build from source" route
I would very much rather Flatpak continue work on improving their security, permissions, and portal design for desktop apps rather then chasing feature parity with Snaps.
Snaps and Flatpak have different focuses. Snaps is general purpose, Flatpak is specifically for desktop applications.
Existing solutions around OCI container format work perfectly fine for CLI apps and services. Things like podman. All that is required to use docker images for CLI applications is to setup a shell alias.
I don't see how coercing Flatpak to fill that role would be a improvement.
And for there to be the ability of having flatpak daemons like snapd, cups, lxd. And for flatpak to be offered as a flatpak. And for flatpak to be able to run apps like docker, firejail.
It would not be too difficult to get flatpak to deal with command line tools, but these other things are just not going to happen. flatpaks and snaps have different "use cases". Both are valid.
It's so much much easier than having to set up 2fa for github account, then github actions to publish on pypi, which of course requires setting up 2fa for pypi as well. Then another complicated setup to publish on snap, and another to publish on flatpack, and… and… and…
Developers can be fixing bugs or can be wasting days upon days to set up all of that, then deal with getting hacking attempts, then deal with random API changes that need changes…
And if the dev isn't a Linux citizen, they have no idea of which format to use. Every few months/years they'll get a bunch of requests to switch to packaging in *xyz* format.
I would rather just get the dependencies from the developers and compile it myself then. If I can't use my package manager, I probably don't want the app, but if it is a "must have," I would rather compile it over using a snap, flatpack, or appimage.
I know this is a snap topic, but i was not talking about snaps at all. I myself don't use ubuntu. I did used to recommend ubuntu, but after the whole Mir thing I stopped recommending it to people and this snap server thing made me it clear that i will never do so again.
My comment though was specifically about how people assuming because some things on windows is bad (being closed source and terrible for privacy) also means some of the user friendly conveniences or even design decisions are bad.
You're completely delusional if you think that "we've been doing fine". There were plenty of valid problems that these new packaging solutions aim to solve.
on the one hand, i feel for the people getting scammed and something needs to be done to prevent this shit. on the other hand, who the fuck downloads a random bitcoin wallet and stores $500k+ in it? holy shit!
> who the fuck downloads a random bitcoin wallet and stores $500k+ in it?
Someone coming from Windows, who is probably used to the Windows Store being a safe place to get software, and who apparently has a lot invested in bitcoin.
Don't blame the user in all this. 100% of the blame should be on Canonical for negligence. I am honestly surprised they aren't being sued out their arses by such a user.
Flathub reviews every new app and when apps change their permissions.
The Snap Store only reviews apps if they request certain permissions. Problem is that social engineering scams don't need dangerous permissions to do harm.
You would have to go over the source code with a fine toothed comb and figure out where the credentials are being sent. At least forbid network access as standard policy for these kinds of apps unless they're a well known business with a physical address. But I doubt they want to get into those weeds and will likely ban crypto apps from the store.
Snap's backend is closed-source, so either third-parties have reverse-engineered the Snap backend, or people are manually installing Snaps they downloaded from the internet. Both of those are bad ideas.
Yes, but Flathub, for example, has a flatpak version of the Exodus app for cryptos and IT IS NOT EXODUS PROVIDING IT. Yet the flatpak is labeled as if it were, with github page link and Exodus website. It appears that it is not a scam app, but it seems to me this is still not right. With something like that, either Exodus provides it, or you don't offer it.
I understand what you're saying, but the code there is SUPER simple. I hardly know any programming but can read through through 5 text files enough to see its safe: https://github.com/flathub/io.exodus.Exodus
The code of the scammer snap is safe. It's what the program asks the user to do that isn't.
According to Exodus, there are only two portals at which to download their software, and Flathub, Github, or the Snap Store are not official portals or source for code.
Yes, but if you read the Github for the Flathub Flatpak, you'd notice that it literally just downloads the software from Exodus directly and verifies its SHA256 checksum.
The checksum wouldn't even matter. A hacker could hack Exodus and post a malicious version with a matching checksum. It [happened before](https://www.zdnet.com/article/hacker-hundreds-were-tricked-into-installing-linux-mint-backdoor/) to Linux Mint.
All I'm saying is that using the Flatpak is about as safe as downloading the file on your own and manually checking the checksum, just like Exodus recommends.
That's something that needs work. It's part of the reason why Flathub created the verification system, but it's not enough. Take Brave as an example: it says "Brave Brower" by "Brave Software", but it's packaged by a third party.
Maybe they should include a seprate line for the publisher. So it should say "Brave Browser" by "Brave Software" published by "third party".
Yes again and again I have seen people quite sure they were using an official flatpak based on what they see at Flathub, but it isn't. This came up a lot in discussions about the snaps and flatpaks for Steam. Neither is official Steam. Major software providers need to take charge of their snaps and flatpaks and then none of this would happen. I would never use an Exodus app unless I was sure it was from Exodus and it's been completely verified that it is. That starts with their official download portals and neither the Snap Store nor the Flathub qualify.
In theory, an app could clear that first check and *then* change stuff out to do the social engineering. Do they have anything in place to handle things like name/logo/description changes?
Changing the app's name should trigger a review:
https://docs.flathub.org/blog/improved-build-validation/
> We have also started moderating all permission changes and some critical MetaInfo changes. For example, if a build adds or removes a static permission (as seen in the finish-args array in the manifest) or changes the app’s user-facing name, it will be withheld for manual human review.
All app manifests are hosted at [github.com/flathub](http://github.com/flathub), while something might slip through it would be in the open for anyone to see and there is no way to "oopsie" your way out of it. Additionally, you know which apps are maintained by their upstream maintainers and thats for certain easier to trust than some random dude packaging for a distro repository.
they both want snaps to be capable of being the sole package manager on your machine and not treating the snap store like a real package manager database
I think it's possible for flatpaks to be scams too. Take for example Exodus for cryptos. I go to their website, and they offer the desktop app in various forms, including deb pkg. But they say nothing about a flatpak. But then I go to Flathub where an Exodus flatpak is listed.. And there are links to the Exodus website--which as I said does not list any flatpak . I would hesitate to use this flatpak until I could certify with Exodus that it is theirs.
Looking at it, it is just a flatpak wrapper around the official code. And the first commit came from a flathub maintainer. So while it may not be official from Exodus, it is official from Flathub itself
Over 100,000 Infected Repos Found on GitHub
[https://apiiro.com/blog/malicious-code-campaign-github-repo-confusion-attack/](https://apiiro.com/blog/malicious-code-campaign-github-repo-confusion-attack/)
When will Canonical face the reality that Snap store is a failed experiment?
I actually installed `snapd` recently after years of avoiding it simply because I wanted to get the BitWarden client from a first-party distribution channel, after having seen Snap shills lying though their teeth about the fact that Snap is no longer slow, and I have no idea who are they trying to fool.
Snap is still by far the slowest format for cold startups, easily, and by a wide margin. If it has improved, it's been from absolutely atrociously slow to merely very slow… BitWarden client still takes solid 5+ seconds to launch, which is an absolute insanity when I'm on Ryzen 5 7600, 32 GB DDR5, and NVMe.
Now that Canonical's refusal to moderate the store has been laid bare multiple times, it really has shown what a travesty it is.
> Snap is no longer slow
Are you still on core 2 duo era hardware?
I've been using snaps for years on an i5-7200u (sky/kaby lake dual core) and i've never noticed slowness (other than 1st-time app launch but thats only 5 sec max and never comes back)
> (other than 1st-time app launch but thats only 5 sec max and never comes back)
"It's not slow if you exclude the parts that are slow" big brain move right there.
Taking 5s to open an app in 2024, even if it's just once, is completely unacceptable. That's what people mean when they say that snap is slow.
> Taking 5s to open an app in 2024 is completely unacceptable.
My god dude. You're whining over 5 seconds delay, once ever.
Do you have any idea how entitled and whiny that sounds? Get some emotional regulation my friend.
I think there was some ambiguity over whether it was "First time ever opened on the operating system" or "First time opened in this session".
The latter is worth being concerned over.
Bitwarden probably launched so slow because it still uses the core18 runtime, which uses a slower compression method. Thankfully they just updated it to core22, which uses a faster compression method, should be faster to launch. But that version probably won't roll out until April.
The Bitwarden snap itself should also switch to the faster compression method with that update as well.
The proper place for compression seems to be file system layer -> snap itself -> the app itself. What is the logical reason for using compression in the least advantageous place?
Compression designed for a highly-specific purpose almost always beats more general solutions. I don't think the added complexity is worth it in this case, but it does have better performance than filesystem-level compression.
General solutions are often "better" than highly specific solutions because they have less complexity and more development resources (due to being more widely applicable), not because they have higher performance or efficiency.
Think of a Pi "compression algorithm" that computes the digits of Pi as needed, compared to compressing the pre-computed digits by any other means. Pi is irrational, so any generic algorithm will still have an infinite size, while the computation program has a finite size. That's essentially a 0% reduction in size compared to a 100% reduction in size.
But snaps solution isn't highly specific and doesn't meaningfully differ on average what filesystem compression handles dealing with the root filesystem.
In fact compressed filesystems have been performant for a long time. For instance ZFS since at least 2008 whereas from 2016–2022 snap was for practical purposes very slow. I include the end date there not because snap became acceptably fast but because I stopped caring and don't know if its still a dog.
Regular executables without filesystem compression probably open faster than regular executables with filesystem compression. That compression isn't for making things faster, it's for making things smaller.
*If* the compression algorithm were properly optimized for a highly-specific situation, *then* it would be smaller *and* faster. Filesystem-level compression *can't* ever reach that level of optimization because it needs to handle all file types, but an algorithm that will only ever compress executables *can*; the problem is not the use of a highly-specific algorithm, it's the fact that it hasn't been sufficiently optimized.
I will NEVER use a snap, or a flatpack, or an appimage. I'm migrating all my Ubuntu machines (most of which I've been running and upgrading from 8.04 or 10.04) to Debian because it's getting too difficult to build and run a server without snaps.
Read an online thread the other day where someone describes that Canonical is looking for a PR manager, and after about 10 interviews got rejected by the CEO. Job is posted regularly, and they never fill it.
No wonder they have no idea how bad that looks.
>When will Canonical face the reality that Snap store is a failed experiment?
probably never since snap have been mostly successful , unlike what you hear about complaining on reddit , most people have no issues with snaps
I will NEVER use a snap, or a flatpack, or an appimage. I'm migrating all my Ubuntu machines (most of which I've been running and upgrading from 8.04 or 10.04, to 20.04) to Debian because it's getting too difficult to build and run a server without snaps.
All of the above are just a symptom of how broken dev toolchains and distribution packaging has become.
It's the epitome of "it works on my machine", except instead of fixing it the solution is to run it on a totally bespoke environment.
Yeah, they are sooooo successful that Canonical had to force their community editions to install it since they'd all followed their users' demands up to that point and used Flatpak instead.
It's absolutely unacceptable not only that scams like this happened several times in Ubuntu's blessed app store, but *continue to happen* after the first incidents.
If they're going to champion the Snap Store, there needs to be some actual stewardship and proper vetting of applications.
> Most meaningful attacks against end users involve tricking them into volunteering information.
Here I disagree. The most common thing a malware does these days is collect all kind of information that is accessible without further asking the user, most common are session cookies and passwords in the browser. And here sandboxing helps a lot to prevent these kinds of attacks.
I dont think it is possible to vet for the huge amount of applications in snap or on Flathub, so a different approach might be to only vet applications that have a legitimate reason to ask for or work with private information (crypto currency client, email client, ftp client) and let sandboxing take care of the security of all the others. Especially those that dont even need to access the internet, no need to waste time vetting a game that only runs offline and has no need to access everything but its own files.
> I dont think it is possible to vet for the huge amount of applications in snap or on Flathub
https://docs.flathub.org/docs/for-app-authors/submission/#how-to-submit-an-app
*"Your pull request will then be reviewed by the Flathub reviewers. Keep in mind that the reviewers are volunteers."*
It appears every app on Flathub has been through some kind of review. And given how these apps are set up, they would definitely have been caught.
Canonical has the money to pay employees to vet applications, especially given their business sector and how Snaps were made in part for their business users.
I would personally just avoid any distribution that forces you to use snaps.
It's literally the only source of applications for Linux that has ever had a serious malware problem, it was designed with no security or review process, and it would cost them money to add one. So don't wait up.
At least with PPAs, someone has to go through the effort of finding and then manually adding the PPA via terminal. And, like with the AUR, people will tell you to be careful with PPAs and third-party repositories.
The implicit trust combined with the lack of proper review was just perfect for this kind of social engineering malware.
Still?
Ubuntu treats the snap store under the same umbrella as the conventional package manager (i.e. searching/installing from their first-part app), so the contents of what's in the snap store really should be vetted properly. Otherwise surely the lack of trust in the store will translate to a lack of trust in the desktop, and then in the company behind it.
Perhaps a blog post is in order, to detail exactly how they'll tackle this long-term. Not that I personally care at all for snaps, but it's a disservice to so many people on the platform.
>Otherwise surely the lack of trust in the store will translate to a lack of trust in the desktop, and then in the company behind it
That must have been a nice rock, we blew past that point awhile ago
Not everyone does, but there's definitely a good sized portion of the community who do. And that's fine, to each their own. Businesses are also worthy of consideration here.
Regardless, I really do hope Canonical can do better for the sakes of the people who want to use it. (Just that's not me.)
> Perhaps a blog post is in order, to detail exactly how they'll tackle this long-term. Not that I personally care at all for snaps, but it's a disservice to so many people on the platform.
Or maybe people should just not recommend and warn about Ubuntu because the company has shown poor judgement (or williingness to sacrifice quality for profits which is too problematic).
It's evil people not Cryptocurrencies, the latter is okay generally.
It's like evil people uses fishing to get people's money from credit/debit cards or bank accounts ... Will you hate fiat money and think they're all scam just because of these incidents?
Except that conventional fiat money doesn't burn a small country's-worth of electricity to run, and doesn't have quite the scale of institution to consumer fraud as crypto.
Plus I love that crypto is *also* fiat money - albeit with fewer people believing in it.
I am fully on-board with the idea that the rich and powerful people that make up The Establishment corruptly direct affairs in their own interest, but wasting resources and accelerating global heating is not the solution.
Good luck protesting "the rich and powerful people that make up The Establishment corruptly direct affairs in their own interest" without them blocking your bank account and other financial assets to disable your activities and the basic living of your family.
> conventional fiat money doesn't burn a small country's-worth of electricity to run, and
Except it does. Count all of the banks, bank HQ's, money trucks burning diesel all day, mega-scale datacenters to track accounting, etc, and it's on par or more CO2 than crypto.
doesn't have quite the scale of institution to consumer fraud as crypto.
Cash is used for 50x more crime than crypto ever will be
The government can freeze your bank account if they suspect you of crimes or terrorism, or if they don't like you. No one can freeze your crypto as long as you retain your keys. And no government or private entity can prevent you from transacting in crypto with anyone in the world, regardless of national borders or sanctions.
Granted, the government *can* make it hard for you to exchange between regular currency and crypto if they want. And they can sometimes trace your crypto payments. But they can't stop or reverse the transactions themselves.
Or at least, the ones that were publicised. It's entirely possible other incidents have occurred..or not. But maybe if there's a blog post, we'll find out.
Not really. Cryptocurrency isn't the problem inherently. Otherwise, it wouldn't be something every major Linux podcast host was a fan of (Tux Digital and Jupiter Broadcasting, the latter of which has an entire segment dedicated to reading what's essentially crypto super chats they've received from the previous episode called Boosts. Sometimes during an episode they'll say that someone just boosted in with a comment and unfortunately they don't have a way to do this with regular currency.)
The main issue is the power draw and the fact that not really any better than regular currency right now since it can apparently be crashed by a single tweet from Elon Musk. Oh yeah, and a bajillion cryptoscams come out every single day. Jupiter Broadcasting even had an office hours podcast called "We Hate Crypto" where they basically said they hate it for the same reasons everyone else does, because everyone's trying to scam people and investors. NTFs are also technically cryoto, which basically quadruples the number of scams.
And hardly any solid legislation.
Regular and audited country and international bank systems have backing of legislation, procedures, policies that protect from volatile acts and save regular folks saving accounts.
I agree with the other comment. If you use LUKS (to encrypt full hard drive), that's probably easier.
But if you want an alternate that supports truecrypt/veracrypt containers and functionality, check out zulucrypt (and zulumount). It's in the main repo for Fedora (and probably others)..
167 Comments
Aristippos69@reddit
Buo-renLin@reddit
that_leaflet@reddit (OP)
that_leaflet@reddit (OP)
mollyforever@reddit
RomanOnARiver@reddit
anna_lynn_fection@reddit
snyone@reddit
redoubt515@reddit
snyone@reddit
redoubt515@reddit
snyone@reddit
mrlinkwii@reddit
NaheemSays@reddit
AdventurousLecture34@reddit
abotelho-cbn@reddit
that_leaflet@reddit (OP)
Michaelmrose@reddit
that_leaflet@reddit (OP)
Business_Reindeer910@reddit
snyone@reddit
Business_Reindeer910@reddit
snyone@reddit
Michaelmrose@reddit
Last_Painter_3979@reddit
Patient_Sink@reddit
Last_Painter_3979@reddit
snyone@reddit
nandru@reddit
snyone@reddit
MetaTrombonist@reddit
Pay08@reddit
natermer@reddit
AdvancedChickenD@reddit
gilium@reddit
Michaelmrose@reddit
mrtruthiness@reddit
dali-llama@reddit
QuantumToilet@reddit
cloggedsink941@reddit
Indolent_Bard@reddit
Sarin10@reddit
Indolent_Bard@reddit
cloggedsink941@reddit
Sarin10@reddit
Pay08@reddit
neon_overload@reddit
Indolent_Bard@reddit
useless_it@reddit
neon_overload@reddit
contigomicielo@reddit
NoWarButMyWar@reddit
dali-llama@reddit
mollyforever@reddit
dali-llama@reddit
mollyforever@reddit
cloggedsink941@reddit
Business_Reindeer910@reddit
cloggedsink941@reddit
Business_Reindeer910@reddit
roerd@reddit
OMightyMartian@reddit
twowheels@reddit
FocusedFossa@reddit
twowheels@reddit
Clinton_won_2016@reddit
whosdr@reddit
Sarin10@reddit
whosdr@reddit
Dynsks@reddit
that_leaflet@reddit (OP)
urban_noise@reddit
SoCZ6L5g@reddit
urban_noise@reddit
FocusedFossa@reddit
SoCZ6L5g@reddit
Plan_9_fromouter_@reddit
bouche_bag@reddit
Plan_9_fromouter_@reddit
bouche_bag@reddit
Plan_9_fromouter_@reddit
bouche_bag@reddit
Plan_9_fromouter_@reddit
that_leaflet@reddit (OP)
Plan_9_fromouter_@reddit
Helmic@reddit
chrisawi@reddit
gp2b5go59c@reddit
Dynsks@reddit
queenbiscuit311@reddit
cloggedsink941@reddit
queenbiscuit311@reddit
Danteynero9@reddit
daddyd@reddit
Plan_9_fromouter_@reddit
KnowZeroX@reddit
Plan_9_fromouter_@reddit
S48GS@reddit
nandru@reddit
CyclingHikingYeti@reddit
JimmyRecard@reddit
PsyOmega@reddit
mollyforever@reddit
PsyOmega@reddit
whosdr@reddit
that_leaflet@reddit (OP)
Michaelmrose@reddit
FocusedFossa@reddit
Michaelmrose@reddit
FocusedFossa@reddit
Michaelmrose@reddit
FocusedFossa@reddit
dali-llama@reddit
andrelope@reddit
arwinda@reddit
mrlinkwii@reddit
dali-llama@reddit
Innominate8@reddit
daemonpenguin@reddit
Michaelmrose@reddit
PorgDotOrg@reddit
shroddy@reddit
whosdr@reddit
nixsurfingtangerine@reddit
whosdr@reddit
whosdr@reddit
ClumsyAdmin@reddit
whosdr@reddit
wiki_me@reddit
secretlyyourgrandma@reddit
EquivalentReal584@reddit
El_profesor_@reddit
amarao_san@reddit
bungotronic@reddit
OMightyMartian@reddit
snyone@reddit
that_leaflet@reddit (OP)
MairusuPawa@reddit
draeath@reddit
themedleb@reddit
SeeMonkeyDoMonkey@reddit
themedleb@reddit
SeeMonkeyDoMonkey@reddit
themedleb@reddit
PsyOmega@reddit
Entity2D@reddit
Jonathan_the_Nerd@reddit
michelbarnich@reddit
RAMChYLD@reddit
whosdr@reddit
that_leaflet@reddit (OP)
Monsieur2968@reddit
SpringSufficient3050@reddit
RomanOnARiver@reddit
LostInPlantation@reddit
Indolent_Bard@reddit
CyclingHikingYeti@reddit
Indolent_Bard@reddit
snyone@reddit
JimmyRecard@reddit
LostInPlantation@reddit
OffendedEarthSpirit@reddit
BoutTreeFittee@reddit
JTCPingasRedux@reddit
CyclingHikingYeti@reddit
NaheemSays@reddit
redddcrow@reddit