{"thread":{"id":"53270","subject":"how to (integrity) verify a whole git repo","startedAt":"2020-04-21T04:50:46Z","lastAt":"2020-04-23T18:12:34Z","messageCount":7,"participants":["Christoph Anton Mitterer","Jonathan Nieder","Konstantin Ryabitsev","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"395808","messageId":"acb9a2da98bce7ea3044cbf37c92163497f7e9e2.camel@scientia.net","threadId":"53270","inReplyTo":null,"subject":"how to (integrity) verify a whole git repo","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.net","sentAt":"2020-04-21T04:45:35Z","receivedAt":"2020-04-21T04:50:46Z","isPatch":false,"sender":{"key":"calestyo@scientia.net","avatar":"https://gravatar.com/avatar/74cd78048081efac1fcd21e681751ed55968f949a50e33adbe1a41c572a605cd?d=mp&s=160"},"body":"Hi.\n\nIt seems I couldn't really find any definitive answer one the\nfollowing:\n\nHow to cryptographically verify the integrity of a whole git repo (i.e.\nall it's commits/blobs/etc. in the history?\n\nAssume e.g. I have the kernel sources and want to do some bisection.\nOne has also retrieved Linus' and GregKH's key via some trusted path\nand assumes that SHA1 is more or less still safe enough ;-)\n\n\n1) Of course there is git verify-tag and verify-commit which are signed\nwith the GPPG, but these alone check, AFAIU, only the respective\ntag/commit.\n\nHow to check everything else? Is it enough to git fsck --full?\n\nEverything earlier in the history of a verified tag/commit should be\ncryptographically safe (assuming SHA1 would be still secure enough),\nright?\n\n\n2) But this of course won't show me anything which is in the repo but\nnot earlier in the history of the tag/commit I've checked, right?!\nIs there a way to e.g. have everything dropped which is not verifiable\nvia some signed commit/tag?\n\n\n3) I'd assume that normal operations like checkout/bisect/etc. notice\nif some SHA1 sum doesn't match. So once I've verified say kernel v.5.6\ntag, I could checkout everything in the history of that and be sure it\nwasn't modified, right?\nBut of course this wouldn't include e.g. other stable versions, like\nv5.5.13.\n\n\nThanks,\nChris.\n\n"},{"id":"395812","messageId":"20200421065301.GH96152@google.com","threadId":"53270","inReplyTo":"acb9a2da98bce7ea3044cbf37c92163497f7e9e2.camel@scientia.net","subject":"Re: how to (integrity) verify a whole git repo","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2020-04-21T06:53:01Z","receivedAt":"2020-04-21T06:53:06Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Christoph,\n\nChristoph Anton Mitterer wrote:\n\n> How to cryptographically verify the integrity of a whole git repo (i.e.\n> all it's commits/blobs/etc. in the history?\n\nThis happens automatically as part of fetch.  When you fetch, the\nobjects' content is transfered over the wire but not their names.  The\nname of each object is a hash of its content.  Thus, whenever you\naddress an object by its name, you are using its verified identity.\n\n> Assume e.g. I have the kernel sources and want to do some bisection.\n> One has also retrieved Linus' and GregKH's key via some trusted path\n> and assumes that SHA1 is more or less still safe enough ;-)\n>\n> 1) Of course there is git verify-tag and verify-commit which are signed\n> with the GPPG, but these alone check, AFAIU, only the respective\n> tag/commit.\n\nTag and commit object content include the object ids for the objects\nthey reference, so (assuming we are using a strong hash) their name\nis enough to verify all content reachable from them.\n\nIn other words, it's a Merkle tree.\n\n> How to check everything else? Is it enough to git fsck --full?\n\nfsck is helpful for checking that objects are valid --- that they\ndon't reference any objects you don't have, that their format is\ncorrect, and so on.  So it's good to run (or you can use the\ntransfer.fsckObjects setting to run fsck as part of the clone or fetch\noperation).\n\nThanks and hope that helps,\nJonathan\n"},{"id":"395833","messageId":"be69ed1bade98cb7e414c2713fe0d6b5cadd7172.camel@scientia.net","threadId":"53270","inReplyTo":"20200421065301.GH96152@google.com","subject":"Re: how to (integrity) verify a whole git repo","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.net","sentAt":"2020-04-21T14:42:16Z","receivedAt":"2020-04-21T14:42:21Z","isPatch":false,"sender":{"key":"calestyo@scientia.net","avatar":"https://gravatar.com/avatar/74cd78048081efac1fcd21e681751ed55968f949a50e33adbe1a41c572a605cd?d=mp&s=160"},"body":"Hey Jonathan.\n\nOn Mon, 2020-04-20 at 23:53 -0700, Jonathan Nieder wrote:\n> This happens automatically as part of fetch.  When you fetch, the\n> objects' content is transfered over the wire but not their\n> names.  The\n> name of each object is a hash of its content.  Thus, whenever you\n> address an object by its name, you are using its verified identity.\n\nOkay maybe I wasn't clear enough :D (mixing up integrity and\nauthenticity).\n\n\nI'd guess that what you describe here is, that effectively the chain of\nall SHA1 hashes is computed when one does fetch, right?\n\nBut this alone doesn't guarantee cryptographic authenticity, e.g. as in\n\"that's the kernel sources as released by Linus\".\n\n\n> Tag and commit object content include the object ids for the objects\n> they reference, so (assuming we are using a strong hash) their name\n> is enough to verify all content reachable from them.\n> \n> In other words, it's a Merkle tree.\n\nAnd for (cryptographically) checking the authenticity of that tree,\nwouldn't I need to verify the signatures on it's leaves?\n\n\nTaking again the kernel as an example:\nIf I clone the repo (or fsck it later), than all I know is that there\nwas no corruption, if the all the tips are correct, since they start\nthe chain of hash sums to all other objects.\n\nBut an attacker could have just forged these tips.\nSo for checking authenticity, I need to verify some signatures on them\n\nNow if I check e.g. Linus signature on tag v5.6; I should know that\neverything earlier (in the tree, not chronologically) to that tag are\nauthentic.\n\nBut not e.g. any commits on top of v.5.6 (which aren't either signed\nthemselves or protected by another tag \"above\" them).\nNeither any commits never reached from v.5.6, e.g. later stable patches\nlike anything from above v.5.5 (which is again below v.5.6) up to \nv.5.5.13, which is not.\n\n\nSo from my understanding, to use only commits that are authentic by the\nkernel upstream developers, I'd need verify all these tips.. and throw\naway everything which is not reachable by one of them.\n\nIs that somehow possible?\n\n\n\n\nThanks,\nChris.\n\n"},{"id":"395836","messageId":"20200421161956.45slynbgkkom3qc3@chatter.i7.local","threadId":"53270","inReplyTo":"be69ed1bade98cb7e414c2713fe0d6b5cadd7172.camel@scientia.net","subject":"Re: how to (integrity) verify a whole git repo","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2020-04-21T16:19:56Z","receivedAt":"2020-04-21T16:20:02Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Tue, Apr 21, 2020 at 04:42:16PM +0200, Christoph Anton Mitterer wrote:\n> Taking again the kernel as an example:\n> If I clone the repo (or fsck it later), than all I know is that there\n> was no corruption, if the all the tips are correct, since they start\n> the chain of hash sums to all other objects.\n\nNotably, there is normally only one branch in torvalds/linux.git, and \nthat's \"master\". So, there's only one tip.\n\n> But an attacker could have just forged these tips.\n> So for checking authenticity, I need to verify some signatures on them\n> \n> Now if I check e.g. Linus signature on tag v5.6; I should know that\n> everything earlier (in the tree, not chronologically) to that tag are\n> authentic.\n\nYes, verifying a signature on a tag tells you that all commits are \nbit-for-bit exactly the same as on Linus's workstation where he created \nthe signature.\n\n> But not e.g. any commits on top of v.5.6 (which aren't either signed\n> themselves or protected by another tag \"above\" them).\n\nThis is mostly true, yes.\n\n> Neither any commits never reached from v.5.6, e.g. later stable patches\n> like anything from above v.5.5 (which is again below v.5.6) up to \n> v.5.5.13, which is not.\n\nStable commits would be in the stable tree, and those tags are signed by \nGreg Kroah-Hartman.\n\n> So from my understanding, to use only commits that are authentic by the\n> kernel upstream developers, I'd need verify all these tips.. and throw\n> away everything which is not reachable by one of them.\n> \n> Is that somehow possible?\n\nYou probably don't care about commits that arrive between releases, so \neffectively you are already doing that? Even if you have loose objects \nthat aren't reachable from your current tip (e.g. you only care about \nobjects in the stable branch linux-5.6.y), it's not like they are going \nto \"poison\" your tree, so removing them is just a garbage collection \noperation at best.\n\n## Minor attestation rant\n\nI would argue that your premise of \"authenticity\" is wrong. The best \nthat we are currently able to offer is a guarantee that, at the point \nwhere the tag was signed, the tree is bit-for-bit exact to the tree the \nway it exists on Linus Torvalds' (or Greg KH's) workstation.\n\nHowever, both Linus and Greg merge code from tens of thousands of other \ncontributors and it's important to keep in mind that their tag \nsignatures do not offer any kind of attestation proof of the code's \nactual authorship or origin. Looking for such proof would be \nnear-impossible -- even if we had a universally accepted mechanism to do \ncryptographic attestation of all patches and commits, normal maintainer \noperations would necessarily break this chain:\n\n- maintainers insert their own trailers into commit messages\n  (Signed-off-by, Tested-by, Acked-by, etc).\n- maintainers reorder and edit patches that they receive from individual \n  contributors -- for typos, minor stylistical cleanups, extra comments, \n  etc.\n- maintainers routinely rebase patches they receive before they can \n  submit them to be merged into mainline.\n\nFull code attestation is possible in projects where all commits are \nforks and merges -- for example, many Git**b/Gerrit projects could be \nset up to require full cryptographic attestation of commits, if all \noperations are forks, pull requests, and merges. However, it would be \nimpossible to force this development paradigm onto the Linux kernel -- \nit would be extremely disruptive and require massive individual effort \nto overhaul every maintainer's workflow. Furthermore, many maintainers \nwould reject this approach because they would disagree about the main \npremise behind the effort -- that cryptographically signing every commit \noffers enough tangible benefit to be worth it.\n\nLet me expound on the last point. There are some 15,000 personas who \nhave committed code to the Linux kernel (a persona could be the same \nperson committing code from different commercial entities -- \njdoe@google.com vs jdoe@redhat.com). Even if we assume that each commit \nis signed, we then must have a way to perform some kind of meaningful \nverification, right?\n\n- Where do we get all the public keys required for such a task?\n- How do we handle cases where a key has expired or worse, has been \n  revoked by the developer? This can't invalidate their past commits, \n  because it's impossible to re-sign those.\n- How do we bootstrap distributed trust without relying on someone being \n  a Fundamentally Non-corruptible Person? It's certainly not me -- I \n  have close relatives living under, shall we say, regimes with loose \n  standards when it comes to personal freedoms.\n- How much trust should we be putting into cryptographic signatures?  \n  Linux developers aren't necessarily that much better about keeping \n  their workstations protected against malicious attacks, so they are \n  just as vulnerable to having their private keys stolen as anyone else.\n\nFor this reason, Linux maintainers use either a zero-trust approach, or \na last-leg trust approach:\n\n- Submaintainers don't put much trust into *who* wrote the code and \n  review all submissions they receive as potentially containing security \n  bugs (intentional or not); their job is to review the code and pass it \n  up the chain to maintainers.\n- if maintainers receive pull requests from submaintainers, then they \n  *may* check cryptographic signatures on the trees they pull. I am \n  trying to encourage all maintainers to do this, and I've been working \n  to introduce patch attestation so that maintainers preferring to work \n  with patch series as opposed to pull requests can have similar \n  functionality.\n- Linus checks all signatures on trees he pulls from non-kernel.org \n  locations. Unfortunately, I've not been able to convince him that he \n  should check them on stuff he pulls from kernel.org as well (and he \n  has his own reasons for that).\n\nSo, all of this is to say that as the person cloning linux.git you are \nmerely the last link in the chain of \"trusting the maintainer before \nyou.\" In your case that maintainer is Linus (or Greg KH), and you have \nto agree that, in the end, \"having a tree that is bit-for-bit identical \nwith what Linus has\" is a pretty good assurance that it's as \"authentic \nLinux\" as it gets.\n\n-K\n"},{"id":"395846","messageId":"xmqqftcwodma.fsf@gitster.c.googlers.com","threadId":"53270","inReplyTo":"acb9a2da98bce7ea3044cbf37c92163497f7e9e2.camel@scientia.net","subject":"Re: how to (integrity) verify a whole git repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-21T19:14:21Z","receivedAt":"2020-04-21T19:14:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christoph Anton Mitterer <calestyo@scientia.net> writes:\n\n> How to check everything else? Is it enough to git fsck --full?\n>\n> Everything earlier in the history of a verified tag/commit should be\n> cryptographically safe (assuming SHA1 would be still secure enough),\n> right?\n\nCorrect.\n\n> 2) But this of course won't show me anything which is in the repo but\n> not earlier in the history of the tag/commit I've checked, right?!\n> Is there a way to e.g. have everything dropped which is not verifiable\n> via some signed commit/tag?\n\nYou can compute the commits that are not reachable from any of the\nsigned tags.\n\n    git rev-list --all --not $list_tags_and_commits_you_trust_here\n\nwill enumerate all the commits that are not reachable from those\ntags.\n\nBut your \"have everything dropped\" is a fuzzy notion and you must be\nmore precise to define what you want.  Imagine this history:\n\n\n    ----o-----o-----L-----x----x-----x-----x-----x----x HEAD (master)\n                                          /\n                                         /\n                                        /\n                   ... ------o----o----G\n\nwhere you have two people you trust (Linus and Greg), HEAD is the\ntip of your 'master' branch, probably you fetched from Linus, L and\nG are the two recent tags Linus and Greg signed.\n\nIf you enumerate commits that are not reachable from L or G, you'll\nget all commits that are marked with 'x'.  Commits marked with 'o'\nare reachable from either 'L' or 'G', and you would want to keep\nthem.\n\nNow, you need to define what you mean by \"have everything dropped\".\nYou can remove commits 'x' but then after that where would your\n'master' branch point at?  There is no good answer to that question.\n\nWhat you could do is remove all branches and tags except for the\nsigned tags you trust from your repository and then use \"git repack\"\nthe repository.  Then there will be tags that point at L and G but\nyou'd be discarding 'master' (which is not signed) and repack will\ndiscard all 'x' in the sample history illustrated above.\n"},{"id":"395977","messageId":"29351ce9763fe8ed1fa591874be961b041848e2d.camel@scientia.net","threadId":"53270","inReplyTo":"xmqqftcwodma.fsf@gitster.c.googlers.com","subject":"Re: how to (integrity) verify a whole git repo","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.net","sentAt":"2020-04-23T04:02:13Z","receivedAt":"2020-04-23T04:02:21Z","isPatch":false,"sender":{"key":"calestyo@scientia.net","avatar":"https://gravatar.com/avatar/74cd78048081efac1fcd21e681751ed55968f949a50e33adbe1a41c572a605cd?d=mp&s=160"},"body":"Hey Junio.\n\n\nOn Tue, 2020-04-21 at 12:14 -0700, Junio C Hamano wrote:\n> You can compute the commits that are not reachable from any of the\n> signed tags.\n> \n>     git rev-list --all --not $list_tags_and_commits_you_trust_here\n> \n> will enumerate all the commits that are not reachable from those\n> tags.\n\nAnd with reachable you mean: \"commits which were not before the commits\nI trust\" (\"before obviously again not in terms of their date, but their\nposition in the tree\").\n\n\n\n> But your \"have everything dropped\" is a fuzzy notion and you must be\n> more precise to define what you want.  Imagine this history:\n> \n> \n>     ----o-----o-----L-----x----x-----x-----x-----x----x HEAD (master)\n>                                           /\n>                                          /\n>                                         /\n>                    ... ------o----o----G\n> \n> where you have two people you trust (Linus and Greg), HEAD is the\n> tip of your 'master' branch, probably you fetched from Linus, L and\n> G are the two recent tags Linus and Greg signed.\n> \n> If you enumerate commits that are not reachable from L or G, you'll\n> get all commits that are marked with 'x'.  Commits marked with 'o'\n> are reachable from either 'L' or 'G', and you would want to keep\n> them.\n\nThat seems to be more or less what I'd want.\n\n\n> Now, you need to define what you mean by \"have everything dropped\".\n> You can remove commits 'x' but then after that where would your\n> 'master' branch point at?  There is no good answer to that question.\n\nHmm well naively I'd have said master should point to L, assuming\nGreg's branch was merged into it and assuming git knows which branch\nwas the one merged into.\n\nOf course that would leave Greg's branch possibly dangling at G.\n\nMaybe one could handle such cases like this:\n    ----o-----o-----L-----x----x-----x-----x-----x----x HEAD (master)\n                                          /\n                                         /\n                                        /\n                    ... -----t----o----G\n\nIf the former branch name can be determined (from the commit message?),\nrecreate it.\nIf not, the commits from Greg's branch could be either left \nunreachable or maybe, with some special option, could be pointed at by\nsome newly created branch-name foo-1 or whatever.\nIf Greg's branch contains a commit pointed to by tag (here named t), at\nleast this would be reachable anyway.\n\nBut I guess for the use case I'm thinking about, unreachable commits\nwouldn't be that much of a problem.\n\n \n\n> What you could do is remove all branches and tags except for the\n> signed tags you trust from your repository and then use \"git repack\"\n> the repository.  Then there will be tags that point at L and G but\n> you'd be discarding 'master' (which is not signed) and repack will\n> discard all 'x' in the sample history illustrated above.\n\nWell one could probably just manually set master to some reasonable\ncommit, i.e. the one which was likely anyway master at some point in\ntime, until Linus added further commits.\n\n\nIs there an easy (like for people who don't dream in git ;-) ) and\nideally fast way to do all this.\n\n\nI would have guessed that a command which does this more or less out of\nthe box, might be quite helpful for security conscious people. The\nscenario shouldn't be so rare:\n\n- one clones a repo, where commits are usually not signed, but tags are\n- one has a number of trusted people and can even securely retrieve\n  their keys (in my case, Debian ships Linus' and Greg's key in the\n  source package of the kernel)\n- one needs to work with the repo, including any older states in the\n  history (in my case it's trying to bisect the - for me - showstopper\n  bug: https://bugzilla.kernel.org/show_bug.cgi?id=207245 )\n- one doesn't want to use anything which is not signed by trusted\n  people, so basically one wants a repo, as if it would have just been\n  cloned when all branches/etc. were at the state of a signed tag (or\n  commit).\n\nSo I have something like the (stable)kernel repo which looks a bit like\n(with (L) and (G) indicating who signed):\n               x---x---x--- foo\n              /\n    ----o-----v.5.5(L)----o----o-----v.5.6(L)----x-----x----x master\n               \\                     \\\n                \\                     o----v.5.6.1(G)---o----v.5.6.1(G)\n                 \\\n                  o----o----v.5.5.1(G)---o---o---v.5.5.1(G)---x---x\n\n\nA command like:\ngit drop-unsigned-stuff --trusted-key 00411886 --trusted-key 6092693E\n\nwould end up in this (and even garbage-collect all unreachable stuff\nalready, unless one uses some special option):\n\n    ----o-----v.5.5(L)----o----o-----v.5.6(L) master\n               \\                     \\\n                \\                     o----v.5.6.1(G)---o----v.5.6.1(G)\n                 \\\n                  o----o----v.5.5.1(G)---o---o---v.5.5.1(G)\n\nSo with that repo, unless I fetch something new, I could be sure,\neverything I have or I could potentially checkout was at some time\ntrusted by someone I trust.\n\nIn the example above, a branch (foo) which is completely unsigned would\nconsequentially be dropped completely.\n\n\nIn earlier days, most projects released their (signed) sources as some\ntarball,...many nowadays just set (and sometimes even sign) some git\ntag (which is great)... but with the old tarball one could have been\nsure that everything in it is trusted (if one trusts the signer), which\ngit this is of course less simple.\nSo such cases I would have liked a simple way to get rid of everything\nuntrusted.\n\n\nBut probably my use case is just too exotic, otherwise git would\nalready have a helper command for it ^^\n\n\nCheers,\nChris.\n\n"},{"id":"396020","messageId":"6661ea6546fc02583959f00a99736cc110792ab9.camel@scientia.net","threadId":"53270","inReplyTo":"20200421161956.45slynbgkkom3qc3@chatter.i7.local","subject":"Re: how to (integrity) verify a whole git repo","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.net","sentAt":"2020-04-23T18:12:28Z","receivedAt":"2020-04-23T18:12:34Z","isPatch":false,"sender":{"key":"calestyo@scientia.net","avatar":"https://gravatar.com/avatar/74cd78048081efac1fcd21e681751ed55968f949a50e33adbe1a41c572a605cd?d=mp&s=160"},"body":"On Tue, 2020-04-21 at 12:19 -0400, Konstantin Ryabitsev wrote:\n> > So from my understanding, to use only commits that are authentic by\n> > the\n> > kernel upstream developers, I'd need verify all these tips.. and\n> > throw\n> > away everything which is not reachable by one of them.\n> > \n> > Is that somehow possible?\n> \n> You probably don't care about commits that arrive between releases, \n\nNo, I guess not.\n\n\n> so \n> effectively you are already doing that? Even if you have loose\n> objects \n> that aren't reachable from your current tip (e.g. you only care\n> about \n> objects in the stable branch linux-5.6.y), it's not like they are\n> going \n> to \"poison\" your tree, so removing them is just a garbage collection \n> operation at best.\n\nWell it's clear that any \"loose\" objects (in the sense of \"not part of\nthe history by something that is signed and that I trust\") don't poison\nthe tree before whatever I trust... but of course only if one never\naccidentally uses anything of them.\n\nFor the Linus' kernel and Gerg's stable kernel repos this is probably\nrather unlikely, since the do not contain much which is not signed by\none of the two.\nBut for other projects one might have many development branches or\nother stuff which might not be signed at all.\n\nWhen one then \"works\" on such a repo one doesn't always want to check\nwhether the current stuff one uses is signed and trusted or not.\n\n\n> I would argue that your premise of \"authenticity\" is wrong. The best \n> that we are currently able to offer is a guarantee that, at the\n> point \n> where the tag was signed, the tree is bit-for-bit exact to the tree\n> the \n> way it exists on Linus Torvalds' (or Greg KH's) workstation.\n\nAnd isn't that already something? :-D\n\nIt means to the least, that no simple MitM was possible in contrast to\nwhen I just git clone git://whatever .\n\n\n> However, both Linus and Greg merge code from tens of thousands of\n> other \n> contributors and it's important to keep in mind that their tag \n> signatures do not offer any kind of attestation proof of the code's \n> actual authorship or origin.\n\nSure... but this is anyway the case... and nothing which one could\neasily change or improve.\n\nThe best thing in terms of authenticity on can possibly get is being\nable to have the repo exactly the same as it considered correct at it's\ncanonical upstream.\n\nEverything better would require full trust paths and mutual signing\nbetween all participating developers - which would surely be nice to\nhave, but is probably a completely other question.\n\n\nAlso, there are many much smaller projects, where things would be much\neasier.\n\n\n\n> \n> - Submaintainers don't put much trust into *who* wrote the code and \n>   review all submissions they receive as potentially containing\n> security \n>   bugs (intentional or not); their job is to review the code and pass\n> it \n>   up the chain to maintainers.\n> - if maintainers receive pull requests from submaintainers, then\n> they \n>   *may* check cryptographic signatures on the trees they pull. I am \n>   trying to encourage all maintainers to do this, and I've been\n> working \n>   to introduce patch attestation so that maintainers preferring to\n> work \n>   with patch series as opposed to pull requests can have similar \n>   functionality.\n> - Linus checks all signatures on trees he pulls from non-kernel.org \n>   locations. Unfortunately, I've not been able to convince him that\n> he \n>   should check them on stuff he pulls from kernel.org as well (and\n> he \n>   has his own reasons for that).\n\nBut all this gives already quite some trust into the whole thing.\n\n\n> So, all of this is to say that as the person cloning linux.git you\n> are \n> merely the last link in the chain of \"trusting the maintainer before \n> you.\" In your case that maintainer is Linus (or Greg KH), and you\n> have \n> to agree that, in the end, \"having a tree that is bit-for-bit\n> identical \n> with what Linus has\" is a pretty good assurance that it's as\n> \"authentic \n> Linux\" as it gets.\n\nExactly... it's at least not much worse (if at all) than taking e.g. my\npre-compiled distro kernel, for which the sources are like not better\nchecked or more securely retrieved than when I clone Linus' git and\nverify the tags.\n\nMy main concern was really to ideally \"throw away\" everything which\nwasn't protected by a set of certain keys,... so that I wouldn't\naccidentally use it.\n\n\n\nThanks,\nChris.\n\n"}]}