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

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.


Reply via email to