GSoC 2017: Community Bonding Period

[Andrew Morgan]

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

Hello Qubes Community!

I've just found that I've been accepted as part of Summer of Code for
Qubes and I couldn't be more excited. I look forward to working with
my mentor, Marek Marczykowski-Górecki, as well as the rest of the
project contributors.

As we're all aware, today until May 29th is the Community Bonding
period. I do however have some quick questions about what entirely we,
as students, should do at this point:

* Setting up the build environment.

Is there anything needed outside of Qubes Builder's
`make get-sources` command that we need to set up a development
environment? For projects that aren't simply a modification of
an existing Qubes component, should those be created under our
own Github username?

For reference, I found some useful guidelines for patch
submission here:

https://www.qubes-os.org/doc/source-code/#how-to-send-patches

* Team communication
Will any communication with the team happen outside of the
mailing list, IRC or GitHub issues? If so, how can we set it up?

I'm still getting my ZNC connection to Freenode ironed out, but
I pop in regularly under the moniker 'anoa'.

* Weekly reports
I assume the weekly reports start even during the community
bonding period, correct? Any preferable day of the week to post
these?

That's mostly it. Anything else we should be doing during the next few
weeks while we wait to code? :)

Thanks again!

Andrew Morgan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZDCWYAAoJEBdL6rAJ/RdtrOMP/AxkCrCqTv22FZ/kuAcuKGEU
Cbzr4IEzVd+z6sBcKpwnVYNX+tcxflhkKtTyo4zeizrajOzw338arEHXq4OdKnWc
xH7AADWym+V0C9BkLQ/kHxebhx+0wNSum9/dwvvGgKJagYA1BwqBhiTWdiPr2F/n
C1EuteeorjQ0PXBk05aEfg26aNK0hLW22JqOSHNFJchyhohYfqYxaSwT178EvOtM
IdwjikgRnMeHqobPClrdWsC4Kf/akEzTR8r+htHA6uXG7nBy3qelmFL2TxqKnxb9
1usIRW+e/1fTzV0nDjv7Jv825/LuAsivVySYbHLr0TMaDjXnlzVOU7lU0PEXm61R
1NMMmlsnvH21HChuaeDZediVbJ3gBlqH5+C6edsAp/xFugWK/D0V628PDdSa9Inh
TyswcTVQ/0F8SyRBx3CEjiQPCO3hhJ3HSaf83/6L8zL3ku/eVet1LODX7pclnc8V
sKbE9y7mjpaaT3iRtAJvSMjW15rfNeVMP5vyQ4/8DSqcAetW7HBG0I4QcpREwq5X
mcW4CispQD3LmQ+S7CeW1NX663zP5WNx9mtXriC4TDyIAh12Y+ORzPlp1Cz2w0wO
ijSt2na+oTnrWA3ce0O+orUcs5Dgo3kb5JNW3m536xysinkwnfaFQD0wM/NzW3Fm
RaZqSpUN6SSvpbgC6t1Z
=cSvJ
-----END PGP SIGNATURE-----

[John Casey]

Congratulations!

Unfortunately, my Qubes project wasn't accepted, but I look forward to seeing how you guys get on. Nice initiative on this thread, will be helpful for anyone getting started with Qubes contributions.

Best of luck!

John. 

[Marek Marczykowski-Górecki]

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

On Fri, May 05, 2017 at 12:11:21AM -0700, Andrew Morgan wrote:
> Hello Qubes Community!
>
> I've just found that I've been accepted as part of Summer of Code for
> Qubes and I couldn't be more excited. I look forward to working with
> my mentor, Marek Marczykowski-Górecki, as well as the rest of the
> project contributors.

Congratulation!

> As we're all aware, today until May 29th is the Community Bonding
> period. I do however have some quick questions about what entirely we,
> as students, should do at this point:
>
> * Setting up the build environment.
>
> Is there anything needed outside of Qubes Builder's
> `make get-sources` command that we need to set up a development
> environment?

