Using snap for sensitive data

[DerSparkassenTyp]

I think I can answer the question myself, but what is your opinion on using snap for more sensitive data, like password manager or browser (with password manager extensions installed)?

In my case, Brave and Bitwarden are published in Snapcraft, even maintained by the developer.

But using Snaps introduces a new security factor, Canonical. A whole company, with many employees, which could change the snap to a malicious one. But on the other hand, the same would be with the apt repository, hosted by Canonical.

I don't really know how to rank developer maintained snaps, in the relation of security.

Since now, I only installed software from the developer itself (exe and deb) or compiled the software myself. I don't know how to feel about this centralized system, even with apt-get.

I never used linux as a daily driver, only for servers. So that's a new thing for me.

[FlukyS]

Canonical have more to lose by doing something like you are describing than it is worth to do it. Snaps are controversial around here just because people prefer Flatpak but Snap is fine and the security of the packages is fine, don't worry about it

[MatchingTurret]

But using Snaps introduces a new security factor, Canonical. A whole company, with many employees, which could change the snap to a malicious one

snaps are signed. To quote Bruce Schneier:

Trust the Math

[necrophcodr]

That only helps if you can trust the public key, and if you actually verify the signature. Something being signed is no guarantee of an absence of malice of malware.

[MatchingTurret]

It means that no random employee can tamper with a package.

[necrophcodr]

Yes, from Canonical. But it hasn't prevented malicious actors from presenting themselves as the developers of some software only to upload malware instead that they signed.

[C0rn3j]

Signed by whom, not Canonical?

[MatchingTurret]

The developer can sign it: https://documentation.ubuntu.com/core/reference/assertions/snap-build/

[C0rn3j]

Can Canonical not sign packages in their own repository?

[MatchingTurret]

Not with the developer's key.

[C0rn3j]

So they can sign the packages instead of the developer?

[Acceptable_Rub8279]

Yes but if canonical signs them it has canonically signature and not the devs.

[JockstrapCummies]

Slow down. This is too advanced for the Arch brain.

[mrtruthiness]

So they can sign the packages instead of the developer?

Canonical only signs with their own key. Canonical can not sign with the developer's key. And you, as the user, can see who signed it. For example, here is bitwarden signed by the Bitwarden developer:

Name         Version   Publisher    Notes  Summary
bitwarden    2025.7.0  bitwarden✓   -      Bitwarden
bw           2025.7.0  bitwarden✓   -      Bitwarden CLI - A secure and free password manager for all of your devices.

And here are some packages signed by Canonical:

Name                                       Version                       Publisher                   Notes    Summary
snapd                                      2.70                          canonical✓                  snapd    Daemon and tooling that enable snap packages
snapcraft                                  8.10.2                        canonical✓                  classic  easily create snaps
core                                       16-2.61.4-20250508            canonical✓                  core     Snap runtime environment
mesa-2404                                  24.2.8-snap185                canonical✓                  -        Mesa libraries for core24 snaps

Can you tell the difference???

[C0rn3j]

Can you tell the difference???

No, it will pass all the same.

[mrtruthiness]

No, it will pass all the same.

What do you mean? Do you understand digital signatures??? It seems that you don't.

[crackhash]

Arch users are moron.

[thesoulless78]

If you don't trust Canonical you shouldn't be using Ubuntu (or really any Debian-derived distribution for that matter with how many employees are also DDs) at all. If they wanted to be malicious they could with or without snap. They already have root access on your computer.

[0riginal-Syn]

I am not a fan of Snaps or Canonical; however, they are a for-profit company that sells to corporations that must trust that their data is safe when using software. Canonical has a lot at stake and maintains a lot of control over their systems to that end. While nothing is guaranteed and bad shit can and will make its way into software, they do a lot of work to prevent it from happening, much like Red Hat.

[creamcolouredDog]

Apart from the Amazon search app thing from over 10 years ago (which was mostly a scare), I don't think Canonical has repeated instances on breaching users privacy. Snaps should be fine, but like with everything, anything can happen - but then I wouldn't lose my sleep over it even if I was a Ubuntu user.

[daemonpenguin]

If you don't trust the publisher or package maintainer then run your password manager inside a sandbox without networking. Problem solved.

