1. 38

  2. 12

    At the SVN project we’re still discussing what needs to be done.

    For the time being it is advisable to not check these files into production databases of … well, … anything.

    1. 2

      Don’t you have backups?

      1. 4

        Better to not break something intentionally than to break it and restore a backup.

        1. 1

          Well, yes.

          But maybe the one who committed it didn’t realize what it could do. And for the record, my question wasn’t trolling, just a legitimate question.

          1. 5

            It’s weird to ask stsp though. I wouldn’t assume he’s in charge of backups, so it comes across as snarkier than you may have intended. (not the downvoter)

        2. 2

          The “you” here is murky/unrelated.

          Above, stsp refers to general advice for all owners of all SVN repos. This is authoritative advice from the development team that it sounds like “no workaround yet exists, don’t repeat this mistake because recovery is difficult/impossible.”

      2. 6

        The files have been deleted so webkit’s svn checkout works again: https://lists.webkit.org/pipermail/webkit-dev/2017-February/028793.html

        WIP SVN discussion about the underlying issues: https://svn.haxx.se/dev/archive-2017-02/0168.shtml

        1. 3

          There is now a hook script (/bin/sh only at present) which rejects shattered.io PDFs:


          1. 1

            That is for the specific PDFs generated by Google, but it’s possible to create arbitrary PDFs with matching SHA1s using the same attack, with a tool like this.

            1. 3

              Don’t they all have the same 320 byte prefix?

              1. 1

                Ah, my bad, I didn’t read the code carefully and thought it was just checking the sha1 of the entire file. They do have the same header.

                1. 3

                  What’s kind of ironic is that the script uses the SHA1 of those 320 bytes to detect them :)