{"push_id":870099675,"size":270,"distinct_size":0,"ref":"refs/heads/master","head":"f34be46e47773d03e9d09641209121591a6b37c8","before":"4c2763062a56cf9f6c48e14213785bc619e373a4","commits":[{"sha":"00a09d57eb8a041e6a6b0470c53533719c049bab","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"introduce \"extensions\" form of core.repositoryformatversion\n\nNormally we try to avoid bumps of the whole-repository\ncore.repositoryformatversion field. However, it is\nunavoidable if we want to safely change certain aspects of\ngit in a backwards-incompatible way (e.g., modifying the set\nof ref tips that we must traverse to generate a list of\nunreachable, safe-to-prune objects).\n\nIf we were to bump the repository version for every such\nchange, then any implementation understanding version `X`\nwould also have to understand `X-1`, `X-2`, and so forth,\neven though the incompatibilities may be in orthogonal parts\nof the system, and there is otherwise no reason we cannot\nimplement one without the other (or more importantly, that\nthe user cannot choose to use one feature without the other,\nweighing the tradeoff in compatibility only for that\nparticular feature).\n\nThis patch documents the existing repositoryformatversion\nstrategy and introduces a new format, \"1\", which lets a\nrepository specify that it must run with an arbitrary set of\nextensions. This can be used, for example:\n\n - to inform git that the objects should not be pruned based\n   only on the reachability of the ref tips (e.g, because it\n   has \"clone --shared\" children)\n\n - that the refs are stored in a format besides the usual\n   \"refs\" and \"packed-refs\" directories\n\nBecause we bump to format \"1\", and because format \"1\"\nrequires that a running git knows about any extensions\nmentioned, we know that older versions of the code will not\ndo something dangerous when confronted with these new\nformats.\n\nFor example, if the user chooses to use database storage for\nrefs, they may set the \"extensions.refbackend\" config to\n\"db\". Older versions of git will not understand format \"1\"\nand bail. Versions of git which understand \"1\" but do not\nknow about \"refbackend\", or which know about \"refbackend\"\nbut not about the \"db\" backend, will refuse to run. This is\nannoying, of course, but much better than the alternative of\nclaiming that there are no refs in the repository, or\nwriting to a location that other implementations will not\nread.\n\nNote that we are only defining the rules for format 1 here.\nWe do not ever write format 1 ourselves; it is a tool that\nis meant to be used by users and future extensions to\nprovide safety with older implementations.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/00a09d57eb8a041e6a6b0470c53533719c049bab"},{"sha":"067fbd4105c5aa8260a73cc6961854be0e93fa03","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"introduce \"preciousObjects\" repository extension\n\nIf this extension is used in a repository, then no\noperations should run which may drop objects from the object\nstorage. This can be useful if you are sharing that storage\nwith other repositories whose refs you cannot see.\n\nFor instance, if you do:\n\n  $ git clone -s parent child\n  $ git -C parent config extensions.preciousObjects true\n  $ git -C parent config core.repositoryformatversion 1\n\nyou now have additional safety when running git in the\nparent repository. Prunes and repacks will bail with an\nerror, and `git gc` will skip those operations (it will\ncontinue to pack refs and do other non-object operations).\nOlder versions of git, when run in the repository, will\nfail on every operation.\n\nNote that we do not set the preciousObjects extension by\ndefault when doing a \"clone -s\", as doing so breaks\nbackwards compatibility. It is a decision the user should\nmake explicitly.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/067fbd4105c5aa8260a73cc6961854be0e93fa03"},{"sha":"c39badbb9acfdbc26a23115943bd08311e784db1","author":{"email":"d2635f9f6be81b9042e1c1be60d20ebe0e16c7e2@gmail.com","name":"Trần Ngọc Quân"},"message":"Updated Vietnamese translation\n\nSigned-off-by: Trần Ngọc Quân <vnwildman@gmail.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/c39badbb9acfdbc26a23115943bd08311e784db1"},{"sha":"7cd17e80579c2bffd6245837175a6e1b12a78045","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"show-branch: avoid segfault with --reflog of unborn branch\n\nWhen no branch is given to the \"--reflog\" option, we resolve\nHEAD to get the default branch. However, if HEAD points to\nan unborn branch, resolve_ref returns NULL, and we later\nsegfault trying to access it.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/7cd17e80579c2bffd6245837175a6e1b12a78045"},{"sha":"d270d7b7a2d631c3d11315f20bb0cf15e438dafa","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"mailsplit: fix FILE* leak in split_maildir\n\nIf we encounter an error while splitting a maildir, we exit\nthe function early, leaking the open filehandle. This isn't\na big deal, since we exit the program soon after, but it's\neasy enough to be careful.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/d270d7b7a2d631c3d11315f20bb0cf15e438dafa"},{"sha":"108332c7a04d309cfed872350ab5c8b8e198f944","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"archive-tar: fix minor indentation violation\n\nThis looks like a simple omission from 8539070 (archive-tar:\nunindent write_tar_entry by one level, 2012-05-03).\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/108332c7a04d309cfed872350ab5c8b8e198f944"},{"sha":"fbe85e73ce425b25c15f0b1f3900a9bf895a9793","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"fsck: don't fsck alternates for connectivity-only check\n\nCommit 02976bf (fsck: introduce `git fsck --connectivity-only`,\n2015-06-22) recently gave fsck an option to perform only a\nsubset of the checks, by skipping the fsck_object_dir()\ncall. However, it does so only for the local object\ndirectory, and we still do expensive checks on any alternate\nrepos. We should skip them in this case, too.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/fbe85e73ce425b25c15f0b1f3900a9bf895a9793"},{"sha":"7b03c89ebd10396ac7569f0c8c4fa0b4efd4f7ed","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"add xsnprintf helper function\n\nThere are a number of places in the code where we call\nsprintf(), with the assumption that the output will fit into\nthe buffer. In many cases this is true (e.g., formatting a\nnumber into a large buffer), but it is hard to tell\nimmediately from looking at the code. It would be nice if we\nhad some run-time check to make sure that our assumption is\ncorrect (and to communicate to readers of the code that we\nare not blindly calling sprintf, but have actually thought\nabout this case).\n\nThis patch introduces xsnprintf, which behaves just like\nsnprintf, except that it dies whenever the output is\ntruncated. This acts as a sort of assert() for these cases,\nwhich can help find places where the assumption is violated\n(as opposed to truncating and proceeding, which may just\nsilently give a wrong answer).\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/7b03c89ebd10396ac7569f0c8c4fa0b4efd4f7ed"},{"sha":"bb3788cebb814aa003941abcf484da872aa61412","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"add git_path_buf helper function\n\nIf you have a function that uses git_path a lot, but would\nprefer to avoid the static buffers, it's useful to keep a\nsingle scratch buffer locally and reuse it for each call.\nYou used to be able to do this with git_snpath:\n\n  char buf[PATH_MAX];\n\n  foo(git_snpath(buf, sizeof(buf), \"foo\"));\n  bar(git_snpath(buf, sizeof(buf), \"bar\"));\n\nbut since 1a83c24, git_snpath has been replaced with\nstrbuf_git_path. This is good, because it removes the\narbitrary PATH_MAX limit. But using strbuf_git_path is more\nawkward for two reasons:\n\n  1. It adds to the buffer, rather than replacing it. This\n     is consistent with other strbuf functions, but makes\n     reuse of a single buffer more tedious.\n\n  2. It doesn't return the buffer, so you can't format\n     as part of a function's arguments.\n\nThe new git_path_buf solves both of these, so you can use it\nlike:\n\n  struct strbuf buf = STRBUF_INIT;\n\n  foo(git_path_buf(&buf, \"foo\"));\n  bar(git_path_buf(&buf, \"bar\"));\n\n  strbuf_release(&buf);\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/bb3788cebb814aa003941abcf484da872aa61412"},{"sha":"399ad553ce87fca77a9bc5a0e734a361a9e8a5a3","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"strbuf: make strbuf_complete_line more generic\n\nThe strbuf_complete_line function makes sure that a buffer\nends in a newline. But we may want to do this for any\ncharacter (e.g., \"/\" on the end of a path). Let's factor out\na generic version, and keep strbuf_complete_line as a thin\nwrapper.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/399ad553ce87fca77a9bc5a0e734a361a9e8a5a3"},{"sha":"af49c6d0918bf04aad89bd885a4eef5767a33d0e","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"add reentrant variants of sha1_to_hex and find_unique_abbrev\n\nThe sha1_to_hex and find_unique_abbrev functions always\nwrite into reusable static buffers. There are a few problems\nwith this:\n\n  - future calls overwrite our result. This is especially\n    annoying with find_unique_abbrev, which does not have a\n    ring of buffers, so you cannot even printf() a result\n    that has two abbreviated sha1s.\n\n  - if you want to put the result into another buffer, we\n    often strcpy, which looks suspicious when auditing for\n    overflows.\n\nThis patch introduces sha1_to_hex_r and find_unique_abbrev_r,\nwhich write into a user-provided buffer. Of course this is\njust punting on the overflow-auditing, as the buffer\nobviously needs to be GIT_SHA1_HEXSZ + 1 bytes. But it is\nmuch easier to audit, since that is a well-known size.\n\nWe retain the non-reentrant forms, which just become thin\nwrappers around the reentrant ones. This patch also adds a\nstrbuf variant of find_unique_abbrev, which will be handy in\nlater patches.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/af49c6d0918bf04aad89bd885a4eef5767a33d0e"},{"sha":"c1fd0809174a31edd17e97c1161e01907f41a4fc","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"fsck: use strbuf to generate alternate directories\n\nWhen fsck-ing alternates, we make a copy of the alternate\ndirectory in a fixed PATH_MAX buffer. We memcpy directly,\nwithout any check whether we are overflowing the buffer.\nThis is OK if PATH_MAX is a true representation of the\nmaximum path on the system, because any path here will have\nalready been vetted by the alternates subsystem. But that is\nnot true on every system, so we should be more careful.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/c1fd0809174a31edd17e97c1161e01907f41a4fc"},{"sha":"1d895f194ff612057989f477dc106aa1c7ac2016","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"mailsplit: make PATH_MAX buffers dynamic\n\nThere are several PATH_MAX-sized buffers in mailsplit, along\nwith some questionable uses of sprintf.  These are not\nreally of security interest, as local mailsplit pathnames\nare not typically under control of an attacker, and you\ncould generally only overflow a few numbers at the end of a\npath that approaches PATH_MAX (a longer path would choke\nmailsplit long before). But it does not hurt to be careful,\nand as a bonus we lift some limits for systems with\ntoo-small PATH_MAX varibles.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/1d895f194ff612057989f477dc106aa1c7ac2016"},{"sha":"0bb443fdd2518600f88434e2aad8f515546ee707","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"trace: use strbuf for quote_crnl output\n\nWhen we output GIT_TRACE_SETUP paths, we quote any\nmeta-characters. But our buffer to hold the result is only\nPATH_MAX bytes, and we could double the size of the input\npath (if every character needs quoting). We could use a\n2*PATH_MAX buffer, if we assume the input will never be more\nthan PATH_MAX. But it's easier still to just switch to a\nstrbuf and not worry about whether the input can exceed\nPATH_MAX or not.\n\nThe original copied the \"p2\" pointer to \"p1\", advancing\nboth. Since this gets rid of \"p1\", let's also drop \"p2\",\nwhose name is now confusing. We can just advance the\noriginal \"path\" pointer.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/0bb443fdd2518600f88434e2aad8f515546ee707"},{"sha":"3131977de1476185209d4d56a0494f5b30ee5557","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"progress: store throughput display in a strbuf\n\nCoverity noticed that we strncpy() into a fixed-size buffer\nwithout making sure that it actually ended up\nNUL-terminated. This is unlikely to be a bug in practice,\nsince throughput strings rarely hit 32 characters, but it\nwould be nice to clean it up.\n\nThe most obvious way to do so is to add a NUL-terminator.\nBut instead, this patch switches the fixed-size buffer out\nfor a strbuf. At first glance this seems much less\nefficient, until we realize that filling in the fixed-size\nbuffer is done by writing into a strbuf and copying the\nresult!\n\nBy writing straight to the buffer, we actually end up more\nefficient:\n\n  1. We avoid an extra copy of the bytes.\n\n  2. Rather than malloc/free each time progress is shown, we\n     can strbuf_reset and use the same buffer each time.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/3131977de1476185209d4d56a0494f5b30ee5557"},{"sha":"04724222d5aad4da48674e69aab715273f05dded","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"test-dump-cache-tree: avoid overflow of cache-tree name\n\nWhen dumping a cache-tree, we sprintf sub-tree names directly\ninto a fixed-size buffer, which can overflow. We can\ntrivially fix this by converting to xsnprintf to at least\nnotice and die.\n\nThis probably should handle arbitrary-sized names, but\nthere's not much point. It's used only by the test scripts,\nso the trivial fix is enough.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/04724222d5aad4da48674e69aab715273f05dded"},{"sha":"db85a8a9c2fb492d3cd528dbbcc52075c607cf79","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"compat/inet_ntop: fix off-by-one in inet_ntop4\n\nOur compat inet_ntop4 function writes to a temporary buffer\nwith snprintf, and then uses strcpy to put the result into\nthe final \"dst\" buffer. We check the return value of\nsnprintf against the size of \"dst\", but fail to account for\nthe NUL terminator. As a result, we may overflow \"dst\" with\na single NUL. In practice, this doesn't happen because the\noutput of inet_ntop is limited, and we provide buffers that\nare way oversized.\n\nWe can fix the off-by-one check easily, but while we are\nhere let's also use strlcpy for increased safety, just in\ncase there are other bugs lurking.\n\nAs a side note, this compat code seems to be BSD-derived.\nSearching for \"vixie inet_ntop\" turns up NetBSD's latest\nversion of the same code, which has an identical fix (and\nswitches to strlcpy, too!).\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/db85a8a9c2fb492d3cd528dbbcc52075c607cf79"},{"sha":"5096d4909f9b13c7a650d9dbb7c9702ea7413566","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"convert trivial sprintf / strcpy calls to xsnprintf\n\nWe sometimes sprintf into fixed-size buffers when we know\nthat the buffer is large enough to fit the input (either\nbecause it's a constant, or because it's numeric input that\nis bounded in size). Likewise with strcpy of constant\nstrings.\n\nHowever, these sites make it hard to audit sprintf and\nstrcpy calls for buffer overflows, as a reader has to\ncross-reference the size of the array with the input. Let's\nuse xsnprintf instead, which communicates to a reader that\nwe don't expect this to overflow (and catches the mistake in\ncase we do).\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/5096d4909f9b13c7a650d9dbb7c9702ea7413566"},{"sha":"f2f026752993054c1b712b6f4ae3ff167db38cbe","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"archive-tar: use xsnprintf for trivial formatting\n\nWhen we generate tar headers, we sprintf() values directly\ninto a struct with the fixed-size header values. For the\nmost part this is fine, as we are formatting small values\n(e.g., the octal format of \"mode & 0x7777\" is of fixed\nlength). But it's still a good idea to use xsnprintf here.\nIt communicates to readers what our expectation is, and it\nprovides a run-time check that we are not overflowing the\nbuffers.\n\nThe one exception here is the mtime, which comes from the\nepoch time of the commit we are archiving. For sane values,\nthis fits into the 12-byte value allocated in the header.\nBut since git can handle 64-bit times, if I claim to be a\nvisitor from the year 10,000 AD, I can overflow the buffer.\nThis turns out to be harmless, as we simply overflow into\nthe chksum field, which is then overwritten.\n\nThis case is also best as an xsnprintf. It should never come\nup, short of extremely malformed dates, and in that case we\nare probably better off dying than silently truncating the\ndate value (and we cannot expand the size of the buffer,\nsince it is dictated by the ustar format). Our friends in\nthe year 5138 (when we legitimately flip to a 12-digit\nepoch) can deal with that problem then.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/f2f026752993054c1b712b6f4ae3ff167db38cbe"},{"sha":"ef1286d3c0ba714c6c2ae87e14edf3c462aef114","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"use xsnprintf for generating git object headers\n\nWe generally use 32-byte buffers to format git's \"type size\"\nheader fields. These should not generally overflow unless\nyou can produce some truly gigantic objects (and our types\ncome from our internal array of constant strings). But it is\na good idea to use xsnprintf to make sure this is the case.\n\nNote that we slightly modify the interface to\nwrite_sha1_file_prepare, which nows uses \"hdrlen\" as an \"in\"\nparameter as well as an \"out\" (on the way in it stores the\nallocated size of the header, and on the way out it returns\nthe ultimate size of the header).\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/larsxschneider/git/commits/ef1286d3c0ba714c6c2ae87e14edf3c462aef114"}]}