Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deconstructing the DAO Attack: A Brief Code Tour

vessenes.com

Post reply on HN
Print view View original

151–160 of 167 posts

Re: Deconstructing the DAO Attack: A Brief Code Tour

#151

Post by wnewman »

kartickv wrote: post #128
rbobby wrote: post #117

Earlier quoted context omitted.

Case sensitivity in any programming language is crazy. I can't for the life of me see a valid engineering principal that accepts IsTheOne() and istheone() being different bits of code. Oh sure at a technical level the computer has no problem with... the problem is restricted to those oh so error prone humans. Can anyone here honestly say that if they were doing a code review they'd agree that solely a difference in c…

I don't know why you've been downvoted, but anyone who disagrees with you needs to explain in what situation it would make sense to have two different functions or files with names differing only in case. I upvoted you.

I have used all-uppercase to make a distinction like class vs. instance in variables (in case-sensitive languages in which the class might be an ordinary held-in-a-variable value, like Javascript), and I might do it again. But it's very unusual, and it's also the kind of practice that is more suitable for a 1KLOC project that will receive 100 hours of effort from a single maintainer over its lifetime than for a bigger project with many maintainers and a highly motivated community of attackers.

I don't think there was ever a case when I was tempted to name two functions with different cases, but if I ever had to write a modest-sized 1-maintainer system in which many functions came in exactly two different flavors, I might be tempted. (Perhaps threadsafe locked vs. raw? or some C++-like distinction between raw functions and closure-like class instances which can be used in a function-call context? or raw functions vs. wrappers with the extra plumbing required to let them be invoked from a scripting language?)

afterthought: And now that I think of it, in old C code I think I vaguely remember working with macro vs. function implementations of the same operation distinguished by capitalizing the name, and I don't think the name convention was an urgent problem. C macros can breed various errors, but I think bitbang_macro vs. bitbang would breed pretty much the same errors as BITBANG vs. bitbang.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#152

Post by astrobe_ »

kartickv wrote: post #128
rbobby wrote: post #117

Earlier quoted context omitted.

Case sensitivity in any programming language is crazy. I can't for the life of me see a valid engineering principal that accepts IsTheOne() and istheone() being different bits of code. Oh sure at a technical level the computer has no problem with... the problem is restricted to those oh so error prone humans. Can anyone here honestly say that if they were doing a code review they'd agree that solely a difference in c…

I don't know why you've been downvoted, but anyone who disagrees with you needs to explain in what situation it would make sense to have two different functions or files with names differing only in case. I upvoted you.

It's not that it would make sense. It is more like it is the programmer's fault.

Next week's stupid but expensive typo will be received() instead of receive(). What will you demand then? That the compiler refuses names based on the Levenshtein distance?

It's the job of a style checking tool, not the job of the compiler.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#153

Post by roblev »

jsprogrammer wrote: post #119
rbobby wrote: post #117

Earlier quoted context omitted.

Case sensitivity in any programming language is crazy. I can't for the life of me see a valid engineering principal that accepts IsTheOne() and istheone() being different bits of code. Oh sure at a technical level the computer has no problem with... the problem is restricted to those oh so error prone humans. Can anyone here honestly say that if they were doing a code review they'd agree that solely a difference in c…

IsTheOne() and istheone() are different bits of code.

clearly case sensitivity is a decision by the language designers. Many languages are case-insensitive.

from https://en.wikipedia.org/wiki/Case_sensitivity

