Skip to content

Latest commit

 

History

History
280 lines (218 loc) · 13.5 KB

2021-02-27-edition-72.markdown

File metadata and controls

280 lines (218 loc) · 13.5 KB
title layout date author categories navbar
Git Rev News Edition 72 (February 27th, 2021)
default
2021-02-27 12:06:51 +0100
chriscool
news
false

Git Rev News: Edition 72 (February 27th, 2021)

Welcome to the 72nd edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on git.github.io.

This edition covers what happened during the month of January 2021.

Discussions

Reviews

  • [PATCH 0/5] Support for commits signed by multiple algorithms

    brian m. carlson sent a patch series to allow verifying signed commits and tags when using multiple hash algorithms. This is a follow up from brian's multi-year work on supporting the SHA-256 hash algorithm in Git, to deal with the fact that the original SHA-1 algorithm is becoming more and more outdated and insecure.

    One of the trickiest part in supporting a new hash algorithm is that when Git objects (except blobs) are converted to the new hash, their contents changes, because the hashes they contain (to reference other Git objects) are converted too. So old signatures they contain become invalid.

    A way to overcome this issue is to add a new signature, that signs the converted object, to each signed object that is converted. This way such object would have 2 signatures, and can always be verified using one of them, even if it gets converted back and forth.

    brian's patch series addressed the issue that for SHA-256 tags it was initially planned to have the signature in a Git object header (which is called a header signature) instead of at the end of the tag message (which is called a trailing signature), but unfortunately the patch implementing that got lost. So we use trailing signatures.

    brian then explained "We can't change this now, because otherwise it would be ambiguous whether the trailing signature on a SHA-256 object was for the SHA-256 contents or whether the contents were a rewritten SHA-1 object with no SHA-256 signature at all." So the solution he implemented was to "use the trailing signature for the preferred hash algorithm and use a header for the other variant".

    brian thinks this solution is the best we can do in the current situation, as it still allows converting back and forth between hashes, and verifying signatures created with older versions of Git, though tags signed with multiple algorithms can't be verified with older versions of Git.

    For commits, brian's patch series fixes the bug that old header signatures weren't stripped off before verifying new signatures, so verification always failed.

    The result of his series is then that signing both commits and tags can now be round-tripped through both SHA-1 and SHA-256 conversions.

    Junio Hamano, the Git maintainer, replied to a patch in the series suggesting using the size_t type for byte lengths, instead of unsigned long, as unsigned long was breaking 32-bit builds.

    brian agreed and sent a version 2 of the series with Junio's fix.

    Junio replied to the cover letter of this series asking "How widely are SHA-256 tags in use in the real world, though?", and if it was really too late to use a header signature for tags, as was originally planned.

    brian replied:

    I don't know. I don't know of any major hosting platform that supports them, but of course many people may be using them independently on self-hosted instances.

    He also explained why he thought the solution didn't matter much, because he'd just noticed that old Git versions don't properly strip header signatures, so wouldn't anyway be able to verify tags or commits with multiple signatures.

    He ended his reply saying "there's a lot more prep work (surprise) before we get to anything interesting." To which Junio replied: "Uncomfortably excited to hear this ;-)".

    brian replied with an interesting summary of his in progress work.

    Gábor Szeder then reported a Clang warning, while Junio suggested more unsigned long to size_t changes.

    brian then sent a version 3 of his patch series with fixes for the issues reported by Gábor and Junio, and then a few weeks later version 4 to fix another small issue.

    This patch series is scheduled to be merged in the master branch soon.

Developer Spotlight: Taylor Blau

  • Who are you and what do you do?

    I am Taylor. I work at GitHub, where I spend most of my time contributing to the Git project.

  • What would you name your most important contribution to Git?

    I'm still submitting many of the patches, but I think multi-pack reachability bitmaps will be my most important contribution to Git so far.

    If they work, they'll allow hosting providers who rely on reachability bitmaps more flexibility to control when and how they repack their repository. If you want to use bitmaps, you have no choice but to repack your repository into one enormous pack. Multi-pack reachability bitmaps mean that you won't have to, and can instead repack your repository however you want.

    If I'm limited to things that I have finished, I would say that the on-disk reverse index is another good one. But that's kind of cheating, since it's related to multi-pack bitmaps ;).

  • What are you doing on the Git project these days, and why?

    Most of my time is spent working on multi-pack bitmaps. There are a lot of different topics in my fork that all need to get merged in order to make this feature work. So, I'm spending my time in all of the usual ways: submitting patches, responding to review, submitting more patches, and so on.

    When I'm not doing that, I enjoy to read and review patches from other folks on the list. I feel like there is a lot of exciting work going on recently, and so I'm always interested.

    Every release or so I have the pleasure of writing a "release highlights" blog post that GitHub publishes. We're still a few weeks away from a release (at the time of writing), so it's not something that I'm working on yet, but it will come up soon enough.

  • If you could get a team of expert developers to work full time on something in Git for a full year, what would it be?

    I'm not sure :). I care a lot about performance on large repositories, so I think that if I were in charge of such a team, that I would just set them loose to explore the boundaries of what's possible, and push them further.

  • If you could remove something from Git without worrying about backwards compatibility, what would it be?

    Gosh, I would love to get rid of .keep packs, or at least the distinction between in-core and on-disk ones. They're incredibly useful, but they are subtly different, in ways that are sort of hard to reason about.

  • What is your favorite Git-related tool/library, outside of Git itself?

    I use tig often, particularly its blame and log view. Michael Haggerty's git when-merged is another indispensable tool in my workflow.

    I'm curious to try Stephen Jung's git absorb tool, but I haven't gotten to it yet.

Releases

Other News

Various

Light reading

Git tools and sites

  • DAGsHub Storage is an alternative (and free-to-use) DVC remote that requires zero configuration.
  • Commitizen is an Open Source project that helps contributors be good Open Source citizens. It accomplishes this by prompting them to follow commit message conventions at commit time, asking the user fill in any required fields and automatically formatting the commit message according to selected convention.
  • Git Gud by Ben Thayer is a command line game designed to help you learn how to use Git. Note that there was a pretty barebone visual web-based Git simulator with the same name by Nic Hartley, which got mentioned in Git Rev News Edition #48, but it is no longer available.

Credits

This edition of Git Rev News was curated by Christian Couder <[email protected]>, Jakub Narębski <[email protected]>, Markus Jansen <[email protected]> and Kaartic Sivaraam <[email protected]> with help from Taylor Blau.