| 1 |
On 03/10/15 17:15, Vladimir Diaz wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> I am a developer in the Secure Systems Lab at NYU. Our lab has |
| 5 |
> collaborated with popular software update systems in the open-source |
| 6 |
> community, including APT, yum, and YaST, to address security problems. |
| 7 |
> More recently, we have been working on a flexible security framework |
| 8 |
> co-developed with the Tor project that can be easily added to software |
| 9 |
> updaters to transparently solve many of the known security flaws we have |
| 10 |
> uncovered in software updaters. We would like to work with The Portage |
| 11 |
> Development Project to better secure the Portage distribution system. |
| 12 |
> |
| 13 |
> TUF |
| 14 |
> <https://github.com/theupdateframework/tuf#a-framework-for-securing-software-update-systems> |
| 15 |
> (The Update Framework) is a library that can be added to an existing |
| 16 |
> software update system and is designed to update files in a more secure |
| 17 |
> manner. Many software updaters verify software updates with cryptographic |
| 18 |
> signatures and hash functions, but they typically fail to protect against |
| 19 |
> malicious attacks that target the metadata and update files presented to |
| 20 |
> clients. A rollback attack is one such example, where an attacker tricks a |
| 21 |
> client into installing older files than those the client has already seen |
| 22 |
> (these older files may be vulnerable versions that have since been fixed). |
| 23 |
> A full list of attacks and weaknesses the framework is designed to address |
| 24 |
> is provided here |
| 25 |
> <https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md#security> |
| 26 |
> . |
| 27 |
> |
| 28 |
> Our website <http://theupdateframework.com/index.html> includes more |
| 29 |
> information about TUF, including: papers |
| 30 |
> <https://github.com/theupdateframework/tuf/tree/develop/docs/papers> and a |
| 31 |
> specification |
| 32 |
> <https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt>. |
| 33 |
> If you want to see how an existing project integrates TUF, there is a |
| 34 |
> standards track proposal |
| 35 |
> <https://github.com/pypa/interoperability-peps/blob/master/pep-0458-tuf-online-keys.rst#abstract> |
| 36 |
> to the Python community that you can review. A more rigorous proposal that |
| 37 |
> requires more administrative work on the repository, but provides more |
| 38 |
> security protections, is also available |
| 39 |
> <https://www.python.org/dev/peps/pep-0480/>. |
| 40 |
> |
| 41 |
> We were thinking of submitting a pull request that shows how such an |
| 42 |
> integration would work. So there hopefully won't be much leg work on your |
| 43 |
> end apart from deciding how the system should be configured (key storage, |
| 44 |
> roles, etc.). |
| 45 |
> |
| 46 |
> Would a pull request be of interest? Is there anything you'd like us to |
| 47 |
> say more about? |
| 48 |
|
| 49 |
I can't speak for the portage team, but I'm certainly interested to see |
| 50 |
what you have to show. Security should matter to everyone. |
| 51 |
|
| 52 |
-Zero. |
| 53 |
> |
| 54 |
> Thanks, |
| 55 |
> Vlad |
| 56 |
> |
| 57 |
> P.S. |
| 58 |
> There are Informational <http://wiki.gentoo.org/wiki/GLEP:57> and Standards |
| 59 |
> Track <http://wiki.gentoo.org/wiki/GLEP:58> GLEPs that reference our work |
| 60 |
> and the security issues that our project addresses, but there hasn't been |
| 61 |
> much recent activity on these proposals. |
| 62 |
> |
| 63 |
> |
| 64 |
> -- |
| 65 |
> vladimir.v.diaz@×××××.com |
| 66 |
> PGP fingerprint = ACCF 9DCA 73B9 862F 93C5 6608 63F8 90AA 1D25 3935 |
| 67 |
> -- |
| 68 |
> |
Archives