Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 9:19 AM, Linus Torvalds wrote: > > I don't think you'd necessarily want to change the size of the hash. > You can use a different hash and just use the same 160 bits from it. Side note: I do believe that in practice you should just change

Re: SHA1 collisions found

Junio C Hamano wrote: > On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess wrote: > > > > Since we now have collisions in valid PDF files, collisions in valid git > > commit and tree objects are probably able to be constructed. > > That may be true, but >

Re: SHA1 collisions found

On Thu, 23 Feb 2017, Junio C Hamano wrote: On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess wrote: Since we now have collisions in valid PDF files, collisions in valid git commit and tree objects are probably able to be constructed. That may be true, but

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess wrote: > > IIRC someone has been working on parameterizing git's SHA1 assumptions > so a repository could eventually use a more secure hash. How far has > that gotten? There are still many "40" constants in git.git HEAD. I don't think

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 9:02 AM, Junio C Hamano wrote: > On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess wrote: >> >> Since we now have collisions in valid PDF files, collisions in valid git >> commit and tree objects are probably able to be constructed. > > That

Re: SHA1 collisions found

On Thu, 23 Feb 2017, Joey Hess wrote: https://shattered.io/static/shattered.pdf https://freedom-to-tinker.com/2017/02/23/rip-sha-1/ IIRC someone has been working on parameterizing git's SHA1 assumptions so a repository could eventually use a more secure hash. How far has that gotten? There are

Re: [PATCH] http(s): automatically try NTLM authentication first

Hi Peff, On Wed, 22 Feb 2017, Jeff King wrote: > On Wed, Feb 22, 2017 at 01:16:33PM -0800, Junio C Hamano wrote: > > > David Turner writes: > > > > > Always, no. For failed authentication (or authorization), > > > apparently, yes. I tested this by setting the

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess wrote: > > Since we now have collisions in valid PDF files, collisions in valid git > commit and tree objects are probably able to be constructed. That may be true, but

SHA1 collisions found

https://shattered.io/static/shattered.pdf https://freedom-to-tinker.com/2017/02/23/rip-sha-1/ IIRC someone has been working on parameterizing git's SHA1 assumptions so a repository could eventually use a more secure hash. How far has that gotten? There are still many "40" constants in git.git

RE: [PATCH 2/2] http: add an "auto" mode for http.emptyauth

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Wednesday, February 22, 2017 8:38 PM > To: David Turner > Cc: Junio C Hamano ; git@vger.kernel.org; > sand...@crustytoothpaste.net; Johannes Schindelin >

SHAttered (the first practical SHA1 attack)

Hello all, I ran into this website presenting the "first practical attack on sha1"[1]. I don't recall seeing this on the ML, so I'm sharing this just in case. I know there are proposals to move out of sha1 already. I wonder if this affects the timeline for their adoption? Thanks, -Santiago. [1]

RE: [RFC] Add support for downloading blobs on demand

I've completed the work of switching our read_object proposal to use a background process (refactored from the LFS code) and have extricated it from the rest of our GVFS fork so that it can be examined/tested separately. It is currently based on a Git For Windows fork that I've pushed to GitHub

[no subject]

winning ticket(1).docx Description: MS-Word 2007 document

[PATCH v5 0/1] Conditional config include

Let's try this again. v4 and before can be found in the original thread [1]. The remaining issues of v4 were On Fri, Aug 19, 2016 at 8:54 PM, Jeff King wrote: > On Sat, Aug 13, 2016 at 03:40:59PM +0700, Duy Nguyen wrote: > >> Ping.. > > There was some discussion after v4. I think

[PATCH v5 1/1] config: add conditional include

This allows some more flexibility in managing configuration across repositories. The most often seen use case on the mailing list is when the user needs to use different email addresses on different repositories. If these repositories share something that we can use to group them up, then we can

[ANNOUNCE] Git Rev News edition 24

Hi everyone, The 24th edition of Git Rev News is now published: https://git.github.io/rev_news/2017/02/22/edition-24/ Thanks a lot to all the contributors and helpers! Enjoy, Christian, Thomas, Jakub and Markus.

Re: [PATCH v5 01/24] refs.h: add forward declaration for structs used in this file

