5 ms·

> But both come from the same authors. The Git repository comes with a history containing each and every commit, along with checksums and sometimes cryptograph

> But both come from the same authors. The Git repository comes with a history containing each and every commit, along with checksums and sometimes cryptographic signatures for it all. The tarball is just a bunch of random files. If somebody wants to rewrite the Git history, that will get instantly noticed by anybody that had an older clone of it. If somebody adds a hack to it, it will be at the top of the history and easy to notice as well. If somebody adds something to a tarball, there is nothing to tell you that something changed, you'll have to audit the whole thing from top to bottom (or compare it to the Git repository it came from). Also the author isn't in control here, the tarball can get changed after it was uploaded to the server and there would be nothing in the tarball itself to tell you. People are using PGP signatures and checksums to secure tarballs some more, but that's always an extra step and doesn't happen automatically. And even that still doesn't give you the history.

badsectoracula 3y ago
> The tarball is just a bunch of random files. But that is EXACTLY WHAT GIT IS!, the only difference is that you also get the previous versions too. That doesn't help you at all when the authors themselves are not trustworthy. It MAY help after finding a compromise to figure out when it happened, but it wont help anyone prevent it. What you write is about someone trying to compromising the Git server itself. This is NOT what i refer to (and even that sort of compromise would be sidestepped with signed tarballs). What i refer to is more fundamental: the author of the project controls what is put in the Git repository itself, just like the tarballs. The Git repository is NOT any more trustworthy than the tarballs: if you do not trust the latter then you should not trust the former either and if you do trust the former then there is no reason to not trust the latter.
- grumbel 3y ago
  > the author of the project controls what is put in the Git repository itself The author doesn't control the Git repository. The Git repository is a shared data structure, not just bits on a server. Neither the author nor anybody else can just change the Git repository arbitrarily. They can only change it in ways allowed by Git or the alarm bells will be going off. A tarball has no such restrictions.
  - badsectoracula 3y ago
    I do not refer to the files or bits or whatever that make the git repository in your `.git` directory. Please take a step back and read again what i wrote, it has nothing to do with what you responded with here.
  - deleted 3y ago
    [deleted]
- Terr_ 3y ago
  > But [a bunch of random files] is EXACTLY WHAT GIT IS! Well, yeah, but only in the same limp way that "a bunch of random bytes" describes both (A) some text file versus (B) an e-mail with valid DKIM headers with a PGP signature. It's possible that both could arrive containing your CEO's name and an urgent demand to wire all company funds to some random city in Myanmar... but one approach is fundamentally more secure. > the only difference is that you also get the previous versions too. No, that's not the only difference nor the most-important. The important difference is that the files represented by a particular git-revision all exist with cryptographically-hashed relationships on their content, and that structure prevents/deters multiple kinds of secret meddling or impersonation.
  - badsectoracula 3y ago
    > The important difference is that the files represented by a particular git-revision all exist with cryptographically-hashed relationships on their content, and that structure prevents/deters multiple kinds of secret meddling or impersonation. ...which a developer with proper write access to the repository (i.e. the same developer that'd make the tarballs) wont need to do since they can decide what goes in there in the first place, thus making this "important difference" not at all important when it comes to the case i argue in this entire thread.

badsectoracula 3y ago

> The tarball is just a bunch of random files. But that is EXACTLY WHAT GIT IS!, the only difference is that you also get the previous versions too. That doesn't help you at all when the authors themselves are not trustworthy. It MAY help after finding a compromise to figure out when it happened, but it wont help anyone prevent it. What you write is about someone trying to compromising the Git server itself. This is NOT what i refer to (and even that sort of compromise would be sidestepped with signed tarballs). What i refer to is more fundamental: the author of the project controls what is put in the Git repository itself, just like the tarballs. The Git repository is NOT any more trustworthy than the tarballs: if you do not trust the latter then you should not trust the former either and if you do trust the former then there is no reason to not trust the latter.

grumbel 3y ago
> the author of the project controls what is put in the Git repository itself The author doesn't control the Git repository. The Git repository is a shared data structure, not just bits on a server. Neither the author nor anybody else can just change the Git repository arbitrarily. They can only change it in ways allowed by Git or the alarm bells will be going off. A tarball has no such restrictions.
- badsectoracula 3y ago
  I do not refer to the files or bits or whatever that make the git repository in your `.git` directory. Please take a step back and read again what i wrote, it has nothing to do with what you responded with here.
- deleted 3y ago
  [deleted]
Terr_ 3y ago
> But [a bunch of random files] is EXACTLY WHAT GIT IS! Well, yeah, but only in the same limp way that "a bunch of random bytes" describes both (A) some text file versus (B) an e-mail with valid DKIM headers with a PGP signature. It's possible that both could arrive containing your CEO's name and an urgent demand to wire all company funds to some random city in Myanmar... but one approach is fundamentally more secure. > the only difference is that you also get the previous versions too. No, that's not the only difference nor the most-important. The important difference is that the files represented by a particular git-revision all exist with cryptographically-hashed relationships on their content, and that structure prevents/deters multiple kinds of secret meddling or impersonation.
- badsectoracula 3y ago
  > The important difference is that the files represented by a particular git-revision all exist with cryptographically-hashed relationships on their content, and that structure prevents/deters multiple kinds of secret meddling or impersonation. ...which a developer with proper write access to the repository (i.e. the same developer that'd make the tarballs) wont need to do since they can decide what goes in there in the first place, thus making this "important difference" not at all important when it comes to the case i argue in this entire thread.