From: Stefan Beller <email@example.com> To: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: "Jonathan Nieder" <firstname.lastname@example.org>, "Junio C Hamano" <email@example.com>, "Phillip Wood" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "Ævar Arnfjörð Bjarmason" <email@example.com> Subject: Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output Date: Tue, 6 Jun 2017 15:45:52 -0700 [thread overview] Message-ID: <CAGZ79kaYMR9uB0G911yRPXeZjbCeef2LHz4J2FLDOEj+mYkmqQ@mail.gmail.com> (raw) In-Reply-To: <alpine.DEB.22.214.171.1246070008440.171564@virtualbox> On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: >> Thanks for offering. ;-) > > Undoubtedly my lack of command of the English language is to blame for > this misunderstanding. Sometimes it is best to not be a native speaker, just fluent enough to get by. :) > What I wanted to suggest instead was that the current direction looks very > unfocused to me That is unfortunate but reality of being a *real* community project. Neither you nor me (nor Junio) can command people to do things. The best we can do is reject an idea going off. >, and that I do not see anything going forward in a > coherent manner. But is this bad? > 1) this cannot be a one-person effort, it is too large I agree. But there are efforts by multiple people. See Brians series (lots of different reviewers), also Brandon picked up parts of it (origin/bw/object-id). Or the design that was discussed on list, which was lots of people participation. > > 2) it cannot even be as uncoordinated an effort as it is now, because that > leads only to bikeshedding instead of progress Jonathan presented a list of things, that can be done in parallel in an uncoordinated effort, because that is how the project works. (C.f. he mentioned "rogue agents") > 3) the only person who could make that call is Junio Occasionally I think the same, but in fact it is not true. As said above, Junio has strong veto power for things going off rails, but in his role as a maintainer he does not coordinate people. (He occasionally asks them to coordinate between themselves, though) > > 4) we still have the problem that there is no cryptography expert among > those who in the Git project are listened to I can assure you that Jonathan listened to crypto experts. It just did not happen on the mailing list, which is sad regarding openness and transparency. 5. The timeline you seem to favor would be really great for people working on Git at $BIG_CORP, as big corps usually plan things by the quarter. So maybe by having a timeline (known in advance of the quarter) can convince managers easier. > >> How did you get the impression that their opinion had no impact? We have >> been getting feedback about the choice of hash function both on and off >> list from a variety of people, some indisputably security experts. >> Sometimes the best one can do is to just listen. > > I did get the impression by talking at length to a cryptography expert who > successfully resisted any suggestions to get involved in the Git mailing > list. > > There were also accounts floating around on Twitter that a certain > cryptography expert who dared to mention already back in 2005 how > dangerous it would be to hardcode SHA-1 into Git was essentially shown the > finger, and I cannot fault him for essentially saying "I told you so" > publicly. Heh. The community between 2005 and now has changed. (I was not there for example. ;-) ) So let's hope the community changes for the better. > In my mind, it would have made sense to ask well-respected cryptographers > about their opinions and then try to figure out a consensus among them (as > opposed to what I saw so far, a lot of enthusastic talk by developers with > little standing in the cryptography community, mostly revolving around > hash size and speed as opposed to security). And then try to implement > that consensus in Git. Sounds good to me. That is why I personally think point (4) from Jonathans list above over-emphasizes performance/size over security. On the other hand if we find a smart way now, then this hash function transition will open the road to switching the hash function down the road once again with less or even no penalty if we make mistakes in choosing yet another bad hash function now. > Given my recent success rate with SHA-1 related > concerns, I am unfortunately not the person who can bring that about. > > But maybe you are. > > Ciao, > Dscho Thanks for bringing the discussion back to life, Stefan
next prev parent reply other threads:[~2017-06-06 22:45 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-31 10:42 [PATCH 0/3] Add regression tests for recent rebase -i fixes Phillip Wood 2017-05-31 10:42 ` [PATCH 1/3] rebase -i: Add test for reflog message Phillip Wood 2017-06-01 2:00 ` Junio C Hamano 2017-05-31 10:42 ` [PATCH 2/3] rebase: Add tests for console output Phillip Wood 2017-05-31 19:02 ` Phillip Wood 2017-06-01 1:59 ` Junio C Hamano 2017-06-01 12:56 ` Johannes Schindelin 2017-06-01 23:40 ` Junio C Hamano 2017-06-01 23:47 ` Stefan Beller 2017-06-02 12:47 ` pushing for a new hash, was " Johannes Schindelin 2017-06-02 17:54 ` Jonathan Nieder 2017-06-02 18:05 ` Jonathan Nieder 2017-06-02 20:29 ` Ævar Arnfjörð Bjarmason 2017-06-15 10:38 ` Johannes Schindelin 2017-06-03 0:36 ` Junio C Hamano 2017-06-06 22:22 ` Johannes Schindelin 2017-06-06 22:45 ` Jonathan Nieder 2017-06-07 1:09 ` Junio C Hamano 2017-06-07 2:18 ` [PATCH] t4005: modernize style and drop hard coded sha1 Stefan Beller 2017-06-07 17:39 ` Brandon Williams 2017-06-06 22:45 ` Stefan Beller [this message] 2017-06-06 22:52 ` pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output Jonathan Nieder 2017-06-07 0:34 ` Samuel Lijin 2017-06-07 14:47 ` Johannes Schindelin 2017-06-07 16:53 ` Stefan Beller 2017-06-07 10:47 ` Phillip Wood 2017-06-09 16:39 ` Junio C Hamano 2017-06-14 10:18 ` Phillip Wood 2017-06-14 12:51 ` Johannes Schindelin 2017-05-31 10:42 ` [PATCH 3/3] rebase: Add tests for console output with conflicting stash Phillip Wood 2017-06-14 10:24 ` [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes Phillip Wood 2017-06-14 10:24 ` [PATCH v2 1/3] rebase -i: Add test for reflog message Phillip Wood 2017-06-14 10:24 ` [PATCH v2 2/3] rebase: Add regression tests for console output Phillip Wood 2017-06-14 10:24 ` [PATCH v2 3/3] rebase: Add more " Phillip Wood 2017-06-14 20:35 ` [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes Johannes Schindelin 2017-06-15 23:05 ` Junio C Hamano 2017-06-15 23:23 ` Junio C Hamano 2017-06-15 23:29 ` Junio C Hamano 2017-06-16 13:49 ` Johannes Schindelin 2017-06-16 18:43 ` Johannes Sixt 2017-06-16 21:05 ` Junio C Hamano 2017-06-19 19:45 ` Johannes Sixt 2017-06-19 20:02 ` Junio C Hamano 2017-06-19 9:49 ` Phillip Wood 2017-06-19 15:45 ` Junio C Hamano 2017-06-19 9:52 ` Phillip Wood 2017-06-19 17:56 ` [PATCH v3 0/4] Add regression tests for recent " Phillip Wood 2017-06-19 17:56 ` [PATCH v3 1/4] sequencer: print autostash messages to stderr Phillip Wood 2017-06-19 17:56 ` [PATCH v3 2/4] rebase -i: Add test for reflog message Phillip Wood 2017-06-19 17:56 ` [PATCH v3 3/4] rebase: Add regression tests for console output Phillip Wood 2017-06-19 17:56 ` [PATCH v3 4/4] rebase: Add more " Phillip Wood 2017-06-23 4:17 ` [PATCH v3 0/4] Add regression tests for recent rebase -i fixes Junio C Hamano 2017-06-23 5:07 ` Junio C Hamano 2017-06-23 9:53 ` Phillip Wood 2017-06-23 17:03 ` Junio C Hamano 2017-06-23 18:53 ` Junio C Hamano 2017-06-26 9:17 ` Phillip Wood 2017-06-23 19:01 ` Junio C Hamano 2017-06-26 9:23 ` Phillip Wood
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAGZ79kaYMR9uB0G911yRPXeZjbCeef2LHz4J2FLDOEj+mYkmqQ@mail.gmail.com \ --firstname.lastname@example.org \ --cc=Johannes.Schindelin@gmx.de \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).