On Fri, Jun 08, 2012 at 03:40:57PM +0200, Michael Weber wrote:
> I'd suggest to generate an tarball (containing an keyring) to sign by
> an master key (member of trustee/council/..) to be deployed on all
> systems (like it's done on archlinux and debian).
>
> But the current vulnerability is expor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/08/2012 01:36 PM, Rich Freeman wrote:
> I doubt any dev checks the signatures on manifest files before
> they overwrite them with a new signature. If they did it wouldn't
> matter since those signatures aren't even mandatory anyway.
> Certain
On Fri, Jun 8, 2012 at 7:01 AM, W. Trevor King wrote:
> When the breach is discovered, you can then isolate the dev (or devs)
> who implicitly signed the hack (2) by pulling the ToT without checking
> for a valid signature (3). Then you yell at them for sloppy security,
> and tell them to install
On Mon, Jun 04, 2012 at 04:57:42PM -0400, Rich Freeman wrote:
> 2. Hacker commits something to the tree. Top of tree is not signed.
> No need for preimage attacks or whatever on sha1 - they just log into
> the server and do a git commit or whatever right into the tree.
> 3. Gentoo dev commits a
On Tue, Jun 5, 2012 at 2:50 AM, Michał Górny wrote:
> On Mon, 4 Jun 2012 16:57:42 -0400
> Rich Freeman wrote:
>
>> If you go back and look at the tree you see a bunch of signed and
>> unsigned commits. How do you easily detect how the unsigned ones got
>> there (via a dev with a merge commit, or
On Mon, 4 Jun 2012 16:57:42 -0400
Rich Freeman wrote:
> If you go back and look at the tree you see a bunch of signed and
> unsigned commits. How do you easily detect how the unsigned ones got
> there (via a dev with a merge commit, or via other means)?
Well, that's not a very good solution but
On Mon, Jun 4, 2012 at 10:41 PM, Brian Harring wrote:
> The dev, prior to signing that, should be verifying what they're
> adding (moreso, what exists between last signed rev and theirs), they
> agree to and know of. Specifically, they're asserting their addition.
What Rich is arguing (and which
On Mon, 04 Jun 2012 22:52:25 +0200
"Andreas K. Huettel" wrote:
> No. What is signed is the "new data" plus the parent hash(es).
>
> No such thing as a "tree hash".
http://eagain.net/articles/git-for-computer-scientists/
Might clear things up a bit.
--
Ciaran McCreesh
signature.asc
Descripti
On Mon, Jun 4, 2012 at 4:41 PM, Brian Harring wrote:
>
> If that doesn't answer your question/concerns, be more explicit
> please.
How about a scenario:
1. Gentoo dev commits a bunch of stuff to the tree. Top of tree is signed.
2. Hacker commits something to the tree. Top of tree is not sign
> A signed commit is a signing of the git metadata; tree hash
> (literally, the state of the tree), committer, author, message, and
> parent sha1. Each git commit includes it's parent sha1 in it; this
> gives a locked history for a given commit sha1 (unless someone
> preimages sha1). What matters
On Mon, Jun 04, 2012 at 03:27:03PM -0400, Rich Freeman wrote:
> On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring wrote:
> > One thing people need to keep in mind here is that when you sign the
> > commit, you're signing off on the history implicitly. ?Directly
> > addressing freeman's comment about "
On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring wrote:
> One thing people need to keep in mind here is that when you sign the
> commit, you're signing off on the history implicitly. Directly
> addressing freeman's comment about "people sign the manifest but don't
> look at what they're signing", wh
On Mon, Jun 04, 2012 at 08:45:42PM +0200, Dirkjan Ochtman wrote:
> On Mon, Jun 4, 2012 at 7:25 PM, Rich Freeman wrote:
> > Anything we do has to be automated to be of any real value. ??Ideally
> > if something goes wrong it should be as detectable as possible.
>
> Yeah, but you'd have to part of
On Mon, Jun 4, 2012 at 7:25 PM, Rich Freeman wrote:
> Anything we do has to be automated to be of any real value. Ideally
> if something goes wrong it should be as detectable as possible.
Yeah, but you'd have to part of that at every developer's box.
Can we just agree that having the tip of the
On Mon, Jun 4, 2012 at 12:19 PM, Dirkjan Ochtman wrote:
> So to prevent your scenario, we'd
> have to get everyone to check the signature of the tip of tree they
> pulled before committing/merging.
How can we be sure this has happened?
This is the problem with signed manifests today. I can sign
On Mon, Jun 4, 2012 at 6:06 PM, Rich Freeman wrote:
> Again, we don't need to be there 100% to go live. However, I think
> that was the whole point of signing commits. If we aren't going to
> add any assurance at all with our signing practices, then there isn't
> much point in having them.
True
On Mon, Jun 4, 2012 at 11:02 AM, Dirkjan Ochtman wrote:
> If the tree was bad before you pushed, then it's not your fault the
> tree is bad. You're only responsible for the commits you bring into
> the tree, so if you're merging contributor's unsigned changesets, you
> merge them with a signature
On Mon, Jun 4, 2012 at 4:48 PM, Rich Freeman wrote:
> When I do a cvs commit, I don't check the logs to make sure the last
> 25 commits all look valid. So, why would I expect others to do any
> differently in git. I make my changes, I run a git pull (bringing in
> the hacked commit on gentoo-x86
On Mon, Jun 4, 2012 at 10:26 AM, Dirkjan Ochtman wrote:
> On Mon, Jun 4, 2012 at 4:18 PM, Rich Freeman wrote:
>> How do you KNOW that the nearest signed descendant actually merged it?
>>
>> How do you know it wasn't added by a hacker?
>
> Because then the signature for the nearest signed descenda
On Mon, Jun 4, 2012 at 4:18 PM, Rich Freeman wrote:
> How do you KNOW that the nearest signed descendant actually merged it?
>
> How do you know it wasn't added by a hacker?
Because then the signature for the nearest signed descendant wouldn't
check out (unless it got hacked before he signed it,
On Mon, Jun 4, 2012 at 9:48 AM, Dirkjan Ochtman wrote:
>
> You simply walk the tree from root to tip. When you encounter an
> unsigned changeset, the nearest signed descendant is responsible for
> merging that changeset.
>
How do you KNOW that the nearest signed descendant actually merged it?
Ho
On 06/04/2012 07:34 AM, Rich Freeman wrote:
> On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman wrote:
>> On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel
>> wrote:
>>> However, then the "committer" of the contributed commits before the merge is
>>> then the user, I guess?
>>>
>>> (The rule mean
On Mon, Jun 4, 2012 at 3:40 PM, Rich Freeman wrote:
> The only thing the merge commit contains is a list of two parents, and
> a tree. It doesn't say which one is which, unless we can rely on
> their order.
You simply walk the tree from root to tip. When you encounter an
unsigned changeset, the
On Mon, Jun 4, 2012 at 8:45 AM, Dirkjan Ochtman wrote:
>
> Well, it doesn't seem like a big deal IF there's an explicit merge
> commit that's signed by a dev.
I'm not sure about that. If you were verifying a tree, how would you
identify which commits were merged in by what dev, using an automate
On Mon, Jun 4, 2012 at 2:34 PM, Rich Freeman wrote:
> Well, only Robin can explain exactly what he meant, but it sounds like
> we don't want the committer field to ever have a non-gentoo email in
> it, and signatures should be gentoo as well. So, if a dev just
> applies a patch to their tree/etc
On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman wrote:
> On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel
> wrote:
>> However, then the "committer" of the contributed commits before the merge is
>> then the user, I guess?
>>
>> (The rule meaning as suggested by Robin
>>> - if you include a com
On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel wrote:
> However, then the "committer" of the contributed commits before the merge is
> then the user, I guess?
>
> (The rule meaning as suggested by Robin
>> - if you include a commit from a user:
>> author := non-@gentoo
>> committer := @gen
Am Sonntag 03 Juni 2012, 18:01:04 schrieb Dirkjan Ochtman:
> On Sun, Jun 3, 2012 at 12:39 PM, Andreas K. Huettel
>
> wrote:
> > Sounds reasonable given the current state of git. Let's just be clear
> > about the following consequence (I hope I understand this correctly):
> >
> > * User makes sig
On Sun, Jun 3, 2012 at 12:39 PM, Andreas K. Huettel
wrote:
> Sounds reasonable given the current state of git. Let's just be clear about
> the following consequence (I hope I understand this correctly):
>
> * User makes signed improvements in gentoo-x86 clone
> * Developer pulls from user and >mer
Am Sonntag 03 Juni 2012, 10:18:24 schrieb Robin H. Johnson:
> I propose:
> - merges are explicitly allowed, even non-fast-forwards
> - all commits MUST be signed
> - if you include a commit from a user:
> author := non-@gentoo
> committer := @gentoo
> signer := $committer
>
Sounds reasonabl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/03/2012 09:18 AM, Robin H. Johnson wrote:
> This is one of several braindumps I've got, getting what are
> potentially very important details about the Git stuff out of my
> head, so that it doesn't matter if I become hit by a bus. Apologies
>
This is one of several braindumps I've got, getting what are potentially
very important details about the Git stuff out of my head, so that it
doesn't matter if I become hit by a bus. Apologies if this mail seems a bit
scrambled, per -core, my brain is rather scrambled lately.
TL;DR:
--
I prop
32 matches
Mail list logo