Take a look here:
https://www.qubes-os.org/doc/development-workflow/

For now, the easiest path is to use ./setup script there and choose
"Release 3.2" version. There is also configuration for Qubes 4.0, but
since some of its code is still in devel branches instead of master, it
may not compile...

`make get-sources` will populate qubes-src directory, then you can use it
as your work area. But if you do, later better use `make prepare-merge`
followed by `make do-merge` to update your local version, instead of
`make get-sources` because the later will unconditionally merge upstream
changes (if properly signed), which may result in some unwanted effects
(merge conflicts etc).

> For projects that aren't simply a modification of
> an existing Qubes component, should those be created under our
> own Github username?

Yes, for new repositories, simply create one on your own github account,
and when will be ready, I'll fork it under @QubesOS.

> For reference, I found some useful guidelines for patch
> submission here:
>
> https://www.qubes-os.org/doc/source-code/#how-to-send-patches
>
> * Team communication
> Will any communication with the team happen outside of the
> mailing list, IRC or GitHub issues? If so, how can we set it up?
>
> I'm still getting my ZNC connection to Freenode ironed out, but
> I pop in regularly under the moniker 'anoa'.

Personally, I prefer qubes-devel ML (or emails in general) for
project-related communication. Mostly for having context attached
(either inline, or at least linked to relevant thread) and searchable
archive. For the same reasons github issues also are ok. But some cases
(especially some debugging) are easier to work out using some IM-like
channel - I have IRC setup ("marmarek" on Freenode and OFTC) and can
show up there if needed.

> * Weekly reports
> I assume the weekly reports start even during the community
> bonding period, correct? Any preferable day of the week to post
> these?

In theory, weekly reports are required only in actual coding period. But
if you like to send them also this month, no problem :)

> That's mostly it. Anything else we should be doing during the next few
> weeks while we wait to code? :)

As you mentioned above - setting up development environment is a good
use of this time. Trying to build something, test how to deploy changes
for testing etc.

- --
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

iQEcBAEBCAAGBQJZDP6lAAoJENuP0xzK19csxFUH/RRUIzfKUGFksSpolev0J1kc
5ajipPvkHoKuYXk0P/uohS4GWtRKOug8lLROcvHKjeAa4E3KOE87C951jfZa3YMX
ZQp0bdVkWUEZ1oBOdv/Fxzx/et9EyrNRol/sQeZ0DGGeCyGD22ZDR27KH/yElaoA
yV53lqdp3c/c2OWghJS3UcgXVMdzkwdLBmOEW0YNZW9LBUGbIxNwPNdk9+47GaA1
Rv8FH1J7GyZLWyj/mxMVgnKAgx5Bg+1dUSo46WYVudfK26c2e088hWhagPApxep4
RP76Z0tE67hUQMVKA1r1I8R8F94+ue8datsufDev0gZjWHrSzM+YRw1DSM1HFzE=
=nIF2
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

Hi!

First off, thanks to whoever was responsible for me
being accepted into the GSoC program and congrats
to both Andrew and Paras for getting in, too! :)

On Fri, May 05, 2017 at 08:27:34AM -0700, John Casey wrote:
> Unfortunately, my Qubes project wasn't accepted

John, sorry to hear your Qubes Manager proposal wasn't
accepted. It really could use a generous dose of (not
only) UI changes.

So... I've spend the last few days setting up my dev
env and getting familiar with qubes-builder.

While skimming through issues on GitHub labeled as
"minor" and "help wanted", searching for something
quick and easy just to get a hang of the dev workflow,
I haven't stumbled upon anything "right up my alley".

Due to this, I decided to start working on my actual
GSoC project instead (I hope it's not discouraged),
implementing the first step as outlined in my project
proposal -- the AEM install script is now able to
generate, enroll and encrypt a LUKS key file and the
sealing script then seals (duh) and copies it to the
AEM media.

You can find my fork of the AEM repo on GitHub under
phagara.

Now to my questions. :)

