If all you cared about was a "content identifier", you'd use CRC.
Only if you're actually looking for content collision issues in your SCMs. CRCs not only normally have much smaller output spaces than crypto hashes, they're also horribly non-uniform, which greatly increases the chance of collisions.
It's arguably a major Bug in Git if the Git software keeps track of an object Solely by Hash, and lazily assumes that the Hash uniquely identifies a specific version of the file, And that assumption turns out to be false, and data corruption or tampering can be caused as a result.
I disagree, this is not a bug. It is perfectly reasonable to use a crypto hash to uniquely identify objects within a SCMs, given that one of their properties is that they provide uniformly distributed IDs over a very large space. Statistically the chance of running into a SHA1 collision under normal git usage is so low as to be practically zero - you have a (much, much) better chance of experiencing repo corruption due to cosmic rays hitting your HDD or memory.
This would be much harder that the PDF example by Google (which is quite impressive though). You'd need to generate a zlib compressed commit with a specific hash which references the correct parent commit's own hash, has consistent naming and dates and yields somehow valid code.
This was said before, but again: the point of having SHA1 hashes in git is not security but to ensure reasonable uniqueness of objects (commit, trees, blobs or tags). SHA1 is (was?) a rather strong crypto hash so you do get some of its benefits in that regard though.
That's quite more than "a bit of thinkering", specially compared with pretty much any other interpreted language in the *nix word, which allow multiple language/library versions on a single system in a much saner way.
Oh, it certainly isn't. Too bad on PHP, == when used on objects compares both value and type of every attribute in them, which is what === does for all other types.
But again, this is to be expected. C is a low level language without memory management; PHP is neither. There is no sane reason why it is supposed to segfault (according to the developers, "infinite recursion crashes") and i'm not aware of any other high level language which does the same. How hard is to add a recursion counter?
I understand what you're saying; my point is that the problem is not the release model.
First off, i'm not aware of any languages which do rolling releases - PHP certainly doesn't - and with good reason. The problem is that PHP makes a security component part of the language itself and provides no other way of updating it; a libsodium update becomes now a PHP update, which means you're at the whim and mercy of the language creators when it comes to managing it.
This is specially annoying in PHP, where language installs cannot be made but system wide. Ever tried to run two different versions on the same machine?
Sorry, that is not enough. There's a vast difference from updating a crypto library (which can happen, f.ex, due to security updates) to updating the whole damn language, which can have system-wide implications.
Agreed. The problem is not the library - PHP is intrinsically insecure. I'm not aware of any other language out there that can reliably be made to segfault and whose developers argue such behavior is working as intended.
I can't believe we got this far. What are you guys doing to your country? Leaving your cellphone home used to be a consideration when visiting places like North Korea.
Go 1.7 greatly improves on this, but yes, it is an issue - a simple hello world clocks at around 1.5Mb. Having said that, it is way better than the footprint for other interpreted/bytecoded languages.
I liked Go much better, in the sense that it compiles to actual binaries. The main problem with both languages though is that they're limited to a small number of OSs/architectures.
Slashdot Mirror
It is possible, yes, but it is also extremely unlikely to happen. Which is the entire point here.
If all you cared about was a "content identifier", you'd use CRC.
Only if you're actually looking for content collision issues in your SCMs. CRCs not only normally have much smaller output spaces than crypto hashes, they're also horribly non-uniform, which greatly increases the chance of collisions.
It's arguably a major Bug in Git if the Git software keeps track of an object Solely by Hash, and lazily assumes that the Hash
uniquely identifies a specific version of the file, And that assumption turns out to be false, and data corruption or tampering can be caused as a result.
I disagree, this is not a bug. It is perfectly reasonable to use a crypto hash to uniquely identify objects within a SCMs, given that one of their properties is that they provide uniformly distributed IDs over a very large space. Statistically the chance of running into a SHA1 collision under normal git usage is so low as to be practically zero - you have a (much, much) better chance of experiencing repo corruption due to cosmic rays hitting your HDD or memory.
Anyway, git's failure mode is not horrible either in that scenario: http://marc.info/?l=git&m=1156...
Not really. You can't just put random binary content on a comment.
This would be much harder that the PDF example by Google (which is quite impressive though). You'd need to generate a zlib compressed commit with a specific hash which references the correct parent commit's own hash, has consistent naming and dates and yields somehow valid code.
This was said before, but again: the point of having SHA1 hashes in git is not security but to ensure reasonable uniqueness of objects (commit, trees, blobs or tags). SHA1 is (was?) a rather strong crypto hash so you do get some of its benefits in that regard though.
"...the software's fault if you use..."
Anyway, want strong security? Use signed commits.
Much more unique than checksums.
Well, it is not the software's use non-cryptographic code for cryptographic applications.
Anyway, git's been planning on a new commit hash for a while.
No. He's absolutely right - there's no reason to panic and rush, specially when they've already been working on switching to a new hash.
Tip: talking about "fake news" really does not help your argument, or image.
Um, not shooting an innocent man in retaliation?
That's quite more than "a bit of thinkering", specially compared with pretty much any other interpreted language in the *nix word, which allow multiple language/library versions on a single system in a much saner way.
You do know that "feature" is present on all PHP versions up to the 7.x line, right?
Oh, it can. It just won't do it reliably. Setting a string pointer to 0x72 will certainly do.
Oh, it certainly isn't. Too bad on PHP, == when used on objects compares both value and type of every attribute in them, which is what === does for all other types.
I think you meant s = 'H'; there....
But again, this is to be expected. C is a low level language without memory management; PHP is neither. There is no sane reason why it is supposed to segfault (according to the developers, "infinite recursion crashes") and i'm not aware of any other high level language which does the same. How hard is to add a recursion counter?
I understand what you're saying; my point is that the problem is not the release model.
First off, i'm not aware of any languages which do rolling releases - PHP certainly doesn't - and with good reason. The problem is that PHP makes a security component part of the language itself and provides no other way of updating it; a libsodium update becomes now a PHP update, which means you're at the whim and mercy of the language creators when it comes to managing it.
This is specially annoying in PHP, where language installs cannot be made but system wide. Ever tried to run two different versions on the same machine?
Sorry, that is not enough. There's a vast difference from updating a crypto library (which can happen, f.ex, due to security updates) to updating the whole damn language, which can have system-wide implications.
Agreed. The problem is not the library - PHP is intrinsically insecure. I'm not aware of any other language out there that can reliably be made to segfault and whose developers argue such behavior is working as intended.
Oh, how i wish i was: https://developers.slashdot.or...
...which effectively prevents me from updating it. Great choice for a security library guys.
Except for objects, where a === b is true only if a and b are the same object. Such a beautifully designed language.
I can't believe we got this far. What are you guys doing to your country? Leaving your cellphone home used to be a consideration when visiting places like North Korea.
Go 1.7 greatly improves on this, but yes, it is an issue - a simple hello world clocks at around 1.5Mb. Having said that, it is way better than the footprint for other interpreted/bytecoded languages.
I liked Go much better, in the sense that it compiles to actual binaries. The main problem with both languages though is that they're limited to a small number of OSs/architectures.