Hey,
> How long does it take to get a successful result of the verification
extension on your machine?
It took half an hour for us. We haven't processed such large SHA files
previously so I wasn't aware that it could take this long. Again, the
problem here is that the javascript implementation of the SHA algo is not
that efficient enough. We can try some other SHA libraries but I don't
expect they will make a considerable difference.
> Did you check the portability of the pinning mechanism when we first asked
you about the feasibility of porting the extension to WebExtensions?
No, tbh. I thought the core functionality of the extension is to only
verify checksum. It was difficult and time consuming for us to understand
all the code so we only focused on core functionality. But I pointed out my
understanding of the extension during our conversation just to make sure
I'm not missing anything:
>Just want to make sure we are on the same page. The main functionality
would be:
> - User will download the image from website.
> - After the download is complete, user will navigate to the verification
page of extension (say by clicking on extension icon).
>- User will select the downloaded file and extension will let user know if
the image is valid or not.
> So do you confirm that we won't be able to do certificate pining in the
new extension?
Yeah, unfortunately not possible with webextensions.
On Thu, Oct 19, 2017 at 3:59 PM, sajolida <sajolida@???> wrote:
> Uzair Farooq:
> > Hey,
>
> Hey!
>
> >> But then the extension doesn't work: it takes a full core starts eating
> > as much RAM as it can. See this screencast:
> >
> > The SHA 256 takes time and CPU to compute for such large files. In the
> > previous add-on we were using a native method (which is not supported in
> > web extensions) which was probably fast because it was a native methods
> are
> > native are not bound to Javascript while the SHA libs must javascript to
> > compute hash.
> >
> > What we can do as a workaround is that we compute hash in a webworker. A
> > web worker won't hang the page/browser but it'll still take CPU and RAM.
>
> Regarding the RAM, today I see that the amount of RAM is topped at
> ~200MiB (fluctuating between 150MB and 200MB). Which is a whole lot but
> at least not continuously increasing until it crashes, which is what I
> thought at first.
>
> Regarding the execution time, I tried again on my machine: it's been
> running for 15 minutes and still eating a whole core.
>
> How long does it take to get a successful result of the verification
> extension on your machine?
>
> Because maybe I'm facing a bug and not a normal run of the extension...
>
> With the current extension, the checksum is calculated within seconds
> (I didn't ever counted how many because it went so fast). On the
> command line computing the checksum takes 11 seconds.
>
> >> That you are embedding a crypto library to compute the SHA256
> > (scripts/vendor/sha256.js) while the previous code didn't do that.
> > In tails-download-and-verify/lib/hash.js he seems to use a build-in
> > function from Firefox with:
> >
> > This is not possible in web extensions, that api only works Add-on SD.
>
> Ok.
>
> >> That you don't pin on the SSL certificate of our certificate authority
> > (Let's Encrypt).
> >
> > This library is also addon SDK specific and is not supported in Web
> > Extensions.
>
> Did you check the portability of the pinning mechanism when we first
> asked you about the feasibility of porting the extension to WebExtensions?
>
> To be honest, I quite worried to learn only now that the two crypto
> operations that are in the design of the extension (checksum and
> certificate pining) are not available in Web Extension while I pointed
> you to the code and the design back in May... while the deadline for the
> new extension is November 16.
>
> > There's this certificate pinning feature in HTML5
> > https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning in
> > which pinned certificates are returned in header of request when user
> > visits the site first time.
>
> We already have HSTS activated on our website and have plans to work on
> having HPKP: https://labs.riseup.net/code/issues/9026 but as you can see
> in #note-7 it's quite complex as it requires careful backups and
> recovery plans. Definitely not something we can have before November 16.
>
> So do you confirm that we won't be able to do certificate pining in the
> new extension?
>
> > It'd have been easier for us to reuse Giorgio's code instead of rewriting
> > from scratch but because of the fact that a lot of API's being used in
> > Giorgio's
> > code are add-on SDK specific and aren't supported in WebExtensions, it
> was
> > better to rewrite.
>
> I can understand that, thanks for the clarification.
>
