On Thu, Apr 25, 2019 at 6:29 PM Kristian Fiskerstrand <k...@gentoo.org> wrote: > > On 4/26/19 12:26 AM, Rich Freeman wrote: > > I mean, I'd expect any Gentoo dev to be able to figure out how to use > > git as well, but git also has a terrible command line interface, > > Not really, it is quite intuitive once you understand the basics. >
So, I love git, and certainly understand the basics, and created a python script to map/reduce our repo into a list of all unique files in the history with their hashes and commit info to compare to cvs during the migration. I certainly think the command line is terrible. How many different ways are branches identified in the various commands? git-am is a favorite whipping boy of many critics. It is just inconsistent from command to command, and some common things like backing out one commit require arcane syntax. Yes, it all makes sense if you understand the data model, but it is hardly a clean interface. I'm certainly not the first to say this, and it is not because of a lack of git knowledge. I suspect Linus himself would concur. It was a personal tool that scratched an itch that we're all stuck with because it works well enough that nobody will want to create a new interface. gpg is the same. Yes, the concepts are great once you understand them (though the smartcard standard is needlessly limited). The actual command line interface is just painful to use if you're doing more than just encrypting/signing something. If you want to use something other than your default key you pass --default-key, which seems odd, since you don't really want to change your default, and there isn't any way to pass a "non-default" key. I get having a default key option in a config file, since that is what it describes. And then there is all the interactivity, which makes sense to have as an option, but not without a command line override. I mean, the FTP interactive console also makes sense but there is a reason everybody uses curl/wget/etc, and not FTP+expect. > > > > Personally I think we ought to make it easier to just use the > > Nitrokeys we spent all this money on in a more secure manner than just > > leaving primary keys lying around on hard drives, > > The decisions involved are disjunct here, but leaving around on > hard-drives is generally a bad idea irrespective of any nitrokey, and > certainly something expected not to happen from a Gentoo Dev to begin > with (for primary key material at least) IMO this is quite naive. The desire to store it offline isn't even documented in the GLEP, nor is it enforceable. I get that some people like to care for their gpg keys the way other people like to wax their cars, but not everybody signed up as a Gentoo dev so that they have an excuse to participate in a WoT. And I think that the practical side of security is VERY relevant here. My argument is that having a single primary+signing key generated on a smartcard is more secure than having a separate primary+signing key stored on an internet-connected PC hard drive. And yet the first is forbidden by the GLEP and the second is allowed. The fact that you can't conceive of somebody using gpg in basically the most out-of-the-box way available doesn't mean that this isn't how most devs would actually do it. The integrity of this entire exercise is as secure as the dev who takes the least care to secure their keys, not the one who takes the greatest care. IMO it is in the interests of security to create a process that is both convenient and secure, and I think that keys generated on a smartcard achieve a better balance of this than other alternatives allowed under the current policy. -- Rich