Is there a preferred way of dealing with forked repos
under qubes-builder? Right now I've simply added a new
remote for the antievilmaid component and I'm assuming
simply running `make prepare-merge` and subsequently
`make do-merge` should do the trick when the upstream
repo has new, non-conflicting commits.

As far as RPM package signing goes -- I guess it's not
even worth setting that up for development since the
only person installing the pkgs built by me would be
just myself, in which case the signature would serve
no practical purpose. Am I right?


Cheers,
Patrik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZGusaAAoJEFwecd8DH5rlTFsQALtCO7EtmRWh6sDPlN2BOVdX
lq9h1g4hc3GMvAkWaDEUItrU6Sszu8Oh7dicUuV9PD73sJ6WG+XaLOIbYlVxnaAv
ZG149jZjTXmnh04kjMyM86WPoSrlJjmT+4bov/eafmwTKkDyMtv9sX9mzyfRixdm
kNW2sJgL+RviEUwUrYYJi4oTd2c/PgeBiwZjhyyeb0VeEj7diwNdHDdJQj+pymU2
G4wtcsFQV6+EAwtI8qa580xYRcaSNUVE5RhYl3Tz4GG55KoWgHFWdfM9UiXaHrxD
2syRtgL8M2myiQnrJu092LDQOTuYa98v4H6gj42IAiGK3STP+egyJFQOkK7pqdlE
wv2qRO66RBl9UfkbT+fShBli1eOkjrhXsgqCO/LKI6zWzDEbxVsRD89haWlPCTg9
DlZUWi64HQmqrdwbjTl6XEN24Etq6EYu94pfVOE0agAnyTLHMHBc+oZoPgeTam3O
5oHlrtXNi6qJc+pNgIFaP+Fh8x1KDftnXTT12GBja2Cf5MPv6aE8n5r6WquMJpwz
6peONSzMwkOGk69v8xl/oOtPE/csPxKu8GedeDeJzHkYRKyeY1k6Hs+IgKZOxkk+
tcB2sJRXdblVdn19p72/n01GFUpbTDWOQzDJ3zrV+96nO9vCH4I7PlJAn/447hOy
T0bT2XFcyee8tJN4BqDm
=zm3L
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Tue, May 16, 2017 at 02:06:39PM +0200, Patrik Hagara wrote:
> Hi!
>
> First off, thanks to whoever was responsible for me
> being accepted into the GSoC program and congrats
> to both Andrew and Paras for getting in, too! :)
>
> On Fri, May 05, 2017 at 08:27:34AM -0700, John Casey wrote:
> > Unfortunately, my Qubes project wasn't accepted
>
> John, sorry to hear your Qubes Manager proposal wasn't
> accepted. It really could use a generous dose of (not
> only) UI changes.

Unfortunately, as new GSoC org, we didn't get as many slots as we
requested, so we were forced to reject some, even good proposals.

> So... I've spend the last few days setting up my dev
> env and getting familiar with qubes-builder.
>
> While skimming through issues on GitHub labeled as
> "minor" and "help wanted", searching for something
> quick and easy just to get a hang of the dev workflow,
> I haven't stumbled upon anything "right up my alley".
>
> Due to this, I decided to start working on my actual
> GSoC project instead (I hope it's not discouraged),

Yes, that's fine. If you finish early, we can always extend the project
;)

> implementing the first step as outlined in my project
> proposal -- the AEM install script is now able to
> generate, enroll and encrypt a LUKS key file and the
> sealing script then seals (duh) and copies it to the
> AEM media.
>
> You can find my fork of the AEM repo on GitHub under
> phagara.
>
> Now to my questions. :)
>
> Is there a preferred way of dealing with forked repos
> under qubes-builder? Right now I've simply added a new
> remote for the antievilmaid component and I'm assuming
> simply running `make prepare-merge` and subsequently
> `make do-merge` should do the trick when the upstream
> repo has new, non-conflicting commits.

Yes, exactly.

