Re: SHA1 collisions found
On Sun, Feb 26, 2017 at 10:30 PM, Jeff King <p...@peff.net> wrote:
> On Sun, Feb 26, 2017 at 07:57:19PM +0100, Thomas Braun wrote:
>> While reading about the subject I came across [1]. The author reduced
>> the hash size to 4bits and then played around with git.
>>
>> Diff taken from the posting (not my code)
>> --- git-2.7.0~rc0+next.20151210.orig/block-sha1/sha1.c
>> +++ git-2.7.0~rc0+next.20151210/block-sha1/sha1.c
>> @@ -246,6 +246,8 @@ void blk_SHA1_Final(unsigned char hashou
>> blk_SHA1_Update(ctx, padlen, 8);
>>
>> /* Output hash */
>> - for (i = 0; i < 5; i++)
>> - put_be32(hashout + i * 4, ctx->H[i]);
>> + for (i = 0; i < 1; i++)
>> + put_be32(hashout + i * 4, (ctx->H[i] & 0xf00));
>> + for (i = 1; i < 5; i++)
>> + put_be32(hashout + i * 4, 0);
>> }
>
> Yeah, that is a lot more flexible for experimenting. Though I'd think
> you'd probably want more than 4 bits just to avoid accidental
> collisions. Something like 24 bits gives you some breathing space (you'd
> expect a random collision after 4096 objects), but it's still easy to
> do a preimage attack if you need to.
Just shortening the hash causes lots of collisions between objects of
different types. While it's valuable to test git behavior for those cases, you
probably want some way to explicitly test collisions that do not change
the object type, as they're not trivial to detect.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: SHA1 collisions found
On Thu, Feb 23, 2017 at 8:13 PM, Morten Welinder <mwelin...@gmail.com> wrote:
> The attack seems to generate two 64-bytes blocks, one quarter of which
> is repeated data. (Table-1 in the paper.)
>
> Assuming the result of that is evenly distributed and that bytes are
> independent, we can estimate the chances that the result is NUL-free
> as (255/256)^192 = 47% and the probability that the result is NUL and
> newline free as (254/256)^192 = 22%. Clearly one should not rely of
> NULs or newlines to save the day. On the other hand, the chances of
> an ascii result is something like (95/256)^192 = 10^-83.
Good. So they can replace linux/Documentation/logo.gif, but not actual source
files, not even if they contain hex arrays with "device parameters" ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)
On Thu, Feb 23, 2017 at 7:17 AM, Jeff King <p...@peff.net> wrote:
> On Thu, Feb 23, 2017 at 07:04:44AM +0100, Greg KH wrote:
>> > Poor Simon Sandström.
>> >
>> > Funnily enough, this only exists for one commit. You've got several
>> > other commits from Simon that get his name right.
>> >
>> > What happened?
>>
>> I don't know what happened, I used git for this, I don't use quilt for
>> "normal" patches accepted into my trees anymore, only for stable kernel
>> work.
>>
>> So either the mail is malformed, or git couldn't figure it out, I've
>> attached the original message below, and cc:ed the git mailing list.
>>
>> Also, Simon emailed me after this was committed saying something went
>> wrong, but I couldn't go back and rebase my tree. Simon, did you ever
>> figure out if something was odd on your end?
>>
>> Git developers, any ideas?
>
> The problem isn't on the applying end, but rather on the generating end.
> The From header in the attached mbox is:
>
> From: =?us-ascii?B?PT9VVEYtOD9xP1NpbW9uPTIwU2FuZHN0cj1DMz1CNm0/PQ==?=
> <si...@nikanor.nu>
Slightly related, once in a while I get funny emails through
git-commits-h...@vger.kernel.org, where the subject is completely screwed up:
Subject: \x64\x72\x6D\x2F\x74\x69\x6E\x79\x64\x72\x6D\x3A
\x6D\x69\x70\x69\x2D\x64\x62\x69\x3A \x53\x69\x6C\x65\x6E\x63\x65\x3A
‘\x63\x6D\x64’ \x6D\x61\x79 \x62\x65
and some of the mail headers end up in the body as well:
=?UTF-8?Q?\x75\x73\x65\x64_\x75\x6E\x69\x6E\x69\x74\x69\x61\x6C\x69\x7A\x65\x64?=
Return-Path: "Linux Kernel Mailing List" <linux-ker...@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Git-Commit: b401f34314db7c60e6d23ee7771cd090b4ef56c1
X-Git-Parent: 1e8ad3d8da4763b238d09244d4d1177aa640c0d3
X-Git-Refname: refs/heads/master
Web:
https://git.kernel.org/torvalds/c/b401f34314db7c60e6d23ee7771cd090b4ef56c1
Commit: b401f34314db7c60e6d23ee7771cd090b4ef56c1
Parent: 1e8ad3d8da4763b238d09244d4d1177aa640c0d3
Refname:refs/heads/master
Author: Noralf Trønnes <nor...@tronnes.org>
AuthorDate: Thu Feb 23 14:29:55 2017 +0100
Committer: Dave Airlie <airl...@redhat.com>
CommitDate: Fri Feb 24 12:08:58 2017 +1000
drm/tinydrm: mipi-dbi: Silence: ‘cmd’ may be used uninitialized
My first guess was Noralf's UTF8 last name, but after looking at a few more,
they all seem to have UTF8 quotes from gcc output in the oneline summary.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: "git send-email" thru Gmail incurs few minutes delay
On Sun, Jan 3, 2016 at 2:52 PM, Andrey Utkin
<andrey.ut...@corp.bluecherry.net> wrote:
> After "Send this email? ([y]es|[n]o|[q]uit|[a]ll): y" prompt and
> before "Password for 'smtp://x...@gmail.com@smtp.gmail.com:587':"
> prompt I always have a delay of 2-3 minutes. It is weird! "Unsafe
> clients" are allowed in Gmail settings.
> I experience this both with @gmail.com mailbox and with gmail-based
> company domain mail.
> I noticed this happening the first time several months ago.
> Has anybody else experienced this? Any solution?
> My git version is 2.6.4.
Does it work better if you store the (preferably app-specific) password in
smtppass in .gitconfig?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Invalid responses to 8bit encoding and In-Reply-To questions
From a thread on another mailing list:
| Content-Type: text/plain; charset=y
| Content-Transfer-Encoding: 8bit
|
| When I try to apply it git am says:
|
| $ git am --signoff geert1.patch
| fatal: cannot convert from y to UTF-8
|
| Wut? I never heard of an encoding named y, and SMTP is
| not my strongest subject anyway.
|
| Oops, I'm afraid automatic-I replied y to the git-send-email question
| Which 8bit encoding should I declare [UTF-8]?
| (happened before with the In-Reply-To questions ;-(
Would it be possible to reject obviously wrong replies (y, yes, n, no)
to the 8bit encoding and In-Reply-To questions?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] checkpatch: Add test for commit id formatting style in commit log
Hi Joe,
On Thu, Jul 3, 2014 at 12:00 AM, Joe Perches j...@perches.com wrote:
Commit logs have various forms of commit id references.
Try to standardize on a 12 character long lower case
commit id along with a description of parentheses and
the quoted subject line
ie: commit 0123456789ab (commit description)
Now this is in mainline, checkpatch starts complaining about my too long
(40 chars) commit IDs in commit messages :-(
40 chars may be too long (but it's quick to copy-and-paste, as git show
shows that by default), but 12 sounds a bit short, as that's only 48 bits.
According to the Birthday Paradox (en.wikipedia.org/wiki/Birthday_problem),
there's a probability of 50% of a collision if you use 48 bits IDs in a
repository with ca. 16 milion (2^24) objects. A Linux kernel repository
counts ca. 4 million objects, so we're getting close...
So soon we'll get error: short SHA1 is ambiguous.
BTW, is there actually an easy way to make git show show all options for
an ambiguous SHA1?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: unneeded merge in the security tree
On Tue, Mar 12, 2013 at 6:13 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
Why not just force the head of the security tree to be v3.9-rc2? Then
you don't end up creating a completely unnecessary merge commit, and
users who were at the previous head of the security tree will
experience a fast forward when they pull your new head.
So I think that may *technically* be the right solution, but it's a
rather annoying UI issue, partly because you can't just do it in a
single operation (you can't do a pull of the tag to both fetch and
fast-forward it), but partly because git reset --hard is also an
operation that can lose history, so it's something that people should
be nervous about, and shouldn't use as some kind of standard let's
just fast-forward to Linus' tree thing.
In many cases, git rebase x does the exact same thing as
git reset --hard x, with an added safeguard: if you forgot to upstream
something, it'll boil up on top of x.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Removing unreachable objects in the presence of broken links?
On Mon, Oct 29, 2012 at 8:56 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Sun, Oct 28, 2012 at 10:34 PM, Andreas Schwab sch...@linux-m68k.org
wrote:
Geert Uytterhoeven ge...@linux-m68k.org writes:
Is there a way to force removing unreachable objects in the presence of
broken
links?
Does it help to forcibly expire the reflogs?
You mean git reflog expire --all --expire=0?
After that the reflog is empty, but git gc still fails.
Although git stash list didn't show anything, .git/refs/stash still contained
one hash.
After running git stash clear, git gc succeeded, and the object pointed to
by .git/refs/stash before was gone.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Removing unreachable objects in the presence of broken links?
Hi Andreas,
On Sun, Oct 28, 2012 at 10:34 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Geert Uytterhoeven ge...@linux-m68k.org writes:
Is there a way to force removing unreachable objects in the presence of
broken
links?
Does it help to forcibly expire the reflogs?
You mean git reflog expire --all --expire=0?
After that the reflog is empty, but git gc still fails.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Removing unreachable objects in the presence of broken links?
Hi,
I managed to have a few missing objects in my development Linux kernel
repository, which uses another Linux kernel clone as an alternate.
Fortunately nothing is lost, as all missing objects are unreachable.
Probably they were in a branch that has been rebased, and the objects existed
for a small timespan in the alternate when I tried whether a patch created
in the development tree applied cleanly.
Is there a way to force removing unreachable objects in the presence of broken
links?
git prune doesn't do it, as it aborts when encountering the first
missing object.
Same with git repack -[aA]d.
git fsck reported
broken link fromtree 1330855dc33c1042b80d4c8ecbb6d56a19557ee8
totree b6c8c53b804662d6a6435c62b6dec1612bfbeb46
broken link fromtree f182e2fa155b9684b79ff6e17159d03d4de9a773
toblob d41f9ed0e2aba47ef62b4b4dd211b91cfe474ff8
missing blob d41f9ed0e2aba47ef62b4b4dd211b91cfe474ff8
missing tree b6c8c53b804662d6a6435c62b6dec1612bfbeb46
git fsck --unreachable HEAD $(git for-each-ref
--format=%(objectname) refs/heads)
told me about lots of unreachable objects, including the tree objects that
contain the two broken links.
BTW, every time I now do a rebase that triggers a gc (after the actual rebase
operation has completed), I end up with (no branch), so I have to do:
git banch -D branch
git branch branch
git checkout branch
to get back on the branch.
This is with git version 1.7.0.4 (1:1.7.0.4-1ubuntu0.2).
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
