Nuts and Bolts report, 2014-07-22

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Nuts And Bolts Party, 2014-07-22
=====================================

in attendance: Zooko (scribe), Daira, Zancas

theme: disable assembly optimizations in pycryptopp

In the history of pycryptopp, about 1/2 of the bugs have been due to
the asm optimizations in Crypto++. And, the C++ implementation is
already fast enough.

In order to make changes to the pycryptopp build system, we first need
to write a unit test of the configuration interface described in
https://github.com/zooko/pycryptopp/commit/5c2e0f729a25eee8f374ff79a9299a818c378bc2#commitcomment-3005081
.

In order to write such a unit test, we need to set up automated
running of unit tests of packaging, as described in here:

* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2050# Expand
HowToWriteTests to packaging and distribution tests
* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2049# Decide where
"packaging tests" should live.

Daira argued that maybe we should disable asm optimizations
unilaterally instead of supporting an optional "build with asm
optimizations" feature, but we decided that other packagers (e.g.
Debian) are certainly going to want that and we might as well support
it ourselves instead of making them patch it in.

Then we switched topics, because Daira is discouraged about packaging
issues of all sorts. So we asked: what does Daira like? What would be
fun? The answer is: harden the WUI!

So Daira and Zancas started working on:

* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2136# Use
Content-Security-Policy to harden the WUI
* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1797# WUI: view
content in an HTML5 sandboxed iframe

(Zooko kept poking at the pycryptopp/assembly-optimizations/packaging
stuff on the side for the rest of Nuts and Bolts, because he — for
whatever reason — is *not* currently despairing about software
packaging.)

Daira looked through our ticket garden
(https://tahoe-lafs.org/trac/tahoe-lafs/wiki/ViewTickets) for other
headers that we should send to harden security. She decided that
preventing content-type sniffing
(https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1455) was too complex
and put it aside for now. She decided to include the option to prevent
frame-busting. The reason we're doing both at once is that CSP sandbox
and frame-busting-prevention are complementary to one another.


Zancas admired the buildbot's "console" page:
https://tahoe-lafs.org/buildbot-tahoe-lafs/console but it appears to
have a bug. The top row is about a git commit "fac1f0d55a7c...", but
the cell showing the result of the build for the "FreeStorm
CentOS6-amd64" builder shows this build:
https://tahoe-lafs.org/buildbot-tahoe-lafs/builders/FreeStorm%20CentOS6-amd64/builds/0
which describes git commit "4889129f3732219cb9cedb1eb27dec3da3f22db2".
That seems inconsistent. Those two git commits should be the same as
one another, but are different. Is this a bug in buildbot?


Zooko wrote a catalog of all pycryptopp bugs ever and classified
whether they were security-relevant or not and whether they would have
been avoided by disabling assembly:

https://tahoe-lafs.org/pipermail/tahoe-dev/2014-July/009134.html





-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.