I feel that I also have a responsibility to publicize such a glaring security hole in your site. This is the number 1 link on HN at the moment. Thousands of people are going to be signing up. I think they have the right to know that a bug like this exists. Like I said in my initial post, a bug this big seemed to be a sign of a bigger problems. I had suspicions the site was malicious and at that point my priority was to point out those suspicions to the HN community.

Pull requests welcome!

And since it wasn't directed toward me, I guess we all can forget my little rant regarding the "trashing" comment.

Cheers to you, fine folks!

If you like it so much, here's a copy-paste from the project for your edification [1]:

  def new_tags=(tags_string)
    tags_string.gsub! /[^a-zA-Z0-9, ]/, ''
    tags = tags_string.split ','
    tags.collect! {|c| (c.match(/^\w+\s\w+/) || c.match(/^\w+/)).to_s }
    @new_tag_strings = tags
  end

That being said, Ruby's syntax makes me want to gouge my eyes out. There's equal signs, unquoted regular expressions, exclamation points, absolute value bars, and at signs all over the above code. You can't even sort-of follow what this code is doing without searching through the manual every third character. Ruby syntax is worse than C++ and almost as bad as Perl.

Someone tried to explain Ruby syntax to me last week [2], and I'm not sure if I understood it more, or less, as a result, because my conclusion was that Ruby's syntax is so bad, the language shouldn't even be able to exist! I.e., there are a large number of syntactical ambiguities, so writing a parser for it should be completely impossible!

[1] https://github.com/kyledrake/neocities-web/blob/933c3549264e...

[2] https://news.ycombinator.com/item?id=5872899

I fail to see how using equal signs for assignment (or for defining assignment methods) is a problem with syntax, rather than an enhancement to clarity.

> unquoted regular expressions

What's wrong with that? Regexes are a different type than strings. Why should they look like strings?

> exclamation points

...again, so, what?

> absolute value bars

vertical bars used to set off block argument lists aren't absolute value bars. (Neither are vertical bars used for logical-or.)

> at signs

Again, so?

> You can't even sort-of follow what this code is doing without searching through the manual every third character.

Yes, I can, and not just "sort-of follow" it.

> Ruby syntax is worse than C++ and almost as bad as Perl.

There's no accounting for taste, I suppose.

> there are a large number of syntactical ambiguities, so writing a parser for it should be completely impossible

As Ruby does exist, and is parsed, this is clearly not the case. That said, ruby's syntax is not optimized for machine parsing, its designed to be ruby-developer-friendly rather than ruby-parser-developer-friendly.

If you want something optimized for the developer of the language's parser, look to Lisp.

    // Parse tags string.
    // Example:
    // "tag1, tag2" => {"tag1", "tag2"}
    // "tag1, very long tag" => {"tag1", "very long"}
    string[] NewTags(string tags_string)
    {
        //Allow only letters, numbers and spaces in tag.
        tags_string = new string(tags_string.Where(c => char.IsLetter(c)
            || char.IsNumber(c) || c == ' ' || c == ',').ToArray());

        //Separate multiple tags with commas.
        string[] tags = tags_string.Split(',').Select(s => s.Trim()).ToArray();

        //Two word per tag maximum (extra words in a tag will be removed).
        for (int i = 0; i < tags.Length; i++)
        {
            List<string> validWords = new List<string>();
            string[] wordsInTag = tags[i].Split(' ');
            if (wordsInTag.Length > 2)
            {
                tags[i] = wordsInTag[0] + " " + wordsInTag[1];
            }
        }
        return tags;
    }

Keep in mind that while your protest does sound intuitive - e.g. that Ruby can be syntactically ambiguous, ergo it is unparseable, it turns out that that doesn't stop us from writing a parser. We can parse most things even if we can't parse the "general case." When we DO encounter something unparseable, the compiler can a) guess or b) fail, hopefully with a message that will help us investigate and rectify the failure.

You point out that Perl's syntax may be worse than Ruby's, and I assume that implies that it is more syntactically ambiguous, ergo, writing a parser should also be impossible for Perl. It turns out that Perl is provably unparseable in the general case - in fact, it's been done rather rigorously: http://www.jeffreykegler.com/Home/perl-and-undecidability

Regardless of Perl's general unparseability, we have compilers for Perl and even large projects manage to compile to what appear to be functional executables. The same is true for Ruby.

I wrote this comment mostly a reminder that while something may appear to be insoluble, we may be able to solve for sufficient cases that we don't care about the rest, particularly if we have an oracle to fix the number of cases that we can't solve. (In this case, the oracle is the developer.)

1. How blocks work, and how their minimalist syntax is beautiful. You see absolute value bars but believe me, getting used to that barebones function syntax is a gift. (No other programming language that I know of has an absolute value operator with vertical bars so it is not as hard as you think.)

2. Every time you see a dot, do NOT think attribute access. Think message sending a la Smalltalk.

Suddenly then, things like the tags.collect! line become pretty for encapsulating a callback on one line unlike the ugly function() {} crud of JavaScript, and things like defining a newtags= method become sensible, because everything including traditional attribute getting and setting reduces to message passing.

Huh. You just rekindled my interest in learning Ruby. Learning Smalltalk was pretty mind-expanding.

Oh, the inability to parse Ruby shouldn't be held against it. It has (at the least) a context-sensitive grammar. So do lots of languages, including HTML and perl.

Not being able to parse it doesn't really mean what you think it means. It just means that in order to figure out what it does programmatically, you have to evaluate it. Its unparseability makes certain things impossible, like writing a perfect syntax highlighter. Also makes building certain tools you'd normally see in an IDE difficult.

That said, I do really enjoy reading this code. It's indeed very, very clean!

Now it looks like something happened, and you've got no site, and thousands of people trying to access it!

I can understand why the developer viewed you as 'trashing' his work, you claimed it as a phishing expedition. That'd make the best of us upset. I see you've sorted it out between you which is great, and I hope others look at this exchange and get some good takeaway from it.

It's a static web site hosting, exactly what "security holes" could we be talking about? Not theoretical holes, that you could technically exploit on the 45th blue moon of the century, things that might actually happen.

Not to nit-pick, but it's never the last security-related bug :)

Guaranteed not.

I don't mean for you in particular, security requires constant vigilance.

(I'm not just being snarky, I have run a freenet out of pocket for sixteen years because people's urls and email addresses are important to not lose.)

It indeed goes without saying, since you don't mention this on the site.