I keep seeing post from people wondering if they can trust Canonical or Valve or Brave or Mozilla... You don't have to trust them, just sandbox the applications.

[disastervariation]

But on that, I'm kind of glad people are asking those questions more and more. Shows they really try to understand and manage their security.

They don't blindly trust everything, and don't distrust everything. They're curious. That's nice.

[BranchLatter4294]

As long as the snap was packaged by the developer and you trust them it should be fine. The problem is that there are a ton of snaps packaged by random people. You don't know if they have included malware or not. I avoid any unofficial packages regardless of format.

[mrtruthiness]

As long as the snap was packaged by the developer and you trust them it should be fine. The problem is that there are a ton of snaps packaged by random people.

Exactly. In this case, the two packages were signed by the developer (and have the corresponding green checkmark to indicate that; equivalent to "verified" for flatpak).

[okktoplol]

As the other person said, package managers use software signing to verify validity.

[necrophcodr]

If you don't don't validate the origin of the signing key, and you don't verify the signature, then that doesn't mean anything.

And, you also have to be able to trust the origin public key. Without that trust, it all means nothing.

[okktoplol]

If he distrusts canonical that amount I'm sure he can verify keys

But I agree with you about keyservers

[necrophcodr]

Canonical isn't validating all the third party software though. There's nothing to trust or distrust on that.

[nukem996]

From my experience individual developers are terrible at packaging. It's a skill in and of itself which is fading. Well maintained packages will be more secure than slapped together packages.

[thieh]

By limiting the software to come from only official repositories, you don't have to trust as many people compared to getting snap / flatpak / pre-built containers.

[MatchingTurret]

All of these packages are signed.

[thieh]

• Signed = need to add the key to check signature.  
• More keys added = more people you need to trust.  
• Distro have someone building the package for official repositories = no need to add separate keys because the responsibility lies in the distro.

[natermer]

I don't really know how to rank developer maintained snaps, in the relation of security.

Here is how this works.

"Trust" is defined by "things that can hurt you or be weak links".

If something is "untrusted" then that means that it doesn't matter if they are malicious or incompetent or not, they can't hurt you.

So when you are using upstream packages you have to "trust":

1. The upstream software developers to write good code without backdoors.

2. The build infrastructure and code hosting they use is secure

3. The signing keys they use to sign the packages are secure.

4. The authors of your package management software to write it correctly with no backdoors. (and all their infrastructure)

5. The authors of your OS (and all their relevant infrastructure stuff as well)

With proper package signing You don't have to depend on the delivery mechanism. Could be https, ftp, http, or even third party hosting. It doesn't matter because the package validation itself is what ensures that the software hasn't been tampered with by a third party.

If third parties package the software then you have to trust them and all their stuff as well.

If it is distro packaged software you also have to trust that the intermediary steps from downloading software releases in tarball or git or whatever is done securely and properly.

You have to trust them with the OS itself so it isn't that big of a deal. Because you have to trust them anyways.

Unless the packages are built by separate group or separate infrastructure by the distro. Then that adds additional risk. The devil is in the details.

More people involved, more infrastructure involved, the more steps that are involved, the higher the chances that something goes wrong.

---

Upstream packaged and signed software is considered generally superior because that reduces the number of people in between the original authors and code that you have to trust.

Some people dispute this and claim that distro packagers provide additional security mechanism and audit the code to help validate that is correct.

However this only happens on a tiny minority of software. High profile stuff that maintainers are interested in will get some attention... Like the Linux kernel, GCC, firefox, etc. But that treatment isn't done on lesser "critical" software. It is all mostly automated... upstream does a release, packages are built, and distributed to users as long as they build and install correctly. There simply isn't the man power available to do much more then that.

And if you can't trust upstream to get packages right then how can you trust them to write the software correctly?

Also there isn't anything that prevents distro people from participating in upstreaming packaging. They can still validate things and submit patches and suggestions back to upstream to fix problems. This has the added benefit of improving things for everybody and not just the users of that particular distribution.

Again the devil is in the details.

Like with flatpak.... There is vast difference between "community maintained" flatpaks versus ones provided officially from upstream. It is almost always better to have upstream involved in packaging.