> As far as RPM package signing goes -- I guess it's not
> even worth setting that up for development since the
> only person installing the pkgs built by me would be
> just myself, in which case the signature would serve
> no practical purpose. Am I right?

If you install packages on the same machine as you build them, then yes.
But if you transfer them using some untrusted channel (network or such),
signing may be useful. All you need for that is to have some key
generated, and adjust builder.conf: SIGN_KEY=<key-id>, NO_SIGN=0.

Pro tip: if you work on a single component (or some subset of them), you
can adjust COMPONENTS in builder.conf to include only what you need. It
will make things a lot faster.

- --
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

iQEcBAEBCAAGBQJZGv95AAoJENuP0xzK19csHJsH+QGLpNYcTn48vRDocFwagvWp
bjcqfi11arjfT+sBSD6oyM13/b1IrVxuVy44GQQM5qmw9GNoUn9EPMIkx7hrGS9R
RalpCjEPgoqi75qVtp0iJau68k8bjP9n+4E0n9+mhQofqaKjjIGdx7ao8wA4z0uz
GnJCMWl9VnIvUcXpHQNLkFPYh+HGhuVBGlOAlfeyR/uH4PH69GEQcydGwDw7yhjN
A52D4uXw12yW10V+gCNge92uaGYoRMrGy+Dd951PCVNrM+4EyFW5od09ZZ67gViv
QmOF5vmPIP/QV09m7m9wbCYi9PJA6qiSmW36dqaFMq3zy8cK34dl7hCk9NQ75DE=
=0Rh6
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

On Tue, May 16, 2017 at 03:32:41PM +0200, Marek Marczykowski-Górecki wrote:
> Unfortunately, as new GSoC org, we didn't get as many slots as we
> requested, so we were forced to reject some, even good proposals.

Ah well. I hope you get more and more slots in the
coming years -- Qubes definitely deserves a lot more
"attention" (and mainstream adoption) than it's getting.

> > Due to this, I decided to start working on my actual
> > GSoC project instead (I hope it's not discouraged),
>
> Yes, that's fine. If you finish early, we can always extend the project
> ;)

Assuming it keeps going this smoothly and I get to
finish even the TOTP token auth stretch goal, then
sure. :)

> > Is there a preferred way of dealing with forked repos
> > under qubes-builder? Right now I've simply added a new
> > remote for the antievilmaid component and I'm assuming
> > simply running `make prepare-merge` and subsequently
> > `make do-merge` should do the trick when the upstream
> > repo has new, non-conflicting commits.
>
> Yes, exactly.

Alright.

> > As far as RPM package signing goes -- I guess it's not
> > even worth setting that up for development since the
> > only person installing the pkgs built by me would be
> > just myself, in which case the signature would serve
> > no practical purpose. Am I right?
>
> If you install packages on the same machine as you build them, then yes.
> But if you transfer them using some untrusted channel (network or such),
> signing may be useful. All you need for that is to have some key
> generated, and adjust builder.conf: SIGN_KEY=<key-id>, NO_SIGN=0.

Same machine, yeah.

I tried to set up split-GPG signing but couldn't get
it working and eventually decided to skip it since
there would be no benefit in my case, anyway.

Now, after a fair bit of debugging, I found out it
was simply a silly typo -- writing the RPM macro
config to `~/.rpmmacro` instead of `~/.rpmmacros`.

All that's needed now is to `rpm --import` my public
key in dom0 and I can start verifying my own RPMs.
Too bad I only have one Qubes machine. :)

> Pro tip: if you work on a single component (or some subset of them), you
> can adjust COMPONENTS in builder.conf to include only what you need. It
> will make things a lot faster.

Yes, I was building just the AEM component pkgs,
although with `make antievilmaid` (and now even
`make sign-antievilmaid`). ;)


