Tarsnap email confirmation bypass(daemonology.net) |
Tarsnap email confirmation bypass(daemonology.net) |
The only disappointing thing being that due to causality constraints, I was unable to upvote past me's answer or further past me's question, which was a shame as they were both really useful.
I've gone back and referred to this (Emacs code browsing tips) http://www.kirubakaran.com/articles/efficiently-browsing-tex... many times. Definitely helps to take some time and write. Even if you aren't helping anyone else, you're definitely helping yourself. https://sites.google.com/site/steveyegge2/you-should-write-b...
My weirdest one was when I was searching for an answer to a progamming question and ended up finding (and then contacting) my "long lost" cousin (the name was fairly unusual).
Turns out he became a programmer too.
I take away a different lesson, though: even simple web security is easy to get wrong, even for a very smart, very talented developer. I'm not sure what the solution is, though.
As for the comments, while I don't take a hard line here, I agree with Bob Martin's quote: "Every time you write a comment, you should grimace and feel the failure of your ability of expression." Wherever possible, you are better off rewriting the code and variable names to clarify in the code itself whatever you wanted to say in the comments. It's hard to say how to accomplish that here without knowing more about the code, though. And it may have been so difficult that a comment was the right choice.
Never "hide" sensitive data in those hidden input fields.
In most cases, logically granular commits with good commit messages, and a knowledge of `git log` and `git blame` etc, is better than leaving comments. Comments can easily get out of sync with reality (see https://twitter.com/nzkoz/status/538892801941848064 ) and create a lot of noise that make reading the code harder (especially when the comment and code contradict each other).
I only leave brief comments where some code is necessary but at a glance doesn't look right, or has a non-obvious reason. But first I find a way to make it look right or be obvious.
Getting devs to write separate documentation is more difficult than comments, and is more likely to get out of sync. Better if they write some general overview inline. (On the opposite end, I also recently reviewed a project that has almost no comments, except on calls to malloc and free, with comments "get some memory" and "release memory".)
This may be true, but I find that every other form of documentation becomes out of sync with reality even more easily, and/or is not in the right place to be noticed when some code is being edited.
I meant cookie.
This certainly isn't a web cookie in the sense that I'm used to (a cookie would be a part of the HTTP header, and you can't specify that header in a URL). It is more like a token as I understand it. Maybe what you are describing is how the web cookie term was started (based on the behavior of generating a thing that someone else gives back to you) but it doesn't sound like a cookie at all to me.
a friendly guy reported to tarsnap that you could sign up without needing the emailed confirmation link by creating that same confirmation link yourself with the cookie/token being hidden, but present in the HTML code.
also, there is no bug bounties for the tarsnap website, only for tarsnap code.
That's a decent summary, but I didn't think I was all that long-winded...
$config->{template} = $container->template;
(There's no spec for the file format - all have the `template` key in the `container` section but some also have it in the `config` section. Since I can't change these files, I have to deal with the duality. But you'd never be able to guess that from this code without a comment.)
Maybe in some purely technical sense this is true, but in a meaningful one it isn't. At an absolute minimum, names reveal intent -- which is why naming is so important.
Regarding your other example, you are always free to wrap what you don't control in objects that have the intention-revealing semantics (read: correctly named behavior) that you desire.
It's impossible to tell from that single line of code if there are other options as well (the surrounding context is missing, and that's where meaning comes from), but you always have some options. I'll grant that in some cases the cure is worse than the disease -- that is, the changes needed to truly reveal your intent in the code would lead to over-engineered complexity. But typically I find that is not the case.
But the problem with comments is that they'll inevitably get out of sync with the code. And a wrong comment is far worse than no comment at all.
In a case like Colin's, I think something as simple as including "secure" or "secret" in the name of the variable would prevent this stuff from happening. If your variable is named `secureAccountCode` then it's unlikely you'll be silly enough to render it back to a hidden input (unless you're writing code comments for "Drunk Me" like the Disqus commenter on the article, in which case all bets are off).
There's a classic Joel on Software article about this, "Making Wrong Code Look Wrong" [1]
Eek, then by all means take comments seriously and change them when your code changes. I think it's particularly important to comment functions and methods (especially effectful/stateful ones) with what precisely they're expected to do, what invariants hold, etc. (insofar as the type system and function name don't make these clear). Otherwise another programmer has no way (aside from looking at and completely understanding every call site) of knowing what bits of the functionality are incidental vs intended behavior, and are likely to make small modifications for their own purposes which break other things.
Programmers seem very eager to lack of comments and I'm super unsympathetic; this is the one thing that just kills me. Comments hold together a codebase, make it much easier to learn and read, and are a way for programmers to impart all sorts of bits of knowledge about the domain that is valuable "we would do X here but foo() from library Y works in such and such a way so, blah blah blah". And if you don't like to read comments like that I'm sure your editor will fold them for you.
But I think clarity at the local level is nice, too. Let's say your function takes a name, sanitizes it, and then does some other processing, perhaps storing it. I think this makes the code more immediately clear than 2 character names:
function storeName(name) {
safeName = sanitize(name);
// do other stuff that works with safeName
//...
} let thisIsAString = 1
In practice, though, I think this kind of "lie" both happens and persists less frequently than comments that "lie" either by inaccuracy or obsolescence. People naturally have a lazier attitude toward the upkeep of comments ("they don't really affect the code") and somehow an inaccurate variable name seems more brazen than an incorrect comment.