> On Mon, 2 Jul 2018, Jason A Donenfeld wrote:
> Proposal:
> - Sign every file in the portage tree so that it has a corresponding
> .asc. Repoman will need support for this.
Not possible, because there are some directories in profiles that must
not contain any files other than those
Hello
On Tue, Jul 3, 2018 at 9:33 AM, Virgil Dupras wrote:
> Hi everyone,
>
> With the recent Github incident, users have (rightfully) voiced concerns
> about the security of their Gentoo ebuild tree. Luckily, thanks to recent
> efforts on the repository verification feature, we can answer
Hi everyone,
With the recent Github incident, users have (rightfully) voiced concerns about
the security of their Gentoo ebuild tree. Luckily, thanks to recent efforts on
the repository verification feature, we can answer "yes, it's possible to
update your ebuild tree in a convenient and
On 07/02/2018 10:16 PM, Michał Górny wrote:
> W dniu pon, 02.07.2018 o godzinie 17∶36 +0200, użytkownik Jason A.
> Donenfeld napisał:
>> Hey guys,
>>
>> While our infrastructure team has some nice technical competence, the
>> recent disaster and ongoing embarrassing aftermath has made ever more
>>
On 07/02/2018 07:47 PM, Hanno Böck wrote:
> I don't want to say this is unworkable. But these are challenges and
> imho fixing them all is really,
I'll say it, it is unworkable, you need a trusted party doing
verification of developers at point in time, then sign it with release
engineering keys
On 07/02/2018 08:08 PM, Jason A. Donenfeld wrote:
> On Mon, Jul 2, 2018 at 7:57 PM Rich Freeman wrote:
>> This only helps you if a dev you don't trust is compromised. If a dev
>> you trust is compromised, they can modify anything in the tree and
>> you're hosed.
> Yes indeed. This is more or
Il 02/07/2018 17:36, Jason A. Donenfeld ha scritto:
> Proposal:
> - Sign every file in the portage tree so that it has a corresponding
> .asc. Repoman will need support for this.
>
implementation detail:
Adding an .asc file for every file would bring the total files from 130k
to 260k.
Would be
On Sonntag, 3. Dezember 2017 23:04:54 CEST Michał Górny wrote:
> W dniu nie, 03.12.2017 o godzinie 20∶54 +, użytkownik James Le
> Cuirot napisał:
> > On Sun, 03 Dec 2017 20:41:56 +0100
> > Andreas Sturmlechner wrote:
> > > # Andreas Sturmlechner (03 Dec 2017)
> > > # Dead upstreams,
W dniu pon, 02.07.2018 o godzinie 17∶36 +0200, użytkownik Jason A.
Donenfeld napisał:
> Hey guys,
>
> While our infrastructure team has some nice technical competence, the
> recent disaster and ongoing embarrassing aftermath has made ever more
> urgent the need to have end-to-end signatures
W dniu pon, 02.07.2018 o godzinie 20∶01 +0200, użytkownik Jason A.
Donenfeld napisał:
> On Mon, Jul 2, 2018 at 7:21 PM Michał Górny wrote:
> >
> > W dniu pon, 02.07.2018 o godzinie 19∶01 +0200, użytkownik Jason A.
> > Donenfeld napisał:
> > > On Mon, Jul 2, 2018 at 6:58 PM Michał Górny wrote:
>
On Mon, Jul 2, 2018 at 11:47 AM, Jason A. Donenfeld wrote:
> On Mon, Jul 2, 2018 at 6:02 PM R0b0t1 wrote:
>> Signed hashes should be faster, no? Each directory with files could
>> have a manifest.
>
> Signatures work over hashes of data, anyway. I think what you're
> wondering, though, is the
On Mon, Jul 2, 2018 at 2:23 PM Alec Warner wrote:
>
> We might reduce the complexity here by saying things like:
>
> "We have N trust levels"
>
I snipped most of your text because I didn't really see a natural way
to include only some of it, though this really pertains to most of it,
and I
On Mon, Jul 2, 2018 at 1:50 PM, Jason A. Donenfeld wrote:
> On Mon, Jul 2, 2018 at 7:41 PM Rich Freeman wrote:
> > To be fair, this is relying quite a bit on the last dev doing a commit
> > to be checking his own tree, though that would certainly be helped if
> > repoman/portage/etc were
On Mon, Jul 2, 2018 at 7:57 PM Rich Freeman wrote:
> This only helps you if a dev you don't trust is compromised. If a dev
> you trust is compromised, they can modify anything in the tree and
> you're hosed.
Yes indeed. This is more or less what we're aiming for. Putting the
trust in
On Mon, Jul 2, 2018 at 7:21 PM Michał Górny wrote:
>
> W dniu pon, 02.07.2018 o godzinie 19∶01 +0200, użytkownik Jason A.
> Donenfeld napisał:
> > On Mon, Jul 2, 2018 at 6:58 PM Michał Górny wrote:
> > > - Have verification use a keyring of all Gentoo developers, with a
> > > > manual prompt to
On Mon, Jul 2, 2018 at 1:50 PM Jason A. Donenfeld wrote:
>
> On Mon, Jul 2, 2018 at 7:41 PM Rich Freeman wrote:
> > To be fair, this is relying quite a bit on the last dev doing a commit
> > to be checking his own tree, though that would certainly be helped if
> > repoman/portage/etc were
On Mon, Jul 2, 2018 at 7:48 PM Hanno Böck wrote:
> Hi,
Oh, thank you for arriving! I've been trying to ping you the last few
days hoping you'd pop in here. :)
> Something like this was I believe the original idea behind signed
> manifests. Not sure how long ago this was, but we used to sign
On Mon, Jul 2, 2018 at 7:41 PM Rich Freeman wrote:
> To be fair, this is relying quite a bit on the last dev doing a commit
> to be checking his own tree, though that would certainly be helped if
> repoman/portage/etc were checking git sigs so that the starting tree
> is more likely to be clean.
Hi,
Something like this was I believe the original idea behind signed
manifests. Not sure how long ago this was, but we used to sign Manifest
files at some point, though it never was part of any consistent concept
as far as I know, and they weren't checked regularly.
Anything like this comes
On Mon, Jul 2, 2018 at 7:44 PM Mariusz Ceier wrote:
> I wonder how would the local changes to ebuilds be handled ?
> Currently it's possible to change ebuild, do "ebuild package.ebuild
> manifest" and emerge package - will this still be supported ?
My proposal is to fit in at the layer of
On Mon, Jul 2, 2018 at 7:23 PM Matthias Maier wrote:
> stores tree snapshots (and not differences). So all you need is exactly
> one signed commit to verify that
>
> - this is the full repository tree the developer saw at the time of the
>commit
> - this is the full history the developer
Hi,
I wonder how would the local changes to ebuilds be handled ?
Currently it's possible to change ebuild, do "ebuild package.ebuild
manifest" and emerge package - will this still be supported ?
If not, would there be any plans for a tool for creating trusted local
overlays ?
This feature is
On Mon, Jul 2, 2018 at 1:23 PM Matthias Maier wrote:
>
>
> On Mon, Jul 2, 2018, at 12:01 CDT, "Jason A. Donenfeld"
> wrote:
>
> > Aren't git signatures done over the full commit objects? Meaning you'd
> > need the entire tree of metadata and thus all commits in order to
> > verify? Or do you
On Mon, Jul 2, 2018, at 12:01 CDT, "Jason A. Donenfeld"
wrote:
> Aren't git signatures done over the full commit objects? Meaning you'd
> need the entire tree of metadata and thus all commits in order to
> verify? Or do you see some clever opportunity for extracting just
> enough metadata
W dniu pon, 02.07.2018 o godzinie 19∶01 +0200, użytkownik Jason A.
Donenfeld napisał:
> On Mon, Jul 2, 2018 at 6:58 PM Michał Górny wrote:
> > - Have verification use a keyring of all Gentoo developers, with a
> > > manual prompt to add new Gentoo developers to it.
> >
> > How are you going to
On Mon, Jul 2, 2018 at 6:58 PM Michał Górny wrote:
> - Have verification use a keyring of all Gentoo developers, with a
> > manual prompt to add new Gentoo developers to it.
>
> How are you going to distribute this keyring, and how are you going to
> protect attacker from injecting malicious key
On Mon, Jul 2, 2018 at 6:55 PM Rich Freeman wrote:
> You might want to read what I wrote then, because I proposed options
> for using the git signatures over rsync, as well as for with git
> syncing
> having a tool that extracts the git
> signatures and stores the metadata in the repo (ideally
W dniu pon, 02.07.2018 o godzinie 17∶36 +0200, użytkownik Jason A.
Donenfeld napisał:
>
- Have verification use a keyring of all Gentoo developers, with a
> manual prompt to add new Gentoo developers to it.
How are you going to distribute this keyring, and how are you going to
protect attacker
On Mon, Jul 2, 2018 at 12:43 PM Jason A. Donenfeld wrote:
>
> There's a lot of text there, and rather than trying to parse all of
> that, I'll just reiterate a primary important design goal that might
> be overlooked:
>
> - End to end signatures from the developer to the user.
>
> This means that
On Mon, Jul 2, 2018 at 6:02 PM R0b0t1 wrote:
> Signed hashes should be faster, no? Each directory with files could
> have a manifest.
Signatures work over hashes of data, anyway. I think what you're
wondering, though, is the granularity of each signature? I'd recommend
this be done on the
Hello Rich,
There's a lot of text there, and rather than trying to parse all of
that, I'll just reiterate a primary important design goal that might
be overlooked:
- End to end signatures from the developer to the user.
This means that no matter the operation infra does before shipping it
out
On Mon, 2 Jul 2018 11:01:58 -0500
R0b0t1 wrote:
> On Mon, Jul 2, 2018 at 10:36 AM, Jason A. Donenfeld
> wrote:
> > Hey guys,
> >
> > While our infrastructure team has some nice technical competence,
> > the recent disaster and ongoing embarrassing aftermath has made
> > ever more urgent the
Overall I very much like the concept, but I might propose a few tweaks
(just quoting the stuff that might benefit from adjustment):
On Mon, Jul 2, 2018 at 11:36 AM Jason A. Donenfeld wrote:
>
> - Sign every file in the portage tree so that it has a corresponding
> .asc. Repoman will need support
On Mon, Jul 2, 2018 at 10:36 AM, Jason A. Donenfeld wrote:
> Hey guys,
>
> While our infrastructure team has some nice technical competence, the
> recent disaster and ongoing embarrassing aftermath has made ever more
> urgent the need to have end-to-end signatures between developers and
> users.
Hey guys,
While our infrastructure team has some nice technical competence, the
recent disaster and ongoing embarrassing aftermath has made ever more
urgent the need to have end-to-end signatures between developers and
users. While the infrastructure team seems fairly impressive at
deploying
35 matches
Mail list logo
