1. 11
  1.  

  2. 3

    A proposal: extend Subresource integrity to links

    Actually this is already mentioned in Subresource integrity spec for some time:

    Note: A future revision of this specification is likely to include integrity support for all possible subresources, i.e., a, audio, embed, iframe, img, link, object, script, source, track, and video elements.

    It’s a nice idea but (there is always but) it protects only against accidental download corruption. As for software all major operating systems already have an “integrity validation” using Code Signing X.509 certificates that not only validate the file is intact but some other, more important things too.

    1. 2

      What a wonderful idea! Security without inconveniencing the user. Maybe at least curl could start silently checking these known checksums, via the PEP format mentioned by twm above.

      1. 2

        This looks really useful to me. I’d love it if browsers automated hash checking as it’s quite tedious to do manually (and easy to mess up, as the paper notes!).

        Another bit of prior art is the Python package index spec, PEP 503, which embeds this information in the link href:

        The URL SHOULD include a hash in the form of an URL fragment with the following syntax: #<hashname>=<hashvalue>, where <hashname> is the lowercase name of the hash function (such as sha256) and <hashvalue> is the hex encoded digest.

        It would also be nice if a HTTP header with this information were in common use (then CLI tools like wget could automatically verify), but I suppose the failure of the Content-MD5 demonstrates that this won’t happen.

        1. 2

          A comment fit for the “What are you working on this week?” thread, I am developing qwerty.sh as a curl-ready POSIX-portable shell program to download, verify, and unpack files with a single command (on Unix systems). The README includes examples.

          This provides an alternative to the ever-common curl ... | sh copy/paste installation instructions for developer tools, and I use it regularly as part of a workflow to have all projects go from a fresh clone to a fully integrated environment in a single-command repeatable build (e.g. with one-liners in a Makefile to download/verify/unpack external resources).

          I test qwerty.sh on Ubuntu GNU/Linux, Mac OS X, and FreeBSD.

          1. 2

            Only 23.4% of respondents even remembered seeing checksums on websites they had used in the past. Only 5.2% of respondents select the correct answer (out of six possible options including ‘not sure’ and ‘other’) when asked what checksums were for.

            I doubt these numbers, they seem far too high to me if they chose “average users”.

            In any case there’s a very simple answer to all of this: Use HTTPS(+HSTS) everywhere and ignore the checksums.

            The idea of extending SRI to downloads has some merit in case the downloads are hosted separately on a less trusted host. But that’s a more obscure scenario. HTTPS does 99% of what you want to do with checksums and works without any extra user interaction.

            1. 1

              The idea of extending SRI to downloads has some merit in case the downloads are hosted separately on a less trusted host.

              Websites pulling in 3rd party content and JS is getting more common every day.