问题描述
今天我想在Ubuntu Xenial上安装Snap Package，但它促使我在Ubuntu Single Sign-On上注册一个帐户。
为什么Ubuntu会问我们这样的事情？
安装Snap包：
这是Launchpad上报告的错误，https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1581713
最佳解决方法
此行为与Ubuntu软件中心一致。 Canonical与third-party软件提供商合作，为合作伙伴存储库中的商业软件提供支付和托管服务。在Ubuntu 16.04 LTS中，它被Ubuntu App Store取代，后者为快照存储库的后端提供支持。
虽然命令行工具可以毫无问题地访问free-of-charge快照，但Ubuntu软件商店使用Ubuntu One来处理支付处理和订单历史记录(以便以前的购买可以下载并安装在您拥有的任意数量的系统上)。
因此，这是一个与Ubuntu软件替换的软件行为相匹配的实现细节。
次佳解决方法
当前行为存在技术原因和设计原因。
首先，snapd需要某种形式的身份验证，因为它正在执行system-level操作。在命令行上，您可以使用sudo，就像您在apt install时一样，因此不需要在线帐户。使用软件时，目前唯一可用的身份验证形式是Snap存储。正在讨论替代方案……
I did an attempt to resolve this by trying to get snapd to generate a Macaroon without store access. But as I understand it getting a Macaroon requires a round trip to the store.
So I think the solution to this is to either allow snapd to generate local Macaroons or use some other type of authentication token for local access. (comment 27)
其次，SSO身份验证是主要的设计模式，因为Snappy的主要use-case正在管理多个IoT设备。对台式机/笔记本电脑用户的负面影响是无计划的。
The net effect is much better security for these devices… look at modern wifi access points, for example. You get a single management account, usually in the cloud, and you manage all devices through that. (comment 25)
看起来有计划更改行为，以便桌面/笔记本电脑用户不需要使用在线帐户进行身份验证。您可以订阅该错误，以便在进行更改时接收新闻。
Handing out a token to root that provides an authorization to manipulate the system is analogous to allowing root itself to be doing removals without further store information, which we allow… The necessary infrastructure for that is pretty much in place since we already have to maintain the local and remote macaroons separately, and the situation where the remote macaroon is missing or incorrect is already handled. (comment 29)