[gentoo-portage-dev] Portage and Update Security

[gentoo-portage-dev] Portage and Update Security

[Vladimir Diaz]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

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.

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?

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.


--
vladimir.v.diaz@gmail.com
PGP fingerprint = ACCF 9DCA 73B9 862F 93C5  6608 63F8 90AA 1D25 3935
--

[-- Attachment #2: Type: text/html, Size: 3665 bytes --]

Re: [gentoo-portage-dev] Portage and Update Security

[Rick "Zero_Chaos" Farina]

[-- Attachment #1: Type: text/plain, Size: 3212 bytes --]

On 03/10/15 17:15, Vladimir Diaz 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.
> 
> 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 can't speak for the portage team, but I'm certainly interested to see
what you have to show.  Security should matter to everyone.

-Zero.
> 
> 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.
> 
> 
> --
> vladimir.v.diaz@gmail.com
> PGP fingerprint = ACCF 9DCA 73B9 862F 93C5  6608 63F8 90AA 1D25 3935
> --
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-portage-dev] Portage and Update Security

[Zac Medico]

On 03/10/2015 02:15 PM, Vladimir Diaz wrote:
> Would a pull request be of interest?  Is there anything you'd like us to
> say more about?

Maybe so, but I need to familiarize myself more with your framework.
Thanks for bringing it to our attention!
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] Portage and Update Security

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3544 bytes --]

On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz <vladimir.v.diaz@gmail.com>
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?


> 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.


> 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 (robbat2@gentoo.org)

-A


>
>
> --
> vladimir.v.diaz@gmail.com
> PGP fingerprint = ACCF 9DCA 73B9 862F 93C5  6608 63F8 90AA 1D25 3935
> --
>

[-- Attachment #2: Type: text/html, Size: 5579 bytes --]

Re: [gentoo-portage-dev] Portage and Update Security

[Vladimir Diaz]

[-- Attachment #1: Type: text/plain, Size: 4562 bytes --]

On Sat, Mar 14, 2015 at 7:18 PM, Alec Warner <antarus@gentoo.org> wrote:

> On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz <vladimir.v.diaz@gmail.com>
> 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 (robbat2@gentoo.org)
>

Thank you.  We'll contact the GLEP author to discuss the standard.



>
> -A
>
>
>>
>>
>> --
>> vladimir.v.diaz@gmail.com
>> PGP fingerprint = ACCF 9DCA 73B9 862F 93C5  6608 63F8 90AA 1D25 3935
>> --
>>
>
>

[-- Attachment #2: Type: text/html, Size: 7585 bytes --]

Re: [gentoo-portage-dev] Portage and Update Security

[Brian Dolbec]

On Sun, 15 Mar 2015 18:27:06 -0400
Vladimir Diaz <vladimir.v.diaz@gmail.com> wrote:

> On Sat, Mar 14, 2015 at 7:18 PM, Alec Warner <antarus@gentoo.org>
> wrote:
> 
> > On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz
> > <vladimir.v.diaz@gmail.com> 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 (robbat2@gentoo.org)
> >
> 
> 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>

Re: [gentoo-portage-dev] Portage and Update Security

[Vladimir Diaz]

[-- Attachment #1: Type: text/plain, Size: 8032 bytes --]

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.

--
vladimir.v.diaz@gmail.com
PGP fingerprint = ACCF 9DCA 73B9 862F 93C5  6608 63F8 90AA 1D25 3935
--

On Sun, Mar 15, 2015 at 9:23 PM, Brian Dolbec <dolsen@gentoo.org> wrote:

> On Sun, 15 Mar 2015 18:27:06 -0400
> Vladimir Diaz <vladimir.v.diaz@gmail.com> wrote:
>
> > On Sat, Mar 14, 2015 at 7:18 PM, Alec Warner <antarus@gentoo.org>
> > wrote:
> >
> > > On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz
> > > <vladimir.v.diaz@gmail.com> 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 (robbat2@gentoo.org)
> > >
> >
> > 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>
>
>
>

[-- Attachment #2: Type: text/html, Size: 12589 bytes --]