[gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Patrick Schleizer]

Hi,

I am currently working on a comparison of package managers in which
Portage is part of.

https://www.whonix.org/wiki/Comparison_Of_Package_Managers

Would you be interested to check if the current assessments are correct
and/or to fill the remaining gaps?

Where the comparison table is hosted or licensing (as long as it's Libre
Software) doesn't matter much to me. Edits can be made by both anonymous
and registered users. Those need to be verified by admins before they go
visible by default for everyone. If you like to have an account without
that limitation, that is also possible.

Cheers,
Patrick

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Rick "Zero_Chaos" Farina]

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

On 03/05/15 09:49, Patrick Schleizer wrote:
> Hi,
> 
> I am currently working on a comparison of package managers in which
> Portage is part of.
> 
> https://www.whonix.org/wiki/Comparison_Of_Package_Managers
> 
> Would you be interested to check if the current assessments are correct
> and/or to fill the remaining gaps?
> 
> Where the comparison table is hosted or licensing (as long as it's Libre
> Software) doesn't matter much to me. Edits can be made by both anonymous
> and registered users. Those need to be verified by admins before they go
> visible by default for everyone. If you like to have an account without
> that limitation, that is also possible.
> 
> Cheers,
> Patrick
> 
> 

Looking at the table, it appears to be unaware of using
FEATURES=webrsync-gpg instead of standard rsync.  We offer a full copy
of the repo which is compressed and gpg signed which would seem to
mitigate a lot of the attacks in your table.  Not that I nessesarily
agree that some of them even qualify as attacks, but webrsync-gpg would
appear to mitigate attacks 3, 11, and 12.

Attack 7 is possible, but the user would know since emerge tells you
every time it is run how long it has been since a successful update
based on a timestamp in the portage tree which for webrsync-gpg the
attacker cannot modify.

Attack 14 is not possible in gentoo as emerge will jump from mirror to
mirror until it successfully gets the desired file.  One would have to
own all the mirrors (or at least hijack dns) to stop the user from
getting a file, but at that point it's no longer a malicious mirror attack.

I used the footnote numbers to reference the attacks.

-Zero


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

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Patrick Schleizer]

> I used the footnote numbers to reference the attacks.

I am afraid, this might cause some confusion. The numbers you have used
won't stay stable. Those were autogenerated numbers of footnotes. As
footnotes change, these numbers change. To keep your post
understandable, I created a snapshot before modifying footnotes:
http://www.webcitation.org/6Wo9Cb2ox

However, numbers (1), (2), (3), etc. that won't be automatically
changed, have just been added now.

Rick "Zero_Chaos" Farina:
> webrsync-gpg would
> appear to mitigate

Actually, I was aware of it. The issue is, signing is not everything.
Signatures need a validity range. Otherwise mirrors can also show half a
year etc. old signatures that are valid. See also:
http://blog.ganneff.de/blog/2008/09/23/valid-until-field-in-release-f.html

> attacks 3, 11, and 12.

There was no attack 3. Now, before we talk past each other, would you
mind to repost by referencing attack by name or by their new, "real"
numbers?

Cheers,
Patrick

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Rick "Zero_Chaos" Farina]

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

On 03/05/15 14:14, Patrick Schleizer wrote:
>> I used the footnote numbers to reference the attacks.
> 
> I am afraid, this might cause some confusion. The numbers you have used
> won't stay stable. Those were autogenerated numbers of footnotes. As
> footnotes change, these numbers change. To keep your post
> understandable, I created a snapshot before modifying footnotes:
> http://www.webcitation.org/6Wo9Cb2ox
> 
> However, numbers (1), (2), (3), etc. that won't be automatically
> changed, have just been added now.

HA, my fault, sorry about that.
> 
> Actually, I was aware of it. The issue is, signing is not everything.
> Signatures need a validity range. Otherwise mirrors can also show half a
> year etc. old signatures that are valid. See also:
> http://blog.ganneff.de/blog/2008/09/23/valid-until-field-in-release-f.html
> 
>> attacks 3, 11, and 12.
> 
> There was no attack 3. Now, before we talk past each other, would you
> mind to repost by referencing attack by name or by their new, "real"
> numbers?

