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 |