Hey Stuart! Thats a really good point about SSL on the interfaces service. I saw the bug a few weeks back but it slipped my mind, and it surprised me to discover its been there since 2015.
I'll work towards having a resolution on this in the next week or so and will re-ping the list once its been TLS secure'd. Thanks for beating the drum on this one, i've needed some motivation. All the best, On Mon, Mar 21, 2016 at 10:14 PM Stuart Bishop <stuart.bis...@canonical.com> wrote: > On 19 March 2016 at 02:58, Jorge O. Castro <jo...@ubuntu.com> wrote: > > > Recommendations from everyone on what we should include here would be > > most welcome, specifically our recommendations around Windows charms > > is non-existent. > > I think the acceptable software sources needs to be expanded. > Launchpad PPAs should be acceptable as signing keys are securely > retrieved when using 'add-apt-repository ppa:foo/bar'. Also, 3rd party > apt repositories should be acceptable if the signing key is embedded > in the charm (PyPi could be checked similarly, but it seems rare to > find signed packages there). > > In addition, any software sources not in the main Ubuntu or CentOS > archives should be listed in configuration items that can be > overridden rather than hard coded in the charm, or else the charm is > useless in network restricted environments (and yes, migrating to > resources may be a better user experience in many cases). > > As examples, the PostgreSQL charm pulls non-default packages from the > upstream PostgreSQL apt repository (PGDG, which is the source which > flows to Debian and Ubuntu). The Cassandra charm pulls a required > driver from a PPA I control. It also installs packages from either the > Apache apt repository or the DataStax apt repository. Cassandra is not > available in the Debian or Ubuntu main archives, probably as it > required the Oracle JVM. Both charms use the > install_sources/install_keys config items parsed by charm-helpers and > the apt layer to make this configurable. > > On a side note, it is somewhat disingenuous to block charms in the > store from pulling dependencies from untrusted sources at run time > when we happily pull dependencies from untrusted sources at build > time. I think the fix here is to do better at build time (Moving the > interfaces web site to https: and ensuring clients use that address, > only allowing https:, git+ssh: and other secure protocols for pulling > branches, and checking GPG signatures of embedded wheels are the > issues here I'm aware of) > > -- > Stuart Bishop <stuart.bis...@canonical.com> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