Well now there is an attack 3 :-)

webrsync-gpg would ALERT the user in the case of attack 3.  Portage
checks the timestamp file from inside the gpg signed snapshot and alerts
the user if the last sync was too long ago.  In the case of a freeze
attack, it should alert the user that the sync is old.  Not that it
fixes the attack, but it won't go unnoticed for long.

Likewise, webrsync-gpg would also completely prevent 7 and 8.  The
snapshot is the entire tree, so it is not possible to "mix and match"
without modifying the signed tarball.  Nor would it be possible to
provide the user with the wrong package since the checksums from inside
the signed portage tarball wouldn't match if the source package was
traded for a different one.

Attack 8 shouldn't work either, as the checksums for everything are
protected in the gpg signed portage tarball it should not be possible to
trade out a source tarball for a different one.  While gentoo doesn't
typically use binary packages, it does have the support for it.  Nothing
in the binary package installation is protected by signatures, so I
would expect this kind of attack to be possible when installing a binary
package.  Might be non-trivial to do, but certainly possible.

Attack 9 won't work either, assuming the user can avoid the freeze
attack (3) the user will have an up to date knowledge of what it expects
on the mirrors and will simply ask other mirrors for the right file in
case of 404 or bad checksum.

tl;dr webrsync-gpg is a built in feature of the package manager which
OPTIONALLY adds a significant amount of security against the attacks
described on your website.  This is not currently the default setting,
however, it is described in many hardening guides for gentoo and widely
used among the security conscious.

-Zero_Chaos


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

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Mark Kubacki]

2015-03-06 1:56 GMT+01:00 Rick "Zero_Chaos" Farina <zerochaos@gentoo.org>:
>
> tl;dr webrsync-gpg is a built in feature of the package manager which
> OPTIONALLY adds a significant amount of security against the attacks
> described on your website.  This is not currently the default setting,
> however, it is described in many hardening guides for gentoo and widely
> used among the security conscious.

Without numbers backing that up this is speculation.

Given the default settings (without webrsync-gpg)…:

> (8) Wrong software installation.

Observe the DNS requests for the rsync- or webrsync mirror. They're
not encrypted and give you a nice heads-up.

A. (data in transit) It's almost never HTTPS and/or without
authentication, so you can easily proceed to hijacking the connection.
- Primed that way (DNS) insert a new rule into a router (or
nameserver) along the path or within the DC to redirect the
transaction. (See "quantum insert".)

B. (data at rest) Bribe or coerce the owner of the (portage tree)
mirror. Manifests and ebuilds are not centrally signed and there is no
authoritative "signing transparency"/record (see "certificate
transparency").

-- 
Mark

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Rick "Zero_Chaos" Farina]

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

On 03/06/15 08:53, Mark Kubacki wrote:
> 2015-03-06 1:56 GMT+01:00 Rick "Zero_Chaos" Farina <zerochaos@gentoo.org>:
>>
>> tl;dr webrsync-gpg is a built in feature of the package manager which
>> OPTIONALLY adds a significant amount of security against the attacks
>> described on your website.  This is not currently the default setting,
>> however, it is described in many hardening guides for gentoo and widely
>> used among the security conscious.
> 
> Without numbers backing that up this is speculation.

5,7,16,38,42.  There are some numbers to back up what I'm saying.  I
have been doing security work for over 15 years and I'm a professional
pen-tester.  If you want to read the portage code to verify what I said
that's fine, but I'm reasonably confident I distilled what portage does
into english.
> 
> Given the default settings (without webrsync-gpg)…:
> 
>> (8) Wrong software installation.
> 
> Observe the DNS requests for the rsync- or webrsync mirror. They're
> not encrypted and give you a nice heads-up.

