1647 lines
75 KiB
HTML
1647 lines
75 KiB
HTML
|
<!DOCTYPE html>
|
||
|
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<meta charset="UTF-8">
|
||
|
|
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
|
||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||
|
|
<meta name="generator" content="Asciidoctor 1.5.8">
|
||
|
|
<title>Git hash function transition</title>
|
||
|
|
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700">
|
||
|
|
<style>
|
||
|
|
/* Asciidoctor default stylesheet | MIT License | http://asciidoctor.org */
|
||
|
|
/* Uncomment @import statement below to use as custom stylesheet */
|
||
|
|
/*@import "https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700";*/
|
||
|
|
article,aside,details,figcaption,figure,footer,header,hgroup,main,nav,section,summary{display:block}
|
||
|
|
audio,canvas,video{display:inline-block}
|
||
|
|
audio:not([controls]){display:none;height:0}
|
||
|
|
script{display:none!important}
|
||
|
|
html{font-family:sans-serif;-ms-text-size-adjust:100%;-webkit-text-size-adjust:100%}
|
||
|
|
a{background:transparent}
|
||
|
|
a:focus{outline:thin dotted}
|
||
|
|
a:active,a:hover{outline:0}
|
||
|
|
h1{font-size:2em;margin:.67em 0}
|
||
|
|
abbr[title]{border-bottom:1px dotted}
|
||
|
|
b,strong{font-weight:bold}
|
||
|
|
dfn{font-style:italic}
|
||
|
|
hr{-moz-box-sizing:content-box;box-sizing:content-box;height:0}
|
||
|
|
mark{background:#ff0;color:#000}
|
||
|
|
code,kbd,pre,samp{font-family:monospace;font-size:1em}
|
||
|
|
pre{white-space:pre-wrap}
|
||
|
|
q{quotes:"\201C" "\201D" "\2018" "\2019"}
|
||
|
|
small{font-size:80%}
|
||
|
|
sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline}
|
||
|
|
sup{top:-.5em}
|
||
|
|
sub{bottom:-.25em}
|
||
|
|
img{border:0}
|
||
|
|
svg:not(:root){overflow:hidden}
|
||
|
|
figure{margin:0}
|
||
|
|
fieldset{border:1px solid silver;margin:0 2px;padding:.35em .625em .75em}
|
||
|
|
legend{border:0;padding:0}
|
||
|
|
button,input,select,textarea{font-family:inherit;font-size:100%;margin:0}
|
||
|
|
button,input{line-height:normal}
|
||
|
|
button,select{text-transform:none}
|
||
|
|
button,html input[type="button"],input[type="reset"],input[type="submit"]{-webkit-appearance:button;cursor:pointer}
|
||
|
|
button[disabled],html input[disabled]{cursor:default}
|
||
|
|
input[type="checkbox"],input[type="radio"]{box-sizing:border-box;padding:0}
|
||
|
|
button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0}
|
||
|
|
textarea{overflow:auto;vertical-align:top}
|
||
|
|
table{border-collapse:collapse;border-spacing:0}
|
||
|
|
*,*::before,*::after{-moz-box-sizing:border-box;-webkit-box-sizing:border-box;box-sizing:border-box}
|
||
|
|
html,body{font-size:100%}
|
||
|
|
body{background:#fff;color:rgba(0,0,0,.8);padding:0;margin:0;font-family:"Noto Serif","DejaVu Serif",serif;font-weight:400;font-style:normal;line-height:1;position:relative;cursor:auto;tab-size:4;-moz-osx-font-smoothing:grayscale;-webkit-font-smoothing:antialiased}
|
||
|
|
a:hover{cursor:pointer}
|
||
|
|
img,object,embed{max-width:100%;height:auto}
|
||
|
|
object,embed{height:100%}
|
||
|
|
img{-ms-interpolation-mode:bicubic}
|
||
|
|
.left{float:left!important}
|
||
|
|
.right{float:right!important}
|
||
|
|
.text-left{text-align:left!important}
|
||
|
|
.text-right{text-align:right!important}
|
||
|
|
.text-center{text-align:center!important}
|
||
|
|
.text-justify{text-align:justify!important}
|
||
|
|
.hide{display:none}
|
||
|
|
img,object,svg{display:inline-block;vertical-align:middle}
|
||
|
|
textarea{height:auto;min-height:50px}
|
||
|
|
select{width:100%}
|
||
|
|
.center{margin-left:auto;margin-right:auto}
|
||
|
|
.stretch{width:100%}
|
||
|
|
.subheader,.admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{line-height:1.45;color:#7a2518;font-weight:400;margin-top:0;margin-bottom:.25em}
|
||
|
|
div,dl,dt,dd,ul,ol,li,h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6,pre,form,p,blockquote,th,td{margin:0;padding:0;direction:ltr}
|
||
|
|
a{color:#2156a5;text-decoration:underline;line-height:inherit}
|
||
|
|
a:hover,a:focus{color:#1d4b8f}
|
||
|
|
a img{border:none}
|
||
|
|
p{font-family:inherit;font-weight:400;font-size:1em;line-height:1.6;margin-bottom:1.25em;text-rendering:optimizeLegibility}
|
||
|
|
p aside{font-size:.875em;line-height:1.35;font-style:italic}
|
||
|
|
h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{font-family:"Open Sans","DejaVu Sans",sans-serif;font-weight:300;font-style:normal;color:#ba3925;text-rendering:optimizeLegibility;margin-top:1em;margin-bottom:.5em;line-height:1.0125em}
|
||
|
|
h1 small,h2 small,h3 small,#toctitle small,.sidebarblock>.content>.title small,h4 small,h5 small,h6 small{font-size:60%;color:#e99b8f;line-height:0}
|
||
|
|
h1{font-size:2.125em}
|
||
|
|
h2{font-size:1.6875em}
|
||
|
|
h3,#toctitle,.sidebarblock>.content>.title{font-size:1.375em}
|
||
|
|
h4,h5{font-size:1.125em}
|
||
|
|
h6{font-size:1em}
|
||
|
|
hr{border:solid #dddddf;border-width:1px 0 0;clear:both;margin:1.25em 0 1.1875em;height:0}
|
||
|
|
em,i{font-style:italic;line-height:inherit}
|
||
|
|
strong,b{font-weight:bold;line-height:inherit}
|
||
|
|
small{font-size:60%;line-height:inherit}
|
||
|
|
code{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;font-weight:400;color:rgba(0,0,0,.9)}
|
||
|
|
ul,ol,dl{font-size:1em;line-height:1.6;margin-bottom:1.25em;list-style-position:outside;font-family:inherit}
|
||
|
|
ul,ol{margin-left:1.5em}
|
||
|
|
ul li ul,ul li ol{margin-left:1.25em;margin-bottom:0;font-size:1em}
|
||
|
|
ul.square li ul,ul.circle li ul,ul.disc li ul{list-style:inherit}
|
||
|
|
ul.square{list-style-type:square}
|
||
|
|
ul.circle{list-style-type:circle}
|
||
|
|
ul.disc{list-style-type:disc}
|
||
|
|
ol li ul,ol li ol{margin-left:1.25em;margin-bottom:0}
|
||
|
|
dl dt{margin-bottom:.3125em;font-weight:bold}
|
||
|
|
dl dd{margin-bottom:1.25em}
|
||
|
|
abbr,acronym{text-transform:uppercase;font-size:90%;color:rgba(0,0,0,.8);border-bottom:1px dotted #ddd;cursor:help}
|
||
|
|
abbr{text-transform:none}
|
||
|
|
blockquote{margin:0 0 1.25em;padding:.5625em 1.25em 0 1.1875em;border-left:1px solid #ddd}
|
||
|
|
blockquote cite{display:block;font-size:.9375em;color:rgba(0,0,0,.6)}
|
||
|
|
blockquote cite::before{content:"\2014 \0020"}
|
||
|
|
blockquote cite a,blockquote cite a:visited{color:rgba(0,0,0,.6)}
|
||
|
|
blockquote,blockquote p{line-height:1.6;color:rgba(0,0,0,.85)}
|
||
|
|
@media screen and (min-width:768px){h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2}
|
||
|
|
h1{font-size:2.75em}
|
||
|
|
h2{font-size:2.3125em}
|
||
|
|
h3,#toctitle,.sidebarblock>.content>.title{font-size:1.6875em}
|
||
|
|
h4{font-size:1.4375em}}
|
||
|
|
table{background:#fff;margin-bottom:1.25em;border:solid 1px #dedede}
|
||
|
|
table thead,table tfoot{background:#f7f8f7}
|
||
|
|
table thead tr th,table thead tr td,table tfoot tr th,table tfoot tr td{padding:.5em .625em .625em;font-size:inherit;color:rgba(0,0,0,.8);text-align:left}
|
||
|
|
table tr th,table tr td{padding:.5625em .625em;font-size:inherit;color:rgba(0,0,0,.8)}
|
||
|
|
table tr.even,table tr.alt,table tr:nth-of-type(even){background:#f8f8f7}
|
||
|
|
table thead tr th,table tfoot tr th,table tbody tr td,table tr td,table tfoot tr td{display:table-cell;line-height:1.6}
|
||
|
|
h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2;word-spacing:-.05em}
|
||
|
|
h1 strong,h2 strong,h3 strong,#toctitle strong,.sidebarblock>.content>.title strong,h4 strong,h5 strong,h6 strong{font-weight:400}
|
||
|
|
.clearfix::before,.clearfix::after,.float-group::before,.float-group::after{content:" ";display:table}
|
||
|
|
.clearfix::after,.float-group::after{clear:both}
|
||
|
|
*:not(pre)>code{font-size:.9375em;font-style:normal!important;letter-spacing:0;padding:.1em .5ex;word-spacing:-.15em;background-color:#f7f7f8;-webkit-border-radius:4px;border-radius:4px;line-height:1.45;text-rendering:optimizeSpeed;word-wrap:break-word}
|
||
|
|
*:not(pre)>code.nobreak{word-wrap:normal}
|
||
|
|
*:not(pre)>code.nowrap{white-space:nowrap}
|
||
|
|
pre,pre>code{line-height:1.45;color:rgba(0,0,0,.9);font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;font-weight:400;text-rendering:optimizeSpeed}
|
||
|
|
em em{font-style:normal}
|
||
|
|
strong strong{font-weight:400}
|
||
|
|
.keyseq{color:rgba(51,51,51,.8)}
|
||
|
|
kbd{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;display:inline-block;color:rgba(0,0,0,.8);font-size:.65em;line-height:1.45;background-color:#f7f7f7;border:1px solid #ccc;-webkit-border-radius:3px;border-radius:3px;-webkit-box-shadow:0 1px 0 rgba(0,0,0,.2),0 0 0 .1em white inset;box-shadow:0 1px 0 rgba(0,0,0,.2),0 0 0 .1em #fff inset;margin:0 .15em;padding:.2em .5em;vertical-align:middle;position:relative;top:-.1em;white-space:nowrap}
|
||
|
|
.keyseq kbd:first-child{margin-left:0}
|
||
|
|
.keyseq kbd:last-child{margin-right:0}
|
||
|
|
.menuseq,.menuref{color:#000}
|
||
|
|
.menuseq b:not(.caret),.menuref{font-weight:inherit}
|
||
|
|
.menuseq{word-spacing:-.02em}
|
||
|
|
.menuseq b.caret{font-size:1.25em;line-height:.8}
|
||
|
|
.menuseq i.caret{font-weight:bold;text-align:center;width:.45em}
|
||
|
|
b.button::before,b.button::after{position:relative;top:-1px;font-weight:400}
|
||
|
|
b.button::before{content:"[";padding:0 3px 0 2px}
|
||
|
|
b.button::after{content:"]";padding:0 2px 0 3px}
|
||
|
|
p a>code:hover{color:rgba(0,0,0,.9)}
|
||
|
|
#header,#content,#footnotes,#footer{width:100%;margin-left:auto;margin-right:auto;margin-top:0;margin-bottom:0;max-width:62.5em;*zoom:1;position:relative;padding-left:.9375em;padding-right:.9375em}
|
||
|
|
#header::before,#header::after,#content::before,#content::after,#footnotes::before,#footnotes::after,#footer::before,#footer::after{content:" ";display:table}
|
||
|
|
#header::after,#content::after,#footnotes::after,#footer::after{clear:both}
|
||
|
|
#content{margin-top:1.25em}
|
||
|
|
#content::before{content:none}
|
||
|
|
#header>h1:first-child{color:rgba(0,0,0,.85);margin-top:2.25rem;margin-bottom:0}
|
||
|
|
#header>h1:first-child+#toc{margin-top:8px;border-top:1px solid #dddddf}
|
||
|
|
#header>h1:only-child,body.toc2 #header>h1:nth-last-child(2){border-bottom:1px solid #dddddf;padding-bottom:8px}
|
||
|
|
#header .details{border-bottom:1px solid #dddddf;line-height:1.45;padding-top:.25em;padding-bottom:.25em;padding-left:.25em;color:rgba(0,0,0,.6);display:-ms-flexbox;display:-webkit-flex;display:flex;-ms-flex-flow:row wrap;-webkit-flex-flow:row wrap;flex-flow:row wrap}
|
||
|
|
#header .details span:first-child{margin-left:-.125em}
|
||
|
|
#header .details span.email a{color:rgba(0,0,0,.85)}
|
||
|
|
#header .details br{display:none}
|
||
|
|
#header .details br+span::before{content:"\00a0\2013\00a0"}
|
||
|
|
#header .details br+span.author::before{content:"\00a0\22c5\00a0";color:rgba(0,0,0,.85)}
|
||
|
|
#header .details br+span#revremark::before{content:"\00a0|\00a0"}
|
||
|
|
#header #revnumber{text-transform:capitalize}
|
||
|
|
#header #revnumber::after{content:"\00a0"}
|
||
|
|
#content>h1:first-child:not([class]){color:rgba(0,0,0,.85);border-bottom:1px solid #dddddf;padding-bottom:8px;margin-top:0;padding-top:1rem;margin-bottom:1.25rem}
|
||
|
|
#toc{border-bottom:1px solid #e7e7e9;padding-bottom:.5em}
|
||
|
|
#toc>ul{margin-left:.125em}
|
||
|
|
#toc ul.sectlevel0>li>a{font-style:italic}
|
||
|
|
#toc ul.sectlevel0 ul.sectlevel1{margin:.5em 0}
|
||
|
|
#toc ul{font-family:"Open Sans","DejaVu Sans",sans-serif;list-style-type:none}
|
||
|
|
#toc li{line-height:1.3334;margin-top:.3334em}
|
||
|
|
#toc a{text-decoration:none}
|
||
|
|
#toc a:active{text-decoration:underline}
|
||
|
|
#toctitle{color:#7a2518;font-size:1.2em}
|
||
|
|
@media screen and (min-width:768px){#toctitle{font-size:1.375em}
|
||
|
|
body.toc2{padding-left:15em;padding-right:0}
|
||
|
|
#toc.toc2{margin-top:0!important;background-color:#f8f8f7;position:fixed;width:15em;left:0;top:0;border-right:1px solid #e7e7e9;border-top-width:0!important;border-bottom-width:0!important;z-index:1000;padding:1.25em 1em;height:100%;overflow:auto}
|
||
|
|
#toc.toc2 #toctitle{margin-top:0;margin-bottom:.8rem;font-size:1.2em}
|
||
|
|
#toc.toc2>ul{font-size:.9em;margin-bottom:0}
|
||
|
|
#toc.toc2 ul ul{margin-left:0;padding-left:1em}
|
||
|
|
#toc.toc2 ul.sectlevel0 ul.sectlevel1{padding-left:0;margin-top:.5em;margin-bottom:.5em}
|
||
|
|
body.toc2.toc-right{padding-left:0;padding-right:15em}
|
||
|
|
body.toc2.toc-right #toc.toc2{border-right-width:0;border-left:1px solid #e7e7e9;left:auto;right:0}}
|
||
|
|
@media screen and (min-width:1280px){body.toc2{padding-left:20em;padding-right:0}
|
||
|
|
#toc.toc2{width:20em}
|
||
|
|
#toc.toc2 #toctitle{font-size:1.375em}
|
||
|
|
#toc.toc2>ul{font-size:.95em}
|
||
|
|
#toc.toc2 ul ul{padding-left:1.25em}
|
||
|
|
body.toc2.toc-right{padding-left:0;padding-right:20em}}
|
||
|
|
#content #toc{border-style:solid;border-width:1px;border-color:#e0e0dc;margin-bottom:1.25em;padding:1.25em;background:#f8f8f7;-webkit-border-radius:4px;border-radius:4px}
|
||
|
|
#content #toc>:first-child{margin-top:0}
|
||
|
|
#content #toc>:last-child{margin-bottom:0}
|
||
|
|
#footer{max-width:100%;background-color:rgba(0,0,0,.8);padding:1.25em}
|
||
|
|
#footer-text{color:rgba(255,255,255,.8);line-height:1.44}
|
||
|
|
#content{margin-bottom:.625em}
|
||
|
|
.sect1{padding-bottom:.625em}
|
||
|
|
@media screen and (min-width:768px){#content{margin-bottom:1.25em}
|
||
|
|
.sect1{padding-bottom:1.25em}}
|
||
|
|
.sect1:last-child{padding-bottom:0}
|
||
|
|
.sect1+.sect1{border-top:1px solid #e7e7e9}
|
||
|
|
#content h1>a.anchor,h2>a.anchor,h3>a.anchor,#toctitle>a.anchor,.sidebarblock>.content>.title>a.anchor,h4>a.anchor,h5>a.anchor,h6>a.anchor{position:absolute;z-index:1001;width:1.5ex;margin-left:-1.5ex;display:block;text-decoration:none!important;visibility:hidden;text-align:center;font-weight:400}
|
||
|
|
#content h1>a.anchor::before,h2>a.anchor::before,h3>a.anchor::before,#toctitle>a.anchor::before,.sidebarblock>.content>.title>a.anchor::before,h4>a.anchor::before,h5>a.anchor::before,h6>a.anchor::before{content:"\00A7";font-size:.85em;display:block;padding-top:.1em}
|
||
|
|
#content h1:hover>a.anchor,#content h1>a.anchor:hover,h2:hover>a.anchor,h2>a.anchor:hover,h3:hover>a.anchor,#toctitle:hover>a.anchor,.sidebarblock>.content>.title:hover>a.anchor,h3>a.anchor:hover,#toctitle>a.anchor:hover,.sidebarblock>.content>.title>a.anchor:hover,h4:hover>a.anchor,h4>a.anchor:hover,h5:hover>a.anchor,h5>a.anchor:hover,h6:hover>a.anchor,h6>a.anchor:hover{visibility:visible}
|
||
|
|
#content h1>a.link,h2>a.link,h3>a.link,#toctitle>a.link,.sidebarblock>.content>.title>a.link,h4>a.link,h5>a.link,h6>a.link{color:#ba3925;text-decoration:none}
|
||
|
|
#content h1>a.link:hover,h2>a.link:hover,h3>a.link:hover,#toctitle>a.link:hover,.sidebarblock>.content>.title>a.link:hover,h4>a.link:hover,h5>a.link:hover,h6>a.link:hover{color:#a53221}
|
||
|
|
.audioblock,.imageblock,.literalblock,.listingblock,.stemblock,.videoblock{margin-bottom:1.25em}
|
||
|
|
.admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{text-rendering:optimizeLegibility;text-align:left;font-family:"Noto Serif","DejaVu Serif",serif;font-size:1rem;font-style:italic}
|
||
|
|
table.tableblock.fit-content>caption.title{white-space:nowrap;width:0}
|
||
|
|
.paragraph.lead>p,#preamble>.sectionbody>[class="paragraph"]:first-of-type p{font-size:1.21875em;line-height:1.6;color:rgba(0,0,0,.85)}
|
||
|
|
table.tableblock #preamble>.sectionbody>[class="paragraph"]:first-of-type p{font-size:inherit}
|
||
|
|
.admonitionblock>table{border-collapse:separate;border:0;background:none;width:100%}
|
||
|
|
.admonitionblock>table td.icon{text-align:center;width:80px}
|
||
|
|
.admonitionblock>table td.icon img{max-width:none}
|
||
|
|
.admonitionblock>table td.icon .title{font-weight:bold;font-family:"Open Sans","DejaVu Sans",sans-serif;text-transform:uppercase}
|
||
|
|
.admonitionblock>table td.content{padding-left:1.125em;padding-right:1.25em;border-left:1px solid #dddddf;color:rgba(0,0,0,.6)}
|
||
|
|
.admonitionblock>table td.content>:last-child>:last-child{margin-bottom:0}
|
||
|
|
.exampleblock>.content{border-style:solid;border-width:1px;border-color:#e6e6e6;margin-bottom:1.25em;padding:1.25em;background:#fff;-webkit-border-radius:4px;border-radius:4px}
|
||
|
|
.exampleblock>.content>:first-child{margin-top:0}
|
||
|
|
.exampleblock>.content>:last-child{margin-bottom:0}
|
||
|
|
.sidebarblock{border-style:solid;border-width:1px;border-color:#e0e0dc;margin-bottom:1.25em;padding:1.25em;background:#f8f8f7;-webkit-border-radius:4px;border-radius:4px}
|
||
|
|
.sidebarblock>:first-child{margin-top:0}
|
||
|
|
.sidebarblock>:last-child{margin-bottom:0}
|
||
|
|
.sidebarblock>.content>.title{color:#7a2518;margin-top:0;text-align:center}
|
||
|
|
.exampleblock>.content>:last-child>:last-child,.exampleblock>.content .olist>ol>li:last-child>:last-child,.exampleblock>.content .ulist>ul>li:last-child>:last-child,.exampleblock>.content .qlist>ol>li:last-child>:last-child,.sidebarblock>.content>:last-child>:last-child,.sidebarblock>.content .olist>ol>li:last-child>:last-child,.sidebarblock>.content .ulist>ul>li:last-child>:last-child,.sidebarblock>.content .qlist>ol>li:last-child>:last-child{margin-bottom:0}
|
||
|
|
.literalblock pre,.listingblock pre:not(.highlight),.listingblock pre[class="highlight"],.listingblock pre[class^="highlight "],.listingblock pre.CodeRay,.listingblock pre.prettyprint{background:#f7f7f8}
|
||
|
|
.sidebarblock .literalblock pre,.sidebarblock .listingblock pre:not(.highlight),.sidebarblock .listingblock pre[class="highlight"],.sidebarblock .listingblock pre[class^="highlight "],.sidebarblock .listingblock pre.CodeRay,.sidebarblock .listingblock pre.prettyprint{background:#f2f1f1}
|
||
|
|
.literalblock pre,.literalblock pre[class],.listingblock pre,.listingblock pre[class]{-webkit-border-radius:4px;border-radius:4px;word-wrap:break-word;overflow-x:auto;padding:1em;font-size:.8125em}
|
||
|
|
@media screen and (min-width:768px){.literalblock pre,.literalblock pre[class],.listingblock pre,.listingblock pre[class]{font-size:.90625em}}
|
||
|
|
@media screen and (min-width:1280px){.literalblock pre,.literalblock pre[class],.listingblock pre,.listingblock pre[class]{font-size:1em}}
|
||
|
|
.literalblock pre.nowrap,.literalblock pre.nowrap pre,.listingblock pre.nowrap,.listingblock pre.nowrap pre{white-space:pre;word-wrap:normal}
|
||
|
|
.literalblock.output pre{color:#f7f7f8;background-color:rgba(0,0,0,.9)}
|
||
|
|
.listingblock pre.highlightjs{padding:0}
|
||
|
|
.listingblock pre.highlightjs>code{padding:1em;-webkit-border-radius:4px;border-radius:4px}
|
||
|
|
.listingblock pre.prettyprint{border-width:0}
|
||
|
|
.listingblock>.content{position:relative}
|
||
|
|
.listingblock code[data-lang]::before{display:none;content:attr(data-lang);position:absolute;font-size:.75em;top:.425rem;right:.5rem;line-height:1;text-transform:uppercase;color:#999}
|
||
|
|
.listingblock:hover code[data-lang]::before{display:block}
|
||
|
|
.listingblock.terminal pre .command::before{content:attr(data-prompt);padding-right:.5em;color:#999}
|
||
|
|
.listingblock.terminal pre .command:not([data-prompt])::before{content:"$"}
|
||
|
|
table.pyhltable{border-collapse:separate;border:0;margin-bottom:0;background:none}
|
||
|
|
table.pyhltable td{vertical-align:top;padding-top:0;padding-bottom:0;line-height:1.45}
|
||
|
|
table.pyhltable td.code{padding-left:.75em;padding-right:0}
|
||
|
|
pre.pygments .lineno,table.pyhltable td:not(.code){color:#999;padding-left:0;padding-right:.5em;border-right:1px solid #dddddf}
|
||
|
|
pre.pygments .lineno{display:inline-block;margin-right:.25em}
|
||
|
|
table.pyhltable .linenodiv{background:none!important;padding-right:0!important}
|
||
|
|
.quoteblock{margin:0 1em 1.25em 1.5em;display:table}
|
||
|
|
.quoteblock>.title{margin-left:-1.5em;margin-bottom:.75em}
|
||
|
|
.quoteblock blockquote,.quoteblock p{color:rgba(0,0,0,.85);font-size:1.15rem;line-height:1.75;word-spacing:.1em;letter-spacing:0;font-style:italic;text-align:justify}
|
||
|
|
.quoteblock blockquote{margin:0;padding:0;border:0}
|
||
|
|
.quoteblock blockquote::before{content:"\201c";float:left;font-size:2.75em;font-weight:bold;line-height:.6em;margin-left:-.6em;color:#7a2518;text-shadow:0 1px 2px rgba(0,0,0,.1)}
|
||
|
|
.quoteblock blockquote>.paragraph:last-child p{margin-bottom:0}
|
||
|
|
.quoteblock .attribution{margin-top:.75em;margin-right:.5ex;text-align:right}
|
||
|
|
.verseblock{margin:0 1em 1.25em}
|
||
|
|
.verseblock pre{font-family:"Open Sans","DejaVu Sans",sans;font-size:1.15rem;color:rgba(0,0,0,.85);font-weight:300;text-rendering:optimizeLegibility}
|
||
|
|
.verseblock pre strong{font-weight:400}
|
||
|
|
.verseblock .attribution{margin-top:1.25rem;margin-left:.5ex}
|
||
|
|
.quoteblock .attribution,.verseblock .attribution{font-size:.9375em;line-height:1.45;font-style:italic}
|
||
|
|
.quoteblock .attribution br,.verseblock .attribution br{display:none}
|
||
|
|
.quoteblock .attribution cite,.verseblock .attribution cite{display:block;letter-spacing:-.025em;color:rgba(0,0,0,.6)}
|
||
|
|
.quoteblock.abstract blockquote::before,.quoteblock.excerpt blockquote::before,.quoteblock .quoteblock blockquote::before{display:none}
|
||
|
|
.quoteblock.abstract blockquote,.quoteblock.abstract p,.quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{line-height:1.6;word-spacing:0}
|
||
|
|
.quoteblock.abstract{margin:0 1em 1.25em;display:block}
|
||
|
|
.quoteblock.abstract>.title{margin:0 0 .375em;font-size:1.15em;text-align:center}
|
||
|
|
.quoteblock.excerpt,.quoteblock .quoteblock{margin:0 0 1.25em;padding:0 0 .25em 1em;border-left:.25em solid #dddddf}
|
||
|
|
.quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{color:inherit;font-size:1.0625rem}
|
||
|
|
.quoteblock.excerpt .attribution,.quoteblock .quoteblock .attribution{color:inherit;text-align:left;margin-right:0}
|
||
|
|
table.tableblock{max-width:100%;border-collapse:separate}
|
||
|
|
p.tableblock:last-child{margin-bottom:0}
|
||
|
|
td.tableblock>.content{margin-bottom:-1.25em}
|
||
|
|
table.tableblock,th.tableblock,td.tableblock{border:0 solid #dedede}
|
||
|
|
table.grid-all>thead>tr>.tableblock,table.grid-all>tbody>tr>.tableblock{border-width:0 1px 1px 0}
|
||
|
|
table.grid-all>tfoot>tr>.tableblock{border-width:1px 1px 0 0}
|
||
|
|
table.grid-cols>*>tr>.tableblock{border-width:0 1px 0 0}
|
||
|
|
table.grid-rows>thead>tr>.tableblock,table.grid-rows>tbody>tr>.tableblock{border-width:0 0 1px}
|
||
|
|
table.grid-rows>tfoot>tr>.tableblock{border-width:1px 0 0}
|
||
|
|
table.grid-all>*>tr>.tableblock:last-child,table.grid-cols>*>tr>.tableblock:last-child{border-right-width:0}
|
||
|
|
table.grid-all>tbody>tr:last-child>.tableblock,table.grid-all>thead:last-child>tr>.tableblock,table.grid-rows>tbody>tr:last-child>.tableblock,table.grid-rows>thead:last-child>tr>.tableblock{border-bottom-width:0}
|
||
|
|
table.frame-all{border-width:1px}
|
||
|
|
table.frame-sides{border-width:0 1px}
|
||
|
|
table.frame-topbot,table.frame-ends{border-width:1px 0}
|
||
|
|
table.stripes-all tr,table.stripes-odd tr:nth-of-type(odd){background:#f8f8f7}
|
||
|
|
table.stripes-none tr,table.stripes-odd tr:nth-of-type(even){background:none}
|
||
|
|
th.halign-left,td.halign-left{text-align:left}
|
||
|
|
th.halign-right,td.halign-right{text-align:right}
|
||
|
|
th.halign-center,td.halign-center{text-align:center}
|
||
|
|
th.valign-top,td.valign-top{vertical-align:top}
|
||
|
|
th.valign-bottom,td.valign-bottom{vertical-align:bottom}
|
||
|
|
th.valign-middle,td.valign-middle{vertical-align:middle}
|
||
|
|
table thead th,table tfoot th{font-weight:bold}
|
||
|
|
tbody tr th{display:table-cell;line-height:1.6;background:#f7f8f7}
|
||
|
|
tbody tr th,tbody tr th p,tfoot tr th,tfoot tr th p{color:rgba(0,0,0,.8);font-weight:bold}
|
||
|
|
p.tableblock>code:only-child{background:none;padding:0}
|
||
|
|
p.tableblock{font-size:1em}
|
||
|
|
td>div.verse{white-space:pre}
|
||
|
|
ol{margin-left:1.75em}
|
||
|
|
ul li ol{margin-left:1.5em}
|
||
|
|
dl dd{margin-left:1.125em}
|
||
|
|
dl dd:last-child,dl dd:last-child>:last-child{margin-bottom:0}
|
||
|
|
ol>li p,ul>li p,ul dd,ol dd,.olist .olist,.ulist .ulist,.ulist .olist,.olist .ulist{margin-bottom:.625em}
|
||
|
|
ul.checklist,ul.none,ol.none,ul.no-bullet,ol.no-bullet,ol.unnumbered,ul.unstyled,ol.unstyled{list-style-type:none}
|
||
|
|
ul.no-bullet,ol.no-bullet,ol.unnumbered{margin-left:.625em}
|
||
|
|
ul.unstyled,ol.unstyled{margin-left:0}
|
||
|
|
ul.checklist{margin-left:.625em}
|
||
|
|
ul.checklist li>p:first-child>.fa-square-o:first-child,ul.checklist li>p:first-child>.fa-check-square-o:first-child{width:1.25em;font-size:.8em;position:relative;bottom:.125em}
|
||
|
|
ul.checklist li>p:first-child>input[type="checkbox"]:first-child{margin-right:.25em}
|
||
|
|
ul.inline{display:-ms-flexbox;display:-webkit-box;display:flex;-ms-flex-flow:row wrap;-webkit-flex-flow:row wrap;flex-flow:row wrap;list-style:none;margin:0 0 .625em -1.25em}
|
||
|
|
ul.inline>li{margin-left:1.25em}
|
||
|
|
.unstyled dl dt{font-weight:400;font-style:normal}
|
||
|
|
ol.arabic{list-style-type:decimal}
|
||
|
|
ol.decimal{list-style-type:decimal-leading-zero}
|
||
|
|
ol.loweralpha{list-style-type:lower-alpha}
|
||
|
|
ol.upperalpha{list-style-type:upper-alpha}
|
||
|
|
ol.lowerroman{list-style-type:lower-roman}
|
||
|
|
ol.upperroman{list-style-type:upper-roman}
|
||
|
|
ol.lowergreek{list-style-type:lower-greek}
|
||
|
|
.hdlist>table,.colist>table{border:0;background:none}
|
||
|
|
.hdlist>table>tbody>tr,.colist>table>tbody>tr{background:none}
|
||
|
|
td.hdlist1,td.hdlist2{vertical-align:top;padding:0 .625em}
|
||
|
|
td.hdlist1{font-weight:bold;padding-bottom:1.25em}
|
||
|
|
.literalblock+.colist,.listingblock+.colist{margin-top:-.5em}
|
||
|
|
.colist td:not([class]):first-child{padding:.4em .75em 0;line-height:1;vertical-align:top}
|
||
|
|
.colist td:not([class]):first-child img{max-width:none}
|
||
|
|
.colist td:not([class]):last-child{padding:.25em 0}
|
||
|
|
.thumb,.th{line-height:0;display:inline-block;border:solid 4px #fff;-webkit-box-shadow:0 0 0 1px #ddd;box-shadow:0 0 0 1px #ddd}
|
||
|
|
.imageblock.left{margin:.25em .625em 1.25em 0}
|
||
|
|
.imageblock.right{margin:.25em 0 1.25em .625em}
|
||
|
|
.imageblock>.title{margin-bottom:0}
|
||
|
|
.imageblock.thumb,.imageblock.th{border-width:6px}
|
||
|
|
.imageblock.thumb>.title,.imageblock.th>.title{padding:0 .125em}
|
||
|
|
.image.left,.image.right{margin-top:.25em;margin-bottom:.25em;display:inline-block;line-height:0}
|
||
|
|
.image.left{margin-right:.625em}
|
||
|
|
.image.right{margin-left:.625em}
|
||
|
|
a.image{text-decoration:none;display:inline-block}
|
||
|
|
a.image object{pointer-events:none}
|
||
|
|
sup.footnote,sup.footnoteref{font-size:.875em;position:static;vertical-align:super}
|
||
|
|
sup.footnote a,sup.footnoteref a{text-decoration:none}
|
||
|
|
sup.footnote a:active,sup.footnoteref a:active{text-decoration:underline}
|
||
|
|
#footnotes{padding-top:.75em;padding-bottom:.75em;margin-bottom:.625em}
|
||
|
|
#footnotes hr{width:20%;min-width:6.25em;margin:-.25em 0 .75em;border-width:1px 0 0}
|
||
|
|
#footnotes .footnote{padding:0 .375em 0 .225em;line-height:1.3334;font-size:.875em;margin-left:1.2em;margin-bottom:.2em}
|
||
|
|
#footnotes .footnote a:first-of-type{font-weight:bold;text-decoration:none;margin-left:-1.05em}
|
||
|
|
#footnotes .footnote:last-of-type{margin-bottom:0}
|
||
|
|
#content #footnotes{margin-top:-.625em;margin-bottom:0;padding:.75em 0}
|
||
|
|
.gist .file-data>table{border:0;background:#fff;width:100%;margin-bottom:0}
|
||
|
|
.gist .file-data>table td.line-data{width:99%}
|
||
|
|
div.unbreakable{page-break-inside:avoid}
|
||
|
|
.big{font-size:larger}
|
||
|
|
.small{font-size:smaller}
|
||
|
|
.underline{text-decoration:underline}
|
||
|
|
.overline{text-decoration:overline}
|
||
|
|
.line-through{text-decoration:line-through}
|
||
|
|
.aqua{color:#00bfbf}
|
||
|
|
.aqua-background{background-color:#00fafa}
|
||
|
|
.black{color:#000}
|
||
|
|
.black-background{background-color:#000}
|
||
|
|
.blue{color:#0000bf}
|
||
|
|
.blue-background{background-color:#0000fa}
|
||
|
|
.fuchsia{color:#bf00bf}
|
||
|
|
.fuchsia-background{background-color:#fa00fa}
|
||
|
|
.gray{color:#606060}
|
||
|
|
.gray-background{background-color:#7d7d7d}
|
||
|
|
.green{color:#006000}
|
||
|
|
.green-background{background-color:#007d00}
|
||
|
|
.lime{color:#00bf00}
|
||
|
|
.lime-background{background-color:#00fa00}
|
||
|
|
.maroon{color:#600000}
|
||
|
|
.maroon-background{background-color:#7d0000}
|
||
|
|
.navy{color:#000060}
|
||
|
|
.navy-background{background-color:#00007d}
|
||
|
|
.olive{color:#606000}
|
||
|
|
.olive-background{background-color:#7d7d00}
|
||
|
|
.purple{color:#600060}
|
||
|
|
.purple-background{background-color:#7d007d}
|
||
|
|
.red{color:#bf0000}
|
||
|
|
.red-background{background-color:#fa0000}
|
||
|
|
.silver{color:#909090}
|
||
|
|
.silver-background{background-color:#bcbcbc}
|
||
|
|
.teal{color:#006060}
|
||
|
|
.teal-background{background-color:#007d7d}
|
||
|
|
.white{color:#bfbfbf}
|
||
|
|
.white-background{background-color:#fafafa}
|
||
|
|
.yellow{color:#bfbf00}
|
||
|
|
.yellow-background{background-color:#fafa00}
|
||
|
|
span.icon>.fa{cursor:default}
|
||
|
|
a span.icon>.fa{cursor:inherit}
|
||
|
|
.admonitionblock td.icon [class^="fa icon-"]{font-size:2.5em;text-shadow:1px 1px 2px rgba(0,0,0,.5);cursor:default}
|
||
|
|
.admonitionblock td.icon .icon-note::before{content:"\f05a";color:#19407c}
|
||
|
|
.admonitionblock td.icon .icon-tip::before{content:"\f0eb";text-shadow:1px 1px 2px rgba(155,155,0,.8);color:#111}
|
||
|
|
.admonitionblock td.icon .icon-warning::before{content:"\f071";color:#bf6900}
|
||
|
|
.admonitionblock td.icon .icon-caution::before{content:"\f06d";color:#bf3400}
|
||
|
|
.admonitionblock td.icon .icon-important::before{content:"\f06a";color:#bf0000}
|
||
|
|
.conum[data-value]{display:inline-block;color:#fff!important;background-color:rgba(0,0,0,.8);-webkit-border-radius:100px;border-radius:100px;text-align:center;font-size:.75em;width:1.67em;height:1.67em;line-height:1.67em;font-family:"Open Sans","DejaVu Sans",sans-serif;font-style:normal;font-weight:bold}
|
||
|
|
.conum[data-value] *{color:#fff!important}
|
||
|
|
.conum[data-value]+b{display:none}
|
||
|
|
.conum[data-value]::after{content:attr(data-value)}
|
||
|
|
pre .conum[data-value]{position:relative;top:-.125em}
|
||
|
|
b.conum *{color:inherit!important}
|
||
|
|
.conum:not([data-value]):empty{display:none}
|
||
|
|
dt,th.tableblock,td.content,div.footnote{text-rendering:optimizeLegibility}
|
||
|
|
h1,h2,p,td.content,span.alt{letter-spacing:-.01em}
|
||
|
|
p strong,td.content strong,div.footnote strong{letter-spacing:-.005em}
|
||
|
|
p,blockquote,dt,td.content,span.alt{font-size:1.0625rem}
|
||
|
|
p{margin-bottom:1.25rem}
|
||
|
|
.sidebarblock p,.sidebarblock dt,.sidebarblock td.content,p.tableblock{font-size:1em}
|
||
|
|
.exampleblock>.content{background-color:#fffef7;border-color:#e0e0dc;-webkit-box-shadow:0 1px 4px #e0e0dc;box-shadow:0 1px 4px #e0e0dc}
|
||
|
|
.print-only{display:none!important}
|
||
|
|
@page{margin:1.25cm .75cm}
|
||
|
|
@media print{*{-webkit-box-shadow:none!important;box-shadow:none!important;text-shadow:none!important}
|
||
|
|
html{font-size:80%}
|
||
|
|
a{color:inherit!important;text-decoration:underline!important}
|
||
|
|
a.bare,a[href^="#"],a[href^="mailto:"]{text-decoration:none!important}
|
||
|
|
a[href^="http:"]:not(.bare)::after,a[href^="https:"]:not(.bare)::after{content:"(" attr(href) ")";display:inline-block;font-size:.875em;padding-left:.25em}
|
||
|
|
abbr[title]::after{content:" (" attr(title) ")"}
|
||
|
|
pre,blockquote,tr,img,object,svg{page-break-inside:avoid}
|
||
|
|
thead{display:table-header-group}
|
||
|
|
svg{max-width:100%}
|
||
|
|
p,blockquote,dt,td.content{font-size:1em;orphans:3;widows:3}
|
||
|
|
h2,h3,#toctitle,.sidebarblock>.content>.title{page-break-after:avoid}
|
||
|
|
#toc,.sidebarblock,.exampleblock>.content{background:none!important}
|
||
|
|
#toc{border-bottom:1px solid #dddddf!important;padding-bottom:0!important}
|
||
|
|
body.book #header{text-align:center}
|
||
|
|
body.book #header>h1:first-child{border:0!important;margin:2.5em 0 1em}
|
||
|
|
body.book #header .details{border:0!important;display:block;padding:0!important}
|
||
|
|
body.book #header .details span:first-child{margin-left:0!important}
|
||
|
|
body.book #header .details br{display:block}
|
||
|
|
body.book #header .details br+span::before{content:none!important}
|
||
|
|
body.book #toc{border:0!important;text-align:left!important;padding:0!important;margin:0!important}
|
||
|
|
body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-break-before:always}
|
||
|
|
.listingblock code[data-lang]::before{display:block}
|
||
|
|
#footer{padding:0 .9375em}
|
||
|
|
.hide-on-print{display:none!important}
|
||
|
|
.print-only{display:block!important}
|
||
|
|
.hide-for-print{display:none!important}
|
||
|
|
.show-for-print{display:inherit!important}}
|
||
|
|
@media print,amzn-kf8{#header>h1:first-child{margin-top:1.25rem}
|
||
|
|
.sect1{padding:0!important}
|
||
|
|
.sect1+.sect1{border:0}
|
||
|
|
#footer{background:none}
|
||
|
|
#footer-text{color:rgba(0,0,0,.6);font-size:.9em}}
|
||
|
|
@media amzn-kf8{#header,#content,#footnotes,#footer{padding:0}}
|
||
|
|
</style>
|
||
|
|
</head>
|
||
|
|
<body class="article">
|
||
|
|
<div id="header">
|
||
|
|
<h1>Git hash function transition</h1>
|
||
|
|
</div>
|
||
|
|
<div id="content">
|
||
|
|
<div class="sect1">
|
||
|
|
<h2 id="_objective">Objective</h2>
|
||
|
|
<div class="sectionbody">
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Migrate Git from SHA-1 to a stronger hash function.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect1">
|
||
|
|
<h2 id="_background">Background</h2>
|
||
|
|
<div class="sectionbody">
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>At its core, the Git version control system is a content addressable
|
||
|
|
filesystem. It uses the SHA-1 hash function to name content. For
|
||
|
|
example, files, directories, and revisions are referred to by hash
|
||
|
|
values unlike in other traditional version control systems where files
|
||
|
|
or versions are referred to via sequential numbers. The use of a hash
|
||
|
|
function to address its content delivers a few advantages:</p>
|
||
|
|
</div>
|
||
|
|
<div class="ulist">
|
||
|
|
<ul>
|
||
|
|
<li>
|
||
|
|
<p>Integrity checking is easy. Bit flips, for example, are easily
|
||
|
|
detected, as the hash of corrupted content does not match its name.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Lookup of objects is fast.</p>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Using a cryptographically secure hash function brings additional
|
||
|
|
advantages:</p>
|
||
|
|
</div>
|
||
|
|
<div class="ulist">
|
||
|
|
<ul>
|
||
|
|
<li>
|
||
|
|
<p>Object names can be signed and third parties can trust the hash to
|
||
|
|
address the signed object and all objects it references.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Communication using Git protocol and out of band communication
|
||
|
|
methods have a short reliable string that can be used to reliably
|
||
|
|
address stored content.</p>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Over time some flaws in SHA-1 have been discovered by security
|
||
|
|
researchers. On 23 February 2017 the SHAttered attack
|
||
|
|
(<a href="https://shattered.io" class="bare">https://shattered.io</a>) demonstrated a practical SHA-1 hash collision.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Git v2.13.0 and later subsequently moved to a hardened SHA-1
|
||
|
|
implementation by default, which isn’t vulnerable to the SHAttered
|
||
|
|
attack.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Thus Git has in effect already migrated to a new hash that isn’t SHA-1
|
||
|
|
and doesn’t share its vulnerabilities, its new hash function just
|
||
|
|
happens to produce exactly the same output for all known inputs,
|
||
|
|
except two PDFs published by the SHAttered researchers, and the new
|
||
|
|
implementation (written by those researchers) claims to detect future
|
||
|
|
cryptanalytic collision attacks.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Regardless, it’s considered prudent to move past any variant of SHA-1
|
||
|
|
to a new hash. There’s no guarantee that future attacks on SHA-1 won’t
|
||
|
|
be published in the future, and those attacks may not have viable
|
||
|
|
mitigations.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>If SHA-1 and its variants were to be truly broken, Git’s hash function
|
||
|
|
could not be considered cryptographically secure any more. This would
|
||
|
|
impact the communication of hash values because we could not trust
|
||
|
|
that a given hash value represented the known good version of content
|
||
|
|
that the speaker intended.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>SHA-1 still possesses the other properties such as fast object lookup
|
||
|
|
and safe error checking, but other hash functions are equally suitable
|
||
|
|
that are believed to be cryptographically secure.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect1">
|
||
|
|
<h2 id="_goals">Goals</h2>
|
||
|
|
<div class="sectionbody">
|
||
|
|
<div class="olist arabic">
|
||
|
|
<ol class="arabic">
|
||
|
|
<li>
|
||
|
|
<p>The transition to SHA-256 can be done one local repository at a time.</p>
|
||
|
|
<div class="olist loweralpha">
|
||
|
|
<ol class="loweralpha">
|
||
|
|
<li>
|
||
|
|
<p>Requiring no action by any other party.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>A SHA-256 repository can communicate with SHA-1 Git servers
|
||
|
|
(push/fetch).</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Users can use SHA-1 and SHA-256 identifiers for objects
|
||
|
|
interchangeably (see "Object names on the command line", below).</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>New signed objects make use of a stronger hash function than
|
||
|
|
SHA-1 for their security guarantees.</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Allow a complete transition away from SHA-1.</p>
|
||
|
|
<div class="olist loweralpha">
|
||
|
|
<ol class="loweralpha">
|
||
|
|
<li>
|
||
|
|
<p>Local metadata for SHA-1 compatibility can be removed from a
|
||
|
|
repository if compatibility with SHA-1 is no longer needed.</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Maintainability throughout the process.</p>
|
||
|
|
<div class="olist loweralpha">
|
||
|
|
<ol class="loweralpha">
|
||
|
|
<li>
|
||
|
|
<p>The object format is kept simple and consistent.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Creation of a generalized repository conversion tool.</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect1">
|
||
|
|
<h2 id="_non_goals">Non-Goals</h2>
|
||
|
|
<div class="sectionbody">
|
||
|
|
<div class="olist arabic">
|
||
|
|
<ol class="arabic">
|
||
|
|
<li>
|
||
|
|
<p>Add SHA-256 support to Git protocol. This is valuable and the
|
||
|
|
logical next step but it is out of scope for this initial design.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Transparently improving the security of existing SHA-1 signed
|
||
|
|
objects.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Intermixing objects using multiple hash functions in a single
|
||
|
|
repository.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Taking the opportunity to fix other bugs in Git’s formats and
|
||
|
|
protocols.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Shallow clones and fetches into a SHA-256 repository. (This will
|
||
|
|
change when we add SHA-256 support to Git protocol.)</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Skip fetching some submodules of a project into a SHA-256
|
||
|
|
repository. (This also depends on SHA-256 support in Git
|
||
|
|
protocol.)</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect1">
|
||
|
|
<h2 id="_overview">Overview</h2>
|
||
|
|
<div class="sectionbody">
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>We introduce a new repository format extension. Repositories with this
|
||
|
|
extension enabled use SHA-256 instead of SHA-1 to name their objects.
|
||
|
|
This affects both object names and object content --- both the names
|
||
|
|
of objects and all references to other objects within an object are
|
||
|
|
switched to the new hash function.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>SHA-256 repositories cannot be read by older versions of Git.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Alongside the packfile, a SHA-256 repository stores a bidirectional
|
||
|
|
mapping between SHA-256 and SHA-1 object names. The mapping is generated
|
||
|
|
locally and can be verified using "git fsck". Object lookups use this
|
||
|
|
mapping to allow naming objects using either their SHA-1 and SHA-256 names
|
||
|
|
interchangeably.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>"git cat-file" and "git hash-object" gain options to display an object
|
||
|
|
in its sha1 form and write an object given its sha1 form. This
|
||
|
|
requires all objects referenced by that object to be present in the
|
||
|
|
object database so that they can be named using the appropriate name
|
||
|
|
(using the bidirectional hash mapping).</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Fetches from a SHA-1 based server convert the fetched objects into
|
||
|
|
SHA-256 form and record the mapping in the bidirectional mapping table
|
||
|
|
(see below for details). Pushes to a SHA-1 based server convert the
|
||
|
|
objects being pushed into sha1 form so the server does not have to be
|
||
|
|
aware of the hash function the client is using.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect1">
|
||
|
|
<h2 id="_detailed_design">Detailed Design</h2>
|
||
|
|
<div class="sectionbody">
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_repository_format_extension">Repository format extension</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>A SHA-256 repository uses repository format version <code>1</code> (see
|
||
|
|
Documentation/technical/repository-version.txt) with extensions
|
||
|
|
<code>objectFormat</code> and <code>compatObjectFormat</code>:</p>
|
||
|
|
</div>
|
||
|
|
<div class="literalblock">
|
||
|
|
<div class="content">
|
||
|
|
<pre>[core]
|
||
|
|
repositoryFormatVersion = 1
|
||
|
|
[extensions]
|
||
|
|
objectFormat = sha256
|
||
|
|
compatObjectFormat = sha1</pre>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The combination of setting <code>core.repositoryFormatVersion=1</code> and
|
||
|
|
populating <code>extensions.*</code> ensures that all versions of Git later than
|
||
|
|
<code>v0.99.9l</code> will die instead of trying to operate on the SHA-256
|
||
|
|
repository, instead producing an error message.</p>
|
||
|
|
</div>
|
||
|
|
<div class="literalblock">
|
||
|
|
<div class="content">
|
||
|
|
<pre># Between v0.99.9l and v2.7.0
|
||
|
|
$ git status
|
||
|
|
fatal: Expected git repo version <= 0, found 1
|
||
|
|
# After v2.7.0
|
||
|
|
$ git status
|
||
|
|
fatal: unknown repository extensions found:
|
||
|
|
objectformat
|
||
|
|
compatobjectformat</pre>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>See the "Transition plan" section below for more details on these
|
||
|
|
repository extensions.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_object_names">Object names</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Objects can be named by their 40 hexadecimal digit sha1-name or 64
|
||
|
|
hexadecimal digit sha256-name, plus names derived from those (see
|
||
|
|
gitrevisions(7)).</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The sha1-name of an object is the SHA-1 of the concatenation of its
|
||
|
|
type, length, a nul byte, and the object’s sha1-content. This is the
|
||
|
|
traditional <sha1> used in Git to name objects.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The sha256-name of an object is the SHA-256 of the concatenation of its
|
||
|
|
type, length, a nul byte, and the object’s sha256-content.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_object_format">Object format</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The content as a byte sequence of a tag, commit, or tree object named
|
||
|
|
by sha1 and sha256 differ because an object named by sha256-name refers to
|
||
|
|
other objects by their sha256-names and an object named by sha1-name
|
||
|
|
refers to other objects by their sha1-names.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The sha256-content of an object is the same as its sha1-content, except
|
||
|
|
that objects referenced by the object are named using their sha256-names
|
||
|
|
instead of sha1-names. Because a blob object does not refer to any
|
||
|
|
other object, its sha1-content and sha256-content are the same.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The format allows round-trip conversion between sha256-content and
|
||
|
|
sha1-content.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_object_storage">Object storage</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Loose objects use zlib compression and packed objects use the packed
|
||
|
|
format described in Documentation/technical/pack-format.txt, just like
|
||
|
|
today. The content that is compressed and stored uses sha256-content
|
||
|
|
instead of sha1-content.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_pack_index">Pack index</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Pack index (.idx) files use a new v3 format that supports multiple
|
||
|
|
hash functions. They have the following format (all integers are in
|
||
|
|
network byte order):</p>
|
||
|
|
</div>
|
||
|
|
<div class="ulist">
|
||
|
|
<ul>
|
||
|
|
<li>
|
||
|
|
<p>A header appears at the beginning and consists of the following:</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>The 4-byte pack index signature: <em>\377t0c</em></p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>4-byte version number: 3</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>4-byte length of the header section, including the signature and
|
||
|
|
version number</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>4-byte number of objects contained in the pack</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>4-byte number of object formats in this pack index: 2</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>For each object format:</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>4-byte format identifier (e.g., <em>sha1</em> for SHA-1)</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>4-byte length in bytes of shortened object names. This is the
|
||
|
|
shortest possible length needed to make names in the shortened
|
||
|
|
object name table unambiguous.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>4-byte integer, recording where tables relating to this format
|
||
|
|
are stored in this index file, as an offset from the beginning.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>4-byte offset to the trailer from the beginning of this file.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Zero or more additional key/value pairs (4-byte key, 4-byte
|
||
|
|
value). Only one key is supported: <em>PSRC</em>. See the "Loose objects
|
||
|
|
and unreachable objects" section for supported values and how this
|
||
|
|
is used. All other keys are reserved. Readers must ignore
|
||
|
|
unrecognized keys.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Zero or more NUL bytes. This can optionally be used to improve the
|
||
|
|
alignment of the full object name table below.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Tables for the first object format:</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>A sorted table of shortened object names. These are prefixes of
|
||
|
|
the names of all objects in this pack file, packed together
|
||
|
|
without offset values to reduce the cache footprint of the binary
|
||
|
|
search for a specific object name.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>A table of full object names in pack order. This allows resolving
|
||
|
|
a reference to "the nth object in the pack file" (from a
|
||
|
|
reachability bitmap or from the next table of another object
|
||
|
|
format) to its object name.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>A table of 4-byte values mapping object name order to pack order.
|
||
|
|
For an object in the table of sorted shortened object names, the
|
||
|
|
value at the corresponding index in this table is the index in the
|
||
|
|
previous table for that same object.</p>
|
||
|
|
<div class="literalblock">
|
||
|
|
<div class="content">
|
||
|
|
<pre>This can be used to look up the object in reachability bitmaps or
|
||
|
|
to look up its name in another object format.</pre>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>A table of 4-byte CRC32 values of the packed object data, in the
|
||
|
|
order that the objects appear in the pack file. This is to allow
|
||
|
|
compressed data to be copied directly from pack to pack during
|
||
|
|
repacking without undetected data corruption.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>A table of 4-byte offset values. For an object in the table of
|
||
|
|
sorted shortened object names, the value at the corresponding
|
||
|
|
index in this table indicates where that object can be found in
|
||
|
|
the pack file. These are usually 31-bit pack file offsets, but
|
||
|
|
large offsets are encoded as an index into the next table with the
|
||
|
|
most significant bit set.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>A table of 8-byte offset entries (empty for pack files less than
|
||
|
|
2 GiB). Pack files are organized with heavily used objects toward
|
||
|
|
the front, so most object references should not need to refer to
|
||
|
|
this table.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Zero or more NUL bytes.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Tables for the second object format, with the same layout as above,
|
||
|
|
up to and not including the table of CRC32 values.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Zero or more NUL bytes.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>The trailer consists of the following:</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>A copy of the 20-byte SHA-256 checksum at the end of the
|
||
|
|
corresponding packfile.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>20-byte SHA-256 checksum of all of the above.</p>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_loose_object_index">Loose object index</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>A new file $GIT_OBJECT_DIR/loose-object-idx contains information about
|
||
|
|
all loose objects. Its format is</p>
|
||
|
|
</div>
|
||
|
|
<div class="literalblock">
|
||
|
|
<div class="content">
|
||
|
|
<pre># loose-object-idx
|
||
|
|
(sha256-name SP sha1-name LF)*</pre>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>where the object names are in hexadecimal format. The file is not
|
||
|
|
sorted.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The loose object index is protected against concurrent writes by a
|
||
|
|
lock file $GIT_OBJECT_DIR/loose-object-idx.lock. To add a new loose
|
||
|
|
object:</p>
|
||
|
|
</div>
|
||
|
|
<div class="olist arabic">
|
||
|
|
<ol class="arabic">
|
||
|
|
<li>
|
||
|
|
<p>Write the loose object to a temporary file, like today.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Open loose-object-idx.lock with O_CREAT | O_EXCL to acquire the lock.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Rename the loose object into place.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Open loose-object-idx with O_APPEND and write the new object</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Unlink loose-object-idx.lock to release the lock.</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>To remove entries (e.g. in "git pack-refs" or "git-prune"):</p>
|
||
|
|
</div>
|
||
|
|
<div class="olist arabic">
|
||
|
|
<ol class="arabic">
|
||
|
|
<li>
|
||
|
|
<p>Open loose-object-idx.lock with O_CREAT | O_EXCL to acquire the
|
||
|
|
lock.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Write the new content to loose-object-idx.lock.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Unlink any loose objects being removed.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Rename to replace loose-object-idx, releasing the lock.</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_translation_table">Translation table</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The index files support a bidirectional mapping between sha1-names
|
||
|
|
and sha256-names. The lookup proceeds similarly to ordinary object
|
||
|
|
lookups. For example, to convert a sha1-name to a sha256-name:</p>
|
||
|
|
</div>
|
||
|
|
<div class="olist arabic">
|
||
|
|
<ol class="arabic">
|
||
|
|
<li>
|
||
|
|
<p>Look for the object in idx files. If a match is present in the
|
||
|
|
idx’s sorted list of truncated sha1-names, then:</p>
|
||
|
|
<div class="olist loweralpha">
|
||
|
|
<ol class="loweralpha">
|
||
|
|
<li>
|
||
|
|
<p>Read the corresponding entry in the sha1-name order to pack
|
||
|
|
name order mapping.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Read the corresponding entry in the full sha1-name table to
|
||
|
|
verify we found the right object. If it is, then</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Read the corresponding entry in the full sha256-name table.
|
||
|
|
That is the object’s sha256-name.</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>Check for a loose object. Read lines from loose-object-idx until
|
||
|
|
we find a match.</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Step (1) takes the same amount of time as an ordinary object lookup:
|
||
|
|
O(number of packs * log(objects per pack)). Step (2) takes O(number of
|
||
|
|
loose objects) time. To maintain good performance it will be necessary
|
||
|
|
to keep the number of loose objects low. See the "Loose objects and
|
||
|
|
unreachable objects" section below for more details.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Since all operations that make new objects (e.g., "git commit") add
|
||
|
|
the new objects to the corresponding index, this mapping is possible
|
||
|
|
for all objects in the object store.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_reading_an_objects_sha1_content">Reading an object’s sha1-content</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The sha1-content of an object can be read by converting all sha256-names
|
||
|
|
its sha256-content references to sha1-names using the translation table.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_fetch">Fetch</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Fetching from a SHA-1 based server requires translating between SHA-1
|
||
|
|
and SHA-256 based representations on the fly.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>SHA-1s named in the ref advertisement that are present on the client
|
||
|
|
can be translated to SHA-256 and looked up as local objects using the
|
||
|
|
translation table.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Negotiation proceeds as today. Any "have"s generated locally are
|
||
|
|
converted to SHA-1 before being sent to the server, and SHA-1s
|
||
|
|
mentioned by the server are converted to SHA-256 when looking them up
|
||
|
|
locally.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>After negotiation, the server sends a packfile containing the
|
||
|
|
requested objects. We convert the packfile to SHA-256 format using
|
||
|
|
the following steps:</p>
|
||
|
|
</div>
|
||
|
|
<div class="olist arabic">
|
||
|
|
<ol class="arabic">
|
||
|
|
<li>
|
||
|
|
<p>index-pack: inflate each object in the packfile and compute its
|
||
|
|
SHA-1. Objects can contain deltas in OBJ_REF_DELTA format against
|
||
|
|
objects the client has locally. These objects can be looked up
|
||
|
|
using the translation table and their sha1-content read as
|
||
|
|
described above to resolve the deltas.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>topological sort: starting at the "want"s from the negotiation
|
||
|
|
phase, walk through objects in the pack and emit a list of them,
|
||
|
|
excluding blobs, in reverse topologically sorted order, with each
|
||
|
|
object coming later in the list than all objects it references.
|
||
|
|
(This list only contains objects reachable from the "wants". If the
|
||
|
|
pack from the server contained additional extraneous objects, then
|
||
|
|
they will be discarded.)</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>convert to sha256: open a new (sha256) packfile. Read the topologically
|
||
|
|
sorted list just generated. For each object, inflate its
|
||
|
|
sha1-content, convert to sha256-content, and write it to the sha256
|
||
|
|
pack. Record the new sha1<→sha256 mapping entry for use in the idx.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>sort: reorder entries in the new pack to match the order of objects
|
||
|
|
in the pack the server generated and include blobs. Write a sha256 idx
|
||
|
|
file</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>clean up: remove the SHA-1 based pack file, index, and
|
||
|
|
topologically sorted list obtained from the server in steps 1
|
||
|
|
and 2.</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Step 3 requires every object referenced by the new object to be in the
|
||
|
|
translation table. This is why the topological sort step is necessary.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>As an optimization, step 1 could write a file describing what non-blob
|
||
|
|
objects each object it has inflated from the packfile references. This
|
||
|
|
makes the topological sort in step 2 possible without inflating the
|
||
|
|
objects in the packfile for a second time. The objects need to be
|
||
|
|
inflated again in step 3, for a total of two inflations.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Step 4 is probably necessary for good read-time performance. "git
|
||
|
|
pack-objects" on the server optimizes the pack file for good data
|
||
|
|
locality (see Documentation/technical/pack-heuristics.txt).</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Details of this process are likely to change. It will take some
|
||
|
|
experimenting to get this to perform well.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_push">Push</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Push is simpler than fetch because the objects referenced by the
|
||
|
|
pushed objects are already in the translation table. The sha1-content
|
||
|
|
of each object being pushed can be read as described in the "Reading
|
||
|
|
an object’s sha1-content" section to generate the pack written by git
|
||
|
|
send-pack.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_signed_commits">Signed Commits</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>We add a new field "gpgsig-sha256" to the commit object format to allow
|
||
|
|
signing commits without relying on SHA-1. It is similar to the
|
||
|
|
existing "gpgsig" field. Its signed payload is the sha256-content of the
|
||
|
|
commit object with any "gpgsig" and "gpgsig-sha256" fields removed.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>This means commits can be signed
|
||
|
|
1. using SHA-1 only, as in existing signed commit objects
|
||
|
|
2. using both SHA-1 and SHA-256, by using both gpgsig-sha256 and gpgsig
|
||
|
|
fields.
|
||
|
|
3. using only SHA-256, by only using the gpgsig-sha256 field.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Old versions of "git verify-commit" can verify the gpgsig signature in
|
||
|
|
cases (1) and (2) without modifications and view case (3) as an
|
||
|
|
ordinary unsigned commit.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_signed_tags">Signed Tags</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>We add a new field "gpgsig-sha256" to the tag object format to allow
|
||
|
|
signing tags without relying on SHA-1. Its signed payload is the
|
||
|
|
sha256-content of the tag with its gpgsig-sha256 field and "-----BEGIN PGP
|
||
|
|
SIGNATURE-----" delimited in-body signature removed.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>This means tags can be signed
|
||
|
|
1. using SHA-1 only, as in existing signed tag objects
|
||
|
|
2. using both SHA-1 and SHA-256, by using gpgsig-sha256 and an in-body
|
||
|
|
signature.
|
||
|
|
3. using only SHA-256, by only using the gpgsig-sha256 field.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_mergetag_embedding">Mergetag embedding</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The mergetag field in the sha1-content of a commit contains the
|
||
|
|
sha1-content of a tag that was merged by that commit.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The mergetag field in the sha256-content of the same commit contains the
|
||
|
|
sha256-content of the same tag.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_submodules">Submodules</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>To convert recorded submodule pointers, you need to have the converted
|
||
|
|
submodule repository in place. The translation table of the submodule
|
||
|
|
can be used to look up the new hash.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_loose_objects_and_unreachable_objects">Loose objects and unreachable objects</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Fast lookups in the loose-object-idx require that the number of loose
|
||
|
|
objects not grow too high.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>"git gc --auto" currently waits for there to be 6700 loose objects
|
||
|
|
present before consolidating them into a packfile. We will need to
|
||
|
|
measure to find a more appropriate threshold for it to use.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>"git gc --auto" currently waits for there to be 50 packs present
|
||
|
|
before combining packfiles. Packing loose objects more aggressively
|
||
|
|
may cause the number of pack files to grow too quickly. This can be
|
||
|
|
mitigated by using a strategy similar to Martin Fick’s exponential
|
||
|
|
rolling garbage collection script:
|
||
|
|
<a href="https://gerrit-review.googlesource.com/c/gerrit/+/35215" class="bare">https://gerrit-review.googlesource.com/c/gerrit/+/35215</a></p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>"git gc" currently expels any unreachable objects it encounters in
|
||
|
|
pack files to loose objects in an attempt to prevent a race when
|
||
|
|
pruning them (in case another process is simultaneously writing a new
|
||
|
|
object that refers to the about-to-be-deleted object). This leads to
|
||
|
|
an explosion in the number of loose objects present and disk space
|
||
|
|
usage due to the objects in delta form being replaced with independent
|
||
|
|
loose objects. Worse, the race is still present for loose objects.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Instead, "git gc" will need to move unreachable objects to a new
|
||
|
|
packfile marked as UNREACHABLE_GARBAGE (using the PSRC field; see
|
||
|
|
below). To avoid the race when writing new objects referring to an
|
||
|
|
about-to-be-deleted object, code paths that write new objects will
|
||
|
|
need to copy any objects from UNREACHABLE_GARBAGE packs that they
|
||
|
|
refer to to new, non-UNREACHABLE_GARBAGE packs (or loose objects).
|
||
|
|
UNREACHABLE_GARBAGE are then safe to delete if their creation time (as
|
||
|
|
indicated by the file’s mtime) is long enough ago.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>To avoid a proliferation of UNREACHABLE_GARBAGE packs, they can be
|
||
|
|
combined under certain circumstances. If "gc.garbageTtl" is set to
|
||
|
|
greater than one day, then packs created within a single calendar day,
|
||
|
|
UTC, can be coalesced together. The resulting packfile would have an
|
||
|
|
mtime before midnight on that day, so this makes the effective maximum
|
||
|
|
ttl the garbageTtl + 1 day. If "gc.garbageTtl" is less than one day,
|
||
|
|
then we divide the calendar day into intervals one-third of that ttl
|
||
|
|
in duration. Packs created within the same interval can be coalesced
|
||
|
|
together. The resulting packfile would have an mtime before the end of
|
||
|
|
the interval, so this makes the effective maximum ttl equal to the
|
||
|
|
garbageTtl * 4/3.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>This rule comes from Thirumala Reddy Mutchukota’s JGit change
|
||
|
|
<a href="https://git.eclipse.org/r/90465" class="bare">https://git.eclipse.org/r/90465</a>.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The UNREACHABLE_GARBAGE setting goes in the PSRC field of the pack
|
||
|
|
index. More generally, that field indicates where a pack came from:</p>
|
||
|
|
</div>
|
||
|
|
<div class="ulist">
|
||
|
|
<ul>
|
||
|
|
<li>
|
||
|
|
<p>1 (PACK_SOURCE_RECEIVE) for a pack received over the network</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>2 (PACK_SOURCE_AUTO) for a pack created by a lightweight
|
||
|
|
"gc --auto" operation</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>3 (PACK_SOURCE_GC) for a pack created by a full gc</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>4 (PACK_SOURCE_UNREACHABLE_GARBAGE) for potential garbage
|
||
|
|
discovered by gc</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>5 (PACK_SOURCE_INSERT) for locally created objects that were
|
||
|
|
written directly to a pack file, e.g. from "git add ."</p>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>This information can be useful for debugging and for "gc --auto" to
|
||
|
|
make appropriate choices about which packs to coalesce.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect1">
|
||
|
|
<h2 id="_caveats">Caveats</h2>
|
||
|
|
<div class="sectionbody">
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_invalid_objects">Invalid objects</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The conversion from sha1-content to sha256-content retains any
|
||
|
|
brokenness in the original object (e.g., tree entry modes encoded with
|
||
|
|
leading 0, tree objects whose paths are not sorted correctly, and
|
||
|
|
commit objects without an author or committer). This is a deliberate
|
||
|
|
feature of the design to allow the conversion to round-trip.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>More profoundly broken objects (e.g., a commit with a truncated "tree"
|
||
|
|
header line) cannot be converted but were not usable by current Git
|
||
|
|
anyway.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_shallow_clone_and_submodules">Shallow clone and submodules</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Because it requires all referenced objects to be available in the
|
||
|
|
locally generated translation table, this design does not support
|
||
|
|
shallow clone or unfetched submodules. Protocol improvements might
|
||
|
|
allow lifting this restriction.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_alternates">Alternates</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>For the same reason, a sha256 repository cannot borrow objects from a
|
||
|
|
sha1 repository using objects/info/alternates or
|
||
|
|
$GIT_ALTERNATE_OBJECT_REPOSITORIES.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_git_notes">git notes</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The "git notes" tool annotates objects using their sha1-name as key.
|
||
|
|
This design does not describe a way to migrate notes trees to use
|
||
|
|
sha256-names. That migration is expected to happen separately (for
|
||
|
|
example using a file at the root of the notes tree to describe which
|
||
|
|
hash it uses).</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_server_side_cost">Server-side cost</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Until Git protocol gains SHA-256 support, using SHA-256 based storage
|
||
|
|
on public-facing Git servers is strongly discouraged. Once Git
|
||
|
|
protocol gains SHA-256 support, SHA-256 based servers are likely not
|
||
|
|
to support SHA-1 compatibility, to avoid what may be a very expensive
|
||
|
|
hash reencode during clone and to encourage peers to modernize.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The design described here allows fetches by SHA-1 clients of a
|
||
|
|
personal SHA-256 repository because it’s not much more difficult than
|
||
|
|
allowing pushes from that repository. This support needs to be guarded
|
||
|
|
by a configuration option --- servers like git.kernel.org that serve a
|
||
|
|
large number of clients would not be expected to bear that cost.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_meaning_of_signatures">Meaning of signatures</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The signed payload for signed commits and tags does not explicitly
|
||
|
|
name the hash used to identify objects. If some day Git adopts a new
|
||
|
|
hash function with the same length as the current SHA-1 (40
|
||
|
|
hexadecimal digit) or SHA-256 (64 hexadecimal digit) objects then the
|
||
|
|
intent behind the PGP signed payload in an object signature is
|
||
|
|
unclear:</p>
|
||
|
|
</div>
|
||
|
|
<div class="literalblock">
|
||
|
|
<div class="content">
|
||
|
|
<pre>object e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7
|
||
|
|
type commit
|
||
|
|
tag v2.12.0
|
||
|
|
tagger Junio C Hamano <gitster@pobox.com> 1487962205 -0800</pre>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="literalblock">
|
||
|
|
<div class="content">
|
||
|
|
<pre>Git 2.12</pre>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Does this mean Git v2.12.0 is the commit with sha1-name
|
||
|
|
e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7 or the commit with
|
||
|
|
new-40-digit-hash-name e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7?</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Fortunately SHA-256 and SHA-1 have different lengths. If Git starts
|
||
|
|
using another hash with the same length to name objects, then it will
|
||
|
|
need to change the format of signed payloads using that hash to
|
||
|
|
address this issue.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_object_names_on_the_command_line">Object names on the command line</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>To support the transition (see Transition plan below), this design
|
||
|
|
supports four different modes of operation:</p>
|
||
|
|
</div>
|
||
|
|
<div class="olist arabic">
|
||
|
|
<ol class="arabic">
|
||
|
|
<li>
|
||
|
|
<p>("dark launch") Treat object names input by the user as SHA-1 and
|
||
|
|
convert any object names written to output to SHA-1, but store
|
||
|
|
objects using SHA-256. This allows users to test the code with no
|
||
|
|
visible behavior change except for performance. This allows
|
||
|
|
allows running even tests that assume the SHA-1 hash function, to
|
||
|
|
sanity-check the behavior of the new mode.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>("early transition") Allow both SHA-1 and SHA-256 object names in
|
||
|
|
input. Any object names written to output use SHA-1. This allows
|
||
|
|
users to continue to make use of SHA-1 to communicate with peers
|
||
|
|
(e.g. by email) that have not migrated yet and prepares for mode 3.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>("late transition") Allow both SHA-1 and SHA-256 object names in
|
||
|
|
input. Any object names written to output use SHA-256. In this
|
||
|
|
mode, users are using a more secure object naming method by
|
||
|
|
default. The disruption is minimal as long as most of their peers
|
||
|
|
are in mode 2 or mode 3.</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>("post-transition") Treat object names input by the user as
|
||
|
|
SHA-256 and write output using SHA-256. This is safer than mode 3
|
||
|
|
because there is less risk that input is incorrectly interpreted
|
||
|
|
using the wrong hash function.</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The mode is specified in configuration.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The user can also explicitly specify which format to use for a
|
||
|
|
particular revision specifier and for output, overriding the mode. For
|
||
|
|
example:</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>git --output-format=sha1 log abac87a<sup>{sha1}..f787cac</sup>{sha256}</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect1">
|
||
|
|
<h2 id="_choice_of_hash">Choice of Hash</h2>
|
||
|
|
<div class="sectionbody">
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>In early 2005, around the time that Git was written, Xiaoyun Wang,
|
||
|
|
Yiqun Lisa Yin, and Hongbo Yu announced an attack finding SHA-1
|
||
|
|
collisions in 2^69 operations. In August they published details.
|
||
|
|
Luckily, no practical demonstrations of a collision in full SHA-1 were
|
||
|
|
published until 10 years later, in 2017.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Git v2.13.0 and later subsequently moved to a hardened SHA-1
|
||
|
|
implementation by default that mitigates the SHAttered attack, but
|
||
|
|
SHA-1 is still believed to be weak.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The hash to replace this hardened SHA-1 should be stronger than SHA-1
|
||
|
|
was: we would like it to be trustworthy and useful in practice for at
|
||
|
|
least 10 years.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Some other relevant properties:</p>
|
||
|
|
</div>
|
||
|
|
<div class="olist arabic">
|
||
|
|
<ol class="arabic">
|
||
|
|
<li>
|
||
|
|
<p>A 256-bit hash (long enough to match common security practice; not
|
||
|
|
excessively long to hurt performance and disk usage).</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>High quality implementations should be widely available (e.g., in
|
||
|
|
OpenSSL and Apple CommonCrypto).</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>The hash function’s properties should match Git’s needs (e.g. Git
|
||
|
|
requires collision and 2nd preimage resistance and does not require
|
||
|
|
length extension resistance).</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>As a tiebreaker, the hash should be fast to compute (fortunately
|
||
|
|
many contenders are faster than SHA-1).</p>
|
||
|
|
</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>We choose SHA-256.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect1">
|
||
|
|
<h2 id="_transition_plan">Transition plan</h2>
|
||
|
|
<div class="sectionbody">
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Some initial steps can be implemented independently of one another:
|
||
|
|
- adding a hash function API (vtable)
|
||
|
|
- teaching fsck to tolerate the gpgsig-sha256 field
|
||
|
|
- excluding gpgsig-* from the fields copied by "git commit --amend"
|
||
|
|
- annotating tests that depend on SHA-1 values with a SHA1 test
|
||
|
|
prerequisite
|
||
|
|
- using "struct object_id", GIT_MAX_RAWSZ, and GIT_MAX_HEXSZ
|
||
|
|
consistently instead of "unsigned char *" and the hardcoded
|
||
|
|
constants 20 and 40.
|
||
|
|
- introducing index v3
|
||
|
|
- adding support for the PSRC field and safer object pruning</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The first user-visible change is the introduction of the objectFormat
|
||
|
|
extension (without compatObjectFormat). This requires:
|
||
|
|
- implementing the loose-object-idx
|
||
|
|
- teaching fsck about this mode of operation
|
||
|
|
- using the hash function API (vtable) when computing object names
|
||
|
|
- signing objects and verifying signatures
|
||
|
|
- rejecting attempts to fetch from or push to an incompatible
|
||
|
|
repository</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Next comes introduction of compatObjectFormat:
|
||
|
|
- translating object names between object formats
|
||
|
|
- translating object content between object formats
|
||
|
|
- generating and verifying signatures in the compat format
|
||
|
|
- adding appropriate index entries when adding a new object to the
|
||
|
|
object store
|
||
|
|
- --output-format option
|
||
|
|
- ^{sha1} and ^{sha256} revision notation
|
||
|
|
- configuration to specify default input and output format (see
|
||
|
|
"Object names on the command line" above)</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The next step is supporting fetches and pushes to SHA-1 repositories:
|
||
|
|
- allow pushes to a repository using the compat format
|
||
|
|
- generate a topologically sorted list of the SHA-1 names of fetched
|
||
|
|
objects
|
||
|
|
- convert the fetched packfile to sha256 format and generate an idx
|
||
|
|
file
|
||
|
|
- re-sort to match the order of objects in the fetched packfile</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>The infrastructure supporting fetch also allows converting an existing
|
||
|
|
repository. In converted repositories and new clones, end users can
|
||
|
|
gain support for the new hash function without any visible change in
|
||
|
|
behavior (see "dark launch" in the "Object names on the command line"
|
||
|
|
section). In particular this allows users to verify SHA-256 signatures
|
||
|
|
on objects in the repository, and it should ensure the transition code
|
||
|
|
is stable in production in preparation for using it more widely.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Over time projects would encourage their users to adopt the "early
|
||
|
|
transition" and then "late transition" modes to take advantage of the
|
||
|
|
new, more futureproof SHA-256 object names.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>When objectFormat and compatObjectFormat are both set, commands
|
||
|
|
generating signatures would generate both SHA-1 and SHA-256 signatures
|
||
|
|
by default to support both new and old users.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>In projects using SHA-256 heavily, users could be encouraged to adopt
|
||
|
|
the "post-transition" mode to avoid accidentally making implicit use
|
||
|
|
of SHA-1 object names.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Once a critical mass of users have upgraded to a version of Git that
|
||
|
|
can verify SHA-256 signatures and have converted their existing
|
||
|
|
repositories to support verifying them, we can add support for a
|
||
|
|
setting to generate only SHA-256 signatures. This is expected to be at
|
||
|
|
least a year later.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>That is also a good moment to advertise the ability to convert
|
||
|
|
repositories to use SHA-256 only, stripping out all SHA-1 related
|
||
|
|
metadata. This improves performance by eliminating translation
|
||
|
|
overhead and security by avoiding the possibility of accidentally
|
||
|
|
relying on the safety of SHA-1.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Updating Git’s protocols to allow a server to specify which hash
|
||
|
|
functions it supports is also an important part of this transition. It
|
||
|
|
is not discussed in detail in this document but this transition plan
|
||
|
|
assumes it happens. :)</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect1">
|
||
|
|
<h2 id="_alternatives_considered">Alternatives considered</h2>
|
||
|
|
<div class="sectionbody">
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_upgrading_everyone_working_on_a_particular_project_on_a_flag_day">Upgrading everyone working on a particular project on a flag day</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Projects like the Linux kernel are large and complex enough that
|
||
|
|
flipping the switch for all projects based on the repository at once
|
||
|
|
is infeasible.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Not only would all developers and server operators supporting
|
||
|
|
developers have to switch on the same flag day, but supporting tooling
|
||
|
|
(continuous integration, code review, bug trackers, etc) would have to
|
||
|
|
be adapted as well. This also makes it difficult to get early feedback
|
||
|
|
from some project participants testing before it is time for mass
|
||
|
|
adoption.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_using_hash_functions_in_parallel">Using hash functions in parallel</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>(e.g. <a href="https://public-inbox.org/git/22708.8913.864049.452252@chiark.greenend.org.uk/" class="bare">https://public-inbox.org/git/22708.8913.864049.452252@chiark.greenend.org.uk/</a> )
|
||
|
|
Objects newly created would be addressed by the new hash, but inside
|
||
|
|
such an object (e.g. commit) it is still possible to address objects
|
||
|
|
using the old hash function.
|
||
|
|
* You cannot trust its history (needed for bisectability) in the
|
||
|
|
future without further work
|
||
|
|
* Maintenance burden as the number of supported hash functions grows
|
||
|
|
(they will never go away, so they accumulate). In this proposal, by
|
||
|
|
comparison, converted objects lose all references to SHA-1.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_signed_objects_with_multiple_hashes">Signed objects with multiple hashes</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Instead of introducing the gpgsig-sha256 field in commit and tag objects
|
||
|
|
for sha256-content based signatures, an earlier version of this design
|
||
|
|
added "hash sha256 <sha256-name>" fields to strengthen the existing
|
||
|
|
sha1-content based signatures.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>In other words, a single signature was used to attest to the object
|
||
|
|
content using both hash functions. This had some advantages:
|
||
|
|
* Using one signature instead of two speeds up the signing process.
|
||
|
|
* Having one signed payload with both hashes allows the signer to
|
||
|
|
attest to the sha1-name and sha256-name referring to the same object.
|
||
|
|
* All users consume the same signature. Broken signatures are likely
|
||
|
|
to be detected quickly using current versions of git.</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>However, it also came with disadvantages:
|
||
|
|
* Verifying a signed object requires access to the sha1-names of all
|
||
|
|
objects it references, even after the transition is complete and
|
||
|
|
translation table is no longer needed for anything else. To support
|
||
|
|
this, the design added fields such as "hash sha1 tree <sha1-name>"
|
||
|
|
and "hash sha1 parent <sha1-name>" to the sha256-content of a signed
|
||
|
|
commit, complicating the conversion process.
|
||
|
|
* Allowing signed objects without a sha1 (for after the transition is
|
||
|
|
complete) complicated the design further, requiring a "nohash sha1"
|
||
|
|
field to suppress including "hash sha1" fields in the sha256-content
|
||
|
|
and signed payload.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect2">
|
||
|
|
<h3 id="_lazily_populated_translation_table">Lazily populated translation table</h3>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Some of the work of building the translation table could be deferred to
|
||
|
|
push time, but that would significantly complicate and slow down pushes.
|
||
|
|
Calculating the sha1-name at object creation time at the same time it is
|
||
|
|
being streamed to disk and having its sha256-name calculated should be
|
||
|
|
an acceptable cost.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="sect1">
|
||
|
|
<h2 id="_document_history">Document History</h2>
|
||
|
|
<div class="sectionbody">
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>2017-03-03
|
||
|
|
<a href="mailto:bmwill@google.com">bmwill@google.com</a>, <a href="mailto:jonathantanmy@google.com">jonathantanmy@google.com</a>, <a href="mailto:jrnieder@gmail.com">jrnieder@gmail.com</a>,
|
||
|
|
<a href="mailto:sbeller@google.com">sbeller@google.com</a></p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Initial version sent to
|
||
|
|
<a href="http://public-inbox.org/git/20170304011251.GA26789@aiede.mtv.corp.google.com" class="bare">http://public-inbox.org/git/20170304011251.GA26789@aiede.mtv.corp.google.com</a></p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>2017-03-03 <a href="mailto:jrnieder@gmail.com">jrnieder@gmail.com</a>
|
||
|
|
Incorporated suggestions from jonathantanmy and sbeller:
|
||
|
|
* describe purpose of signed objects with each hash type
|
||
|
|
* redefine signed object verification using object content under the
|
||
|
|
first hash function</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>2017-03-06 <a href="mailto:jrnieder@gmail.com">jrnieder@gmail.com</a>
|
||
|
|
* Use SHA3-256 instead of SHA2 (thanks, Linus and brian m. carlson).[1][2]
|
||
|
|
* Make sha3-based signatures a separate field, avoiding the need for
|
||
|
|
"hash" and "nohash" fields (thanks to peff[3]).
|
||
|
|
* Add a sorting phase to fetch (thanks to Junio for noticing the need
|
||
|
|
for this).
|
||
|
|
* Omit blobs from the topological sort during fetch (thanks to peff).
|
||
|
|
* Discuss alternates, git notes, and git servers in the caveats
|
||
|
|
section (thanks to Junio Hamano, brian m. carlson[4], and Shawn
|
||
|
|
Pearce).
|
||
|
|
* Clarify language throughout (thanks to various commenters,
|
||
|
|
especially Junio).</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>2017-09-27 <a href="mailto:jrnieder@gmail.com">jrnieder@gmail.com</a>, <a href="mailto:sbeller@google.com">sbeller@google.com</a>
|
||
|
|
* use placeholder NewHash instead of SHA3-256
|
||
|
|
* describe criteria for picking a hash function.
|
||
|
|
* include a transition plan (thanks especially to Brandon Williams
|
||
|
|
for fleshing these ideas out)
|
||
|
|
* define the translation table (thanks, Shawn Pearce[5], Jonathan
|
||
|
|
Tan, and Masaya Suzuki)
|
||
|
|
* avoid loose object overhead by packing more aggressively in
|
||
|
|
"git gc --auto"</p>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>Later history:</p>
|
||
|
|
</div>
|
||
|
|
<div class="literalblock">
|
||
|
|
<div class="content">
|
||
|
|
<pre>See the history of this file in git.git for the history of subsequent
|
||
|
|
edits. This document history is no longer being maintained as it
|
||
|
|
would now be superfluous to the commit log</pre>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="paragraph">
|
||
|
|
<p>[1] <a href="http://public-inbox.org/git/CA+55aFzJtejiCjV0e43+9oR3QuJK2PiFiLQemytoLpyJWe6P9w@mail.gmail.com/" class="bare">http://public-inbox.org/git/CA+55aFzJtejiCjV0e43+9oR3QuJK2PiFiLQemytoLpyJWe6P9w@mail.gmail.com/</a>
|
||
|
|
[2] <a href="http://public-inbox.org/git/CA+55aFz+gkAsDZ24zmePQuEs1XPS9BP_s8O7Q4wQ7LV7X5-oDA@mail.gmail.com/" class="bare">http://public-inbox.org/git/CA+55aFz+gkAsDZ24zmePQuEs1XPS9BP_s8O7Q4wQ7LV7X5-oDA@mail.gmail.com/</a>
|
||
|
|
[3] <a href="http://public-inbox.org/git/20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net/" class="bare">http://public-inbox.org/git/20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net/</a>
|
||
|
|
[4] <a href="http://public-inbox.org/git/20170304224936.rqqtkdvfjgyezsht@genre.crustytoothpaste.net" class="bare">http://public-inbox.org/git/20170304224936.rqqtkdvfjgyezsht@genre.crustytoothpaste.net</a>
|
||
|
|
[5] <a href="https://public-inbox.org/git/CAJo=hJtoX9=<a href="mailto:AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com">AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com</a>/" class="bare">https://public-inbox.org/git/CAJo=hJtoX9=<a href="mailto:AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com">AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com</a>/</a></p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div id="footer">
|
||
|
|
<div id="footer-text">
|
||
|
|
Last updated 2019-02-26 19:31:11 UTC
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|