Cheers,
Patrik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZGxEMAAoJEFwecd8DH5rlL2gP/RhMSgoqcIT2tjlUDOjAif3u
vgLuSwZy31EKsJquq13IxESo+WMb2Yozw43L58jIauNKPNZ3GvoEMhDkul0wMxzo
8SsatfIJCcoUkeulX+jqKtL3zwWw+Pl2C1HJzcQJ7xDK60L3ozjawIwSt7SJiPQp
Wmb9S9iVkQRA+5SIIYrqWRr+Vf01FT8q9kDYJ5KkmEEpFlCwTAMb23NbduNQ9Rf1
B6r9ed5C9Nxr1nZOvpSP2JCJgyYyysl7P2UrIWf9xhR9Th0TcumAb3/cjSZBkSud
wBodYyNSD1qwMPSIYxa/D8uuLJkmdOWHl8zCCqVH4ybfE2Gakpk5VKSYF4f21yBo
ZIXSBqks0jV14xZAGjm00/nX9ad3/O18jBzIpskd6MFAk14zAsm5bRSvGHKJAsye
0wdUxuhLRitDznNokkWGB6tJ2VRvC/ZtZLghxxSV6o5ScDUkqZu82Zyd0GzI6gpu
N8C6jui5K0FQ6EMX+kjy5II9WxVc0XWvwauEZnqI8SZnWu2KkIgrC5xRYUrlymcl
d7WZPGxF5ngK/OHKvpAnX47CS9qxOsEiVsPdMw0vzjNApHfBnAi/zQn2OioFWOy5
pHmjqd0G7CL5WUcW7a27KYUrz56LbpVvesaqTfgPW6MqR20TwOILX73c73UbxX36
ooGF7tR26q2VmL8lKURH
=g1jD
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Patrik!

> While skimming through issues on GitHub labeled as
> "minor" and "help wanted", searching for something
> quick and easy just to get a hang of the dev workflow,
> I haven't stumbled upon anything "right up my alley".
>
> Due to this, I decided to start working on my actual
> GSoC project instead (I hope it's not discouraged),
> implementing the first step as outlined in my project
> proposal -- the AEM install script is now able to
> generate, enroll and encrypt a LUKS key file and the
> sealing script then seals (duh) and copies it to the
> AEM media.
>
> You can find my fork of the AEM repo on GitHub under
> phagara.

Well that was quick, nice! I'll post some commit comments on Github
soon. https://github.com/phagara/qubes-antievilmaid/commits/master

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZGzNiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf7lMP/1TrPBHdlyFIFc4TTw7ScSbz
zPnv+rTFQu6KsTvmqE+Ubo1APeOg6lANfqrH8THaGIc6/TghLD5FuNzmS8xkRqnu
meYmg58zajg2/SscTSwYB10t8Lubg79gTB6jI2QpgnsY4iGn9SOZLPxgrIhwlo3P
TF1CX5zwAqtYWGPFq8/Kmkva0mc/fQVhOmNFJ9FvOgV5GkDEyhxXE7RQfTQOzKQj
C6oOYeDYxqmyByUETxqANK4bZKVEgQ6UUpIAw1nPlCVbpUvPT8tRJAoInd5C2M08
sFQ/TKMQWjxJZZNcCteryc8fFRMusp++Q5btMF48rdQQJaFUvYY8otwj89hF9VkX
IkMSu+gl27ceAZZnBjpolToUl9UqCPMq60FOYrBYvIpLrYuRDqnHC+1ypYPT6Tg7
CXzOOyxye7mQBiB9jJ7zRboIeWHeZzTFHJmxkfBVvw+YGjzN1QtE9pj6rpou2pzt
0hB50aEJD8Btopw4hlgMyljShh0BPgyy9ps/1Pg6ptBoSMFpP4ILvATIcdFXeuQ0
ATjSxDtpEYTp9GF6VZBW5SrU6vP+2gm0Z67M16WX+C6fYVbuG4nFyhve92VVFd3i
MsqVh/Oo5w4u/e16pKBwCyqd6GI74X42VcCxPeKv61IjdJGVWGioWzF64++443A6
wAvbCCDGQU7uQol4gOmr
=fqqq
-----END PGP SIGNATURE-----