Yup, dns is basically never encrypted, this is not new information or a
new attack.
> 
> A. (data in transit) It's almost never HTTPS and/or without
> authentication, so you can easily proceed to hijacking the connection.
> - Primed that way (DNS) insert a new rule into a router (or
> nameserver) along the path or within the DC to redirect the
> transaction. (See "quantum insert".)

Yup, this was discussed, however, it doesn't matter, and I'll explain
why.  The portage tree itself is a tarball with a signature attached,
that means that short of coercion, the information in the portage tree
should be correct (in the case of webrsync-gpg).  The Manifest file for
each package contains a sha256, sha512, and whirlpool hash for each file
(including the source tarballs which would be downloaded to install) and
ALL of them must match.  Good luck modifying the file and getting all
three hashs to match, I would suggest that is statistically impossible.
  Yes, an attacker could easily pass any file they like, but portage
would fail to validate it and refuse to continue.
> 
> B. (data at rest) Bribe or coerce the owner of the (portage tree)
> mirror. Manifests and ebuilds are not centrally signed and there is no
> authoritative "signing transparency"/record (see "certificate
> transparency").
> 
Only the portage tree is centrally signed, and currently the manifest
signatures aren't even verified automatically at this point.  Yes, I
completely agree that a gentoo dev could be coerced or bribed to add
malicious code to the repository which would then get signed and shipped
with the secure tarball.  This avenue of attack is very difficult to
stop.  If would be cool to have some kind of automated check for
malicious codes, however, I doubt it would be all that effective.

-Zero


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

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Patrick Schleizer]

Hi,

it was naive of me to attempt to create such a comparison table. Takes
much more time than I have available for this.

It was to be expected that there are disagreements and I cannot resolve
them without checking the code myself and perhaps without coming up with
proof of concept exploitation code to settle it.

To prevent spreading false information, I took that wiki page offline.

If someone else wants to maintain such a wiki comparison page, I could
still help with hosting, mediawiki markup and such stuff.

Sorry for the noise!

Your answered were appreciated and helpful!

We had somewhat a bad timing. I am sure Vlad in the "Portage and Updater
Security" thread is much more knowledgeable, realistic and dedicated. (I
am not part of the TUF team, just interested in their work.)

Cheers,
Patrick

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Brian Dolbec]

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

On Fri, 06 Mar 2015 10:20:27 -0500
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> On 03/06/15 08:53, Mark Kubacki wrote:
> > 2015-03-06 1:56 GMT+01:00 Rick "Zero_Chaos" Farina
> > <zerochaos@gentoo.org>:
> >>
> >> tl;dr webrsync-gpg is a built in feature of the package manager
> >> which OPTIONALLY adds a significant amount of security against the
> >> attacks described on your website.  This is not currently the
> >> default setting, however, it is described in many hardening guides
> >> for gentoo and widely used among the security conscious.
> > 
> > Without numbers backing that up this is speculation.
> 
> 5,7,16,38,42.  There are some numbers to back up what I'm saying.  I
> have been doing security work for over 15 years and I'm a professional
> pen-tester.  If you want to read the portage code to verify what I
> said that's fine, but I'm reasonably confident I distilled what
> portage does into english.
> > 
> > Given the default settings (without webrsync-gpg)…:
> > 
> >> (8) Wrong software installation.
> > 
> > Observe the DNS requests for the rsync- or webrsync mirror. They're
> > not encrypted and give you a nice heads-up.
> 
> Yup, dns is basically never encrypted, this is not new information or
> a new attack.
> > 
> > A. (data in transit) It's almost never HTTPS and/or without
> > authentication, so you can easily proceed to hijacking the
> > connection.
> > - Primed that way (DNS) insert a new rule into a router (or
> > nameserver) along the path or within the DC to redirect the
> > transaction. (See "quantum insert".)
> 
> Yup, this was discussed, however, it doesn't matter, and I'll explain
> why.  The portage tree itself is a tarball with a signature attached,
> that means that short of coercion, the information in the portage tree
> should be correct (in the case of webrsync-gpg).  The Manifest file
> for each package contains a sha256, sha512, and whirlpool hash for
> each file (including the source tarballs which would be downloaded to
> install) and ALL of them must match.  Good luck modifying the file
> and getting all three hashs to match, I would suggest that is
> statistically impossible. Yes, an attacker could easily pass any file
> they like, but portage would fail to validate it and refuse to
> continue.
> > 
> > B. (data at rest) Bribe or coerce the owner of the (portage tree)
> > mirror. Manifests and ebuilds are not centrally signed and there is
> > no authoritative "signing transparency"/record (see "certificate
> > transparency").
> > 
> Only the portage tree is centrally signed, and currently the manifest
> signatures aren't even verified automatically at this point.  Yes, I
> completely agree that a gentoo dev could be coerced or bribed to add
> malicious code to the repository which would then get signed and
> shipped with the secure tarball.  This avenue of attack is very
> difficult to stop.  If would be cool to have some kind of automated
> check for malicious codes, however, I doubt it would be all that
> effective.
> 
> -Zero
> 

I have refrained from replying till now because I don't consider myself
qualified to answer security issues like these.

But, for the few holes there are currently in portage's security
methods, there are already efforts underway to plug them.  Using a new
project called gentoo-keys (a gpg-key management app) portage will be
able to independently able to verify the gpg signed Manifest
files provided with each package.  So, even if the user does not use
the gpg signed emerge-webrsync method.  There will still be an
alternate authentication method on the package level.  There are other
steps being taken as well in other areas of the tree handling and
building as well, but portage verifying the Manifest file is the next
step being taken with gentoo-keys.  

What Zero did not mention was that a user can independently verify the
gpg signature of each Manifest file now.  The developer gpg keys are
listed and available.  The gentoo-keys project is just automating the
whole process.

-- 
Brian Dolbec <dolsen>


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

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Mark Kubacki]