On Thu, Feb 23, 2017 at 1:18 AM, Stefan Beller wrote: > On Wed, Feb 22, 2017 at 6:04 AM, Nguyễn Thái Ngọc Duy > wrote: >> Signed-off-by: Nguyễn Thái Ngọc Duy >> --- >> refs.h | 6 +- >> 1 file changed, 5 insertions(+), 1

Re: [PATCH v2 1/4] delete_ref: accept a reflog message argument

On Tue, Feb 21, 2017 at 8:10 AM, Kyle Meyer wrote: > diff --git a/refs.h b/refs.h > index 9fbff90e7..5880886a7 100644 > --- a/refs.h > +++ b/refs.h > @@ -276,8 +276,8 @@ int reflog_exists(const char *refname); > * exists, regardless of its old value. It is an error for old_sha1

Re: [PATCH] http(s): automatically try NTLM authentication first

On 2017-02-23 03:03, David Turner wrote: > Actually, though, I am not sure this is as bad as it seems, because gssapi > might protect us. When I locally tried a fake server, git (libcurl) refused > to > send my Kerberos credentials because "Server not found in Kerberos > database". I don't

[PATCH 3/4] filter-branch: fix --prune-empty on parentless commits

Previously, the git_commit_non_empty_tree function would always pass any commit with no parents to git-commit-tree, regardless of whether the tree was nonempty. The new commit would then be recorded in the filter-branch revision map, and subsequent commits which leave the tree untouched would be

[PATCH 4/4] p7000: add test for filter-branch with --prune-empty

Signed-off-by: Devin J. Pohly --- t/perf/p7000-filter-branch.sh | 5 + 1 file changed, 5 insertions(+) diff --git a/t/perf/p7000-filter-branch.sh b/t/perf/p7000-filter-branch.sh index 15ee5d1d5..b029586cc 100755 --- a/t/perf/p7000-filter-branch.sh +++

[PATCH 2/4] t7003: ensure --prune-empty removes entire branch when applicable

Sanity check before changing the logic in git_commit_non_empty_tree. Signed-off-by: Devin J. Pohly --- t/t7003-filter-branch.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh index 2dfe46250..7cb60799b 100755 ---

[PATCH 1/4] t7003: ensure --prune-empty can prune root commit

New test to expose a bug in filter-branch whereby the root commit is never pruned, even though its tree is empty and --prune-empty is given. The setup isn't exactly pretty, but I couldn't think of a simpler way to create a parallel commit graph sans the first commit. Signed-off-by: Devin J.

[PATCH 4/4] ident: do not ignore empty config name/email

When we read user.name and user.email from a config file, they go into strbufs. When a caller asks ident_default_name() for the value, we fallback to auto-detecting if the strbuf is empty. That means that explicitly setting an empty string in the config is identical to not setting it at all. This

[PATCH 3/4] ident: reject all-crud ident name

An ident name consisting of only "crud" characters (like whitespace or punctuation) is effectively the same as an empty one, because our strbuf_addstr_without_crud() will remove those characters. We reject an empty name when formatting a strict ident, but don't notice an all-crud one because our

[PATCH 1/4] ident: mark error messages for translation

We already translate the big "please tell me who you are" hint, but missed the individual error messages that go with it. Signed-off-by: Jeff King --- ident.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/ident.c b/ident.c index

[PATCH 2/4] ident: handle NULL email when complaining of empty name

If we see an empty name, we complain about and mention the matching email in the error message (to give it some context). However, the "email" pointer may be NULL here if we were planning to fill it in later from ident_default_email(). This was broken by 59f929596 (fmt_ident: refactor strictness

Re: possible bug: inconsistent CLI behaviour for empty user.name

On Fri, Feb 03, 2017 at 05:13:09AM +0100, bs.x@recursor.net wrote: > The problem is that GIT accepts a user.name of " " for some operations > (for example when doing a simple "git commit"), but does require a > "non-empty" user.name for others (like git commit --amend and git > rebase). In

Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)

On Thu, Feb 23, 2017 at 01:17:02AM -0500, Jeff King wrote: > On Thu, Feb 23, 2017 at 07:04:44AM +0100, Greg KH wrote: > > > > > 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

<    1   2