111–120 of 128 posts
Earlier quoted context omitted.
The hash function may not matter for overall git performance in virtually all dev machine setups, but there will be a (maybe tiny, maybe larger, depending on the repo and disk io speed) difference in cpu utilization and heat generation, right?
That's a silly thing to worry about when you're developing Ruby or Java applications. My PC boots faster than the Rails console or IntelliJ.
Earlier quoted context omitted.
I feel like Linus (and others) have earned the right to be assholes on the mailing lists. He's demonstrated good judgement and made huge contributions, if he doesn't feel the need to be nice i don't think he should have to.
No-one has the right to be an asshole.
Earlier quoted context omitted.
Linus regularly treats security as a second-class citizen and is famous for his outrageous harassment [0]: > Of course, I'd also suggest that whoever was the genius who thought it was a good idea to read things ONE F CKING BYTE AT A TIME with system calls for each byte should be retroactively aborted. Who the f ck does idiotic things like that? How did they noty die as babies, considering that they were likely too st…
What does his "outrageous harassment" have to do with his ignorance towards security? I agree that he should've used SHA-2 or better yet, have made the hash algorithm modular, but what does your quote add to the discussion?
Not much, thanks for the gentle reminder :)
Earlier quoted context omitted.
Until a few weeks ago, SHA-1 collisions had never been demonstrated.
But, in any case, that's in the cryptographic realm. Git hashes aren't digital signatures for cryptographic authenticity.
The git tag and signing verify logic assume the sha-1 hashes for integrity.
Do they anticipate that one day we'll have to move from SHA256 to something else again? It's only matter of time. Hash function have lifecycle. Tre transition has to be done in a way that will also make the next transition more straightforward.
Reading even one changed line tells us that they replaced hardcoded char arrays for SHA1 with a generic struct that could be used as a container for any hash. Some functions that previously operated on those char arrays have been changed to deal with the more generic struct instead.
Earlier quoted context omitted.
But, in any case, that's in the cryptographic realm. Git hashes aren't digital signatures for cryptographic authenticity.
They are. The git tag and signing verify logic assume the sha-1 hashes for integrity.
For instance, a mere four byte CRC-32 can reasonably assure integrity in some situations, like when used on sufficiently small payload frames; yet it is not useful as a digest for certifying authenticity.
SHA-1 is suitable for integrity.
Earlier quoted context omitted.
They are. The git tag and signing verify logic assume the sha-1 hashes for integrity.
Hashing for integrity and authenticity are different things. For instance, a mere four byte CRC-32 can reasonably assure integrity in some situations, like when used on sufficiently small payload frames; yet it is not useful as a digest for certifying authenticity. SHA-1 is suitable for integrity.
Earlier quoted context omitted.
Perhaps you haven't read Linus' comments where he stated (more than a decade ago) that the usage of SHA1 here isn't for "security"? (Hint: that's why GPG signing commits is an option.)
Yes, Linus wrote that SHA1 isn't here for security, but that was a glaring misunderstanding of security on his part. Integrity protection of source code is a security function.
The rest of the code is sent through mailing lists as patches, so the hash is irrelevant.
SHA1 here protects against "random" corruption (which is more than some VCS do), but not an attacker. At no point one is able to send trusted contributors bad commit objects.
Now, the use people have of git is very different from the kernel (or git) style, so their threat model is different, and SHA1 may become a security function.
struct object_id was introduced in this commit, in 2015: https://git.kernel.org/pub/scm/git/git.git/commit/?id=5f7817... So this change doesn't do much for now. Good to see, though.
Yes, this is correct. The struct object_id changes don't actually change the hash. What they do, however, is allow us to remove a lot of the hard-coded instances of 20 and 40 (SHA-1 length in bytes and hex, respectively) in the codebase. The remaining instances of those values become constants or variables (which I'm also doing as part of the series), and it then becomes much easier to add a new hash function, since…
Earlier quoted context omitted.
Given that both claims are unreferenced and using deliberately provocative language, I'd say he wrote very little...
I'm a long time fan of Fossil and contributed a bit to its development (in particular, TLS support and some protections against timing attacks). I'm not sure where you found provocative language, but let me try to explain it here more clearly. Design deficiency (This is unrelated to the choice of hash.) Fossil stores blobs as-is. A file containing "hello world" will be stored as "hello world" and referenced as HASH("…
(My concern was that the twitter basically contained nothing of any content: no technical details, no link to a blog post, nothing which can be checked or verified... which makes it indistinguishable from insinuation; and so I have to dismiss what you said out of hand.)
(Regarding provocative language: I don't think publicly calling someone out as a liar, in so many words, particularly on a medium like Twitter which doesn't really allow for an effective response, is particularly effective in producing a useful result...)
Anyway:
Re the manifest issue: to paraphrase, to check I'm understanding you correctly: because each manifest refers to its predecessor, and not vice versa, adding any blob which looks like a manifest implicitly adds that manifest to the tree. Normally Fossil trusts authenticated users to add blobs to the tree, because they're authenticated, but ticket attachments can be added by anyone, which effectively means that you can bypass the authentication and commits can be done by anyone. Is that correct?
In which case, yeah, I agree; that's very bad. I can't spot any holes in your reasoning. It is possible to positively identify attachments by looking at their parent manifest, as each one should be pointed at by an A record, so I suppose you could disallow manifests if they're referenced like this, but my gut tells me that's going to be horribly fragile... you're right, adding a type prefix is obviously the right way to go.
If you create a manifest and check it in as a normal file, so it's referenced by an F record, is it still treated as a manifest? If not, could this machinery be extended to attachments as well?
You did bring this up on the mailing list, right?