2015-03-06 1:56 GMT+01:00 Rick "Zero_Chaos" Farina <zerochaos@gentoo.org>:
>
> tl;dr webrsync-gpg is a built in feature of the package manager which
> OPTIONALLY adds a significant amount of security against the attacks
> described on your website.  This is not currently the default setting,
> however, it is described in many hardening guides for gentoo and widely
> used among the security conscious.

On 03/06/15 08:53, Mark Kubacki wrote:
>
> Without numbers backing that up this is speculation.

2015-03-06 16:20 GMT+01:00 Rick "Zero_Chaos" Farina <zerochaos@gentoo.org>:
>
> 5,7,16,38,42.  There are some numbers to back up what I'm saying.  I
> have been doing security work for over 15 years and I'm a professional
> pen-tester.  If you want to read the portage code to verify what I said
> that's fine, but I'm reasonably confident I distilled what portage does
> into english.

We're on the same side here.

Do we have numbers showing the ratio "portage used with defaults" vs.
where "[webrsync-gpg] is described in many hardening guides for gentoo
and widely used among the security conscious" applies?

DNS not being encrypted is just painting the whole picture. Point is,
the default is that "emerge --sync" results in a transfer using RSYNC
(or http).

And by default you cannot compare the result with any authoritative source.

-- 
Mark

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Zac Medico]

On 03/06/2015 09:50 AM, Mark Kubacki wrote:
> We're on the same side here.
> 
> Do we have numbers showing the ratio "portage used with defaults" vs.
> where "[webrsync-gpg] is described in many hardening guides for gentoo
> and widely used among the security conscious" applies?
> 
> DNS not being encrypted is just painting the whole picture. Point is,
> the default is that "emerge --sync" results in a transfer using RSYNC
> (or http).
> 
> And by default you cannot compare the result with any authoritative source.
> 

Ideally, we can rely on security mechanisms built into git [1], possibly
involving signed commits.

[1] https://github.com/gentoo/gentoo-portage-rsync-mirror
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Brian Dolbec]

On Sat, 07 Mar 2015 15:26:26 -0800
Zac Medico <zmedico@gentoo.org> wrote:

