<div dir="ltr"><div><div>hi there,<br><br></div>just wanted to follow-up on this query and see if we have a solution to this problem?<br><br></div>/manik<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 6, 2017 at 9:17 AM, Loïc Minier <span dir="ltr"><<a href="mailto:loic.minier@ubuntu.com" target="_blank">loic.minier@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>This question came up in the context of Docker registries with self-signed certificates:</div><div><a href="http://askubuntu.com/questions/868268/add-self-signed-certificate-in-ubuntu-core-16-04" rel="noreferrer" style="font-size:12.8px" target="_blank">http://askubuntu.com/questions<wbr>/868268/add-self-signed-certif<wbr>icate-in-ubuntu-core-16-04</a><br style="color:rgb(0,0,0);font-size:12.8px"></div><div>this could be addressed in ways specific to the Docker snap, but I believe this touches a larger question: support for extending the list of system-trusted certificates.</div><div><br></div><div>Our Ubuntu Core images ship with a set of trusted certificates. These are inherited from the .deb world where there is a mechanism to locally extend the list of trusted certificates (update-ca-certificates). This mechanism doesn't work with core images due to read-only directories (and perhaps other issues as well).</div><div><br></div><div>Here are some possible options to address this:</div><div>1) fix the update-ca-certificates system to also work on core images; this might just be a matter of making some directories bind-mounts to the writable space</div><div><br></div><div>2) implement some kind of snapd keystore feature/configs/APIs (much like system keystores on mobile OSes); this is likely significant work, but opens interesting perspectives in providing new management APIs and a more secure implementation. For instance, one could design this to store secrets in hw-specific secure stores, or offer mechanisms to roll out new certificates/keys via assertions, or to disable some specific CAs</div><div><br></div><div>3) keep the list of system certificates as static and not locally configurable; this will likely result in some snaps developing alternate keystores</div><div><br></div><div>I'm sure there are other options and I'd to hear how people think this should best be addressed in the snap/snapd world.</div><div><br></div><div>Cheers,</div><div><div class="m_1023034043401009308gmail_signature"><div dir="ltr">- Loïc Minier</div></div>
</div></div>
<br>--<br>
Snapcraft mailing list<br>
<a href="mailto:Snapcraft@lists.snapcraft.io">Snapcraft@lists.snapcraft.io</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/snapcraft" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/snapcraft</a><br>
<br></blockquote></div><br></div>