On Sat, Mar 14, 2015 at 7:18 PM, Alec Warner <[email protected]> wrote:
> On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz <[email protected]> > wrote: > >> Hi, >> >> 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 Portage >> Development Project to better secure the Portage distribution system. >> > > I'm not familiar with your work on APT, do you have a link? > There are LWN.net <http://lwn.net/Articles/327847/> and ;login: <https://www.usenix.org/legacy/publications/login/2009-02/openpdfs/samuel.pdf> articles, and an Ubuntu bug report <https://bugs.launchpad.net/ubuntu/+source/apt/+bug/247445>, that discuss some of the architectural and security improvements adopted (at the time) by APT and other package managers. The A Look In the Mirror: Attacks on Package Managers <https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf> paper <https://bugs.launchpad.net/ubuntu/+source/apt/+bug/247445>goes into more detail. > > >> TUF >> <https://github.com/theupdateframework/tuf#a-framework-for-securing-software-update-systems> >> (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 here >> <https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md#security> >> . >> >> Our website <http://theupdateframework.com/index.html> includes more >> information about TUF, including: papers >> <https://github.com/theupdateframework/tuf/tree/develop/docs/papers> and >> a specification >> <https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt>. >> If you want to see how an existing project integrates TUF, there is a >> standards track proposal >> <https://github.com/pypa/interoperability-peps/blob/master/pep-0458-tuf-online-keys.rst#abstract> >> 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 available >> <https://www.python.org/dev/peps/pep-0480/>. >> >> 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.). >> > >> Would a pull request be of interest? Is there anything you'd like us to >> say more about? >> > > 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. > How can we contact the infrastructure team? I searched the Gentoo mailing list page <https://www.gentoo.org/main/en/lists.xml> and found "gentoo-infrastructure", but it is a restricted list. > > >> Thanks, >> Vlad >> >> P.S. >> There are Informational <http://wiki.gentoo.org/wiki/GLEP:57> and Standards >> Track <http://wiki.gentoo.org/wiki/GLEP:58> GLEPs that reference our >> work and the security issues that our project addresses, but there hasn't >> been much recent activity on these proposals. >> > > 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 ([email protected]) > Thank you. We'll contact the GLEP author to discuss the standard. > > -A > > >> >> >> -- >> [email protected] >> PGP fingerprint = ACCF 9DCA 73B9 862F 93C5 6608 63F8 90AA 1D25 3935 >> -- >> > >