> On 03/06/2015 09:50 AM, Mark Kubacki wrote:
> > We're on the same side here.
> > 
> > Do we have numbers showing the ratio "portage used with defaults"
> > vs. where "[webrsync-gpg] is described in many hardening guides for
> > gentoo and widely used among the security conscious" applies?
> > 
> > DNS not being encrypted is just painting the whole picture. Point
> > is, the default is that "emerge --sync" results in a transfer using
> > RSYNC (or http).
> > 
> > And by default you cannot compare the result with any authoritative
> > source.
> > 
> 
> Ideally, we can rely on security mechanisms built into git [1],
> possibly involving signed commits.
> 
> [1] https://github.com/gentoo/gentoo-portage-rsync-mirror


Actually, git makes it nearly impossible to get the correct info
required to re-process the git commit signature.  It is all embedded
into the commit itself, but not in a way for gpg to be able to
re-verify it.  Git relies on the issuer's gpg verification status which
it records in it's data before the push.  So, without some major
hacking on git data, it is not viable for routine verification purposes.

When we move from cvs to git, newer git makes it possible to git push
--sign.  That info is available on the recieving server and the
receiving server also runs gpg to verifiy the incoming data.

Only problem there is git does not store that data.  There is however a
hook that gathers the info and saves it in git's metadata for that
repo.  That makes it possible to run a verification on the repo at any
other time.  Not just during the recieve operation.

When we do move to a git tree.  My information is that pushes will not
contain a signed manifest like they are now for cvs.  Instead the
Manifest files will be generated for the rsync distribution tree and
signed with gentoo gpg key.  Replicating the existing tree structure.

I will likely have a patch for portage very soon which uses gkeys libs
to verify the Manifests.  gkeys-9999 is able to verify the Manifest
files now if the gentoo-devs keys are installed.

Main questions for now is.  Do we want to have a post sync hook that
checks the tree for invalid Manifest sigs?  Or do we just have it
verify the manifest for the pkg at build/merge time?  Or both?

-- 
Brian Dolbec <dolsen>

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Zac Medico]

On 03/07/2015 05:24 PM, Brian Dolbec wrote:
> On Sat, 07 Mar 2015 15:26:26 -0800
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> On 03/06/2015 09:50 AM, Mark Kubacki wrote:
>>> We're on the same side here.
>>>
>>> Do we have numbers showing the ratio "portage used with defaults"
>>> vs. where "[webrsync-gpg] is described in many hardening guides for
>>> gentoo and widely used among the security conscious" applies?
>>>
>>> DNS not being encrypted is just painting the whole picture. Point
>>> is, the default is that "emerge --sync" results in a transfer using
>>> RSYNC (or http).
>>>
>>> And by default you cannot compare the result with any authoritative
>>> source.
>>>
>>
>> Ideally, we can rely on security mechanisms built into git [1],
>> possibly involving signed commits.
>>
>> [1] https://github.com/gentoo/gentoo-portage-rsync-mirror
> 
> 
> Actually, git makes it nearly impossible to get the correct info
> required to re-process the git commit signature.  It is all embedded
> into the commit itself, but not in a way for gpg to be able to
> re-verify it.  Git relies on the issuer's gpg verification status which
> it records in it's data before the push.  So, without some major
> hacking on git data, it is not viable for routine verification purposes.

Maybe we can use the relatively recently added git verify-commit command
[1]. If we run that command with --verbose, then we can use that to
verify that that a commit was signed with a trusted key. Shouldn't
verification of the HEAD commit be enough to vouch for the integrity of
the entire tree?

[1]
https://github.com/git/git/commit/d07b00b7f31d0cb6675b4bdba269ce7f087ddd24
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Brian Dolbec]

On Sat, 07 Mar 2015 18:31:44 -0800
Zac Medico <zmedico@gentoo.org> wrote:

