Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote: > Shawn O. Pearce schrieb: > > I'm currently finishing a side-band-64k protocol extension to the > > send-pack/receive-pack pair. My next task after I flush those > > RFC patches out to the list tonight will be to prototype at least > > some of the auth1 extension I described. > > I propose to make the syntax of the extension > > server capability: auth=<list of hash methods>:<challenge> > client response: auth=<chosen hash method> > > where <challenge> is a random sequence of non-blank ASCII text, not > necessarily of a fixed length, but perhaps of a minimum length. > > Then we can extend the list of hash algorithms (that are used for > authentication purposes) if people think that SHA1 is not secure enough: > > auth=SHA1,SHA256:random-stuff-goes-here > > I'm not a security expert, so take this with a grain of salt. I'm not certain this is worth the extra complexity. One reason I proposed "auth-1" as the extension name is so we could introduce an "auth-2" and make changes in the future if we need to. But I think there's little value in this authentication hash being anything other than SHA-1. Remember that the data itself in the packfile following the authentication is only protected by SHA-1. If SHA-1 is considered too weak to protect the ref update commands then its likely also too weak to protect the file content following behind those same commands. Getting stronger authentication here than SHA-1 would probably require changing the commit object name hash to something stronger than SHA-1, and the tree object name hash, etc. Remember that signed tags are only using the SHA-1 of the commit and that's only got the SHA-1 of the tree... ;-) -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
