On 03/15/2018 11:16 PM, Daniele Nicolodi wrote: > On 12/03/2018 15:57, Jacob Adams wrote: >> I've written a draft proposal for my GSoC application and I'm now >> looking for feedback: >> >> https://wiki.debian.org/JacobAdams/PGPCleanRoomGSoC2018ProjectProposal > > Hi Jacob, > > I had a look at your proposal: it looks good! A few notes:> > - 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. > - Have you thought about having the possibility of having the keys > generated in the smartcard directly? How would that fit in the workflow? > Do you think that the RAID1 disks would be the recommended solution in > that case too? > This is of course a valid alternative. I'm thinking that the first screen should probably ask the user where they intend to store the key and work from there. That changes a bunch of the backend stuff for key generation but the workflow should look the same from the user's perspective just without the backup disks. > 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 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. > > - 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. > That's all for now. Thanks for the feedback! > > Cheers, > Dan >
Attachment:
signature.asc
Description: OpenPGP digital signature