Hi Brian, FYI: The OCaml and Haskell folks are working on a proposal that might be of interest to the Portage team.
Thanks, Vlad P.S. Robin and I exchanged a few emails, but there doesn't seem to be much interest from his side. -- [email protected] PGP fingerprint = ACCF 9DCA 73B9 862F 93C5 6608 63F8 90AA 1D25 3935 -- On Sun, Mar 15, 2015 at 9:23 PM, Brian Dolbec <[email protected]> wrote: > On Sun, 15 Mar 2015 18:27:06 -0400 > Vladimir Diaz <[email protected]> wrote: > > > 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. > > > > > > > > robbat2 is the infra lead, so that is the correct person to contact. > > > > I've held off replying so far because I'm trying to get some time to > figure out your system. I'm not sure yet whether your system will fit > the plans and structure for our main tree. > > git now has signed commit support, which was a request gentoo had made > long ago in order for our migration to git from cvs. Until recent > versions it was not easy to re-verify a signed commit. We have have > signed Manifest support in the system for some time now, but have not > been enforcing it fully up till now. We have a new project called > gentoo-keys [1] which is a gpg key management app and libs to handle the > various gpg keys from devs, release media, and others. We are in the > process of getting our devs to create/update their gpg keys to meet the > new minimum spec (GLEP 63). I am just starting to integrate gkeys libs > use into portage to verify the package Manifests which is similar to > what you do. With the git migration, commits must be signed, but > will be using a "thin" manifest rather than the full one. Instead we > will be enforcing the --sign option for git push (recently added to > git). That will use gkeys to verify the pushed content via a hook and > replacement gpg command that uses gkeys. > > So the main git repo will be secured similar to what I've gleaned from > your code so far. The main syncing of the tree for users will be done > via rsync still, but for that the full Manifest files will be > (re)generated as needed and signed with an infra controlled key. > Normal users system will be able to verify those Manifests. There is > also optional versions of the tree which are signed in total > (emerge-webrsync) and verify-able. > > As has been pointed out the other thread [3] which was started just > before this one. We are in a different place than what the binary > distributions are in terms of repositories. Not all attack vectors > your code is meant to address applies to our situation. > > I do think your repository manifest was something that robbat2 had > talked about implementing for overlay maintainers as an option for > layman to be able to verify updates to the overlay repos. It would > likely have to be generated from a VCS hook which runs when commits are > made/pushed. > > > I'd love to hear how your code can fit in to the Gentoo system. > > links: > > [1] http://gitweb.gentoo.org/proj/gentoo-keys.git/ > > gkeys article in LWN: http://lwn.net/Articles/634777/ > > [3] > > http://archives.gentoo.org/gentoo-portage-dev/message/bda425ee6c676ec7a6b3c9500a9b00bf > -- > Brian Dolbec <dolsen> > > >
