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

Tarsnap email confirmation bypass

daemonology.net

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Tarsnap email confirmation bypass

#41

Post by kirubakaran »

caf wrote: post #8

The value of writing comments intended for your future self was confirmed in a strange way for me: I once found myself googling some faintly obscure question of systems programming, and soon found an article that answered my question perfectly. At that point I noticed with considerable surprise that I was reading a web archive of a Usenet posting I had made myself, some 10 years prior - of all the people to randomly…

Yes, and it is weirdly unsettling too... seeing how you used to phrase things differently.

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...

Re: Tarsnap email confirmation bypass

#43

Post by cperciva »

paulannesley wrote: post #31

> That last part is ultimately the most important lesson from this: Comments matter! 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 whe…

Comments can easily get out of sync with reality

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.

Re: Tarsnap email confirmation bypass

#44

Post by cperciva »

ninguem2 wrote: post #15
cperciva wrote: post #3

Earlier quoted context omitted.

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. That's a decent summary, but I didn't think I was all that long-winded...

Maybe the guy who found the bug won't get $1000, according to your rules, but he definitely deserves a cookie.

I did pay out a bounty of $200 for this.

Re: Tarsnap email confirmation bypass

#46

Post by jberryman »

strommen wrote: post #40
zimpenfish wrote: post #25

Earlier quoted context omitted.

Code can only tell you about the implementation - never the intent. Taking an example from my code yesterday: $config->{template} = $container->template; There's not much can be clarified here, I don't think. But it tells you precisely nothing about why it's required in this instance. (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` se…

There are definitely cases where comments are required to describe intent...the "Why?" of the code. 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…

> But the problem with comments is that they'll inevitably get out of sync with the code.

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.

Re: Tarsnap email confirmation bypass

#48

Post by MichaelGG »

jonahx wrote: post #38
MichaelGG wrote: post #34

Earlier quoted context omitted.

Naming at the higher level is important (type names). But locals, eh, it's unlikeky that you can comprehend lines without the full context, as you say. And our working memory is limited. So might as well use 1- or 2-char names and keep the code less and thus more easily kept in-head. If this is confusing, there's probably too many locals, so setup new scopes (either by nesting or via separate functions).

I agree higher level names are far more important. 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 //... }

In that case it's better to rebind name instead of introducing a new binding - it makes it impossible to misuse it. I hate languages that don't let me rebind (or sometimes, not even shadow).

Re: Tarsnap email confirmation bypass

#49

Post by nchelluri »

cperciva wrote: post #47
nchelluri wrote: post #45

Does he mean "token" instead of "cookie"?

A token is something you are given so that you can give to someone else. A cookie is a token where the "someone else" is the person who originally gave it to you. I meant cookie.

> it sends that cookie to you as part of a URL in the confirmation email

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.

Re: Tarsnap email confirmation bypass

#50

Post by cperciva »

nchelluri wrote: post #49
cperciva wrote: post #47

Earlier quoted context omitted.

A token is something you are given so that you can give to someone else. A cookie is a token where the "someone else" is the person who originally gave it to you. I meant cookie.

> it sends that cookie to you as part of a URL in the confirmation email 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 yo…

Yes, HTTP cookies are so named because they're... well, cookies. The concept is more general and was around long before HTTP though.
Post reply on HN