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 Fri, Jun 8, 2012 at 7:01 AM, W. Trevor King wk...@tremily.us 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
-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.
Certainly
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
On Mon, 4 Jun 2012 16:57:42 -0400
Rich Freeman ri...@gentoo.org 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
On Tue, Jun 5, 2012 at 2:50 AM, Michał Górny mgo...@gentoo.org wrote:
On Mon, 4 Jun 2012 16:57:42 -0400
Rich Freeman ri...@gentoo.org 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
On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel dilfri...@gentoo.org 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
On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman d...@gentoo.org wrote:
On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel dilfri...@gentoo.org
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
-
On Mon, Jun 4, 2012 at 2:34 PM, Rich Freeman ri...@gentoo.org 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
On Mon, Jun 4, 2012 at 8:45 AM, Dirkjan Ochtman d...@gentoo.org 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,
On Mon, Jun 4, 2012 at 3:40 PM, Rich Freeman ri...@gentoo.org 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
On 06/04/2012 07:34 AM, Rich Freeman wrote:
On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman d...@gentoo.org wrote:
On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel dilfri...@gentoo.org
wrote:
However, then the committer of the contributed commits before the merge is
then the user, I guess?
On Mon, Jun 4, 2012 at 9:48 AM, Dirkjan Ochtman d...@gentoo.org 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
On Mon, Jun 4, 2012 at 4:18 PM, Rich Freeman ri...@gentoo.org 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
On Mon, Jun 4, 2012 at 10:26 AM, Dirkjan Ochtman d...@gentoo.org wrote:
On Mon, Jun 4, 2012 at 4:18 PM, Rich Freeman ri...@gentoo.org 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
On Mon, Jun 4, 2012 at 4:48 PM, Rich Freeman ri...@gentoo.org 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 Mon, Jun 4, 2012 at 11:02 AM, Dirkjan Ochtman d...@gentoo.org 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
On Mon, Jun 4, 2012 at 6:06 PM, Rich Freeman ri...@gentoo.org 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
On Mon, Jun 4, 2012 at 12:19 PM, Dirkjan Ochtman d...@gentoo.org 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
On Mon, Jun 4, 2012 at 7:25 PM, Rich Freeman ri...@gentoo.org 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
On Mon, Jun 04, 2012 at 08:45:42PM +0200, Dirkjan Ochtman wrote:
On Mon, Jun 4, 2012 at 7:25 PM, Rich Freeman ri...@gentoo.org 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
On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring ferri...@gmail.com 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
On Mon, Jun 04, 2012 at 03:27:03PM -0400, Rich Freeman wrote:
On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring ferri...@gmail.com 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
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 is
On Mon, Jun 4, 2012 at 4:41 PM, Brian Harring ferri...@gmail.com 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
On Mon, 04 Jun 2012 22:52:25 +0200
Andreas K. Huettel dilfri...@gentoo.org 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
On Mon, Jun 4, 2012 at 10:41 PM, Brian Harring ferri...@gmail.com 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
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
-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
if
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 reasonable given
On Sun, Jun 3, 2012 at 12:39 PM, Andreas K. Huettel
dilfri...@gentoo.org 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
Am Sonntag 03 Juni 2012, 18:01:04 schrieb Dirkjan Ochtman:
On Sun, Jun 3, 2012 at 12:39 PM, Andreas K. Huettel
dilfri...@gentoo.org 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
32 matches
Mail list logo
