<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 14, 2015 at 7:18 PM, Alec Warner <span dir="ltr"><<a href="mailto:antarus@gentoo.org" target="_blank">antarus@gentoo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz <span dir="ltr"><<a href="mailto:vladimir.v.diaz@gmail.com" target="_blank">vladimir.v.diaz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><br>I am a developer in the Secure Systems Lab at NYU. Our lab has collaborated with popular software update systems in the open-source community, including APT, yum, and YaST, to address security problems. More recently, we have been working on a flexible security framework co-developed with the Tor project that can be easily added to software updaters to transparently solve many of the known security flaws we have uncovered in software updaters. We would like to work with The <span>Portage</span> Development Project to better secure the <span>Portage</span> distribution system.<br></div></blockquote><div><br></div></span><div>I'm not familiar with your work on APT, do you have a link?</div></div></div></div></blockquote><div><br></div><div>There are <a href="http://lwn.net/Articles/327847/">LWN.net</a> and <a href="https://www.usenix.org/legacy/publications/login/2009-02/openpdfs/samuel.pdf">;login:</a> articles, and an <a href="https://bugs.launchpad.net/ubuntu/+source/apt/+bug/247445" target="_blank">Ubuntu bug report</a>, that discuss some of the architectural and security improvements adopted (at the time) by APT and other package managers. The <a href="https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf">A Look In the Mirror: Attacks on Package Managers</a> paper <a href="https://bugs.launchpad.net/ubuntu/+source/apt/+bug/247445" target="_blank"></a>goes into more detail.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><a href="https://github.com/theupdateframework/tuf#a-framework-for-securing-software-update-systems" target="_blank">TUF</a> (The Update Framework) is a library that can be added to an existing software update system and is designed to update files in a more secure manner. Many software updaters verify software updates with cryptographic signatures and hash functions, but they typically fail to protect against malicious attacks that target the metadata and update files presented to clients. A rollback attack is one such example, where an attacker tricks a client into installing older files than those the client has already seen (these older files may be vulnerable versions that have since been fixed). A full list of attacks and weaknesses the framework is designed to address is provided <a href="https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md#security" target="_blank">here</a>.<br><br>Our <a href="http://theupdateframework.com/index.html" target="_blank">website</a> includes more information about TUF, including: <a href="https://github.com/theupdateframework/tuf/tree/develop/docs/papers" target="_blank">papers</a> and a <a href="https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt" target="_blank">specification</a>. If you want to see how an existing project integrates TUF, there is a standards track <a href="https://github.com/pypa/interoperability-peps/blob/master/pep-0458-tuf-online-keys.rst#abstract" target="_blank">proposal</a> to the Python community that you can review. A more rigorous proposal that requires more administrative work on the repository, but provides more security protections, is also <a href="https://www.python.org/dev/peps/pep-0480/" target="_blank">available</a>.<br><br>We were thinking of submitting a pull request that shows how such an integration would work. So there hopefully won't be much leg work on your end apart from deciding how the system should be configured (key storage, roles, etc.).</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Would a pull request be of interest? Is there anything you'd like us to say more about?</div></div></blockquote><div><br></div></span><div>I guess I am less concerned with adding support to portage (which as you note, is likely fairly straightforward) vs actually generating, publishing, and signing the metadata; which you would have convince the infrastructure team to do.</div></div></div></div></blockquote><div><br></div><div>How can we contact the infrastructure team? I searched the <a href="https://www.gentoo.org/main/en/lists.xml">Gentoo mailing list page</a> and found "gentoo-infrastructure", but it is a restricted list.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>Thanks,<br>Vlad<br><br>P.S.<br>There are <a href="http://wiki.gentoo.org/wiki/GLEP:57" target="_blank">Informational</a> and <a href="http://wiki.gentoo.org/wiki/GLEP:58" target="_blank">Standards Track</a> GLEPs that reference our work and the security issues that our project addresses, but there hasn't been much recent activity on these proposals.<br></div></blockquote><div><br></div></span><div>FWIW, I would rather adopt the standard than continue with a gentoo specific thing; but I'm not the guy who is going to implement it. I would recommend talking to the GLEP author (<a href="mailto:robbat2@gentoo.org" target="_blank">robbat2@gentoo.org</a>)</div></div></div></div></blockquote><div><br></div><div>Thank you. We'll contact the GLEP author to discuss the standard.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><font color="#888888"><div><br></div><div>-A</div></font></span><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(102,102,102)">--<br><a href="mailto:vladimir.v.diaz@gmail.com" target="_blank">vladimir.v.diaz@gmail.com</a><br>PGP fingerprint = ACCF 9DCA 73B9 862F 93C5 6608 63F8 90AA 1D25 3935<br>--</span><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div> </div> </blockquote></span></div><br></div></div> </blockquote></div><br></div></div>