Tasks for Beta 3: coders wanted!

[Joanna Rutkowska]

Hello,

It seems like we won't be able to complete all of the tasks/tickets that
were originally scheduled for Beta 3 (and so for the final Release 2).
We do have lots of work with some of the "core" tasks, such as porting
Qubes to the Odyssey Framework, as well as with the Windows GUI
virtualization support for the current Qubes. And so I would like to
find out if anybody from the community would be interested in working on
some of those tasks...

Examples of tasks that are now being relabeled as "optional" include (I
give ticket numbers in the brackets as a reference to specific tickets
in our wiki):

1) Getting Xen PVUSB backend to work (#531, #704)

2) Support to send (encrypted) backups to AppVM, and restore them (after
integrity-checking) from AppVM (#703)

3) Split GPG using qrexec (#474) -- I think Abel expressed some interest
in working on this?

4) Improve entropy collection for AppVMs (#673)

5) Upgrade Anti Evil Maid so that the installation works fine with GRUB2
that we now use in Qubes since R2B2 (#726)

6) Ability to permanently mark files for opening in disp vm, going
through trusted PDF conversion, etc (#441)

Some of the above tasks are really interesting, so the work on them
might be a great opportunity to actually learn something and make
something ubercool at the same time, as well as gain some immortality by
becoming a Qubes Developer.

In most cases we (Marek, me) already have some ideas how to approach
those tasks, so people who would like to work on them should definitely
discuss this on the list (yes, preferably on the list, not in private).
Also, if you let us know that you're working on a specific task, chances
are high we will wait for you with beta 3 release.

It's also possible that we might offer some limited remuneration (aka
money) for some of the tasks. If you think you are well skilled to work
on any of the tasks mentioned above, but you condition this on getting
paid for your time, then please do contact me in private and we can
discuss it.

One important notice: if you are not a coder (so, a "talker" :P), or if
you're a coder but not really planning on putting any work on those
tasks (but just want to signalize your existence by posting to the
list), then please do not take part in the discussions on those tasks.
This is to keep the discussions manageable for those would actually
decide to put some real work on them. Again, projects like Qubes do
value coders, not talkers.

joanna.

[Ariel Ben-Yehuda]

Hi,

I could probably do #703 (I am familiarizing myself with that area of the code) and maybe #441.

I think that for #441, following the "don't mix explosives and detonators" principle, we should encrypt the files under a "null key" to prevent accidents and then make qvm-open-with-dvm decrypt with said "null key".

The "null key" should be publicly known (even the zero key will suffice) but we use it to prevent accidents (say, running `evince *.pdf' or creating thumbnails on the filesystem).

This has the problem of preventing Bittorrent, but one shouldn't put it on a trusted domain anyway...

 - Ariel Ben-Yehuda

[Andrew Sorensen]

On 05/03/2013 11:15 AM, Joanna Rutkowska wrote:

Hello,

It seems like we won't be able to complete all of the tasks/tickets that
were originally scheduled for Beta 3 (and so for the final Release 2).
We do have lots of work with some of the "core" tasks, such as porting
Qubes to the Odyssey Framework, as well as with the Windows GUI
virtualization support for the current Qubes. And so I would like to
find out if anybody from the community would be interested in working on
some of those tasks...

Examples of tasks that are now being relabeled as "optional" include (I
give ticket numbers in the brackets as a reference to specific tickets
in our wiki):

1) Getting Xen PVUSB backend to work (#531, #704)

2) Support to send (encrypted) backups to AppVM, and restore them (after
integrity-checking) from AppVM (#703)

I worked on this feature a month or so ago, and got a system that sends the backups to an AppVM, but I haven't had time to add encryption and backup restoring.

The code I have so far is here: https://github.com/AndrewX192/qubes-core/blob/master/dom0/qvm-core/qubesutils.py

I will try to set aside some time to change the code to use the qubes python api instead of qvm-run and implement gpg in the next two weeks.

[Joanna Rutkowska]

On 05/04/13 22:37, Andrew Sorensen wrote:
>> > 2) Support to send (encrypted) backups to AppVM, and restore them (after
>> > integrity-checking) from AppVM (#703)
> I worked on this feature a month or so ago, and got a system that sends
> the backups to an AppVM, but I haven't had time to add encryption and
> backup restoring.
>
> The code I have so far is here:
> https://github.com/AndrewX192/qubes-core/blob/master/dom0/qvm-core/qubesutils.py
>
> I will try to set aside some time to change the code to use the qubes
> python api instead of qvm-run and implement gpg in the next two weeks.
>

Ok, Andrew, I modified the ticket to indicate that you will work on this
in the coming weeks, so that we could easily keep track who is working
on what:

http://wiki.qubes-os.org/trac/ticket/703

Thanks,
joanna.

[Joanna Rutkowska]

On 05/04/13 22:27, Ariel Ben-Yehuda wrote:
> Hi,
>
> I could probably do #703 (I am familiarizing myself with that area of the
> code) and maybe #441.
>

"Could probably"? Hey, I "could" work on any of those tickets, the
question is whether I _will_ work on any of them! There is a big
difference between "could" and "will" ;)

Anyway, because Andrew Sorenson has already done some work on this, and
declared to work on this in the coming weeks, so let's leave this ticket
to him.

> I think that for #441, following the "don't mix explosives and detonators"
> principle, we should encrypt the files under a "null key" to prevent
> accidents and then make qvm-open-with-dvm decrypt with said "null key".
>
> The "null key" should be publicly known (even the zero key will suffice)
> but we use it to prevent accidents (say, running `evince *.pdf' or creating
> thumbnails on the filesystem).
>
> This has the problem of preventing Bittorrent, but one shouldn't put it on
> a trusted domain anyway...
>

