Hello,
How can I be sure that an app is actually from the developers of the software and not some potentially dangerous duplicate?
is there a way to verify the owner like they do in keybase, where you can verify your website, github, twitter etc?
or you could verify your snapcraft account with keybase eventually?
Well, you can always reach out to the upstream developers and verify that it’s from them. Failing that, here are the precautions I follow, if it’s helpful:
snap interfaces. If the snap uses an insecure interface (e.g. x11), don’t use it unless you trust the publisher. Similarly, if the snap uses the home interface, disconnect it unless there’s an obvious reason it’s required (the snap might break if it’s required).Other than that, a strictly confined snap is pretty limited in the damage it can do.
A few of us were having this exact discussion on Twitter a few days ago. Something that was brought up that was interesting was the concept of a “verified” packager. It seemed more logical as the upstream dev may not always be the one packaging. I’m not entirely sure how that would work (we only chatted high level - and in 140 character bursts).
But maybe some sort of reputation driven system similar to ask Ubuntu? Some other manual validation (not sustainable)? Combination there of?
Just a few high level thoughts.
I was just recently thinking along the same lines. Just like all .deb packages have a “maintainer” field that includes the maintainer’s name and email address, so should snaps. There should also be a "snap source’ command to download the packaging tree. For snaps released under open source licences this should be the exact equivalent of apt-get source; for closed-source snaps it should provide at least the snapcraft.yaml.
I think in reality people could be looking for:
Depends on what a malicious snap would be trying to do…could be a bitcoin snap that takes the info about your bitcoin wallet, then the confinement wouldn’t stop the malicious act?
(I may be misunderstanding bitcoin, that’s just an example!)
Note that they do have a contact field, e.g.:
$ snap info nextcloud
name: nextcloud
summary: Nextcloud Server - A safe home for all your data
publisher: nextcloud
contact: https://github.com/nextcloud/nextcloud-snap
<snip>
Of course. I didn’t mean to say the risk was zero, I meant it was limited.
It seems it’s not systematic. For example:
$ snap info quadrapassel
name: quadrapassel
summary: Fit falling blocks together
publisher: canonical
description: |
Quadrapassel is a derivative of a classic Russian falling-block game.
Reposition and rotate the blocks as they fall, and attempt to fit them
together. When you form a complete horizontal row of blocks, the row will
disappear and you score points. The game is over when the blocks get stacked
too high. As your score gets higher, you level up and the blocks fall faster.
If you’re looking for a challenge, Quadrapassel allows you to increase the
initial speed of the blocks, or begin the game with partial blocks on some
of the rows. Or, instead of allowing the blocks to fall randomly, it can
select blocks that will be hard for you to place.
snap-id: bjPxXSBdXzlBa4PnaYGZtofDVAHRlcj7
commands:
No contact there. And I think that being able to retrieve snapcraft.yaml together with the source code where applicable would also be very useful. Essentially it comes down to a topic that has been discussed several times already: lest it constitutes a giant step backwards, snap should fundamentally stick to the philosophy and expectations of the open source community, where access to the source code and being able to rebuild any supplied software are paramount. It should steer clear from the Apple or Google app store model where apps are opaque blobs and publishers are abstract entities that it may or may not be actually possible to contact and which one has no choice but to “trust” by default.
you dont think that is valid as a contact ?
I think what is missing here is proper wording from snapd and proper chain of signed assertions that is meaningful to the user.
Right now snapd doesn’t know much about an account but this is planend to be exposed through various assertions. I think there should be commands that display information about a snap and about an account equally. In addition there’s the very important flag (I forgot if is called certified or verified) that is associated with each account. If set an account is actually verified to belong to the person or entity being claimed.
While not widespread today I think this is paramount to the actual chain of user trust for a snap.
If a user can inspect snap “foo” belongs go user / entity “bar” and that the account really belongs to “bar” and not to some unknown person then this is important re-affirmation from snapd.
Hypothetical:
$ snap info --account zygoon
name: zygoon
display-name: Zygmunt Krynicki
email: ...@zygoon.pl
certified: no
...
We intend to make this more visible and provide a means for ISVs to get their account “certified”, but currently you can see the account info with snap known, e.g.:
$ snap known --remote account series=16 account-id=canonical
type: account
authority-id: canonical
account-id: canonical
display-name: Canonical
timestamp: 2016-04-01T00:00:00.0Z
username: canonical
validation: certified
sign-key-sha3-384: -CvQKAwRQ5h3Ffn10FILJoEZUXOv6km9FwA80-Rcj-f-6jadQ89VRswHNiEB9Lxk
Docs on assertions can be found here: https://docs.ubuntu.com/core/en/reference/assertions
@noise Per the discussion in the sprint last week, we really want those to be “verified” rather than “certified”.
But indeed yes, we do plan to implement exactly that. Some of the support is already in place even.
I see many publishers that are marked as verified on the Snap Store home page now. I just wanted to add a reminder that this thread is out of date to those who are coming across this thread like I did from a search engine results page.