1. 26

    https://hackerone.com/reports/293359#activity-2203160 via https://twitter.com/infosec_au/status/945048806290321408 seems to at least shed a bit more light on things. I don’t find this kind of behavior to be OK at all:

    ”Oh my God.

    Are you seriously the Program Manager for Uber’s Security Division, with a 2013 psych degree and zero relevant industry experience other than technical recruiting?

    LULZ”

    1. 6

      The real impact with this vulnerability is the lack of rate limiting and/or IP address blacklisting for multiple successive failed authentication attempts, both issues of which were not mentioned within your summary dismissal of the report. Further, without exhaustive entropy analysis of the PRNG that feeds your token generation process, hand waving about 128 bits is meaningless if there are any discernible patterns that can be picked up in the PRNG.

      Hrm. He really wants to be paid for this?

      1. 3

        I mean, it’s a lot better than, say, promising a minimum of 500 for unlisted vulnerabilities and then repeatedly not paying it. Also, that’s not an unfair critique–if you’re a program manager in a field, I’d expect some relevant experience. Or, maybe, we should be more careful about handing out titles like program manager, project manager, product manager, etc. (a common issue outside of security!).

        At the core of it, it seems like the fellow dutifully tried to get some low-hanging fruit and was rebuffed, multiple times. This was compounded when the issues were closed as duplicate or known or unimportant or whatever…it’s impossible to tell the difference from the outside between a good actor saying “okay this is not something we care about” and a bad actor just wanting to save 500 bucks/save face.

        Like, the correct thing to have done would have been to say “Hey, thanks for reporting that, we’re not sure that that’s a priority concern right now but here’s some amount of money/free t-shirt/uber credits, please keep at it–trying looking .”

        The fact that the company was happy to accept the work product but wouldn’t compensate the person for what sounded like hours and hours of work is a very bad showing.

        1. 9

          Also, that’s not an unfair critique–if you’re a program manager in a field, I’d expect some relevant experience.

          No-one deserves to be talked to in that way, in any context, but especially not in a professional one.

          Or, maybe, we should be more careful about handing out titles like program manager, project manager, product manager, etc. (a common issue outside of security!).

          There is no evidence that the title was “handed out”, especially since we don’t even know what the job description is.

          1. 3
            1. open the hackerone thread
            2. open her profile to find her name
            3. look her up on linkedin

            I don’t presume to know what her job entails or whether or not she’s qualified, but titles should reflect reality or they lose their value. She certainly has a lot of endorsements on linkedin, which often carry more value than formal education.

            It’s “Program Manager, Security” btw.

            1. 2

              There is no evidence that the title was “handed out”, especially since we don’t even know what the job description is.

              There’s no evidence that it wasn’t–the point I’m making is that, due to practices elsewhere in industry, that title doesn’t really mean anything concrete.

        1. 2

          Go doesn’t have a dispatch table, but interface values. It’s literally more of a freestyle dispatcher mechanism that requires some work during interface value assignment — it generates a tiny lookup hash-table for the concrete type it’s pointing to. The assignment is not insanely expensive, so it’s a fair exchange for a more pleasant type system. Ian Lance Taylor has a great blog post about the internals if you’re looking for further reading.

          Yes it does have a dispatch table, and the linked post says it too:

          The table of functions is stored sorted by the name of the method, although the name does not appear in the table. Calling a method on an interface means calling a specific entry in this table, where the entry to call is known at compile time. Thus the table of functions is essentially the same as a C++ virtual function table, and calling a method on an interface requires the same series of steps as calling a C++ virtual function: load the address of the virtual table, load a specific entry in the table, and call it.

          1. 3

            It’s the case of gccgo maybe not go native compiler

            1. 1

              If one wants run-time subtyping, one have no choice but to include a dispatch table.

            2. 3

              You should point it out in the Medium post so that she can correct it. I doubt she’ll see it here :).

              1. 3

                I saw it and made it clearer.

              2. 2

                The post should have said Go doesn’t have a traditional dispatch table, the ivalue mechanism I’m explaining is also dispatching. I made it more obvious.

                The point of the Go’s type system is the way it organizes the table, a method via an interface has its own entry that’s not associated with a parent type.

              1. 1

                The design docs briefly mention Calvin (“This is another great paper.”), but without a close comparison. I’d be interested[1] in hearing the Cockroach team’s views on the tradeoffs they make differently etc. Are the replication and consistency guarantees the same? Throughput and latency?

                [1] Since I’m speaking on Calvin next week: http://www.meetup.com/papers-we-love-too/events/171291972.

                1. 2

                  You are welcome to ask any clarifying questions on the list – cockroach-db@googlegroups.com

                  To be honest we’re at such an early stage that we may not have answers for you, but there’s no harm in asking.

                1. 3

                  That sounds like the data store a lot of people would want! I’m curious to know who is behind this project, because it cannot be just a hobby project.

                  1. 1

                    See https://github.com/cockroachdb/cockroach/graphs/contributors.

                    FWIW one of my coworkers identified one of those as a former googler.

                    1. 1

                      I’m under the impression this comes from Poptip, but it’s just my impression :)

                      1. 4

                        andybons from Poptip, here. You may have seen me in the contributor list as the top committer, but if you look closely at the stats, Spencer has written the most code and wrote the original design document linked to in the README. He is the mad scientist behind Cockroach.

                        Poptip has been supportive, but it was not born within our walls and I do not work on it full-time.

                        From the list of authors, everyone works at Square, Inc. now and we are all ex-Google (except for one person). It is more than a side-project, but I, personally, don’t have the domain expertise that the other authors have within this space, so it has largely been a fun learning experience for me.

                        I hope this clarifies things a bit. I don’t want to speak for the other authors regarding some of the questions raised, but I can say they are brilliant people who I am lucky to work with.

                        1. 2

                          Thanks Andrew: yes, it clarifies things a lot! This is an ambitious project: kudos for tackling this. Now that I know most authors work at Square, I understand better the emphasis on the ACID properties which, I guess, are quite useful to them.