Some computer languages are case-sensitive for their identifiers (C, C++, Java, C#, Verilog, Ruby and XML). Others are case-insensitive (i.e., not case-sensitive), such as Ada, most BASICs (an exception being BBC BASIC), Fortran, SQL and Pascal.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#154

Post by [deleted] »

RobertoG wrote: post #66

I'm going to be a little polemic here. It's this an attack? It's not the problem that those technologies try to solve, to get rid of subjectivity?. In a way, this could be interpreted as trying to be free of politics. If my understanding of what they are trying to accomplish here is correct, if the system allow it, then, by definition, it's legal. If you require a framework where something allowed by the code but wit…

[deleted]

Re: Deconstructing the DAO Attack: A Brief Code Tour

#155

Post by [deleted] »

vessenes wrote: post #93
winteriscoming wrote: post #39

The apparent typo is odd, IMO. I don't know the language in which that program is written, but looking at that snippet, "Transfer" takes 3 arguments whereas the "transfer" function takes 2 arguments. Isn't there any code review involved when this makes into the codebase. Assuming there was some code review and the reviewer just missed it (which is very much possible), a basic unit test case would have easily caught t…

I think after sleeping on it that I agree with you, this is more likely the outcome of bad refactoring. You can read the code commits on github if you like; I don't have them handy, unfortunately. transfer is a very poorly named function, of that there is no doubt. And Transfer is badly named as well. transferAndLockTokens vs LogTransfer would be much, much better.

[deleted]

Re: Deconstructing the DAO Attack: A Brief Code Tour

#156

Post by kartickv »

astrobe_ wrote: post #152
kartickv wrote: post #128

Earlier quoted context omitted.

I don't know why you've been downvoted, but anyone who disagrees with you needs to explain in what situation it would make sense to have two different functions or files with names differing only in case. I upvoted you.

It's not that it would make sense. It is more like it is the programmer's fault. Next week's stupid but expensive typo will be received() instead of receive(). What will you demand then? That the compiler refuses names based on the Levenshtein distance? It's the job of a style checking tool, not the job of the compiler.

That's a false analogy.

Saying it's the programmer's fault is another circular argument. It is, only in languages that make it the programmer's fault, but I would say that it's actually the language designers' fault.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#157

Post by kartickv »

wnewman wrote: post #151
kartickv wrote: post #128

Earlier quoted context omitted.

I don't know why you've been downvoted, but anyone who disagrees with you needs to explain in what situation it would make sense to have two different functions or files with names differing only in case. I upvoted you.

I have used all-uppercase to make a distinction like class vs. instance in variables (in case-sensitive languages in which the class might be an ordinary held-in-a-variable value, like Javascript), and I might do it again. But it's very unusual, and it's also the kind of practice that is more suitable for a 1KLOC project that will receive 100 hours of effort from a single maintainer over its lifetime than for a bigge…

In those situations, it would have been much more readable to have classFoo vs foo, foo() vs nonThreadSafeFoo(), etc.

The bigger point is that while you can come up with creative ways to take advantage of case-sensitivity, it's not that you would have missed it if the language was case-insensitive. From that point of view, case-sensitivity has no benefit, but only a cost: leads to irritating errors from the compiler, or runtime errors in dynamically typed languages.

If something has no benefit, and only a cost, we should get rid of it.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#158

Post by kartickv »

jacquesm wrote: post #146
kartickv wrote: post #132

Earlier quoted context omitted.

I'm not the OP, but I think they should be case-insensitive, if only to prevent errors like this. If you think otherwise, in what situation would it make sense to have two functions with names differing only in case? No upside, only a downside.

Case sensitive is fine if you throw an error when someone tries to define the same name with different case.

That gets us to 99% of what I had in mind, by preventing bugs like this one, but the remaining 1% is: why, then, generate an error when someone invokes a function while specifying a different case? If there's only one function, does the case matter?

Re: Deconstructing the DAO Attack: A Brief Code Tour

#159

Post by wyager »

rrradical wrote: post #97
winteriscoming wrote: post #39

The apparent typo is odd, IMO. I don't know the language in which that program is written, but looking at that snippet, "Transfer" takes 3 arguments whereas the "transfer" function takes 2 arguments. Isn't there any code review involved when this makes into the codebase. Assuming there was some code review and the reviewer just missed it (which is very much possible), a basic unit test case would have easily caught t…

Test cases...code review... How about type checking?? The idea of writing financial software without taking every available precaution to verify correctness is insane to me.

This is why Fintech groups are some of the biggest users of strongly typed functional languages (ocaml, Haskell, etc). Your insane-o-meter is working.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#160

Post by egg_head »

dang wrote: post #87
tinco wrote: post #37

In addition to this the language is not explicit enough. Even standard Haskell wouldn't be safe enough for a program that manages $250MM directly without safe guards. In addition to typesafety, it would have to be both explicitly typed at the lowest possible granularity and annotated with pre and post conditions. Not only did this code allow a bunch of tokens be transferred without compensation, it left the whole acc…

> It's nice that Vitalik Buterin is a genius, but it shows that this guy is only 22 and dropped out of university because anyone with a degree in computer science knows about this stuff Personal attacks, which this crosses into, are not ok on Hacker News. Please edit such stuff out of your comments here. We detached this subthread from https://news.ycombinator.com/item?id=11928562 and marked it off-topic.

He is stating facts, except for the last clause which is an opinion which does not apply to the main subject.
Post reply on HN