> On 03/07/2015 05:24 PM, Brian Dolbec wrote:
> > On Sat, 07 Mar 2015 15:26:26 -0800
> > Zac Medico <zmedico@gentoo.org> wrote:
> > 
> >> On 03/06/2015 09:50 AM, Mark Kubacki wrote:
> >>> We're on the same side here.
> >>>
> >>> Do we have numbers showing the ratio "portage used with defaults"
> >>> vs. where "[webrsync-gpg] is described in many hardening guides
> >>> for gentoo and widely used among the security conscious" applies?
> >>>
> >>> DNS not being encrypted is just painting the whole picture. Point
> >>> is, the default is that "emerge --sync" results in a transfer
> >>> using RSYNC (or http).
> >>>
> >>> And by default you cannot compare the result with any
> >>> authoritative source.
> >>>
> >>
> >> Ideally, we can rely on security mechanisms built into git [1],
> >> possibly involving signed commits.
> >>
> >> [1] https://github.com/gentoo/gentoo-portage-rsync-mirror
> > 
> > 
> > Actually, git makes it nearly impossible to get the correct info
> > required to re-process the git commit signature.  It is all embedded
> > into the commit itself, but not in a way for gpg to be able to
> > re-verify it.  Git relies on the issuer's gpg verification status
> > which it records in it's data before the push.  So, without some
> > major hacking on git data, it is not viable for routine
> > verification purposes.
> 
> Maybe we can use the relatively recently added git verify-commit
> command [1]. If we run that command with --verbose, then we can use
> that to verify that that a commit was signed with a trusted key.
> Shouldn't verification of the HEAD commit be enough to vouch for the
> integrity of the entire tree?
> 
> [1]
> https://github.com/git/git/commit/d07b00b7f31d0cb6675b4bdba269ce7f087ddd24

GREAT!  So, same as for push --sign, we just need to configure a
replacement gpg command for git that uses gkeys instead of gpg
directly.  

That will simplify things over the previous.

A replacement gpg command is needed because of the way gkeys stores the
developer keys in separate keyrings.  gkeys determines which keyring to
use and runs gpg with the correct settings.  It is also capable of
searching is db for the correct keyring to verify against as well.

-- 
Brian Dolbec <dolsen>

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Patrick Schleizer]

Zac Medico:
> On 03/06/2015 09:50 AM, Mark Kubacki wrote:
>> We're on the same side here.
>>
>> Do we have numbers showing the ratio "portage used with defaults" vs.
>> where "[webrsync-gpg] is described in many hardening guides for gentoo
>> and widely used among the security conscious" applies?
>>
>> DNS not being encrypted is just painting the whole picture. Point is,
>> the default is that "emerge --sync" results in a transfer using RSYNC
>> (or http).
>>
>> And by default you cannot compare the result with any authoritative source.
>>
> 
> Ideally, we can rely on security mechanisms built into git [1], possibly
> involving signed commits.
> 
> [1] https://github.com/gentoo/gentoo-portage-rsync-mirror

Then the question is, how secure are signatures when used wit hgit?

A while ago I wrote a blog post asking that question, referencing a lot
related information, started a discussion and also posted this on the
git mailing list.

"How safe are signed git tags? Only as safe as SHA-1 or somehow safer?"
[1] [2]

Cheers,
Patrick

[1]
https://www.whonix.org/blog/how-safe-are-signed-git-tags-only-as-safe-as-sha-1-or-somehow-safer
[2] http://www.mail-archive.com/git@vger.kernel.org/msg61087.html

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Mark Kubacki]

On 03/06/2015 09:50 AM, Mark Kubacki wrote:
>
> And by default you cannot compare the result with any authoritative source.

2015-03-08 0:26 GMT+01:00 Zac Medico <zmedico@gentoo.org>:
>
> Ideally, we can rely on security mechanisms built into git [1], possibly
> involving signed commits.

Some brownfield thinking here, without GIT and not replacing GIT:

1. Find and compile all directories two levels deep in a file
"category.idx" and sign it.
2. Sign every Manifest.
3. Distribute that as usual.

Will need N+1 checks (N × Manifest + 1 × category present/missing) and
doesn't break anything already deployed.

