Building security updates

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

Our build infrastructure[1] has been designed with transparency as one
of main goals - so that anyone can verify (to some degree) what were
built from what sources. This is a half-measure until reproducible
builds are implemented. Central point of this design is to have
"append-only"(*), public log of actions leading to signing something with
Qubes release signing key. This is done by allowing access to sign
operation (split-gpg) only when a build log was uploaded to public
github repository. There are few catches (described in [1]), but
generally those properties are preserved.

Now, the problem is this approach prevent us from building packages with
security fixes, while advisory is still under embargo - because building
it would reveal information about the vulnerability (at least patch
names and which issues applies to Qubes OS, but probably more). This
specifically applies to Xen bugs - where we're on pre-disclosure list.

Currently we simply delay package upload for this reason. When embargo
is lifted we start the build process in official infrastructure(**) and
packages are uploaded as soon as it finishes. This takes about half
an hour for Xen or Linux kernel (this time - QSB#31 it required both, so
all packages were available with 1h delay). Previously we had notice
about this delay in advisory, this time we have delayed publishing the
advisory.

There are few solutions to this issue:

1. Do nothing - have fixed packages delayed by about 1h in the worst
case.

2. Change our infrastructure to allow building packages without
immediately uploading build log to public place. Instead, hold build log
somewhere (private git repository?) and publish it only when publishing
package itself. Q: when package should be signed - when build log is
published (like in current configuration), or when it is only uploaded
to some intermediate storage (to be published later)?

3. Something else?

The second point would require few additional adjustments:

- Build process is triggered by pushing signed version tag to
public repository. In this case, it would also require some other
method - probably private repository.

- After package build, it is immediately uploaded to
"current-testing" repository. We'd need some method to delay this
action (probably similar to that preventing publishing build log)

- There is one "build-logs" VM handling build logs, enforcing
"append-only" property. There is (intentionally) no way to
influence its behavior from build VM. We'd need either another
build-logs VM (and some method to synchronize between them), or some
other method to prevent publishing build log (some argument to
qubesbuilder.BuildLog service? a different service?)

Generally, fixing the 1h delay issue is probably doable, but IMHO may
introduce some corner cases when build log for some package is not
published. So, the question is what is more important here?

Note that this issue will go away after implementing reproducible
builds, because there will be better method of validating if given
package really comes from the right sources. Relying for this on
published build log works only under multiple conditions, like trusting
us that we actually use the configuration as advertised.

(*) "Append-only" property is enforced by sending log to a different VM
in real-time.
(**) This is independent of building packages privately earlier to test
it.

[1] https://github.com/QubesOS/qubes-infrastructure/#detailed-description-of-the-infrastructure

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZSbNIAAoJENuP0xzK19csFlsH/0cyWH1RcPEV6zPUR0syYdkM
CZahREC749Em+R6oOfmsxj96eJ9+lF7LaXBgbHEmrSSKRg5c60LNLTE0nCeh82h9
16rP/JVQEaWIuhZ8285XSKoikuw3uvoINJp/cif0LvrWmNSAXTdYTpoPepvOJLde
aje1W5eMc9UTFVOqVBehT3NDYTH3DW9SFfnTBnhJUN1fUGYidn3oM0PZToZPrcCy
c8iCES2VDXlX3zUvIlPrxdEJM8HgcC4Vv4IZcHUEa+UtwCDoTNbRcyv+3VfEQ6qe
F3DC+nvz/4yvW2F/NDF9Mb1F3yJLwlEvd7Y/TxNhUDiLGVBZJYJA5xDYjxIvEMI=
=94NV
-----END PGP SIGNATURE-----

[Chris Laprise]

I am more concerned with unforeseen incompatibilities between Qubes and
upstream patches causing an extended delay where regular users can't
install them.

If the Qubes team has access to the patches in advance and can do
preliminary testing before the embargo is lifted, then I guess that's OK
because delays for user updates will then be minimized. In addition, an
hour delay for building doesn't seem too bad.

As long as users can enable *security-testing (or just *security) repo
to receive timely security updates (without exposing themselves to
feature instability in *current-testing) this seems fair.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Holger Levsen]

On Wed, Jun 21, 2017 at 01:44:07AM +0200, Marek Marczykowski-Górecki wrote:
> 1. Do nothing - have fixed packages delayed by about 1h in the worst
> case.

I think that's entirely fine, especially as this is a (time) limited
"solution". (the issue will go away with reproducible builds…)

Fixing this seems to be quite some work and result in a somewhat suboptimal
solution too (bugs/glitches possible…), for a small gain, which will benefit
very few people. (I'd dare to say that 99% of the users update later than in
the first hour…)

There are bigger fish to fry :-)


--
cheers,
Holger