1. 42
  1.  

  2. 15

    ugh. https://github.com/bdmac/strong_password/blob/master/CHANGELOG#L1

    The CHANGELOG doesn’t mention this rubygems incident and it ALSO breaks BC. Maybe I’m overly pessimistic and paranoid but I’d have republished 0.0.6 unchanged as 0.0.8 and released anything new as 0.1.0.

    1. 1

      Exactly. If you’re doing breaking changes, you shouldn’t increment the patch version…

      1. 4

        Pre-1.0.0 releases in semantic versioning have no defined compatibility requirements with any other version.

        Though, if this module is being used in production, a 1.0.0 release should be cut. Even more so since this is open source and you don’t know all of the consumers.

        e: sp

        1. 2

          fair, that’s a good point.

        2. 2

          With a 0.0.x I wouldn’t call that a problem, really. It just irks me that I suppose a lot of people might think not to upgrade from 0.0.7 although they should. Or would gem warn you that the installed version was yanked?

      2. 6

        Only tool I have seen addressing these issues in a way that might work:

        https://github.com/dpc/crev

        1. 5

          In a few years we will be looking back with envy at the golden age of open source. People where doing things because they could and where enthusiast about it. People trusted each-other.

          We are not done yet but it’s slowly eroding away.

          1. 3

            While the Ruby scripting language and RoR aren’t as popular as they once were, they’re still embedded in numerous enterprise development environments, many of which might have used the default library, strong_password, in its infected version 0.0.7.

            (my emphasis)

            Call me old-fashioned, but I’d be leery to trust my password verification to a library with a version number not close to 1 ;)

            1. 3

              I don’t see your point, in that case the infected version would have just been 1.0.1 . The whole issue was someone hijacked the repository and published a new version.

              1. 5

                You’re right, the version number is not in any way sufficient to guarantee correctness.

                My point was more that, faced with the requirement to include a password strength checker and perusing the list of gems, I’d pass on a gem with that low of a version number - on the assumption that it hasn’t really been tested enough. Again, someone could just start their versioning at 1 and “defeat” this heuristic.

                1. 7

                  Oracle defeated this heuristic twice over: The Oracle database started at version 2.

            2. 0

              Debian’s policy is a direct mapping between Rust crate and package versions: https://wiki.debian.org/Teams/RustPackaging/Policy

              Perhaps it will fall to Debian Developers to monitor what happens in the librust packages under their care? It’s hardly fair, but they may be the only ones paying attention.

              1. 2

                …did you mean to post this on a different thread?