Write a script to build a package when proper signed version tag is pushed

[marmarek]

Script the build phase of release workflow: https://github.com/QubesOS/qubes-builder/blob/master/doc/ReleaseManagerWorkflow.md#building-and-signing-the-packages

[marmarek]

A prototype: https://github.com/QubesOS/qubes-builder/compare/master...marmarek:auto-build It also automatically upload build logs to https://github.com/QubesOS/build-logs Missing parts:

• plugging into github hook handler (actually writing hook handler, which would call appropriate qrexec service triggering the script)
• handling build failures - I think it should create github issue (in separate repository - don't spam qubes-issues!) with a link to build log; currently build script doesn't have easy way to get build log filename (but can upload a second copy of the log from qubes-builder/build-logs/, for example to gist).
• consider adding some github commit status/deployment status feedback - I don't really know how it works and if could be useful (build it's not directly related to pull request)

@woju this script could use some review...

Also, it incorporate build log handling done by @HW42 as part of #2023

[andrewdavidwong]

handling build failures - I think it should create github issue (in separate repository - don't spam qubes-issues!) with a link to build log

How about QubesOS/build-issues?

consider adding some github commit status/deployment status feedback - I don't really know how it works and if could be useful (build it's not directly related to pull request)

Maybe a Gist would work for this? (Or maybe just at first, to trial it.)

[jpouellet]

If such builds are automated, then I think the infrastructure on which they are taking place should be discussed at some point.

[marmarek]

How about QubesOS/build-issues?

:+1:

Maybe a Gist would work for this? (Or maybe just at first, to trial it.)

I don't think it is related. Build logs are already uploaded to https://github.com/QubesOS/build-logs. I was talking about https://developer.github.com/v3/repos/deployments/#create-a-deployment-status

If such builds are automated, then I think the infrastructure on which they are taking place should be discussed at some point.

What exactly do you have in mind? Where it will be running? The same as currently - on a Qubes machine(s), in a location we have physical control over. The only thing that change is how the build is triggered - "arrow up & enter" vs "pushing signed tag".

Detecting when signed tag is pushed may look non-trivial, but github allows registering hooks (an URL where events are sent using POST). It's enough to terminate HTTP(s) in NetVM and call qrexec service from there to trigger a script discussed here. It doesn't need to parse content of that POST, as the script will look what is new in the repository anyway (and do nothing, if nothing interesting there). In practice this mechanism needs to be repeated, as the machine isn't directly reachable from the internet (the thing reachable from the internet triggers a simple network request to a NetVM of the target machine).

[adrelanos]

Marek Marczykowski-Górecki:

Detecting when signed tag is pushed may look non-trivial, but github allows registering hooks (an URL where events are sent using POST). It's enough to terminate HTTP(s) in NetVM and call qrexec service from there to trigger a script discussed here. It doesn't need to parse content of that POST, as the script will look what is new in the repository anyway (and do nothing, if nothing interesting there).

Or perhaps skip the notification and just keep checking in an interval that doesn't trigger API spam protection if that is doable.

In practice this mechanism needs to be repeated, as the machine isn't directly reachable from the internet (the thing reachable from the internet triggers a simple network request to a NetVM of the target machine).

Or perhaps "cheat". Use a Tor onion service. I am using them for simple NAT traversal. Speed could perhaps also be optimized by using non-anonymous (single hop) onion services as well as single hop onion circuits.

[jpouellet]

If such builds are automated, then I think the infrastructure on which they are taking place should be discussed at some point.

What exactly do you have in mind? Where it will be running? The same as currently - on a Qubes machine(s), in a location we have physical control over. The only thing that change is how the build is triggered - "arrow up & enter" vs "pushing signed tag".

I don't know enough about on what machines Qubes things are currently built to ask the right question.

@marmarek I suppose all Qubes users already transitively trust the physical security of your personal laptop to some (large) extent already. If builds are currently done there, and they are being transitioned to ${server} in ${datacenter} in ${jurisdiction}, then that is noteworthy to me.

Until reproducible builds are a reality, it might be nice to have some statement on the website to inform users about what build infrastructure they are trusting by using the official Qubes ISOs - unless you want to keep that information secret for opsec reasons, which I can totally understand.

[marmarek]

Or perhaps "cheat". Use a Tor onion service. I am using them for simple NAT traversal. Speed could perhaps also be optimized by using non-anonymous (single hop) onion services as well as single hop onion circuits.

That wouldn't work here, as github can't contact to Tor onion service...

[adrelanos]

Marek Marczykowski-Górecki:

Or perhaps "cheat". Use a Tor onion service. I am using them for simple NAT traversal. Speed could perhaps also be optimized by using non-anonymous (single hop) onion services as well as single hop onion circuits.

That wouldn't work here, as github can't contact to Tor onion service...

I see.

For NAT traversal, alternatively there is also pagekite and also VPN services that provide port forwarding (regular end-user account would suffice due to low traffic, I guess).

[marmarek]

Until reproducible builds are a reality, it might be nice to have some statement on the website to inform users about what build infrastructure they are trusting by using the official Qubes ISOs - unless you want to keep that information secret for opsec reasons, which I can totally understand.

I think you may like to read https://www.qubes-os.org/news/2016/05/30/build-security/. There is also some statement on this in http://blog.invisiblethings.org/2015/04/23/qubes-30rc1-and-roadmap.html

We're not strictly against publishing some information on build infrastructure, but I think some details should be kept secret (for example exact location of the machine(s) itself). I can say it isn't the same machine I use daily for mails etc (and also travel with). Actually we're considering preparing build infrastructure for Qubes 4.0 using salt stack and then publishing this configuration. The script discussed here is part of this infrastructure.

[woju]

I put my comments on the commit diff, which unfortunately looks badly on the diff you linked. Otherwise looks good to me.

[marmarek]

Actually we're considering preparing build infrastructure for Qubes 4.0 using salt stack and then publishing this configuration. The script discussed here is part of this infrastructure.

Created #2602 for this.