Hi Jeremy, Thanks very much for raising this issue. As you and I discussed on IRC, it appears there was an assumption that the Technical Board was aware of and comfortable with the MATE behavior here. In fact, the exact behavior implemented in MATE has not been reviewed by the TB as a body, and I do have some serious concerns about how it squares with the policy for archives in Ubuntu images (including flavors).
On Tue, Feb 20, 2018 at 03:46:40PM -0500, Jeremy Bicha wrote: > Hi, > My understanding is that the Ubuntu Technical Board has a > long-standing policy against enabling PPAs without a formal exception. > For background, a request to enable a Unity 8 PPA for 16.04 LTS users > was denied. See LP: #1585362 > Software Boutique > ----------------------- > Ubuntu MATE for several releases has shipped a Software Boutique app > (source package is ubuntu-mate-welcome). While it respects the letter > of the policy (Ubuntu MATE does not enable PPAs by default), the UI at > least bends the interpretation of the policy. > It's fairly easy to try out even without installing Ubuntu MATE. Just > grab the 17.10 iso (the 18.04 version of the app hasn't been fully > updated for available sources) and run System> Administration> > Software Boutique. (The Boutique app is also promoted as part of the > Welcome app experience after install). > There is a large amount of software available for install, some of it > comes directly from Ubuntu. Others are not part of Ubuntu at all. A > user could easily install the Brave web browser and be unaware that > they have enabled a third-party software source and unaware of the > consequences of doing that. > The prominent "Retrieve the latest software listings" link (once > "Apply Changes" is clicked) enables the Ubuntu Mate Welcome PPA. My understanding is that this is the code you've directed me to in the ubuntu-mate-welcome package, which allows installing software from a range of repositories. data/js/applications.json within that package is quite illuminating - in particular, search for 'apt-key-url', 'apt-key-server', and 'enable-ppa'. In principle, there is nothing wrong with flavor developers promoting the use of a particular ppa. The problems arise when the flavor enables the ppa on behalf of the user, without getting the user's informed consent. The UX around add-apt-repository isn't great, it's awkward and scary - but it's that way because you're doing an awkward and scary thing, with significant security implications for the system. You must implicitly trust the owner of the ppa you're enabling, and this decision to trust isn't one that the MATE developers should be making on behalf of the end user. The problem is even worse for the non-ppa sources. By enabling these archives, you are expanding the circle of trust to include: whoever uploads content to the archive; whoever controls the signing key used (which is not Canonical, unlike for a ppa); and in the case of some of the archives, everyone upstream of you on the Internet because while the archive is secured with GPG, the key used to sign the archive is being downloaded over plaintext http. (Of course, even when you're downloading the key over https, you're trusting all of the SSL CAs, because you don't know which one is used to issue the certificate of any particular archive provider and you don't want to break compatibility, so you just use the default list rather than pinning. Unfortunately, it turns out this is not any worse with third-party archives than it is with ppas, because add-apt-repository does: # Specify to use the system default SSL store; change to a different path # to test with custom certificates. LAUNCHPAD_PPA_CERT = "/etc/ssl/certs/ca-certificates.crt" This is regrettable, but I think it is probably not worth fixing in the ppa case given that we should generally try to encourage use of the Snap Store - with its much stronger security story on /multiple/ axes - over ppas.) I see that there are some differences in the display of the different types of sources; but find no explanations to the user of the implications of enabling each type. > Consequences > ------------------- > It's a lot of third-party sources that are not vetted or monitored by > anyone except for the Ubuntu MATE developers. > My understanding is that all third-party sources are disabled on > upgrade by ubuntu-release-upgrader and not re-enabled afterwards. This > is a serious problem. For instance, a user could install Brave in > 17.10 and a few months later, upgrade to 18.04 and then not receive > any security updates for Brave any more. > Also, the Ubuntu upgrader does not run ppa-purge which could cause > issues on upgrade. I don't know if it affects any of the Boutique > apps, but it is a problem for some types of repos. > I think many Ubuntu developers and contributors would consider a > system with a significant number of third-party repositories like that > to be in an unsupported state. (??) > Informed Consent > ---------------------- > During install of those apps, the app does not directly explain to > users what they are doing and where the software is coming from. > There is a details button next to the Install button that does mention > the source. > Other Background > ----------------------- > I had assumed that the Tech Board was aware of the Software Boutique > and had generally approved it. I do feel a bit uncomfortable with > bringing up a topic that could take away one of Ubuntu MATE's popular > features, and I didn't really feel doing so was my responsibility. I > believe I was mistaken on some of those points, but it explains why I > hadn't written this list sooner. > I (very) briefly discussed this app and the possible TB concerns with > Martin Wimpress a long while ago. > Conclusion > -------------- > Therefore, I propose this topic for the next Technical Board meeting, > which I believe is scheduled for February 27. I might not attend (I've > said quite a bit in this email already!) Again, thank you very much for raising this, I think you've quite cogently summarized the problem points. I'm confident that it's possible for us to find a solution that doesn't involve asking the Ubuntu MATE team to eliminate this feature. Martin, would you be available to discuss at the TB meeting on the 27th, or would you prefer that we handle this by email? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
