| <!DOCTYPE html> |
| <html xmlns="http://www.w3.org/1999/xhtml" lang="en"> |
| <head> |
| <meta charset="UTF-8"/> |
| <meta http-equiv="X-UA-Compatible" content="IE=edge"/> |
| <meta name="viewport" content="width=device-width, initial-scale=1.0"/> |
| <meta name="generator" content="Asciidoctor 2.0.23"/> |
| <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 | https://asciidoctor.org */ |
| /* Uncomment the following line when using as a 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"; */ |
| html{font-family:sans-serif;-webkit-text-size-adjust:100%} |
| a{background:none} |
| a:focus{outline:thin dotted} |
| a:active,a:hover{outline:0} |
| h1{font-size:2em;margin:.67em 0} |
| b,strong{font-weight:bold} |
| abbr{font-size:.9em} |
| abbr[title]{cursor:help;border-bottom:1px dotted #dddddf;text-decoration:none} |
| dfn{font-style:italic} |
| hr{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} |
| audio,video{display:inline-block} |
| audio:not([controls]){display:none;height: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]{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{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;line-height:1;position:relative;cursor:auto;-moz-tab-size:4;-o-tab-size:4;tab-size:4;word-wrap:anywhere;-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%} |
| .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} |
| a{color:#2156a5;text-decoration:underline;line-height:inherit} |
| a:hover,a:focus{color:#1d4b8f} |
| a img{border:0} |
| p{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} |
| 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{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} |
| ul.circle{list-style-type:circle} |
| ul.disc{list-style-type:disc} |
| ul.square{list-style-type:square} |
| ul.circle ul:not([class]),ul.disc ul:not([class]),ul.square ul:not([class]){list-style:inherit} |
| 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} |
| blockquote{margin:0 0 1.25em;padding:.5625em 1.25em 0 1.1875em;border-left:1px solid #ddd} |
| 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:1px solid #dedede;word-wrap:normal} |
| 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{background:#f8f8f7} |
| table thead tr th,table tfoot tr th,table tbody tr td,table tr td,table tfoot tr td{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} |
| .center{margin-left:auto;margin-right:auto} |
| .stretch{width:100%} |
| .clearfix::before,.clearfix::after,.float-group::before,.float-group::after{content:" ";display:table} |
| .clearfix::after,.float-group::after{clear:both} |
| :not(pre).nobreak{word-wrap:normal} |
| :not(pre).nowrap{white-space:nowrap} |
| :not(pre).pre-wrap{white-space:pre-wrap} |
| :not(pre):not([class^=L])>code{font-size:.9375em;font-style:normal!important;letter-spacing:0;padding:.1em .5ex;word-spacing:-.15em;background:#f7f7f8;border-radius:4px;line-height:1.45;text-rendering:optimizeSpeed} |
| pre{color:rgba(0,0,0,.9);font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;line-height:1.45;text-rendering:optimizeSpeed} |
| pre code,pre pre{color:inherit;font-size:inherit;line-height:inherit} |
| pre>code{display:block} |
| pre.nowrap,pre.nowrap pre{white-space:pre;word-wrap:normal} |
| 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:#f7f7f7;border:1px solid #ccc;border-radius:3px;box-shadow:0 1px 0 rgba(0,0,0,.2),inset 0 0 0 .1em #fff;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:0 auto;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{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:flex;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} |
| body.toc2 #header>h1:nth-last-child(2){border-bottom:1px solid #dddddf;padding-bottom:8px} |
| #toc.toc2{margin-top:0!important;background:#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:1px solid #e0e0dc;margin-bottom:1.25em;padding:1.25em;background:#f8f8f7;border-radius:4px} |
| #content #toc>:first-child{margin-top:0} |
| #content #toc>:last-child{margin-bottom:0} |
| #footer{max-width:none;background:rgba(0,0,0,.8);padding:1.25em} |
| #footer-text{color:hsla(0,0%,100%,.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} |
| details,.audioblock,.imageblock,.literalblock,.listingblock,.stemblock,.videoblock{margin-bottom:1.25em} |
| details{margin-left:1.25rem} |
| details>summary{cursor:pointer;display:block;position:relative;line-height:1.6;margin-bottom:.625rem;outline:none;-webkit-tap-highlight-color:transparent} |
| details>summary::-webkit-details-marker{display:none} |
| details>summary::before{content:"";border:solid transparent;border-left:solid;border-width:.3em 0 .3em .5em;position:absolute;top:.5em;left:-1.25rem;transform:translateX(15%)} |
| details[open]>summary::before{border:solid transparent;border-top:solid;border-width:.5em .3em 0;transform:translateY(15%)} |
| details>summary::after{content:"";width:1.25rem;height:1em;position:absolute;top:.3em;left:-1.25rem} |
| .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)} |
| .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);word-wrap:anywhere} |
| .admonitionblock>table td.content>:last-child>:last-child{margin-bottom:0} |
| .exampleblock>.content{border:1px solid #e6e6e6;margin-bottom:1.25em;padding:1.25em;background:#fff;border-radius:4px} |
| .sidebarblock{border:1px solid #dbdbd6;margin-bottom:1.25em;padding:1.25em;background:#f3f3f2;border-radius:4px} |
| .sidebarblock>.content>.title{color:#7a2518;margin-top:0;text-align:center} |
| .exampleblock>.content>:first-child,.sidebarblock>.content>:first-child{margin-top:0} |
| .exampleblock>.content>:last-child,.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,.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>.content>pre{border-radius:4px;overflow-x:auto;padding:1em;font-size:.8125em} |
| @media screen and (min-width:768px){.literalblock pre,.listingblock>.content>pre{font-size:.90625em}} |
| @media screen and (min-width:1280px){.literalblock pre,.listingblock>.content>pre{font-size:1em}} |
| .literalblock pre,.listingblock>.content>pre:not(.highlight),.listingblock>.content>pre[class=highlight],.listingblock>.content>pre[class^="highlight "]{background:#f7f7f8} |
| .literalblock.output pre{color:#f7f7f8;background:rgba(0,0,0,.9)} |
| .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:inherit;opacity:.5} |
| .listingblock:hover code[data-lang]::before{display:block} |
| .listingblock.terminal pre .command::before{content:attr(data-prompt);padding-right:.5em;color:inherit;opacity:.5} |
| .listingblock.terminal pre .command:not([data-prompt])::before{content:"$"} |
| .listingblock pre.highlightjs{padding:0} |
| .listingblock pre.highlightjs>code{padding:1em;border-radius:4px} |
| .listingblock pre.prettyprint{border-width:0} |
| .prettyprint{background:#f7f7f8} |
| pre.prettyprint .linenums{line-height:1.45;margin-left:2em} |
| pre.prettyprint li{background:none;list-style-type:inherit;padding-left:0} |
| pre.prettyprint li code[data-lang]::before{opacity:1} |
| pre.prettyprint li:not(:first-child) code[data-lang]::before{display:none} |
| table.linenotable{border-collapse:separate;border:0;margin-bottom:0;background:none} |
| table.linenotable td[class]{color:inherit;vertical-align:top;padding:0;line-height:inherit;white-space:normal} |
| table.linenotable td.code{padding-left:.75em} |
| table.linenotable td.linenos,pre.pygments .linenos{border-right:1px solid;opacity:.35;padding-right:.5em;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none} |
| pre.pygments span.linenos{display:inline-block;margin-right:.75em} |
| .quoteblock{margin:0 1em 1.25em 1.5em;display:table} |
| .quoteblock:not(.excerpt)>.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-serif;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>blockquote,.quoteblock .quoteblock{padding:0 0 .25em 1em;border-left:.25em solid #dddddf} |
| .quoteblock.excerpt,.quoteblock .quoteblock{margin-left:0} |
| .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;font-size:.85rem;text-align:left;margin-right:0} |
| p.tableblock:last-child{margin-bottom:0} |
| td.tableblock>.content{margin-bottom:1.25em;word-wrap:anywhere} |
| td.tableblock>.content>:last-child{margin-bottom:-1.25em} |
| table.tableblock,th.tableblock,td.tableblock{border:0 solid #dedede} |
| table.grid-all>*>tr>*{border-width:1px} |
| table.grid-cols>*>tr>*{border-width:0 1px} |
| table.grid-rows>*>tr>*{border-width:1px 0} |
| table.frame-all{border-width:1px} |
| table.frame-ends{border-width:1px 0} |
| table.frame-sides{border-width:0 1px} |
| table.frame-none>colgroup+*>:first-child>*,table.frame-sides>colgroup+*>:first-child>*{border-top-width:0} |
| table.frame-none>:last-child>:last-child>*,table.frame-sides>:last-child>:last-child>*{border-bottom-width:0} |
| table.frame-none>*>tr>:first-child,table.frame-ends>*>tr>:first-child{border-left-width:0} |
| table.frame-none>*>tr>:last-child,table.frame-ends>*>tr>:last-child{border-right-width:0} |
| table.stripes-all>*>tr,table.stripes-odd>*>tr:nth-of-type(odd),table.stripes-even>*>tr:nth-of-type(even),table.stripes-hover>*>tr:hover{background:#f8f8f7} |
| 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{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} |
| 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} |
| 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} |
| li>p:empty:only-child::before{content:"";display:inline-block} |
| ul.checklist>li>p:first-child{margin-left:-1em} |
| 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:flex;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} |
| td.hdlist2{word-wrap:anywhere} |
| .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:4px solid #fff;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,#footnotes .footnote a:first-of-type: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} |
| 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:#00fafa} |
| .black{color:#000} |
| .black-background{background:#000} |
| .blue{color:#0000bf} |
| .blue-background{background:#0000fa} |
| .fuchsia{color:#bf00bf} |
| .fuchsia-background{background:#fa00fa} |
| .gray{color:#606060} |
| .gray-background{background:#7d7d7d} |
| .green{color:#006000} |
| .green-background{background:#007d00} |
| .lime{color:#00bf00} |
| .lime-background{background:#00fa00} |
| .maroon{color:#600000} |
| .maroon-background{background:#7d0000} |
| .navy{color:#000060} |
| .navy-background{background:#00007d} |
| .olive{color:#606000} |
| .olive-background{background:#7d7d00} |
| .purple{color:#600060} |
| .purple-background{background:#7d007d} |
| .red{color:#bf0000} |
| .red-background{background:#fa0000} |
| .silver{color:#909090} |
| .silver-background{background:#bcbcbc} |
| .teal{color:#006060} |
| .teal-background{background:#007d7d} |
| .white{color:#bfbfbf} |
| .white-background{background:#fafafa} |
| .yellow{color:#bfbf00} |
| .yellow-background{background:#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:rgba(0,0,0,.8);border-radius:50%;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,summary{letter-spacing:-.01em} |
| p strong,td.content strong,div.footnote strong{letter-spacing:-.005em} |
| p,blockquote,dt,td.content,td.hdlist1,span.alt,summary{font-size:1.0625rem} |
| p{margin-bottom:1.25rem} |
| .sidebarblock p,.sidebarblock dt,.sidebarblock td.content,p.tableblock{font-size:1em} |
| .exampleblock>.content{background:#fffef7;border-color:#e0e0dc;box-shadow:0 1px 4px #e0e0dc} |
| .print-only{display:none!important} |
| @page{margin:1.25cm .75cm} |
| @media print{*{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]{border-bottom:1px dotted} |
| 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} |
| #header,#content,#footnotes,#footer{max-width:none} |
| #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 amzn-kf8,print{#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, but SHA-1 is still weak.</p> |
| </div> |
| <div class="paragraph"> |
| <p>Thus 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="_choice_of_hash">Choice of Hash</h2> |
| <div class="sectionbody"> |
| <div class="paragraph"> |
| <p>The hash to replace the 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>There were several contenders for a successor hash to SHA-1, including |
| SHA-256, SHA-512/256, SHA-256x16, K12, and BLAKE2bp-256.</p> |
| </div> |
| <div class="paragraph"> |
| <p>In late 2018 the project picked SHA-256 as its successor hash.</p> |
| </div> |
| <div class="paragraph"> |
| <p>See 0ed8d8da374 (doc hash-function-transition: pick SHA-256 as |
| NewHash, 2018-08-04) and numerous mailing list threads at the time, |
| particularly the one starting at |
| <a href="https://lore.kernel.org/git/20180609224913.GC38834@genre.crustytoothpaste.net/" class="bare">https://lore.kernel.org/git/20180609224913.GC38834@genre.crustytoothpaste.net/</a> |
| for more information.</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 SHA-1 form and write an object given its SHA-1 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 SHA-1 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 |
| <a href="../gitrepository-layout.html">gitrepository-layout(5)</a>) with <code>extensions.objectFormat</code> and |
| <code>extensions.compatObjectFormat</code> (see <a href="../git-config.html">git-config(1)</a>) set to:</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 SHA-1 name or 64 |
| hexadecimal digit SHA-256 name, plus names derived from those (see |
| gitrevisions(7)).</p> |
| </div> |
| <div class="paragraph"> |
| <p>The SHA-1 name of an object is the SHA-1 of the concatenation of its |
| type, length, a nul byte, and the object’s SHA-1 content. This is the |
| traditional <sha1> used in Git to name objects.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The SHA-256 name of an object is the SHA-256 of the concatenation of its |
| type, length, a nul byte, and the object’s SHA-256 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 SHA-1 and SHA-256 differ because an object named by SHA-256 name refers to |
| other objects by their SHA-256 names and an object named by SHA-1 name |
| refers to other objects by their SHA-1 names.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The SHA-256 content of an object is the same as its SHA-1 content, except |
| that objects referenced by the object are named using their SHA-256 names |
| instead of SHA-1 names. Because a blob object does not refer to any |
| other object, its SHA-1 content and SHA-256 content are the same.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The format allows round-trip conversion between SHA-256 content and |
| SHA-1 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 <a href="../gitformat-pack.html">gitformat-pack(5)</a>, just like |
| today. The content that is compressed and stored uses SHA-256 content |
| instead of SHA-1 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> |
| <div class="ulist"> |
| <ul> |
| <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> |
| <div class="ulist"> |
| <ul> |
| <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> |
| </ul> |
| </div> |
| </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> |
| </ul> |
| </div> |
| </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> |
| <div class="ulist"> |
| <ul> |
| <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. |
| This can be used to look up the object in reachability bitmaps or |
| to look up its name in another object format.</p> |
| </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> |
| </ul> |
| </div> |
| </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> |
| <div class="ulist"> |
| <ul> |
| <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> |
| </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 SHA-1 names |
| and SHA-256 names. The lookup proceeds similarly to ordinary object |
| lookups. For example, to convert a SHA-1 name to a SHA-256 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 SHA-1 names, then:</p> |
| <div class="olist loweralpha"> |
| <ol class="loweralpha"> |
| <li> |
| <p>Read the corresponding entry in the SHA-1 name order to pack |
| name order mapping.</p> |
| </li> |
| <li> |
| <p>Read the corresponding entry in the full SHA-1 name table to |
| verify we found the right object. If it is, then</p> |
| </li> |
| <li> |
| <p>Read the corresponding entry in the full SHA-256 name table. |
| That is the object’s SHA-256 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_sha_1_content">Reading an object’s SHA-1 content</h3> |
| <div class="paragraph"> |
| <p>The SHA-1 content of an object can be read by converting all SHA-256 names |
| of its SHA-256 content references to SHA-1 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 SHA-1 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 SHA-256: open a new SHA-256 packfile. Read the topologically |
| sorted list just generated. For each object, inflate its |
| SHA-1 content, convert to SHA-256 content, and write it to the SHA-256 |
| pack. Record the new SHA-1←→SHA-256 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 SHA-256 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.adoc).</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 SHA-1 content |
| of each object being pushed can be read as described in the "Reading |
| an object’s SHA-1 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 SHA-256 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</p> |
| </div> |
| <div class="olist arabic"> |
| <ol class="arabic"> |
| <li> |
| <p>using SHA-1 only, as in existing signed commit objects</p> |
| </li> |
| <li> |
| <p>using both SHA-1 and SHA-256, by using both gpgsig-sha256 and gpgsig |
| fields.</p> |
| </li> |
| <li> |
| <p>using only SHA-256, by only using the gpgsig-sha256 field.</p> |
| </li> |
| </ol> |
| </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 |
| SHA-256 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</p> |
| </div> |
| <div class="olist arabic"> |
| <ol class="arabic"> |
| <li> |
| <p>using SHA-1 only, as in existing signed tag objects</p> |
| </li> |
| <li> |
| <p>using both SHA-1 and SHA-256, by using gpgsig-sha256 and an in-body |
| signature.</p> |
| </li> |
| <li> |
| <p>using only SHA-256, by only using the gpgsig-sha256 field.</p> |
| </li> |
| </ol> |
| </div> |
| </div> |
| <div class="sect2"> |
| <h3 id="_mergetag_embedding">Mergetag embedding</h3> |
| <div class="paragraph"> |
| <p>The mergetag field in the SHA-1 content of a commit contains the |
| SHA-1 content of a tag that was merged by that commit.</p> |
| </div> |
| <div class="paragraph"> |
| <p>The mergetag field in the SHA-256 content of the same commit contains the |
| SHA-256 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 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 SHA-1 content to SHA-256 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 SHA-256 repository cannot borrow objects from a |
| SHA-1 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 SHA-1 name as key. |
| This design does not describe a way to migrate notes trees to use |
| SHA-256 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 re-encode 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 SHA-1 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 |
| 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="literalblock"> |
| <div class="content"> |
| <pre>git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256}</pre> |
| </div> |
| </div> |
| </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:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>adding a hash function API (vtable)</p> |
| </li> |
| <li> |
| <p>teaching fsck to tolerate the gpgsig-sha256 field</p> |
| </li> |
| <li> |
| <p>excluding gpgsig-* from the fields copied by "git commit --amend"</p> |
| </li> |
| <li> |
| <p>annotating tests that depend on SHA-1 values with a SHA1 test |
| prerequisite</p> |
| </li> |
| <li> |
| <p>using "struct object_id", GIT_MAX_RAWSZ, and GIT_MAX_HEXSZ |
| consistently instead of "unsigned char *" and the hardcoded |
| constants 20 and 40.</p> |
| </li> |
| <li> |
| <p>introducing index v3</p> |
| </li> |
| <li> |
| <p>adding support for the PSRC field and safer object pruning</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The first user-visible change is the introduction of the objectFormat |
| extension (without compatObjectFormat). This requires:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>teaching fsck about this mode of operation</p> |
| </li> |
| <li> |
| <p>using the hash function API (vtable) when computing object names</p> |
| </li> |
| <li> |
| <p>signing objects and verifying signatures</p> |
| </li> |
| <li> |
| <p>rejecting attempts to fetch from or push to an incompatible |
| repository</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Next comes introduction of compatObjectFormat:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>implementing the loose-object-idx</p> |
| </li> |
| <li> |
| <p>translating object names between object formats</p> |
| </li> |
| <li> |
| <p>translating object content between object formats</p> |
| </li> |
| <li> |
| <p>generating and verifying signatures in the compat format</p> |
| </li> |
| <li> |
| <p>adding appropriate index entries when adding a new object to the |
| object store</p> |
| </li> |
| <li> |
| <p>--output-format option</p> |
| </li> |
| <li> |
| <p>^{sha1} and ^{sha256} revision notation</p> |
| </li> |
| <li> |
| <p>configuration to specify default input and output format (see |
| "Object names on the command line" above)</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>The next step is supporting fetches and pushes to SHA-1 repositories:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>allow pushes to a repository using the compat format</p> |
| </li> |
| <li> |
| <p>generate a topologically sorted list of the SHA-1 names of fetched |
| objects</p> |
| </li> |
| <li> |
| <p>convert the fetched packfile to SHA-256 format and generate an idx |
| file</p> |
| </li> |
| <li> |
| <p>re-sort to match the order of objects in the fetched packfile</p> |
| </li> |
| </ul> |
| </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://lore.kernel.org/git/22708.8913.864049.452252@chiark.greenend.org.uk/" class="bare">https://lore.kernel.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.</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>You cannot trust its history (needed for bisectability) in the |
| future without further work</p> |
| </li> |
| <li> |
| <p>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> |
| </li> |
| </ul> |
| </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 SHA-256 content based signatures, an earlier version of this design |
| added "hash sha256 <SHA-256 name>" fields to strengthen the existing |
| SHA-1 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:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Using one signature instead of two speeds up the signing process.</p> |
| </li> |
| <li> |
| <p>Having one signed payload with both hashes allows the signer to |
| attest to the SHA-1 name and SHA-256 name referring to the same object.</p> |
| </li> |
| <li> |
| <p>All users consume the same signature. Broken signatures are likely |
| to be detected quickly using current versions of git.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>However, it also came with disadvantages:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Verifying a signed object requires access to the SHA-1 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 <SHA-1 name>" |
| and "hash sha1 parent <SHA-1 name>" to the SHA-256 content of a signed |
| commit, complicating the conversion process.</p> |
| </li> |
| <li> |
| <p>Allowing signed objects without a SHA-1 (for after the transition is |
| complete) complicated the design further, requiring a "nohash sha1" |
| field to suppress including "hash sha1" fields in the SHA-256 content |
| and signed payload.</p> |
| </li> |
| </ul> |
| </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 SHA-1 name at object creation time at the same time it is |
| being streamed to disk and having its SHA-256 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="ulist"> |
| <ul> |
| <li> |
| <p>Initial version sent to <a href="https://lore.kernel.org/git/20170304011251.GA26789@aiede.mtv.corp.google.com" class="bare">https://lore.kernel.org/git/20170304011251.GA26789@aiede.mtv.corp.google.com</a></p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>2017-03-03 <a href="mailto:jrnieder@gmail.com">jrnieder@gmail.com</a> |
| Incorporated suggestions from jonathantanmy and sbeller:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Describe purpose of signed objects with each hash type</p> |
| </li> |
| <li> |
| <p>Redefine signed object verification using object content under the |
| first hash function</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>2017-03-06 <a href="mailto:jrnieder@gmail.com">jrnieder@gmail.com</a></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Use SHA3-256 instead of SHA2 (thanks, Linus and brian m. carlson).[1][2]</p> |
| </li> |
| <li> |
| <p>Make SHA3-based signatures a separate field, avoiding the need for |
| "hash" and "nohash" fields (thanks to peff[3]).</p> |
| </li> |
| <li> |
| <p>Add a sorting phase to fetch (thanks to Junio for noticing the need |
| for this).</p> |
| </li> |
| <li> |
| <p>Omit blobs from the topological sort during fetch (thanks to peff).</p> |
| </li> |
| <li> |
| <p>Discuss alternates, git notes, and git servers in the caveats |
| section (thanks to Junio Hamano, brian m. carlson[4], and Shawn |
| Pearce).</p> |
| </li> |
| <li> |
| <p>Clarify language throughout (thanks to various commenters, |
| especially Junio).</p> |
| </li> |
| </ul> |
| </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></p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>Use placeholder NewHash instead of SHA3-256</p> |
| </li> |
| <li> |
| <p>Describe criteria for picking a hash function.</p> |
| </li> |
| <li> |
| <p>Include a transition plan (thanks especially to Brandon Williams |
| for fleshing these ideas out)</p> |
| </li> |
| <li> |
| <p>Define the translation table (thanks, Shawn Pearce[5], Jonathan |
| Tan, and Masaya Suzuki)</p> |
| </li> |
| <li> |
| <p>Avoid loose object overhead by packing more aggressively in |
| "git gc --auto"</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>Later history:</p> |
| </div> |
| <div class="ulist"> |
| <ul> |
| <li> |
| <p>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</p> |
| </li> |
| </ul> |
| </div> |
| <div class="paragraph"> |
| <p>References:</p> |
| </div> |
| <div class="literalblock"> |
| <div class="content"> |
| <pre>[1] https://lore.kernel.org/git/CA+55aFzJtejiCjV0e43+9oR3QuJK2PiFiLQemytoLpyJWe6P9w@mail.gmail.com/ |
| [2] https://lore.kernel.org/git/CA+55aFz+gkAsDZ24zmePQuEs1XPS9BP_s8O7Q4wQ7LV7X5-oDA@mail.gmail.com/ |
| [3] https://lore.kernel.org/git/20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net/ |
| [4] https://lore.kernel.org/git/20170304224936.rqqtkdvfjgyezsht@genre.crustytoothpaste.net |
| [5] https://lore.kernel.org/git/CAJo=hJtoX9=AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com/</pre> |
| </div> |
| </div> |
| </div> |
| </div> |
| </div> |
| <div id="footer"> |
| <div id="footer-text"> |
| Last updated 2025-06-20 18:10:42 -0700 |
| </div> |
| </div> |
| </body> |
| </html> |