Contributors (individuals, teams) need to provide a public key before
submitting, and the "mirror source" (authority) just checks against
the author's signature and signs (1) and (2) with its own key
("official portage tree root key X"). That way, in the end, it's
enough to announce only one signing key for every tree.

(It's easier with binhosts, because all you need to sign is "Packages{,gz}".)

There are many interoperable implementations of OpenBSD's "signify"
[2] (sha256 + ed25519). Implementations are simple and small enough
[3] to be included into Portage to not require GPG.

-- 
Mark

[2] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/signify.1?query=signify&arch=i386
[3] http://ed25519.cr.yp.to/python/ed25519.py — needs reading the key
and hashing the file to be checked

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Zac Medico]

On 03/08/2015 07:59 AM, Patrick Schleizer wrote:
> Zac Medico:
>> On 03/06/2015 09:50 AM, Mark Kubacki wrote:
>>> We're on the same side here.
>>>
>>> Do we have numbers showing the ratio "portage used with defaults" vs.
>>> where "[webrsync-gpg] is described in many hardening guides for gentoo
>>> and widely used among the security conscious" applies?
>>>
>>> DNS not being encrypted is just painting the whole picture. Point is,
>>> the default is that "emerge --sync" results in a transfer using RSYNC
>>> (or http).
>>>
>>> And by default you cannot compare the result with any authoritative source.
>>>
>>
>> Ideally, we can rely on security mechanisms built into git [1], possibly
>> involving signed commits.
>>
>> [1] https://github.com/gentoo/gentoo-portage-rsync-mirror
> 
> Then the question is, how secure are signatures when used wit hgit?

And once we answer that question, the question is, is git secure enough
for our needs?

> A while ago I wrote a blog post asking that question, referencing a lot
> related information, started a discussion and also posted this on the
> git mailing list.
> 
> "How safe are signed git tags? Only as safe as SHA-1 or somehow safer?"
> [1] [2]
> 
> Cheers,
> Patrick
> 
> [1]
> https://www.whonix.org/blog/how-safe-are-signed-git-tags-only-as-safe-as-sha-1-or-somehow-safer
> [2] http://www.mail-archive.com/git@vger.kernel.org/msg61087.html

For the time being, I think that git is secure enough for our needs, and
I trust that git will implement stronger security soon enough.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Zac Medico]

On 03/08/2015 08:02 AM, Mark Kubacki wrote:
> On 03/06/2015 09:50 AM, Mark Kubacki wrote:
>>
>> And by default you cannot compare the result with any authoritative source.
> 
> 2015-03-08 0:26 GMT+01:00 Zac Medico <zmedico@gentoo.org>:
>>
>> Ideally, we can rely on security mechanisms built into git [1], possibly
>> involving signed commits.
> 
> Some brownfield thinking here, without GIT and not replacing GIT:
> 
> 1. Find and compile all directories two levels deep in a file
> "category.idx" and sign it.
> 2. Sign every Manifest.
> 3. Distribute that as usual.
> 
> Will need N+1 checks (N × Manifest + 1 × category present/missing) and
> doesn't break anything already deployed.

I think it's an unnecessary expenditure of effort to implement our own
Merkle tree, considering that git's Merkle tree is good enough for the
time being, and will likely implement stronger security soon enough.

> Contributors (individuals, teams) need to provide a public key before
> submitting, and the "mirror source" (authority) just checks against
> the author's signature 

Ideally, this signature check would be implemented as a server-side git
hook, so that a push would be automatically rejected if any of the
pushed commits lacked a good signature.

> and signs (1) and (2) with its own key
> ("official portage tree root key X"). That way, in the end, it's
> enough to announce only one signing key for every tree.

Or just rely on signed commits in git. We can automatically generate an
empty signed commit with the root key every 30 minutes or something like
that.

> (It's easier with binhosts, because all you need to sign is "Packages{,gz}".)

Yes, much easier. We might also want to embed signatures directly in
each binary package, so that they can be independently verified without
needing a copy of the original Packages file.
-- 
Thanks,
Zac