Thank you for your interest in participating in the `Google Summer of Code program <https://summerofcode.withgoogle.com/>`__ with the `Qubes OS team <https://www.qubes-os.org/team/>`__. You can read more about the Google Summer of Code
program at the `official website <https://summerofcode.withgoogle.com/>`__ and the `official FAQ <https://developers.google.com/open-source/gsoc/faq>`__.
Being accepted as a Google Summer of Code contributor is quite
competitive. If you are interested in participating in the Summer of
Code please be aware that you must be able to produce code for Qubes OS
for 3-5 months. Your mentors, Qubes developers, will dedicate a portion
of their time towards mentoring you. Therefore, we seek candidates who
are committed to helping Qubes long-term and are willing to do quality
work and be proactive in communicating with your mentor.
You don’t have to be a proven developer – in fact, this whole program is
meant to facilitate joining Qubes and other free and open source
communities. The Qubes community maintains information about
:ref:`contributing to Qubes development <introduction/contributing:contributing code>` and :ref:`how to send patches <developer/code/source-code:how to send patches>`. In order to
contribute code to the Qubes project, you must be able to :doc:`sign your code </developer/code/code-signing>`.
You should start learning the components that you plan on working on
before the start date. Qubes developers are available on the :ref:`mailing lists <introduction/support:qubes-devel>` for help. The GSoC timeline reserves a
lot of time for bonding with the project – use that time wisely. Good
communication is key, you should plan to communicate with your team
daily and formally report progress and plans weekly. Students who
neglect active communication will be failed.
Overview of Steps
^^^^^^^^^^^^^^^^^
- Join the :ref:`qubes-devel list <introduction/support:qubes-devel>` and introduce
yourself, and meet your fellow developers
- Read `Google’s instructions for participating <https://developers.google.com/open-source/gsoc/>`__
and the `GSoC Student Manual <https://google.github.io/gsocguides/student/>`__
- Take a look at the list of ideas below
- Come up with a project that you are interested in (and feel free to
propose your own! Don’t feel limited by the list below.)
- Read the Contributor Proposal guidelines below
- Write a first draft proposal and send it to the qubes-devel mailing
list for review
- Submit proposal using `Google’s web interface <https://summerofcode.withgoogle.com/>`__ ahead of the
deadline (this requires a Google Account!)
- Submit proof of enrollment well ahead of the deadline
Coming up with an interesting idea that you can realistically achieve in
the time available to you (one summer) is probably the most difficult
part. We strongly recommend getting involved in advance of the beginning
of GSoC, and we will look favorably on applications from prospective
contributors who have already started to act like free and open source
developers.
Before the summer starts, there are some preparatory tasks which are
highly encouraged. First, if you aren’t already, definitely start using
Qubes as your primary OS as soon as possible! Also, it is encouraged
that you become familiar and comfortable with the Qubes development
workflow sooner than later. A good way to do this (and also a great way
to stand out as an awesome applicant and make us want to accept you!)
issue-tracking repo) and submit some patches addressing them. Some
suitable issues might be those with tags `“help wanted” and “P: minor” <https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20label%3A%22P%3A%20minor%22%20label%3A%22help%20wanted%22>`__
(although more significant things are also welcome, of course). Doing
this will get you some practice with
:doc:`qubes-builder </developer/building/qubes-builder>`, our code-signing policies, and
some familiarity with our code base in general so you are ready to hit
the ground running come summer.
Contributor proposal guidelines
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A project proposal is what you will be judged upon. Write a clear
proposal on what you plan to do, the scope of your project, and why we
should choose you to do it. Proposals are the basis of the GSoC projects
and therefore one of the most important things to do well.
Every software project should solve a problem. Before offering the solution (your Google Summer of Code project), you should first define the problem. What’s the current state of things? What’s the issue you wish to solve and why? Then you should conclude with a sentence or two about your solution. Include links to discussions, features, or bugs that describe the problem further if necessary.
# Project goals
Be short and to the point, and perhaps format it as a list. Propose a clear list of deliverables, explaining exactly what you promise to do and what you do not plan to do. “Future developments” can be mentioned, but your promise for the Google Summer of Code term is what counts.
# Implementation
Be detailed. Describe what you plan to do as a solution for the problem you defined above. Include technical details, showing that you understand the technology. Illustrate key technical elements of your proposed solution in reasonable detail.
# Timeline
Show that you understand the problem, have a solution, have also broken it down into manageable parts, and that you have a realistic plan on how to accomplish your goal. Here you set expectations, so don’t make promises you can’t keep. A modest, realistic and detailed timeline is better than promising the impossible.
If you have other commitments during GSoC, such as a job, vacation, exams, internship, seminars, or papers to write, disclose them here. GSoC should be treated like a full-time job, and we will expect approximately 40 hours of work per week. If you have conflicts, explain how you will work around them. If you are found to have conflicts which you did not disclose, you may be failed.
Open and clear communication is of utmost importance. Include your plans for communication in your proposal; daily if possible. You will need to initiate weekly formal communications such as a detailed email to the qubes-devel mailing list. Lack of communication will result in you being failed.
# About me
Provide your contact information and write a few sentences about you and why you think you are the best for this job. Prior contributions to Qubes are helpful; list your commits. Name people (other developers, students, professors) who can act as a reference for you. Mention your field of study if necessary. Now is the time to join the relevant mailing lists. We want you to be a part of our community, not just contribute your code.
Tell us if you are submitting proposals to other organizations, and whether or not you would choose Qubes if given the choice.
Other things to think about:
* Are you comfortable working independently under a supervisor or mentor who is several thousand miles away, and perhaps 12 time zones away? How will you work with your mentor to track your work? Have you worked in this style before?
* If your native language is not English, are you comfortable working closely with a supervisor whose native language is English? What is your native language, as that may help us find a mentor who has the same native language?
* After you have written your proposal, you should get it reviewed. Do not rely on the Qubes mentors to do it for you via the web interface, although we will try to comment on every proposal. It is wise to ask a colleague or a developer to critique your proposal. Clarity and completeness are important.
Project Ideas
-------------
These project ideas were contributed by our developers and may be
incomplete. If you are interested in submitting a proposal based on
these ideas, you should contact the :ref:`qubes-devel mailing list <introduction/support:qubes-devel>` and associated GitHub issue to learn
REMOVED as of February 2022: work is being done on this
### Wayland support in GUI agent and/or GUI daemon
**Project**: Wayland support in GUI agent and/or GUI daemon
**Brief explanation**: Currently both GUI agent (VM side of the GUI virtualization) and GUI daemon (dom0 side of GUI virtualization) support X11 protocol only. It may be useful to add support for Wayland there. Note that those are in fact two independent projects:
1. GUI agent - make it work as Wayland compositor, instead of extracting window's composition buffers using custom X11 driver
2. GUI daemon - act as Wayland application, showing windows retrieved from VMs, keeping zero-copy display path (window content is directly mapped from application running in VM, not copied)
**Expected results**:
Choose either of GUI agent, GUI daemon. Both are of similar complexity and each separately looks like a good task for GSoC time period.
- design relevant GUI agent/daemon changes, the GUI protocol should not be affected
- consider window decoration handling - VM should have no way of spoofing those, so it must be enforced by GUI daemon (either client-side - by GUI daemon itself, or server-side, based on hints given by GUI daemon)
- implement relevant GUI agent/daemon changes
- implement tests for new GUI handling, similar to existing tests for X11 based GUI
### Unikernel-based firewallvm with Qubes firewall settings support
REMOVED as of January 2020: work is being done on this
**Project**: Unikernel based firewallvm with Qubes firewall settings support
**Brief explanation**: `blog post <https://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/>`__, `repo <https://github.com/talex5/qubes-mirage-firewall>`__
**Expected results**: A firewall implemented as a unikernel which supports all the networking-related functionality as the default sys-firewall VM, including configuration via Qubes Manager. Other duties currently assigned to sys-firewall such as the update proxy may need to be appropriately migrated first.
**Knowledge prerequisite**:
-`OCaml <https://ocaml.org/>`__ + `MirageOS <https://mirage.io/>`__ or other unikernel framework,
**Brief explanation**: One of the pioneering ideas of Qubes is to use
disposable virtual machines to convert untrustworthy files (such as
documents given to journalists by unknown and potentially malicious
whistleblowers) into trustworthy files. See `Joanna’s blog on the Qubes PDF Convert <https://theinvisiblethings.blogspot.co.uk/2013/02/converting-untrusted-pdfs-into-trusted.html>`__
for details of the idea. Joanna has implemented a prototype for PDF
documents. The goal of this project would be to generalize beyond the
simple prototype to accommodate a wide variety of file formats,
including Word documents, audio files, video files, spreadsheets, and so
on. The converters should prioritise safety over faithful conversion.
For example the Qubes PDF converter typically leads to lower quality
PDFs (e.g.cut and paste is no longer possible), because this makes the
conversion process safer.
**Expected results**: We expect that in the timeframe, it will be
possible to implement many converters for many file formats. However, if
any unexpected difficulties arise, we would prioritise a small number of
safe and high quality converters over a large number of unsafe or
unuseful converters.
**Difficulty**: easy
**Knowledge prerequisite**: Most of the coding will probably be
implemented as shell scripts to interface with pre-existing converters
(such as ImageMagick in the Qubes PDF converter). However, shell scripts
are not safe for processing untrusted data, so any extra processing will
need to be implemented in another language – probably Python.
**Size of the project**: 175 hours
**Mentors**: Andrew Clausen and Jean-Philippe Ouellet
Progress towards reproducible builds
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**Project**: Progress towards reproducible builds
**Brief explanation**: A long-term goal is to be able to build the
entire OS and installation media in a completely bit-wise deterministic
manner, but there are many baby steps to be taken along that path. See:
- “`Security challenges for the Qubes build process <https://www.qubes-os.org/news/2016/05/30/build-security/>`__”
-`This mailing list post <https://groups.google.com/d/msg/qubes-devel/gq-wb9wTQV8/mdliS4P2BQAJ>`__
- and `reproducible-builds.org <https://reproducible-builds.org/>`__
for more information and qubes-specific background.
**Expected results**: Significant progress towards making the Qubes
build process deterministic. This would likely involve cooperation with
and hacking on several upstream build tools to eliminate sources of
REMOVED as of February 2021: work is being done on this
### Porting Qubes to POWER9/PPC64
**Project**: Porting Qubes to POWER9/ppc64
**Brief explanation**:
Qubes currently supports the x86_64 CPU architecture. PowerPC is desirable for security purposes as it is the only architecture where one can get performant hardware with entirely open source firmware. Xen has **deprecated** support for Power9/PPC64 processors. Here are two directions to tackle this project from:
- Port Qubes to KVM then work on ppc64 specifics
- Implement some missing functionality in KVM then implement KVM support in the Qubes Hypervisor Abstraction Layer and build process. Improving the HAL will also be beneficial for simplifying the process of porting to further architectures and hypervisors.
- Port Xen to ppc64 then work on Qubes specifics
- For more information on porting Xen see `this thread <https://markmail.org/message/vuk7atnyqfq52epp>`__.
More information and further links can be found in the related issue:
You can view the projects we had in 2017 in the `GSoC 2017 archive <https://summerofcode.withgoogle.com/archive/2017/organizations/5074771758809088/>`__.
We also participated in GSoC 2020 and GSoC 2021, and you can see the
project in the `GSoC 2020 archive <https://summerofcode.withgoogle.com/archive/2020/organizations/4924517870206976/>`__
and `GSoC 2021 archive <https://summerofcode.withgoogle.com/archive/2021/organizations/5682513023860736>`__.
Here are some successful projects which have been implemented in the
past by Google Summer of Code participants.
Template manager, new template distribution mechanism
