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