Re: GSoC Proposal Draft Feedback
Hi Jacob,
maybe I'm going ahead of the GSoC timing here, maybe those things could
be discussed after the project officially start, but I don't see many
drawbacks in moving ahead. I would love the opinion of more experienced
mentors.
On 16/03/2018 16:52, Jacob Adams wrote:
> On 03/15/2018 11:16 PM, Daniele Nicolodi wrote:
>> - I think it would be relevant to explain why you on having two storage
>> devices used in RAID1, and what are the possible alternatives. Have you
>> thought about the possibility of recommending the RAID1 setup but not
>> requiring it?
>
> I will definitely add a full explanation to my workflow, but the short
> version is that having two identical drives protects against random disk
> failure. btrfs or zfs are other options but RAID1 seemed like the safest
> one.
>
> This proposal kinda assumes that flash drives are easily obtainable for
> the user, but that's probably not the case for everyone. The option for
> only one should perhaps be available. I'll have to think about it.
I didn't want to suggest that the requirement is a bad requirement, but
that opinionated choices must be documented and justified as part of the
documentation of the project. I agree that flash drives of the capacity
required for this are easy to obtain, but for example, my laptop does
have only two USB ports...
>> From the proposed workflow I also deduce that you are
>> planning to have the storage encrypted. What's the reason fro that?
>> Isn't having the private keys password protected enough?
>
> This is just because it is how I store my keys currently. I'll have to
> think about this and write up a proper threat model here. You're
> probably right that encrypting the disk is overkill. Just keeping the
> disks in a safe place would probably provide enough practical security
> for most people. I'm just paranoid sometimes.
I'm not expert in the field, but isn't the GPG key passphrase enough to
secure the private key even if someone gains access to the storage
medium? What would be the benefit of an extra layer of encryption?
Again, I'm not suggesting that the choice is not a good one, but that if
you go that way it would be nice to have the reasoning at the base of
this choice documented (not necessarily in the GSoC proposal).
>> - I see a lot of testing mentioned, but not mention of an automated test
>> setup. Have you thought a bit about this aspects? Having automated
>> testing in mind will help in structuring the code in a way that will
>> make testing easier and the code structure better. Also, for example, I
>> would allocate some time to investigate solutions to do automated
>> testing of newt user interfaces.
>
> That's a really good point! I'll have to look into ways to mock
> responses for python-newt (or perhaps write my own). Automated testing
> is definitely important and I will add that to my proposal.
Other than testing the interface, I guess, that you will need to test
the underlying functionality in isolation (unit tests). Also, if you
foresee that handling the storage is going to be the most complex part,
I think you will like to have a way to test that without having to
physically fiddle with flash drivers. Does KVM (or similar) have
functionality to emulate plugging and unplugging USB storage, and an API
to control it?
>> - The first activity in the proposed schedule is to realize a
>> mock/skeleton user interface. I think it is a good idea, but wouldn't it
>> be simpler and faster to iterate on "user stories" at the beginning:
>> defining user tasks, the required steps to accomplish them and how the
>> interface for them should look like. Actually writing the code for the
>> ui can come as a second step.
>>
>
> Definitely jumped the gun a bit there. My usual approach to these things
> is to just try it and iterate on the design for a bit till it makes
> sense, but I think this will require a different approach. What the user
> wants to do and GPG's normal workflow don't always coincide.
> That planning should probably be the first week. I'll add that to my
> schedule.
The suggestion here is also a bit selfish: user stories are also easier
and faster to review and discuss than having to navigate the menus of
the interface.
Cheers,
Dan
Reply to: