Re: [Tails-dev] HTML prototype for new download page
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. > 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. > 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. 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. 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. On Sun, Oct 15, 2017 at 10:07 PM, sajolida wrote: > Uzair Farooq: > > We made the commit on top of existing repo, here > > https://github.com/usman-subhani/Tails-repos > > Yeah, I like that! > > I merged your changes in the production website so you can test it from: > > http://tails.boum.org/install/download_2 > > I also: > > - Hid the "Update extension" that was displayed by default. > - Hid the that you added for the file chooser. > > So far so good! > > > Here's how to install Firefox extension > > https://developer.mozilla.org/en-US/Add-ons/WebExtensions/ > Temporary_Installation_in_Firefox > > . There's a video tutorial at the end. > > I tried this as well and installing the extension like this works, yeah! > > But then the extension doesn't work: it takes a full core starts eating > as much RAM as it can. See this screencast: > > https://dl.poivron.org/n7exagegay7wmynbugh4-ekzsjrqmajdq5lyn > > Also, I see in the report for the extension itself that you decided to > start a code base from scratch. Our initial idea was to instead base > your work on the current code base from Giorgio Maone, but I also > understand that given the fact that the scope of the extension has been > drastically reduced after we removed the download from it and that the > download page has been completely rewritten, it might make more sense > for you to start from scratch. So that's not a problem as such. > > Still, as initial comments (because I can't really understand your code > beyond that), I see: > > - 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: > > let hasher = Cc["@mozilla.org/security/hash;1"] > .createInstance(Ci.nsICryptoHash); > hasher.init(hasher.SHA256); > > https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/ > Reference/Interface/nsICryptoHash > > If this is still possible with WebExtensions, why not do that? > > Because auditing and maintaining crypto primitives is not really > something we want to go into... > > - That you don't pin on the SSL certificate of our certificate authority > (Let's Encrypt). > > See: > > - https://tails.boum.org/blueprint/bootstrapping/extension/#index5h2 > - tails-download-and-verify/lib/cert-pinner.js in the current code > > I'm sorry if I didn't point you to this document before but I didn't > expect that you would rewrite the internals of the verification > mechanism and would rather reuse Giorgio's code. > ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Improving ikiwiki upstream [was: CSS fixes]
Hi! sajolida: > intrigeri: >> sajolida: >>> CSS is notoriously painful to work with in the project because nobody >>> likes it, our CSS are super messy, ikiwiki is crap in this regard, etc. >> >> Taking a step back. >> I'd be happy to help translate "ikiwiki is crap in this regard" into >> actionable bug reports, but I can't do it alone. > > I admit that I'm very bad at reporting bugs to ikiwiki but in my > imaginary at least, ikiwiki is not a very active upstream project > either. So I thought that the bugs that I might fill would just rot > there forever. Same here. > Now: > > - Improving our website in general, like reporting and fixing bugs in > ikiwiki is nowhere in our core budget so it would have to be volunteer > time, and at least to me, not at all exciting time. Maybe that's a > problem in our core budget but right now changes happen on the website > mostly through technical writing (which is about content), ideally > through UX (tiny tiny bits), as side effect of other work > (installation assistant, donation campaign, etc.). But right now > nobody is really responsible for this work I think. > > - The limitations I suffer the most from in ikiwiki seem, at first > sight, too deep to deserve a bug report. The "templating" system > extremely primitive and my suggestion would be to replacing > completely, it has no CSS framework, it's not designed for content > reuse, etc. But I trust you intrigeri to help me frame this as > more pragmatic fixes that can happen before the year 2525. What my problems with ikiwiki were while working on the donation campaign: - make it easy to add parameters to URLs when building links, i.e. [[linktext|path/to/link]] should be able to also build links that resemble [[linktext|path/to/link?param=something]] and let's go crazy: [[linktext|path/to/link?param=something&somethingelse]] - the template language can only check for boolean variables while it should be possible to check for a value, i.e. @if var == (string) value@. Currently ikiwiki can only either print variables or check if they are set or not. This is the part I found extremely limiting. - I want to be able to include template parts, or to be more precise, .mdwn files, within page.tmpl based on some if statement. These template parts should be translateable. > What's the next step here and who will do it? Call for a voice meeting > with intrigeri, u, and me? Take a few hours during a sprint to talk > about this? I'm at least not ready to take long hours to write emails > about this and would need synchronous communication. I can create bug reports out of these three things I guess. No need for a meeting from my POV. Cheers! u. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Issue #9700 (Torbutton preset)
Dear intrigeri, > I'll mention a few issues below but this will > need a full review by our technical writers at some point (and when > we're there you'll want to follow > https://tails.boum.org/contribute/merge_policy/#submit). Thanks for the constructive (and rapid) feedback, and for emphasizing that the style of the wiki should stay consistent. I must confess most of my previous experience in technical documentation has been in a field in which the passive voice was heavily overused, to the point of sounding pompous at times. (I've just done it again...) I'll keep an eye on it in the future :) > I think this approach is good enough for a first iteration if, and > only if, there's a solid plan to come up with something better soon > after, because this approach has a few serious issues that I don't > want to see in Tails for more than a major release cycle (~3 months): Absolutely, this proposed GNOME autostart hack of mine was purely intended as a very quick fix to temporarily deal with a few users concerned about JavaScript being (re)enabled at every boot (since there are enough 'duplicate' and 'rejected' tickets about this tedious matter in our Redmine already. ) > - It makes the doc unnecessarily complicated for the vast majority of > users who'll have to skip the added tip. My first instinct was just to document the creation of a bash script under ~/Persistent, that would run at boot through by means of a .desktop autostart file. I figured, however, that if a user were able to do that, he/she wouldn't need my tip in the first place. > Now, our next major release is scheduled for March 6, so you have > plenty of time to implement something better :) Out of your proposals from last week, I think a separate configurable GUI option in the Configure Tails Persistence dialog, such as "Torbutton security slider setting" may be the most future- and upgrade-proof from a developer's point of view. I'll get out my developer hat and just focus on this from now on. :) > I believe the same result can be achieved with one single command > (instead of 3) and without the $_ bashism: > > install -D --mode 0700 /dev/null \ > >/live/persistence/TailsData_unlocked/dotfiles/.config/autostart/torbutton.desktop I agree, using install is wiser. The less bash 'punctuation' the better, it can make even file manipulation look obscure and downright suspicious to those who don't work with linux. > I think we use "start" instead of "boot", please check the terminology > we commonly use elsewhere in our doc. Also, please avoid passive voice > and technical details that are not needed (e.g. I bet most users don't > know that "the amnesia user" is themselves, so "you" would be more > straightforward to understand). Agreed, I'll work on my style to make more succinct and match the rest of the wiki. > I don't get it: you're calling bash only to call echo, and the command > output redirection is outside of the argument passed to bash -c. > Either we need bash to do the ">" (and then >prefs.js must be passed > to -c) or we don't (and then we can drop "bash -c"), no? Both the script to generate the .desktop file, and the Exec= value itself are very convoluted, I concur. They're the product of far too much testing and tweaking to get around the hideous limitations imposed by Gnome's .desktop launchers. Normally I'm a real fan of scripts that can be understood at a glance, but I had a terrible time trying to get a launcher do something as simple as reliably echo out a multi-line file. The spec for launchers is so limited that even wrapping a command with a long path to avoid deforming our wiki doesn't appear to be supported. Having to escape single quotes within nested quotes felt so hacky, that at one point I was ready to change course and just instruct a user to put bash script in ~/Persistent and autorun that. I guess launchers are designed to be launchers, and not scripts, so my desire to be 'clever' may have been too much of a good thing. Let me know you'd like a polished version of this 'tip' to be included. In any case I'll prepare a good dev/vagrant build environment for myself on Stretch and get to work on a proper Persistence solution that 'just works' for our next major release. As always, any comments and suggestions are much appreciated :) synthe ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Improving ikiwiki upstream [was: CSS fixes]
intrigeri: > sajolida: >> CSS is notoriously painful to work with in the project because nobody >> likes it, our CSS are super messy, ikiwiki is crap in this regard, etc. > > Taking a step back. > > I notice that this year again, we're working around ikiwiki > limitations for the donation campaign. Of course we haven't much > choice given the timing. But it would be nice to translate these > limitations into upstream bug reports *at some point*, otherwise we'll > keep repeating "ikiwiki is crap in this regard" and inventing new > workarounds as long as we use ikiwiki, which makes me sad, makes > everyone involved spend time rather pointlessly, and contradicts our > "Relationship with upstream" statement. > > I'd be happy to help translate "ikiwiki is crap in this regard" into > actionable bug reports, but I can't do it alone. I admit that I'm very bad at reporting bugs to ikiwiki but in my imaginary at least, ikiwiki is not a very active upstream project either. So I thought that the bugs that I might fill would just rot there forever. But I'm happy to spend some time with you to change my mindset here if that leads to less pain in the future. Now: - Improving our website in general, like reporting and fixing bugs in ikiwiki is nowhere in our core budget so it would have to be volunteer time, and at least to me, not at all exciting time. Maybe that's a problem in our core budget but right now changes happen on the website mostly through technical writing (which is about content), ideally through UX (tiny tiny bits), as side effect of other work (installation assistant, donation campaign, etc.). But right now nobody is really responsible for this work I think. - The limitations I suffer the most from in ikiwiki seem, at first sight, too deep to deserve a bug report. The "templating" system extremely primitive and my suggestion would be to replacing completely, it has no CSS framework, it's not designed for content reuse, etc. But I trust you intrigeri to help me frame this as more pragmatic fixes that can happen before the year 2525. What's the next step here and who will do it? Call for a voice meeting with intrigeri, u, and me? Take a few hours during a sprint to talk about this? I'm at least not ready to take long hours to write emails about this and would need synchronous communication. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
