I agree that they do assume that, but fail to see what connection that has to the actual workings of git. AFAIK the behaviour of software doesn't change in accordance with how developers think it works.
1,925 karma · joined March 22, 2010
I'm not sure that it says anywhere in the documentation that it guarantees anything more than that, but I agree that a significant proportion of developers would intuitively expect that the entire content of the tree to be signed rather than just the SHA1.
In as much as SHA1 is a "cryptographic hash function", Linus isn't taking advantage of a few of it's cryptographic properties in his usage of it in git. It would for example, make no difference to the workings of git if you could reverse-engineer the contents of an object from its SHA1. In the same way, it doesn't matter much to the operation of git that you can generate collisions for SHA1, though if you were running into collisions all the time, it would make everyday usage difficult.
> if git's SHA1 content-addressable design is not crypto, how do you distinguish crypto from software like git that uses cryptographic primitives for useful purposes?
If I'm understanding you correctly, software that "uses cryptographic primitives for useful purposes" is usually trying to guarantee one or more of the following:
* Confidentiality - Keeping data secret
* Integrity - Making sure data hasn't been tampered with
* Authentication - Making sure that the person you think sent the data is in fact the person who sent the data.
* Non-repudiation - Ensuring that the person who sent the data can't deny that they in fact sent the data.
Git makes guarantees about none of the above in its usage of SHA1. You could argue that it makes a guarantee of integrity in its content addressable file store, but it doesn't. If you can modify the files in the .git/ directory, you can screw up the repository to your hearts content. There's no way to do so remotely, i.e. by creating and pushing a Git commit with an existing SHA1. You typically protect Git from local tampering by only allowing access via SSH, which has plenty of crypto in it.
When it does make guarantees about authentication (signing tags) it uses GPG more or less off the shelf. In that case the SHA1 is a reference to a commit object, and you're saying that "I, Najaf Ali, sign off on the commit with this SHA1". It doesn't guarantee anything about the contents of that commit if the repository has been tampered with.
> is a project like git a safe/sane thing for a non-cryptographer to design and implement? If so, why do all the warnings in this article not apply?
See above on git not making the guarantees that software that "uses cryptographic primitives for useful purposes" tend to make. Since Git makes none of those guarantees, it's (I think) a safe/sane thing for a non-cryptographer to design and implement. In practice, what Linus has done has let other off-the-shelf crypto (SSH and GPG) make the required guarantees for him.
N.B. Patrick also says to use your powers for good rather than for evil :)
The content addressable data store where all the objects are kept is basically a filesystem where every filename is the SHA1 of its contents.
If you were to generate an object that was a SHA1 collision of an existing object and inject it via a commit (without access to filesystem, otherwise the point is sort of moot) then git won't overwrite the original object with that SHA1[1].
Maybe there's some other mechanism in Git that you're referring to that uses SHA1 as a MAC that I'm perhaps unaware of?
[1]: http://stackoverflow.com/questions/9392365/how-would-git-han...
So FYI, "read and manipulate an applications cookies" is strictly the same as "run arbitrary ruby code in your Rails application process". I would upgrade "never a good idea" to "completely and catastrophically exposes your application to remote code execution" in this paragraph.
In theory, an additional precaution one could take: change the default session serializer to `JSON`. By using `JSON` instead of `Marshal`, you're limited to storing strings, hashes and arrays in the session, but that's a good thing. The remote code execution vulnerability takes advantage of `Marshal` deserializing the session and loading objects deep within the Rails process in order to run arbitrary code. Take away that ability by using `JSON` instead of `Marshal` and you should no longer have to worry about this particular attack vector.
After a brief spelunk of the Rails codebase (and not getting very far, my laptop bricked itself today) there doesn't seem to be an easy way to do this, apart from finding the instance of `ActiveSupport::MessageVerifier` in your rails process and then running something like `verifier.instance_variable_set(:@serializer, JSON)`.
Reminds me a little of my favourite series of comics ever, Preacher: http://en.wikipedia.org/wiki/Preacher_(comics)
1. Create a new library, rubygem, infrastructure thingie that was genuinely useful but had a non-trivial setup process.
2. To aid in that setup process, create a script that I recommend be piped into your shell.
3. Somewhere in the middle of that script, silently tar up everything in the users .ssh/ directory and send it somewhere I can see it.
This one wasn't smarter than Einstein. It's been a while since I've been near a live PHP installation, but IIRC running with an opcode cache like APC probably means the comments will be parsed at most once (every server restart?)
Also the word 面倒 translates to trouble, difficulty; care; attention;, so that with +くさい would make it troublesome.
I've not heard it being used for messy, unless perhaps you mean messy as in a messy situation (rather than say, a messy room).
[1]: http://jisho.org/words?jap=%E9%9D%A2%E5%80%92%E3%81%8F%E3%81...
If living and being in Japan has taught me anything, it's that generalising from anecdote is not a good idea.
Case in point, if you visit an outlet mall a few miles outside of central Sendai on a weekend, you'd have a lot of trouble convincing anyone that Japanese people aren't making enough babies. It was very, very difficult to spot single people, or even couples without babies crawling all over them on our one day out there.
In a population of nearly 130 million, if there's any generalisation you want to make about Japanese people, you'll find enough anecdotes to put together into a convincing article.
On the usage of mendokusai, I think the author of the article may have misunderstood in the situation he's describing. I believe that in this situation mendokusai meant "It's tiresome to be constantly propositioned by male colleagues at work" rather than "I would have sex with everyone, but I can't be bothered". IME you use mendokusai whenever you're tired of something, along with describing a task that is tiresome.
I talk a lot about web application security. The following line from flesh and blood developers on multiple occasions:
"Shouldn't your tests catch security vulnerabilities?"
To which I always respond:
"Yeah sure, they'll catch the vulnerabilities that you already thought of"
I've personally seen codebases with test suites that cost (even with the most conservative estimates of time spent and day rate) upwards of 300,000 USD with 100% coverage that allowed an anonymous client to drop the users table.
If a lack of security bugs (and therefore bugs in general) is any indicator of software quality, TDD has yet to impress me in the wild.
My development process has always been to prototype out three or four implementations, evaluate them against the known use cases and then settle on a final API design. Then I'm ready to do TDD. Glad to know I'm not the only one who works roughly this way.
It also bugs me a little that many otherwise intelligent developers use TDD as their sole software design tool much of the time. The exact term they use for this is using tests to "drive out" a design. While I understand this may work in textbook examples, in real life I've seen the concept being used to justify designs that clearly aren't fit for purpose.
My main concern about a scheme like this is the vulnerability to SSL stripping.
I'm not sure what you can do mitigate it apart from have SSL on all the time, HSTS telling the browser that it should be using SSL and hoping that the first time a user comes to your site is via a https link.
You could however have picked Ruby, PHP, Python, Haskell, Java, C(++), Objective-C (holy crap, Objective-C), Scala, Clojure etc to deep-dive on and would have been just as employable.
To convince me otherwise, you'd have to make the case that all of my professional connections are conspiring to deceive me or that I'm experiencing hallucinations on a near-daily basis and need professional help.
In the worst case, I... I mean my made-up friend Bob... has worked on teams that seemed to have no other purpose than to execute the new idea that week, with little or no connection to any actual business value.
Bob has seen this happen too many times for it to be a random occurrence. According to Bob, such engagements/teams are typically funded by the taxpayer or upper management at companies that have more cash than God. Then I told Bob to shut up, because he's in breach of all the NDAs and sometimes people read things on Hacker News.
PS I think the last time I ran into you on HN a beer was offered, then we had a fight about a movie on twitter (I forget what). If your adventures ever bring you to London, that beer offer is still open.
Assuming there's nothing you can do to escape your pending jail term, I would suggest getting your legal person to draw up some sort of agreement where someone can run the business and keep the profits in your stead. This will have to be someone you trust as no matter how good the contract, the potential downside for you is huge. You could structure it as selling the company with an option to buy it back at the sale price when you get out of jail.
This sucks so hard. As an openly atheist ex-muslim, I'm permanently striking Indonesia, Malaysia and more or less any other predominantly muslim country off my lifetime travel itenerary. If they'll throw you in jail for some snarky photos, my head rolling into a bucket isn't a great stretch if the imagination.
I'm genuinely interested in collecting good examples of it working. The other article about flickr doing this with feature toggles seemed to be a good fit.
<Rant>
The reason I ask is that earlier this year, I was working with a client who spent upwards of $3 million USD on a content managed website with a huge consultancy that I can neither confirm nor deny is heavily affiliated with the author of the article you may or may not have posted a link to.
They were left with a config-driven feature-toggle system that can only be described as a Rube-Goldberg monstrosity. If statements from old feature toggles littering the codebase and different features toggled on or off in environments that no one knew the meaning of. My favourite was when we discovered after days of trawling through the code that a feature toggle was being used to switch a feature off rather than on.
There was also a team-wide ban on branching of any kind, including local branching. This belies a misunderstanding of how git works more than anything else. I went ahead and kept as many local branches as I bloody well felt like, because there's no way they'd know the difference.
</Rant>