Let's move this discussion to a new thread for better clarity and easier
referencing. Ariel, can write a new message describing the overall
approach to this task? What you mentioned above is just one little
element, while many other remain to be answered. E.g. how would you
"hook" the mime handlers in the first place? How would you remember the
user choices (Open natively, Open in DispVM, Open in another VM, Send to
converter) for each file?

I don't quite like the approach with null keys, or any approach with
requires modification of the original files that could prevent opening
of them on other systems. We don't want to lock people to Qubes OS,
we're not Apple :)

So, anyway, please give this a thought, and please describe your plan in
a new message in a new thread that could be nicely linked in from the
ticker.

Thanks.
joanna.

[Olivier Médoc]

On 05/03/13 20:15, Joanna Rutkowska wrote:
> Hello,
>
> It seems like we won't be able to complete all of the tasks/tickets that
> were originally scheduled for Beta 3 (and so for the final Release 2).
> We do have lots of work with some of the "core" tasks, such as porting
> Qubes to the Odyssey Framework, as well as with the Windows GUI
> virtualization support for the current Qubes. And so I would like to
> find out if anybody from the community would be interested in working on
> some of those tasks...
>
> Examples of tasks that are now being relabeled as "optional" include (I
> give ticket numbers in the brackets as a reference to specific tickets
> in our wiki):
>
> 1) Getting Xen PVUSB backend to work (#531, #704)
>
> 2) Support to send (encrypted) backups to AppVM, and restore them (after
> integrity-checking) from AppVM (#703)
>
> 3) Split GPG using qrexec (#474) -- I think Abel expressed some interest
> in working on this?
>
> 4) Improve entropy collection for AppVMs (#673)
>
> 5) Upgrade Anti Evil Maid so that the installation works fine with GRUB2
> that we now use in Qubes since R2B2 (#726)

Is there any work in progress grub2 anti-evil-maid ? I started playing
with tboot, maybe somebody has ideas or additionnal information on this ?

I'm just playing with it currently so I can't promess anything.

[Joanna Rutkowska]

On 06/22/13 09:26, Olivier Médoc wrote:
>> 5) Upgrade Anti Evil Maid so that the installation works fine with GRUB2
>> that we now use in Qubes since R2B2 (#726)
> Is there any work in progress grub2 anti-evil-maid ? I started playing
> with tboot, maybe somebody has ideas or additionnal information on this ?
>
> I'm just playing with it currently so I can't promess anything.

No, no grub2 work for AEM, at least not that I would be aware of...

Additional info and support for tboot can be found on their tboot-devel
maling list:

http://sourceforge.net/mailarchive/forum.php?forum_name=tboot-devel

Cheers,
joanna.