Re: SHA1 collisions found
On Sun, Feb 26, 2017 at 10:30 PM, Jeff King 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 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 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==?= > 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" 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 AuthorDate: Thu Feb 23 14:29:55 2017 +0100 Committer: Dave Airlie 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 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 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 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 wrote: > On Sun, Oct 28, 2012 at 10:34 PM, Andreas Schwab > wrote: >> Geert Uytterhoeven 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 wrote: > Geert Uytterhoeven 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 git branch git checkout 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