* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Sun, 17 Apr 2005, Ingo Molnar wrote:
> >
> > in fact, this attack cannot even be proven to be malicious, purely via
> > the email from Malice: it could be incredible bad luck that caused that
> > good-looking patch to be mistakenly matching a da
On Sun, 17 Apr 2005, Ingo Molnar wrote:
>
> in fact, this attack cannot even be proven to be malicious, purely via
> the email from Malice: it could be incredible bad luck that caused that
> good-looking patch to be mistakenly matching a dangerous object.
I really hate theoretical discussions
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> The compromise relies on you having reviewed something harmless, while
> in reality what happened within the DB was far less harmless. And the
> DB remains self-consistent: neither fsck, nor others importing your
> tree will be able to detect the comp
* Brad Roberts <[EMAIL PROTECTED]> wrote:
> While I agree that a hash collision is bad and certainly worth
> preventing during new object creation, for it to actually implant a
> trojan in a build successfully it'd have to meet even more criteria
> than you've layed out. It'd have to...
> -
lt;[EMAIL PROTECTED]>, git@vger.kernel.org
> Subject: Re: Re: Merge with git-pasky II.
>
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > Almost all attacks on sha1 will depend on _replacing_ a file with a
> > bogus new one. So guys, instead of using sha256 or goi
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Almost all attacks on sha1 will depend on _replacing_ a file with a
> bogus new one. So guys, instead of using sha256 or going overboard,
> just make sure that when you synchronize, you NEVER import a file you
> already have.
here is a bit complex
On Sat, 16 Apr 2005, Linus Torvalds wrote:
Almost all attacks on sha1 will depend on _replacing_ a file with a bogus
new one. So guys, instead of using sha256 or going overboard, just make
sure that when you synchronize, you NEVER import a file you already have.
It's really that simple. Add "--igno
On Sat, Apr 16, 2005 at 06:03:33PM +0200, Petr Baudis wrote:
> Dear diary, on Sat, Apr 16, 2005 at 05:55:37PM CEST, I got a letter
> where Simon Fowler <[EMAIL PROTECTED]> told me that...
> > On Sat, Apr 16, 2005 at 05:19:24AM -0700, David Lang wrote:
> > > Simon
> > >
> > > given that you have mu
On Sat, 16 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sat, Apr 16, 2005 at 05:55:37PM CEST, I got a letter
> where Simon Fowler <[EMAIL PROTECTED]> told me that...
>
> > The id is a sha1 hash of the current time and the full path of the
> > file being added - the chances of that being replica
Dear diary, on Sat, Apr 16, 2005 at 05:55:37PM CEST, I got a letter
where Simon Fowler <[EMAIL PROTECTED]> told me that...
> On Sat, Apr 16, 2005 at 05:19:24AM -0700, David Lang wrote:
> > Simon
> >
> > given that you have multiple machines creating files, how do you deal with
> > the idea of the
Dear diary, on Fri, Apr 15, 2005 at 12:22:26PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> After I re-read [*R1*], in which Linus talks about dircache,
> especially this section:
>
> - The "current directory cache" describes some baseline. In particular,
>n
Dear diary, on Fri, Apr 15, 2005 at 02:58:25AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> > "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
> >> I think the above would result in what SCM person would call
> >> "merge upstream/sidestream changes into my work
BTW, I am not competing with Junio script. If that is the way
we all agree on. It is should be very easy for Junio to fix his
perl script. right?
Chris
On Thu, Apr 14, 2005 at 04:37:17PM -0400, Christopher Li wrote:
> Is that some thing you want to see? Maybe clean up the error printing.
>
>
>
Is that some thing you want to see? Maybe clean up the error printing.
Chris
--- /dev/null 2003-01-30 05:24:37.0 -0500
+++ merge.py2005-04-14 16:34:39.0 -0400
@@ -0,0 +1,76 @@
+#!/usr/bin/env python
+
+import re
+import sys
+import os
+from pprint import pprint
+
+def get_t
On Fri, Apr 15, 2005 at 01:31:59AM +0200, Petr Baudis wrote:
> > I am just trying to follow my understanding of what Linus
> > wanted. One of the guiding principle is to do as much things as
> > in dircache without ever checking things out or touching working
> > files unnecessarily.
>
> I'm just
Dear diary, on Fri, Apr 15, 2005 at 01:12:34AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> > "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
>
> PB> What I would like your script to do is therefore just do the
> PB> merge in a given already prepared (includi
Dear diary, on Thu, Apr 14, 2005 at 10:23:26PM CEST, I got a letter
where Erik van Konijnenburg <[EMAIL PROTECTED]> told me that...
> On Thu, Apr 14, 2005 at 09:35:07PM +0200, Petr Baudis wrote:
> > Hmm. I actually don't like this naming. I think it's not too consistent,
> > is irregular, therefore
On Thu, Apr 14, 2005 at 09:35:07PM +0200, Petr Baudis wrote:
> Hmm. I actually don't like this naming. I think it's not too consistent,
> is irregular, therefore parsing it would be ugly. What I propose:
>
> 12c\tname <- legend
> <- original file
> D <- tree #1 removed file
> D
Dear diary, on Thu, Apr 14, 2005 at 09:59:04PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> > "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> LT> On Thu, 14 Apr 2005, Junio C Hamano wrote:
>
> >> Sorry, I have not seen what you have been doing since p
Dear diary, on Thu, Apr 14, 2005 at 08:12:35PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> > "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
>
> PB> Bah, you outran me. ;-)
>
> Just being in a different timezone, I guess.
>
> PB> I'll change it to use the
Dear diary, on Thu, Apr 14, 2005 at 01:14:13PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Here is a diff to update the git-merge.perl script I showed you
> earlier today ;-). It contains the following updates against
> your HEAD (bb95843a5a0f397270819462812735e
21 matches
Mail list logo
