Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: Kristian Fiskerstrand <k_f@g.o>
Cc: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
Date: Thu, 25 Apr 2019 22:52:46
Message-Id: CAGfcS_nnONjdWhdgrpYtv6Hrcr1gw8b7OmVLu3-o5mKs-bNmmw@mail.gmail.com
In Reply to: Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard? by Kristian Fiskerstrand
1 On Thu, Apr 25, 2019 at 6:29 PM Kristian Fiskerstrand <k_f@g.o> wrote:
2 >
3 > On 4/26/19 12:26 AM, Rich Freeman wrote:
4 > > I mean, I'd expect any Gentoo dev to be able to figure out how to use
5 > > git as well, but git also has a terrible command line interface,
6 >
7 > Not really, it is quite intuitive once you understand the basics.
8 >
9
10 So, I love git, and certainly understand the basics, and created a
11 python script to map/reduce our repo into a list of all unique files
12 in the history with their hashes and commit info to compare to cvs
13 during the migration. I certainly think the command line is terrible.
14 How many different ways are branches identified in the various
15 commands? git-am is a favorite whipping boy of many critics. It is
16 just inconsistent from command to command, and some common things like
17 backing out one commit require arcane syntax. Yes, it all makes sense
18 if you understand the data model, but it is hardly a clean interface.
19
20 I'm certainly not the first to say this, and it is not because of a
21 lack of git knowledge. I suspect Linus himself would concur. It was
22 a personal tool that scratched an itch that we're all stuck with
23 because it works well enough that nobody will want to create a new
24 interface.
25
26 gpg is the same. Yes, the concepts are great once you understand them
27 (though the smartcard standard is needlessly limited). The actual
28 command line interface is just painful to use if you're doing more
29 than just encrypting/signing something. If you want to use something
30 other than your default key you pass --default-key, which seems odd,
31 since you don't really want to change your default, and there isn't
32 any way to pass a "non-default" key. I get having a default key
33 option in a config file, since that is what it describes. And then
34 there is all the interactivity, which makes sense to have as an
35 option, but not without a command line override. I mean, the FTP
36 interactive console also makes sense but there is a reason everybody
37 uses curl/wget/etc, and not FTP+expect.
38
39 > >
40 > > Personally I think we ought to make it easier to just use the
41 > > Nitrokeys we spent all this money on in a more secure manner than just
42 > > leaving primary keys lying around on hard drives,
43 >
44 > The decisions involved are disjunct here, but leaving around on
45 > hard-drives is generally a bad idea irrespective of any nitrokey, and
46 > certainly something expected not to happen from a Gentoo Dev to begin
47 > with (for primary key material at least)
48
49 IMO this is quite naive. The desire to store it offline isn't even
50 documented in the GLEP, nor is it enforceable. I get that some people
51 like to care for their gpg keys the way other people like to wax their
52 cars, but not everybody signed up as a Gentoo dev so that they have an
53 excuse to participate in a WoT.
54
55 And I think that the practical side of security is VERY relevant here.
56 My argument is that having a single primary+signing key generated on a
57 smartcard is more secure than having a separate primary+signing key
58 stored on an internet-connected PC hard drive. And yet the first is
59 forbidden by the GLEP and the second is allowed. The fact that you
60 can't conceive of somebody using gpg in basically the most
61 out-of-the-box way available doesn't mean that this isn't how most
62 devs would actually do it.
63
64 The integrity of this entire exercise is as secure as the dev who
65 takes the least care to secure their keys, not the one who takes the
66 greatest care. IMO it is in the interests of security to create a
67 process that is both convenient and secure, and I think that keys
68 generated on a smartcard achieve a better balance of this than other
69 alternatives allowed under the current policy.
70
71 --
72 Rich

Replies