Re: EasyGnuPG

[Viktor Dick]

On 22.03.2016 23:10, Dashamir Hoxha wrote:
> You got this wrong. It does not enforce 1 month expiry. Right after
> creating the key you can change its expiry to 10y, if you wish. But if
> you say nothing, after 1m you will have to renew it (if you still
> remember the passphrase). This is like a safety measure for people who
> are not familiar with gpg.

In this case, I think you have got a point. I think the gnupg default of
'expires: never' is not the best solution, since people who just try it
out might end up with a public key published to keyservers where they
have lost the private key. Of course, this is not different from fake
keys published by third parties, as long as there are no relevant
signatures on it nobody should trust them. But I still think it might be
better to set a default expiry of, let's say, 1 year and two months for
the primary key and one year for the subkeys.

Then there is the problem that the user might not notice that his key is
expired. I remember vagely spending a day trying to find the error until
I noticed that my subkeys were expired. But this might have been a
problem with Enigmail, which did not give a clear error message.

However, one month is IMHO too short. But maybe I'm not the best judge
since the last time I wrote an encrypted email was multiple months ago
and I only once in my lifetime got an encrypted email except for testing
purposes. Renewing my keys every month (and, which is more difficult
than simply remembering to do so, distributing them between the couple
or so machines where I read email) would be too much of a hassle.

Regards,
Viktor



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AES-GCM and AEAD Protected Data Packet (IETF draft)

[Tankred Hase]

Hi,

I’ve implemented initial support for AES-GCM in OpenPGP.js using the IETF draft 
for authenticated encryption:

https://tools.ietf.org/html/draft-ford-openpgp-format-00

I’ve created a pull request on GitHub for the implementation. The specification 
leaves quite a bit of wiggle room and I’ve listed my thoughts here: 

https://github.com/openpgpjs/openpgpjs/pull/430

I’ve already contacted the specification author to give feedback, but being the 
most widely adopted OpenPGP implementation out there, I also wanted to get the 
GnuPG community's thoughts. Making GCM the new standard mode for symmetric 
encryption would give us a modern and performant alternative to OpenPGP's CFB 
mode. Especially with regards to the WebCrypto api, where GCM is natively 
supported, but not CFB (currently marked as a 'WontFix' in the chromium bug 
tracker):

https://www.chromium.org/blink/webcrypto#TOC-Supported-algorithms-as-of-Chrome-46-

Together will ECC asymmetric encryption, GCM should give OpenPGP a modern 
cipher suite supported natively in browsers. This will hopefully also allow the 
community to deprecate some older crypto down the road. Looking forward to your 
feedback.

Thanks,
Tankred


P.S. Just for reference, here are the GitHub issues tracking ECC in OpenPGP.js. 
We have not started implementing them, but the plan is to move ahead after GCM 
is merged:

https://github.com/openpgpjs/openpgpjs/issues/427
https://github.com/openpgpjs/openpgpjs/issues/428
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Dashamir Hoxha]

On Tue, Mar 22, 2016 at 11:25 PM, Peter Lebbing 
wrote:
>
> > What is wrong with that? As long as there is a subkey for encryption,
> > gpg will use the subkey for encryption, even if the primary key is
> > capable of encryption.
>
> That is not up to you! It's up to your peers, or your attackers. They
> pick which key they encrypt to, and your GnuPG will just use whatever
> key was encrypted to, to decrypt it. You don't have a say in it. Your
> only recourse is to delete your primary key, meaning you can't certify
> anymore either.
>
> If there are hidden recipients, GnuPG will simply try both your primary
> and your subkey to decrypt the hidden PKESK packet.
>
> Why did you change this to the setting it had in the way before, the
> long-long ago: one key for everything? I've only ever seen it advocated
> in the sense that "you should encrypt to the primary key for TOP SECRET
> material, since I only have that key on an air-gapped offline computer".
> Not precisely a beginner's scenario, and a flawed argument anyway if you
> ask me.
>

You are right on this, I got it wrong. I had no particular reason for doing
that.
I will make the primary key ony with certification capability, if this is
what the experts recommend.


>
> > And I beleive that this can be done with a bunch of simple
> > shell scripts.
>
> Go ahead. You've heard multiple opinions from several people. But please
> be aware of the criticism with regard to the details like the key
> capabilities and so forth. You're choosing this for your users, not just
> for yourself. Be prudent. Don't hurt your users, and realise that the
> defaults are that for good reason. I would strongly urge you to keep
> GnuPG at its defaults: they are good. Just change the interface, not the
> defaults.


I do expect some help on these matters, because I am neither a security
expert nor a gpg expert.

Regards,
Dashamir
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Andrew Gallagher]

On 22 Mar 2016, at 22:10, Dashamir Hoxha  wrote:
>> On Tue, Mar 22, 2016 at 10:21 PM, Peter Lebbing  
>> wrote: 
>> And why is your primary key capable of encryption? One of the reasons for
>> subkeys is so you don't have to use the same key material for both encryption
>> and signing, since this opens up some subtle points of attack that are easily
>> avoided.
> 
> What is wrong with that? As long as there is a subkey for encryption, gpg 
> will use the subkey for encryption, even if the primary key is capable of 
> encryption.

Please please for the love of all that is sweet and beautiful in the world 
don't make an encryption-usage primary key. If you ignore everything else Peter 
has said, please don't ignore this. There are no benefits whatsoever to making 
an E-usage primary key, and plenty of reasons not to. And unlike expiry dates 
which can be fixed later, once you have E enabled on a primary key you can't 
remove it without hacking the innards of the data structure.

IMHO the only thing to do with E-usage primary keys is revoke them and start 
again from scratch. The only reason they are even still allowed in GPG is for 
backwards compatibility, right...?

A___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Peter Lebbing]

On 22/03/16 15:31, Ben McGinnes wrote:
> What, you mean like "gpg2 --use-embedded-filename"?

No, I meant what it already does, I had it wrong in my head and should
have tried it. I mean that it would be nice if the following were
equivalent:

$ gpg2 -r de500b3e -e file.ext
$ gpg2 -o file.ext.gpg -r de500b3e -e file.ext

Which they are. So the whole argument is moot.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Peter Lebbing]

On 22/03/16 23:10, Dashamir Hoxha wrote:
> You got this wrong. It does not enforce 1 month expiry. Right after
> creating the key you can change its expiry to 10y, if you wish. But if
> you say nothing, after 1m you will have to renew it (if you still
> remember the passphrase). This is like a safety measure for people who
> are not familiar with gpg.

It's not a good default. There is something to be said for an expiry, so
keys eventually become stale if the owner loses the revocation
certificate and the key itself.

But we clearly have an informed disagreement. There's nothing more I can
say, I think.

> What is wrong with that? As long as there is a subkey for encryption,
> gpg will use the subkey for encryption, even if the primary key is
> capable of encryption.

That is not up to you! It's up to your peers, or your attackers. They
pick which key they encrypt to, and your GnuPG will just use whatever
key was encrypted to, to decrypt it. You don't have a say in it. Your
only recourse is to delete your primary key, meaning you can't certify
anymore either.

If there are hidden recipients, GnuPG will simply try both your primary
and your subkey to decrypt the hidden PKESK packet.

Why did you change this to the setting it had in the way before, the
long-long ago: one key for everything? I've only ever seen it advocated
in the sense that "you should encrypt to the primary key for TOP SECRET
material, since I only have that key on an air-gapped offline computer".
Not precisely a beginner's scenario, and a flawed argument anyway if you
ask me.

> And I beleive that this can be done with a bunch of simple
> shell scripts.

Go ahead. You've heard multiple opinions from several people. But please
be aware of the criticism with regard to the details like the key
capabilities and so forth. You're choosing this for your users, not just
for yourself. Be prudent. Don't hurt your users, and realise that the
defaults are that for good reason. I would strongly urge you to keep
GnuPG at its defaults: they are good. Just change the interface, not the
defaults. Okay, I should stop, I get the feeling every next sentence is
a rephrasing of previous ones :).

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Keith Mallen]

Sorry to butt in here but in my first post to the list I mentioned that
I was attempting to use FreePascal/Lazarus to interface with GPG via the
command line but whilst I had managed to get it working with OpenSSL
attempting the same methodology on GPG resulted in a 'hang'.

Now I realise I am a novice and whilst Lazarus is supposedly
cross-platform the documentation for Lazarus is hard to interpret
presumably because I am a novice but Lazarus is Pascal and cross
platform and it is Pascal so I would hope more understandable to knuckle
scrapers such as myself.

http://wiki.freepascal.org/Executing_External_Programs

Someone recently asked about using FreePascal under Windows but made
mention of using a DLL. As far as I am aware FreePascal should give you
a 'direct' command line interface on any platform. I'll be rubbish here
but scratching my head about DLLs reminds me of when I was looking into
'keyloggers' which, under Windows, require a hook into the system if you
wish to capture data across running applications...

Honest I was trying to catch out a 'Microsoft Support Person' who wanted
to fix my computer over the phone.

Anyway, for what it might be worth..

http://www.soondae.co.uk/testssl

Yes I hate myself already for dropping that one on you with no
explanation but basically it is a GUI that interfaces with OpenSSL via
the command line in order to generate multiple key pairs. As I say
similar does not work on GPG but it would seem that if you can get
access to the command line interface for GPG in a similar manner then,
being naive, it could be a solution

Just floating one

Keith

On Tue, 2016-03-22 at 13:55 +, Andrew Gallagher wrote:
> > On 22 Mar 2016, at 10:40, Paolo Bolzoni  
> > wrote:
> > 
> > And besides, it's much easier to build a GUI app in front of a C API
> > than a command line application.
> 
> This is undeniably true. Unfortunately you first need to learn the API, which 
> can be a barrier to someone who knows the command line interface and just 
> wants to hack together a script to do a particular job. 
> 
> Cryptography is hard, and decades later we still aren't at the point where 
> average computer users can take advantage of it without either first becoming 
> experts or punching holes in the sides of the boat. For that we need to be 
> encouraging hackers and tinkerers to experiment with novel interfaces; and 
> this is best done by giving them the software equivalent of Lego rather than 
> Meccano. 
> 
> This is not a gpg-specific issue. OpenSSL suffers the same problem of having 
> to be both a comprehensive implementation and a user interface, and handles 
> it pretty much the same way, by using a basic command prompt. 
> 
> Where is the gpg equivalent of easy-rsa though? This is a complaint about 
> software tools in general, but for hackers and tinkerers inconsistency across 
> UIs is a significant barrier to entry. If I can't take what I've learned from 
> using the command line for years and apply it (safely) to writing a modest 
> shell script, I'm going to think long and hard before taking the time to 
> learn a Python API. At the very least, any feature accessible through an 
> interactive interface should have an equivalent command line option, so that 
> all interactive operations can trivially be automated. Thought should also be 
> given to whether wrapping all functionality in a single binary with thousands 
> of options is the best interface to present to even expert command line users 
> (again, OpenSSL is another offender). 
> 
> I say this because I found myself in exactly the same boat as the OP. I 
> wanted to write a small script for my technically-proficient but 
> non-cryptography-expert users so that they could easily manage gpg private 
> keys without me worrying that they'd screw it up; and I ended up with a 
> fragile interface very similar to his that needed to be completely refactored 
> using gpgme. Just interfacing with gpg was the most difficult part of the 
> process; the logic that I built on top of it was easy by comparison. This is 
> the wrong way around.
> 
> A
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Dashamir Hoxha]

On Tue, Mar 22, 2016 at 10:21 PM, Peter Lebbing 
wrote:

>
> Your one month expiry thing is not well thought through. Not only will the
> owner
> need to re-sign and redistribute every damn month, but all his contacts
> will
> pretty much always need tor refresh the key before they can use it, /even/
> if
> they are currently working offline (e.g., commuting), which means they
> simply
> need to wait until they have network coverage again. The 4k RSA primary
> key with
> 3 subkeys grows by 2 kilobytes on the keyserver every single month (new
> expiry
> signatures). When, not if but when the user forgets to renew, his contacts
> have
> no other recourse than to contact the user in plain text to remind them of
> their
> forgetfulness.
>

You got this wrong. It does not enforce 1 month expiry. Right after
creating the key you can change its expiry to 10y, if you wish. But if you
say nothing, after 1m you will have to renew it (if you still remember the
passphrase). This is like a safety measure for people who are not familiar
with gpg.


> And why is your primary key capable of encryption? One of the reasons for
> subkeys is so you don't have to use the same key material for both
> encryption
> and signing, since this opens up some subtle points of attack that are
> easily
> avoided.
>

What is wrong with that? As long as there is a subkey for encryption, gpg
will use the subkey for encryption, even if the primary key is capable of
encryption.


> Current GnuPG is the culmination of several decades of very hard work by
> talented people. Don't forget that when you think something isn't as you
> think
> it should be.


I did not judge the people who built GnuPG. And I know that it is easier to
criticize than to do something better. Actually my goal was not to replace
GnuPG, my goal was to make things a bit simpler (especially for beginners).
And I beleive that this can be done with a bunch of simple shell scripts.

Peace,
Dashamir
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Peter Lebbing]

First of all, let me say that I regret that I didn't start my mail with feedback
on your project on a positive note. I think it's good that people spend effort
trying to make things more usable, and I applaud you for it. It would have been
a lot nicer of me to start out with that. There's no excuse for forgetting basic
civility and just being friendly to one another. Sorry.

Please don't feel put off by the fact that I might lack some tact here and 
there...

On 22/03/16 20:53, Dashamir Hoxha wrote:
> The implementation will not break, as long as it is based on the latest stable
> release.
> When the next stable release of gpg is out, the implementation will be 
> adjusted
> to match it.

So you should do a check on the version and fail if it is different than the
version you worked with. And you need to support all the versions of all your
users; on short notice as well, probably. Plus the elephant in the room that the
developers of GnuPG are very explicit in that this interface is not for
scripting, yet you use it as such. You can reason about it all you want, in the
end, you're still using it differently than upstream intended.

> Regarding your main question above (I have also answered it previously), I 
> think
> that `gpg` (the command) is monolithic

All asymmetric crypto is done in the agent by now, there are separate programs
for several tasks like keyserver communication and smartcard communication. Sure
you can argue that the tasks are not spread in the way you would like, but in a
strict sense it is definitely not monolithic. "Fairly monolithic" at most.

>, bloated with functionality and options,

You might be bothered by this on principal grounds, since it is security
software and there's the attack surface and amount of code to consider, but it's
not a practical issue, purely a principal one. That's like saying you don't like
Inkscape because it lets you paint in pink and you hate pink and never use it...

> the docs are like a maze and not clearly structured

A reasonably fair criticism... writing good documentation is hard, very hard. In
fact, it turned out to be easier to write academical papers on why it is so
difficult to make crypto easy to use than to write documentation that makes
crypto easy to use.

When I refer to the man page, which is just one bloody long list without
structure (and hence not a maze either), I use search terms to find what I look
for. If specific ones will not do, a generic one, repeating the search until I
find the option I want. Then again, by now I've referred to it reasonably often
when trying to help people on this list or playing around.

>, the number of commands and
> options is huge,

Yes. Again, if we had documentation that omitted these, you would not be
bothered by it, right?


> there is no clear distinction between the commands and the
> options

This one is odd. Have you examined the structure of the man page? Let me quote
(quite) a bit:

> COMMANDS
>Commands are not distinguished from options except for the fact that 
> only one
>command is allowed.
> 
>[...]
>Commands not specific to the function
>[...]
>Commands to select the type of operation
>[...]
>How to manage your keys
>[...]
> OPTIONS
>gpg2 features a bunch of options to control the exact behaviour and to 
> change
>the default configuration.
>
>[...]
>How to change the configuration
>[...]
>Key related options
>[...]
>Input and Output
>[...]
>OpenPGP protocol specific options.
>[...]
>Compliance options
>[...]
>Doing things one usually doesn't want to do.
>[...]
>Deprecated options
>[...]

This is the structure of the two sections 'commands' and 'options'. I find it
perfectly obvious which are which. If you're lost in the massive list of options
and wonder whether you're looking at a command or an option, you do a backwards
search for a line that doesn't start with a blank. You'll end up at either
"COMMANDS" or "OPTIONS", and you'll have your answer. Basic man page voodoo,
searching for a non-blank first character to navigate sections.

>, the supported use cases are not so clear (it actually tries to support
> everything)

Everything OpenPGP related, yes. The gpg2 binary is the front end to GnuPG with
regards to OpenPGP. Is this the same argument as "it's monolithic"? What
practical gain do you get if, for instance, key management were done with a
binary called "keymgr", and so on? In the end, when you verify a signature, you
want to know the validity of the key, so the same code gets exercised, whether
it's in a library shared by several binaries or one binary.

And even the library, GPGME, executes a binary: that way you get address space
separation. That way, all the crypto is in a separate process, out of the grubby
hands of whatever calls it. The private key is even further away in the agent
:). Again a separate 

Re: EasyGnuPG

[Dashamir Hoxha]

On Tue, Mar 22, 2016 at 3:41 PM, Ben McGinnes  wrote:
>
> You might try experimenting with gpgme-tool then, it's one of the
> undocumented/self-documented extras which comes with GPGME.  It
> provides a socket interface with which you can interact with portions
> of the GPGME functions, including most of the most common functions.
> You can also pipe its commands to it through a shell, so start with
> something like this:
>
> echo help | gpgme-tool
>
> Or this:
>
> echo help | gpgme-tool > gpgme-tool-cheatsheet.txt
>

This seems promissing. Thanks for the suggestion.
The problem is that I cannot find `gpgme-tool` in ubuntu 14.04 and it seems
that the only way to install it is by compiling. This certainly complicates
things a bit.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Dashamir Hoxha]

On Tue, Mar 22, 2016 at 10:54 AM, Paolo Bolzoni <
paolo.bolzoni.br...@gmail.com> wrote:

> I totally agree, Dashamir I really think you should focus on what you
> think is hard in gnupg? And why?
> Are you sure a new program (and not a simple patch) is the best answer?
>
> At the moment you are showing us strange defaults, an implementation
> that can break at any time, and I am not really sure how much it is
> easier anyway.
>

The implementation will not break, as long as it is based on the latest
stable release.
When the next stable release of gpg is out, the implementation will be
adjusted to match it.


> For example, I find strange and needlessy difficult that the keys have
> a duration and not an expiration date. So when one wants the key to
> last until the end of the year or to his birthday one has to make a
> date difference manually.
>

You are right, I find it strange and counterintuitive too. I can try to fix
it on egpg.

Regarding your main question above (I have also answered it previously), I
think that `gpg` (the command) is monolithic, bloated with functionality
and options, the docs are like a maze and not clearly structured, the
number of commands and options is huge, there is no clear distinction
between the commands and the options, the supported use cases are not so
clear (it actually tries to support everything), the default values are not
well-thought, the terminology is confusing and counter-intuitive, etc.
Do you think these can be fixed with simple patches?
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Dashamir Hoxha]

On Tue, Mar 22, 2016 at 2:28 PM, Werner Koch  wrote:

>
> There are two simple things you need to remember when using gpg in a
> script:
>
>   1. --batch to avoid all interaction.
>
>   2. --with-colons to get a well defined output format.  That format is
>  not good for humans, though.
>
> Well we could have done switching the output format automagically but
> that would be rather surprising.  If it is used by a script, adding two
> extra options for the invocation is not really a bug task.
>

I don't think that automagic would be a good thing.
I still think that the colons format is a bit difficult to process and not
so suitable.

But most importantly, I think that these two options are not enough, it is
not as easy as that. For example there is also --passphrase-fd,
--command-fd, --logging-fd etc. and sometimes I still don't manage to
control properly all the input and output, or I have to do spectacular
things that complicate things a lot. I think that it doesn't have to be
that difficult.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Dashamir Hoxha]

On Tue, Mar 22, 2016 at 4:29 PM, Werner Koch  wrote:

> On Tue, 22 Mar 2016 15:41, b...@adversary.org said:
>
> > provides a socket interface with which you can interact with portions
> > of the GPGME functions, including most of the most common functions.
>
> FWIW: We even consider to extend gpgme-tool to be a Native Messaging
> Server for Browsers.
>

In this case, "gpgme-tool" should be packaged on its own, not inside the
package "*libgpgme11-dev*".
I am refering to this message:
https://lists.gnupg.org/pipermail/gnupg-devel/2014-December/029206.html
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Verification via the web of trust

[Andrew Gallagher]

On 22/03/16 18:30, Peter Lebbing wrote:
> On 22/03/16 19:14, Andrew Gallagher wrote:
>> All this is true. But this does not help *me* one iota.
> 
> It sounds to me like you're not looking for the Web of Trust, which is indeed
> very limited in its options. Instead, you are probably looking for something
> more like TOFU, in the sense that this developer whose signature you see is 
> the
> same one whose signature you saw last time.

Only for a project with one developer! Otherwise, the person who signs
it could legitimately change between releases. Large projects often have
a separate release signing key, but not apache it seems...

And at the risk of getting shot down (again), TOFU doesn't work. Not
because TOFU is broken (it's a perfectly valid method), but because
*people* are broken. How many times have you blithely clicked through an
ssh "WARNING: the remote host key has changed!" prompt? ;-)

A



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Verification via the web of trust

[Peter Lebbing]

On 22/03/16 19:14, Andrew Gallagher wrote:
> Real world example. I wanted to install the latest copy of Apache for
> windows. It is signed by one William A Rowe Jr. I do not know William A
> Rowe Jr, nor do I know any of the people who have signed his key, nor am
> I ever likely to meet them, let alone trust them enough to verify other
> keys on my behalf.

By the looks of it, you could get an interesting alternate trust path here.

You say you run Debian. You can download digitally signed source code through
Debian, and in this source code, I see this file:

https://anonscm.debian.org/cgit/pkg-apache/apache2.git/tree/debian/upstream/signing-key.pgp

My guess is that this is the list of keys accepted for apache2 source code for
the Debian builds. Your William A Rowe Jr is in there. Apparently Debian trusts
him, and if you download it with apt-get source, you can get a verified genuine
copy of this file. So if the signature is valid for the key in this file, you
can be pretty darn sure that you have the right one. Otherwise, somebody managed
to subvert the integrity system of Debian.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Verification via the web of trust

[Peter Lebbing]

On 22/03/16 19:14, Andrew Gallagher wrote:
> All this is true. But this does not help *me* one iota.

It sounds to me like you're not looking for the Web of Trust, which is indeed
very limited in its options. Instead, you are probably looking for something
more like TOFU, in the sense that this developer whose signature you see is the
same one whose signature you saw last time.

Or maybe a radically different other trust model. Quite likely one which hasn't
actually been implemented. It's still the same though: the OP talked about the
Web of Trust, so my answer was about the Web of Trust. That the Web of Trust is
not what you are looking for is a completely different issue.

> Even importing the entire Debian keyring and setting them all to marginal
> trust (I'm already trusting them to write my OS, so why not?)

Exactly! Well observed. I've said it before as well, a nefarious person holding
the private key of a Debian Developer can do much more interesting stuff than
introduce false signatures in the Web of Trust, so you might as well trust them
on that too. That is, as always, depending on your threat model. But I'd wager
that it's compatible with a lot of threat models, since Debian developers can
pretty much execute code as root on your machine.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Verification via the web of trust

[Andrew Gallagher]

On 22/03/16 17:11, Peter Lebbing wrote:
> 
> That trust is not transitive is not some quirk of the web of trust: it
> is fundamental. I might trust Carl, and Carl might trust Jenny, but if I
> don't know Jenny, I would not trust her, despite the fact that I trust
> someone who trusts her. Trust is personal and direct, not transitive.

All this is true. But this does not help *me* one iota.

While the usual formulation of the web of trust (or any PKI for that
matter) runs along the lines of "given that I trust this finite list of
people, can I verify this particular signature?", the question most
useful to a user is "given this particular signature, how much
confidence should I invest in it?".

They are not the same question.

Real world example. I wanted to install the latest copy of Apache for
windows. It is signed by one William A Rowe Jr. I do not know William A
Rowe Jr, nor do I know any of the people who have signed his key, nor am
I ever likely to meet them, let alone trust them enough to verify other
keys on my behalf. I'd never even heard of William A Rowe Jr before I
tried to download his software. And yet the PGP signature on that binary
must be worth something other than zero.

In my quest to verify the signature of William A Rowe Jr, I ended up
downloading over a thousand keys. Even importing the entire Debian
keyring and setting them all to marginal trust (I'm already trusting
them to write my OS, so why not?) wasn't enough. I did manage it in the
end by assigning full trust to a judicious selection of people that I
recognised by name and reputation, and a few that I didn't.

Sure, it probably wasn't worth the effort I spent on it. And of course,
I then ended up with a terrifyingly liberal trustdb - but which was
still not liberal enough to verify a significant fraction of posts to
debian-security despite me marginally trusting their entire keyring.

My point is, there are times when you want to be absolutely certain that
a particular key belongs to someone you know and trust. And there are
times when you are looking for whatever assurances you can get that some
random dude on the internet isn't about to pwn your server. I'd contend
that the second use case is far more common than the first.

If you can't ascribe at least *some* level of trust to multiple PGP
signatures in the WOT made by named individuals (even those not
personally known to you), then you certainly shouldn't be relying on
X509 certificates issued by a single one of hundreds of faceless CAs
through some automated process. But every day you do that, because the
alternative is not to use the internet at all.

A




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Verification via the web of trust

[Peter Lebbing]

On 22/03/16 13:21, Lachlan Gunn wrote:
> All the pathfinders I've seen have been full-on HTML websites, is there
> anything out there more suitable for scripting?

This doesn't help you one iota. The simple reason: trust is not
transitive. If you want key A, which is 4 hops away from you, to become
valid, you need to trust a key B that has signed it. So either you see
among the people who signed key A someone you trust, or you don't. I'm
pretty sure you would recognise the name of someone you trust.

If you do see a name you recognise, key B, and who you trust, the task
simply transfers from A to this B. Only if, on every hop along the path,
there are people you recognise and trust, can you actually get valid
keys that are several hops away.

That trust is not transitive is not some quirk of the web of trust: it
is fundamental. I might trust Carl, and Carl might trust Jenny, but if I
don't know Jenny, I would not trust her, despite the fact that I trust
someone who trusts her. Trust is personal and direct, not transitive.

There is one exception: when you trust someone so much that you'd
delegate the issue of trust to them. This is usually only done in
specific, small communities and employer-employee relations, and is a
"trust signature". They are hardly ever used. Note that the trust might
be more built into the relationship than that you actually do trust your
employer... ;)

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Ben McGinnes]

On Tue, Mar 22, 2016 at 04:29:42PM +0100, Werner Koch wrote:
> On Tue, 22 Mar 2016 15:41, b...@adversary.org said:
> 
> > provides a socket interface with which you can interact with
> > portions of the GPGME functions, including most of the most common
> > functions.
> 
> FWIW: We even consider to extend gpgme-tool to be a Native Messaging
> Server for Browsers.

Ah, well that explains the reasoning behind the XML format used for
storing key data then.  Presumably it was done back when XHTML was
being pushed as the future of the web, way before the current H5
thing.  Fortunately there's still a bunch of decent reasons to use XML
when defining information sets, even if most developers and almost all
users never touch it.

I guess I'd better make another branch to put those Relax-NG and XSD
(W3C) schemas I generated in for anyone who needs them.


Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Verification via the web of trust

[Brian Minton]

One idea I've been tossing about: import the whole dump.  I read that gpg
2.1 uses a new efficient key database called keybox. It would be
interesting to see if it could handle that much data, and if so, gpg could
do the WoT calculations directly.

On Tue, Mar 22, 2016, 9:33 AM Lachlan Gunn  wrote:

> Hello,
>
> Apologies if this is an excessively newbie question, but is there any
> reasonably automated way to do verification via the web-of-trust when
> you don't have all the intermediate steps in the keyring already?
>
> All the pathfinders I've seen have been full-on HTML websites, is there
> anything out there more suitable for scripting?  If not, is there a
> reason?  I have a keyserver dump, a newly-written OpenPGP
> parser/verifier, and a mild sense of irritation :)
>
> Thanks,
> Lachlan
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A better interface to the GnuPG-Framework (Re: EasyGnuPG)

[Dashamir Hoxha]

On Tue, Mar 22, 2016 at 3:53 PM, Paolo Bolzoni <
paolo.bolzoni.br...@gmail.com> wrote:

> I guess we should start from the desired use case.
> We want a GUI for what? Encrypting? Signing? Managing the web of
> trust? SSH login? Everything?


I think that deciding the desired use case(s) is important.
In a certain use case only 5-6 commands/operations/options may be needed,
not 300+.

In my opinion this is one of the problems with `gpg`. It is so generic that
it tries to cover all the possible cases. Consequently, it is huge, and
difficult, and suitable for none of them. It is more like a library than
like a user interface. Any GUI that tries to follow it faithfully will be
difficult, confusing and unintuitive. Each GUI should try to simplify
according to its specific use case.

Another problem that people have noticed with PGP (and inherited to GPG by
trying to follow PGP faithfully), is the confusing terminology (private
key, public key, etc.). In egpg I have tried to improve this by using the
term "key" for the personal key-pair, and using the term "contact" for the
public keys of the people with whom we communicate. This term ("contact")
maybe does not have an exactly correct meaning, but it is widely popular,
even among dummies who have never used anything but a (non-smart) mobile
phone. If you say "contact" they immediately think about the details of a
person with whom you want to communicate

The names of the commands and options can be improved as well, to better
fit the use case on which the GUI app is being used. I have also tried to
make sure that there is only one valid (unrevoked and unexpired) private
key at any time. Allowing more than one would increase the complexity of
the interface and make things more complicated. In certain cases you may
need more than one valid keys, but these cases are rare and can be handled
by other means.

Dashamir
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A better interface to the GnuPG-Framework (Re: EasyGnuPG)

[Ben McGinnes]

On Tue, Mar 22, 2016 at 03:45:09PM +0100, Bernhard Reiter wrote:
> On Tuesday 22 March 2016 at 15:14:41, Ben McGinnes wrote:
> > You know what might, though, if someone were to take up the old GPA
> > project perhaps ... maybe port it to GTK 3 or implement a Qt version.
> 
> We have just cleanup and simplified the structure of Kleopatra,
> so that is making steps into the direction of the Qt5 version
> you are thinking of. If you want to help improve a gui part 
> Andre currently is hacking on Kleopatra, so that is a good chance
> to test and give feedback about its user interface.
> 
> We want to know what it would take to make Kleo an easy
> to use crypto GUI for GnuPG.

Ah, no, I think I'll have to leave that to the others.  Mainly because
I already have quite the task ahead of me with the future planned
GPGME Python 3 work (GPyGME, but it's waiting on the GPGME overhaul),
though also because the last serious effort I made at any GUI
programming was with Tkinter about 15 years ago (and I sucked at it).

As for more modern things ... well I'verecently dumped Thunderbird to
return to Mutt plus Emacs, so I guess that says something.  Note, that
wasn't Enigmail's fault, it was purely the compounding of Mozilla's
... whatever it's becoming (plus it can't handle the volume of mail
and accounts I have to deal with).

 
Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Werner Koch]

On Tue, 22 Mar 2016 15:41, b...@adversary.org said:

> provides a socket interface with which you can interact with portions
> of the GPGME functions, including most of the most common functions.

FWIW: We even consider to extend gpgme-tool to be a Native Messaging
Server for Browsers.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A better interface to the GnuPG-Framework (Re: EasyGnuPG)

[Paolo Bolzoni]

I guess we should start from the desired use case.
We want a GUI for what? Encrypting? Signing? Managing the web of
trust? SSH login? Everything?

On Tue, Mar 22, 2016 at 3:45 PM, Bernhard Reiter  wrote:
> On Tuesday 22 March 2016 at 15:14:41, Ben McGinnes wrote:
>> You know what might, though, if someone were to take up the old GPA
>> project perhaps ... maybe port it to GTK 3 or implement a Qt version.
>
> We have just cleanup and simplified the structure of Kleopatra,
> so that is making steps into the direction of the Qt5 version
> you are thinking of. If you want to help improve a gui part
> Andre currently is hacking on Kleopatra, so that is a good chance
> to test and give feedback about its user interface.
>
> We want to know what it would take to make Kleo an easy
> to use crypto GUI for GnuPG.
>
> Best,
> Bernhard
>
>
> --
> www.intevation.de/~bernhard (CEO)www.fsfe.org (Founding GA Member)
> Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
> Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Ben McGinnes]

On Tue, Mar 22, 2016 at 11:20:40AM +0100, Dashamir Hoxha wrote:
> On Tue, Mar 22, 2016 at 9:56 AM, Bernhard Reiter 
> wrote:
> >
> > Any cross plattform approach would work. Python has the advantage
> > that the source code can be changed by an editor an immedeately run
> > and that it works fairly well cross-plattform.
> >
> > What is even more important is that you should use the official API to
> > GnuPG which is Gpgme. https://wiki.gnupg.org/APIs
> 
> 
> This is an important point (using the API), because trying to use
> `gpg` in scripts is terribly difficult. I don't understand why `gpg`
> does not follow the unix philosophy of being easily used in scripts
> and cooperating easily with other commands.

> So, if there are some things to be improved on gpg, this is one of
> them: make it more scriptable. Alternatively, make a bash wrapper of
> Gpgme (which can be used on bash scripts).

You might try experimenting with gpgme-tool then, it's one of the
undocumented/self-documented extras which comes with GPGME.  It
provides a socket interface with which you can interact with portions
of the GPGME functions, including most of the most common functions.
You can also pipe its commands to it through a shell, so start with
something like this:

echo help | gpgme-tool
 
Or this:

echo help | gpgme-tool > gpgme-tool-cheatsheet.txt


Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

A better interface to the GnuPG-Framework (Re: EasyGnuPG)

[Bernhard Reiter]

On Tuesday 22 March 2016 at 15:14:41, Ben McGinnes wrote:
> You know what might, though, if someone were to take up the old GPA
> project perhaps ... maybe port it to GTK 3 or implement a Qt version.

We have just cleanup and simplified the structure of Kleopatra,
so that is making steps into the direction of the Qt5 version
you are thinking of. If you want to help improve a gui part 
Andre currently is hacking on Kleopatra, so that is a good chance
to test and give feedback about its user interface.

We want to know what it would take to make Kleo an easy
to use crypto GUI for GnuPG.

Best,
Bernhard


-- 
www.intevation.de/~bernhard (CEO)www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Ben McGinnes]

On Mon, Mar 21, 2016 at 06:38:31PM +0100, Peter Lebbing wrote:
> On 21/03/16 16:49, Dashamir Hoxha wrote:
> > Yes, but the overall number of commands and options supported
> > is 10 times smaller than those of gpg2. Tutorials about egpg are also
> > much shorter.
> 
> These things can simply be solved through new documentation rather
> than a new interface. The man page is typical reference style: all
> commands and options in a list format. It's not tutorial style,
> omitting all but common options and presenting the material in a
> tutorial form.

The thing about training in GPG is people have to want it.  In my
experience everyone in the general public decides that "it's all too
hard" right up until the moment where it is actually their freedom on
on the line or the opportunity to make a buck.  Then they can suddenly
learn the basics within 1 to 2 hours and love it.  Funny that ...

Mind you, some students are better than others and two of my best
students certainly put it all to good use.  One wrote this:

https://store.kobobooks.com/en-ca/ebook/silk-road-4

And the other conducted the academic study while shepherding PhD
candidates through the "dark net" (some of which was hilarious).

> > And the default values of the options are more suitable
> > for a beginner (at least in my opinion).
> 
> I had a quick look through the source.
> 
> The only thing I see in that category, IMHO, is automatically naming output
> filenames.

What, you mean like "gpg2 --use-embedded-filename"?  The only time
that is null is when the original file was actually from stdin
(usually in the case of an email) in which case you should be able to
generate a unique filename from the message ID.


Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Ben McGinnes]

On Mon, Mar 21, 2016 at 03:05:05PM +0100, Bernhard Reiter wrote:
> Hi Dashamir,
> 
> On Friday 18 March 2016 at 09:49:16, Dashamir Hoxha wrote:
> > I am writting some shell scripts for making GnuPG more accessible and
> > easier to use:
> >  - https://github.com/dashohoxha/egpg
> 
> I like the goal of making gpg2 more accessible.
> However I am not sure that you are actually reaching the goal
> by using sh wrappers. When looking at the man pages, it seems
> that they are already long with a number of phrases to learn.
> Most of these commands are not much easier than the direct gpg2
> commands they are aiming to replace.

You know what might, though, if someone were to take up the old GPA
project perhaps ... maybe port it to GTK 3 or implement a Qt version.

Or make a free thing that does what that GPGShell GUI thing so many
Windows users seem fond of, but isn't even available under a BSD or
LGPL license, let alone GPL 2 or 3.  I've never used that one, but so
many of the PGPNET subscribers swear by the thing for ease of use as
well as effectiveness.

> Drawbacks I see with your approach:
> * people will have to learn a slightly different set of commands
>   with egpg and gpg2 and sooner or later will use the gpg2 commands
>   and then they will be confused or have extra learning efforts.
> * shell scripts will not work on plattforms without a shell
>   (e.g. Windows)

And those of us used to using shells have probably rolled our own by
this stage.  In my case gpg1 is a shell wrapper for GPG 1.4.x and an
alternate homedir so I really can keep using both keyring formats,
gpg2 is 2.1 with some kind of proper-ish trust model, gpg21 is the
same except it also reloads dirmngr to use tor and gpg runs the 2.1
binary with trust-model always.  Although all mine still use and
accept all the standard flags, they just load slightly different
configurations for the most part.

> * I haven't looked into the .epgp directory, but it may have some configs
>   and then the behaviour of other applications will depend on whoch config
>   they use.

> * BTW: There is a potential name clash with https://wiki.gnupg.org/EasyGpg2016

Also with the old Emacs binding of EasyPG (now under the EPA banner).

> Ideas for improvements:
> * I you must, write wrappers code it in something more plattform indepentent, 
>   e.g. in python3 (using pyme or pygpgme where appropriate)

There's already a port of pyme to Python 3, it's pretty much ready to
go save for some final PEP8 checks which I'm working through the last
of currently (in between the occasional local unrelated catastrophe,
of course).  The 99% ready code is in one of my branches in the gpgme
repo on playfair.

> * Suggest and improve the original gpg2 command line interface, so that
>   usage is easier and the more esotheric options will not be seen or used
>   by default.

Given most of them should be in the gpg.conf file anyway, they
normally only need to be set once.  Sometimes toggled back and forth
(e.g. with --expert), but mostly it's set once and leave it that way
(e.g. enable-large-rsa, enable-dsa2, allow-freeform-uid, etc.).


Regards,
Ben

-- 
|   Ben McGinnes  |  Adversarial Press  |  Twitter: benmcginnes |
| Writer, Publisher, Systems Administrator, Trainer, ICT Consultant |
|   http://www.adversary.org/  http://publishing.adversary.org/ |
| GPGME Python 3 API Dev, GNU Privacy Guard  https://www.gnupg.org/ |
| Encrypted email preferred, OpenPGP/GPG key: 0x321E4E2373590E5D|
| OpenPGP/GPG key here: http://goo.gl/GVGwT and http://goo.gl/SDs0D |

 


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: more files in private-keys-v1.d than shown with 'gpg --with-keygrip -K'

[Brad Rogers]

On Tue, 22 Mar 2016 10:12:36 +0100
Viktor Dick  wrote:

Hello Viktor,

>Thanks, I found it myself but since the sender of a mail to the list
>does not get a copy of it,

It's a gmail-ism;  Most people get their list messages sent back to
them, but not gmail users.  It's a 'feature' google seem to be proud of.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
It's cool to know nothin'
Never Miss A Beat - Kaiser Chiefs


pgpfOPM0exMI6.pgp
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Andrew Gallagher]

> On 22 Mar 2016, at 10:40, Paolo Bolzoni  wrote:
> 
> And besides, it's much easier to build a GUI app in front of a C API
> than a command line application.

This is undeniably true. Unfortunately you first need to learn the API, which 
can be a barrier to someone who knows the command line interface and just wants 
to hack together a script to do a particular job. 

Cryptography is hard, and decades later we still aren't at the point where 
average computer users can take advantage of it without either first becoming 
experts or punching holes in the sides of the boat. For that we need to be 
encouraging hackers and tinkerers to experiment with novel interfaces; and this 
is best done by giving them the software equivalent of Lego rather than 
Meccano. 

This is not a gpg-specific issue. OpenSSL suffers the same problem of having to 
be both a comprehensive implementation and a user interface, and handles it 
pretty much the same way, by using a basic command prompt. 

Where is the gpg equivalent of easy-rsa though? This is a complaint about 
software tools in general, but for hackers and tinkerers inconsistency across 
UIs is a significant barrier to entry. If I can't take what I've learned from 
using the command line for years and apply it (safely) to writing a modest 
shell script, I'm going to think long and hard before taking the time to learn 
a Python API. At the very least, any feature accessible through an interactive 
interface should have an equivalent command line option, so that all 
interactive operations can trivially be automated. Thought should also be given 
to whether wrapping all functionality in a single binary with thousands of 
options is the best interface to present to even expert command line users 
(again, OpenSSL is another offender). 

I say this because I found myself in exactly the same boat as the OP. I wanted 
to write a small script for my technically-proficient but 
non-cryptography-expert users so that they could easily manage gpg private keys 
without me worrying that they'd screw it up; and I ended up with a fragile 
interface very similar to his that needed to be completely refactored using 
gpgme. Just interfacing with gpg was the most difficult part of the process; 
the logic that I built on top of it was easy by comparison. This is the wrong 
way around.

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Where is /usr/local/gnupg-2.1?

[Ben McGinnes]

On Mon, Mar 21, 2016 at 11:31:56PM -0400, Robert J. Hansen wrote:
> > There are two other possible explanations: MacPorts (see macports.org)
> > and Home Brew.
> 
> And Fink, and... etc.  However, I'm omitting the ... let's call them
> "comprehensive" solutions that allow you to install all manner of
> things.  For standalone packages, it's either GPGTools or GPGOSX.

True enough, but at least this time I managed to resist the temptation
to answer the question with the facetious "it's in /usr/local"
response.  ;)


Regards,
Ben


 


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Verification via the web of trust

[Lachlan Gunn]

Hello,

Apologies if this is an excessively newbie question, but is there any
reasonably automated way to do verification via the web-of-trust when
you don't have all the intermediate steps in the keyring already?

All the pathfinders I've seen have been full-on HTML websites, is there
anything out there more suitable for scripting?  If not, is there a
reason?  I have a keyserver dump, a newly-written OpenPGP
parser/verifier, and a mild sense of irritation :)

Thanks,
Lachlan



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Werner Koch]

On Tue, 22 Mar 2016 11:20, dashoho...@gmail.com said:

> scripts is terribly difficult. I don't understand why `gpg` does not follow
> the unix philosophy of being easily used in scripts and cooperating easily
> with other commands.

It actually does.  There are just two things which differ:

  - gpg needs to ask for a passphrase.  For obvious reasons we do not
want to take the passphrase from stdin by default but use a direct
pty access for this.

  - gpg was designed as a replacement for pgp and thus comes with an
extensive tty based user interface.  This is indeed not what a Unix
tool should be but it helps the user to get the crypto right.

And different to many Unix tools, gpg keeps state like cron, batch,
mail, and at does.

There are two simple things you need to remember when using gpg in a
script:

  1. --batch to avoid all interaction.

  2. --with-colons to get a well defined output format.  That format is
 not good for humans, though.

Well we could have done switching the output format automagically but
that would be rather surprising.  If it is used by a script, adding two
extra options for the invocation is not really a bug task.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Paolo Bolzoni]

My real question is: what do you think in gpg is not easy enough?

On Tue, Mar 22, 2016 at 11:53 AM, Dashamir Hoxha  wrote:
> On Tue, Mar 22, 2016 at 11:40 AM, Paolo Bolzoni
>  wrote:
>>
>> And besides, it's much easier to build a GUI app in front of a C API
>> than a command line application.
>
>
> By no means I want to prevent anybody from starting to build a GUI app...

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Paolo Bolzoni]

I totally agree, Dashamir I really think you should focus on what you
think is hard in gnupg? And why?
Are you sure a new program (and not a simple patch) is the best answer?

At the moment you are showing us strange defaults, an implementation
that can break at any time, and I am not really sure how much it is
easier anyway.

For example, I find strange and needlessy difficult that the keys have
a duration and not an expiration date. So when one wants the key to
last until the end of the year or to his birthday one has to make a
date difference manually.



On Tue, Mar 22, 2016 at 10:46 AM, Robert J. Hansen  wrote:
>> Just like Peter wrote I think that a user would usually not
>> encounter all bells and wistles.
>
> I think it's rather a bit more extreme than that.  I think if a user has
> to fire GnuPG up from the command line *for anything*, something's gone
> terribly wrong and we're in danger of losing a user.
>
> No, no, I'm not saying GnuPG is bad for being a command-line
> application.  But ask yourself how many users even know how to launch a
> terminal, much less interact with one.  The number is shockingly low.
> If you want to improve GnuPG's adoption rate, the best path forward
> appears to be to target users who only know how to navigate GUI interfaces.
>
> I don't think the EasyGnuPG authors have thought through their target
> market.  It targets users who are comfortable enough to say "oh, I
> should use the terminal for this!", but not comfortable enough to read a
> manpage.  It's targeting a small subset of a small subset.
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Dashamir Hoxha]

On Tue, Mar 22, 2016 at 11:40 AM, Paolo Bolzoni <
paolo.bolzoni.br...@gmail.com> wrote:

> And besides, it's much easier to build a GUI app in front of a C API
> than a command line application.


By no means I want to prevent anybody from starting to build a GUI app...
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Robert J. Hansen]

> This is an important point (using the API), because trying to use `gpg`
> in scripts is terribly difficult. I don't understand why `gpg` does not
> follow the unix philosophy of being easily used in scripts and
> cooperating easily with other commands.

GnuPG is, believe it or not, a lot more like Apache than it is like
grep, cat, or wc.  When I start an Apache server it always asks me for
an SSL certificate password, it opens network connections, it spawns
daemons, it awaits connections... etc.

When I run "gpg2 --card-status", GnuPG has to spawn at least two
daemons: gpg-agent and scdaemon.  When I do a "--recv-key" I'm opening
HTTPS connections with the outside world.  When I do a signing
operation, gpg-agent has to connect with gpg2 and do complex handoffs
between them.

GnuPG isn't a single tool.  GnuPG is a complete platform, a whole
system, the same way that Apache or MySQL are.

Thinking that the gpg command-line tool is GnuPG is sort of like
thinking apachectl is Apache.  In both cases they're just tools that you
use to manipulate a far larger software ecosystem.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Paolo Bolzoni]

And besides, it's much easier to build a GUI app in front of a C API
than a command line application.

On Tue, Mar 22, 2016 at 11:35 AM, Robert J. Hansen  wrote:
>> And then, it is not difficult to build a GUI app on top of a
>> command-line tool that works properly. I cannot do it, but somebody
>> maybe can do it easily.
>
> Oh, it's *hard*.  Look at how long it took Enigmail to get into a state
> where it wasn't painful to use -- and there are still, today, parts
> about it that give me the heebie-jeebies.  (Admittedly, I don't have a
> good fix for it, but...)
>
> User interface design is a hard subject.  It requires a much different
> set of skills than software development, particularly cognitive
> psychology.  Look at how much money Apple spends making user interfaces;
> they're not throwing that much money at the problem because it's easy.  ;)
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Robert J. Hansen]

> And then, it is not difficult to build a GUI app on top of a
> command-line tool that works properly. I cannot do it, but somebody
> maybe can do it easily.

Oh, it's *hard*.  Look at how long it took Enigmail to get into a state
where it wasn't painful to use -- and there are still, today, parts
about it that give me the heebie-jeebies.  (Admittedly, I don't have a
good fix for it, but...)

User interface design is a hard subject.  It requires a much different
set of skills than software development, particularly cognitive
psychology.  Look at how much money Apple spends making user interfaces;
they're not throwing that much money at the problem because it's easy.  ;)


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Dashamir Hoxha]

On Tue, Mar 22, 2016 at 10:46 AM, Robert J. Hansen 
wrote:
>
> I don't think the EasyGnuPG authors have thought through their target
> market.  It targets users who are comfortable enough to say "oh, I
> should use the terminal for this!", but not comfortable enough to read a
> manpage.  It's targeting a small subset of a small subset.
>

The target users (not market, because I don't intend to sell it) are people
like me, who are comfortable using the terminal, but still find it
difficult to use gpg properly, even after reading lots of docs and
tutorials.

And then, it is not difficult to build a GUI app on top of a command-line
tool that works properly. I cannot do it, but somebody maybe can do it
easily.

Dashamir
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Dashamir Hoxha]

On Tue, Mar 22, 2016 at 9:56 AM, Bernhard Reiter 
wrote:
>
> Any cross plattform approach would work. Python has the advantage
> that the source code can be changed by an editor an immedeately run
> and that it works fairly well cross-plattform.
>
> What is even more important is that you should use the official API to
> GnuPG which is Gpgme. https://wiki.gnupg.org/APIs


This is an important point (using the API), because trying to use `gpg` in
scripts is terribly difficult. I don't understand why `gpg` does not follow
the unix philosophy of being easily used in scripts and cooperating easily
with other commands.
So, if there are some things to be improved on gpg, this is one of them:
make it more scriptable. Alternatively, make a bash wrapper of Gpgme (which
can be used on bash scripts).

The other option (for EasyGnuPG) is to be reimplemented in Python or Ruby
etc. (which have Gpgme wrappers and can use the API). Maybe someday
somebody will do this, or maybe I will do it myself some day. But for the
time being I have to stick to bash scripts and try to finish all the
features that I had in mind when I started it.

Dashamir
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: more files in private-keys-v1.d than shown with 'gpg --with-keygrip -K'

[Viktor Dick]

Thanks, I found it myself but since the sender of a mail to the list
does not get a copy of it, I could not simply reply. If I use
'--list-options show-unusable-subkeys', I see the missing keys, they are
simply expired. Sorry to disrupt.

Regards,
Viktor



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Robert J. Hansen]

> Just like Peter wrote I think that a user would usually not
> encounter all bells and wistles.

I think it's rather a bit more extreme than that.  I think if a user has
to fire GnuPG up from the command line *for anything*, something's gone
terribly wrong and we're in danger of losing a user.

No, no, I'm not saying GnuPG is bad for being a command-line
application.  But ask yourself how many users even know how to launch a
terminal, much less interact with one.  The number is shockingly low.
If you want to improve GnuPG's adoption rate, the best path forward
appears to be to target users who only know how to navigate GUI interfaces.

I don't think the EasyGnuPG authors have thought through their target
market.  It targets users who are comfortable enough to say "oh, I
should use the terminal for this!", but not comfortable enough to read a
manpage.  It's targeting a small subset of a small subset.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Using gpg for ssh access

[Bernhard Reiter]

On Thursday 17 March 2016 at 10:40:27, Damien Goutte-Gattat wrote:
> If I may, I wrote two blog posts on this subject:
>
> * http://www.incenp.org/notes/2014/gnupg-for-ssh-authentication.html
> (for GnuPG 2.0)
>
> * http://www.incenp.org/notes/2015/gnupg-for-ssh-authentication.html
> (for GnuPG 2.1)

I've now linked them from https://wiki.gnupg.org/documentation.

Bernhard


-- 
www.intevation.de/~bernhard (CEO)www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: EasyGnuPG

[Bernhard Reiter]

Hi Dashamir,

On Monday 21 March 2016 at 16:49:41, Dashamir Hoxha wrote:
> Hi Bernhard, thanks for having a look at it.

you are welcome! I appreciate all efforts to make GnuPG more accessible,
this is why I am taking a little bit of time to write up some feedback.



> On Mon, Mar 21, 2016 at 3:05 PM, Bernhard Reiter 
> > Most of these commands are not much easier than the direct gpg2
> > commands they are aiming to replace.
>
> Yes, but the overall number of commands and options supported
> is 10 times smaller than those of gpg2. Tutorials about egpg are also
> much shorter. 

Just like Peter wrote I think that a user would usually not
encounter all bells and wistles. You can get along with just a few 
commands. This is why I suggest of trying to approach this from
the documentation angle and for the remaining options that are still too hard: 
Suggest improvements directly to gpg2.

> And the default values of the options are more suitable 
> for a beginner (at least in my opinion).

Just like Peter I do not fully understand the rationale behind those
choices and would probably choose different ones.
A good path forward would be to try to measure this with 
groups of users in a usability test. This is a lot of effort I guess,
so instead we could try to develop a few personas (example user types)
and try to argu from their point of view.

> > * shell scripts will not work on plattforms without a shell
> >   (e.g. Windows)
>
> I have heard that you can use shell scripts on Windows (with cygwin).

Using Cygwin is not a good approach because it is lik a second operating 
system within windows. Windows users would prefer a more windows like 
approach.

> > Ideas for improvements:
> > * I you must, write wrappers code it in something more plattform
> > indepentent,
> >   e.g. in python3 (using pyme or pygpgme where appropriate)
>
> The problem with Python is that I am not familar with it (and there may be
> other problems too, that I don't know).
> But if you could fork egpg and re-implement it in Python, it could be
> great.

Any cross plattform approach would work. Python has the advantage
that the source code can be changed by an editor an immedeately run
and that it works fairly well cross-plattform.

What is even more important is that you should use the official API to
GnuPG which is Gpgme. https://wiki.gnupg.org/APIs

> > * Suggest and improve the original gpg2 command line interface, so that
> >   usage is easier and the more esotheric options will not be seen or used
> >   by default.
> > * Write a beginners man page for the original gpg2, which covers only the
> > main
> >   use cases.
>
> I guess these two are suggestions for EasyGpg2016.

The goals of out EasyGpg206 are different: We will add some new trust and cert 
distribution methods to GnuPG and some selected email applications. Users 
shall never needs to go to the command line.

Best,
Bernhard


-- 
www.intevation.de/~bernhard (CEO)www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: more files in private-keys-v1.d than shown with 'gpg --with-keygrip -K'

[Werner Koch]

On Mon, 21 Mar 2016 21:05, viktordic...@gmail.com said:

> key and not present in the folder). I guess these are expired subkeys
> which I somehow deleted from my keyring, but why would the private keys

Or keys used by SSh or X.509.

Use gpg-connect-agent and then:

  > help keyinfo
  # KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] 
  # 
  # Return information about the key specified by the KEYGRIP.  If the
  # key is not available GPG_ERR_NOT_FOUND is returned.  If the option
  # --list is given the keygrip is ignored and information about all
  # available keys are returned.  If --ssh-list is given information
  # about all keys listed in the sshcontrol are returned.  With --with-ssh
  # information from sshcontrol is always added to the info. Unless --data
  # is given, the information is returned as a status line using the format:
  # 
  #   KEYINFO   
  # 
  # KEYGRIP is the keygrip.
  # 
  # TYPE is describes the type of the key:
  # 'D' - Regular key stored on disk,
  # 'T' - Key is stored on a smartcard (token),
  # 'X' - Unknown type,
  # '-' - Key is missing.
  # 
  # SERIALNO is an ASCII string with the serial number of the
  #  smartcard.  If the serial number is not known a single
  #  dash '-' is used instead.
  # 
  # IDSTR is the IDSTR used to distinguish keys on a smartcard.  If it
  #   is not known a dash is used instead.
  # 
  # CACHED is 1 if the passphrase for the key was found in the key cache.
  #If not, a '-' is used instead.
  # 
  # PROTECTION describes the key protection type:
  # 'P' - The key is protected with a passphrase,
  # 'C' - The key is not protected,
  # '-' - Unknown protection.
  # 
  # FPR returns the formatted ssh-style fingerprint of the key.  It is only
  # printed if the option --ssh-fpr has been used.  It defaults to '-'.
  # 
  # TTL is the TTL in seconds for that key or '-' if n/a.
  # 
  # FLAGS is a word consisting of one-letter flags:
  #   'D' - The key has been disabled,
  #   'S' - The key is listed in sshcontrol (requires --with-ssh),
  #   'c' - Use of the key needs to be confirmed,
  #   '-' - No flags given.
  # 
  # More information may be added in the future.
  OK
  
This returns what gpg-agent knows about the private keys.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Where is /usr/local/gnupg-2.1?

[Ben McGinnes]

On Mon, Mar 21, 2016 at 06:39:33PM -0400, Robert J. Hansen wrote:
> Edgar reached out to me earlier, and I directed him here to this list in
> the hopes that someone with more clue than me would be able to help.
> 
> Edgar, I'm not particularly up on GPG for OS X.  However:
> 
> > So, I went to the GnuPG site and I was able to download GnuPG-2.1.11. I
> > received a “Installation successful” message, but
> > the Thunderbird/Enigmail Set-up Wizard cannot find the files
> > automatically.
> 
> GnuPG doesn't host an OS X build.  These are provided by either the
> GPGTools group (providing GnuPG 2.0) or Patrick Brunschwig (providing
> GnuPG 2.1).  I don't know which version of GnuPG you installed, but if
> you got it from the GnuPG site then I'm pretty sure it wasn't what you
> think it is.

There are two other possible explanations: MacPorts (see macports.org)
and Home Brew.  By default Mac Ports installs software to /opt/local
and users always have the option of compiling anything from source.
Ports tend to have a a specific set of generic compilation or
configuration options so more ofteh than not I'll use it to grab the
libraries and then do some serious customisation on the last two
packages (GPG and GPGME).

Home Brew, however, is an autocratic little pain in the butt, but
because it uses GitHub as an ad-hoc package manager it is very
popular.  The price os using home brew means that /usr/local is
off-limits for your own projects (a deal breaker for me), it won't run
if MacPorts is installed at all (another deal breaker), it doesn't
source its tarballs from their origin projects they're all separate
github repos with who knows what modifications or added.  Plus it
complains about any installation of Python other than the version each
version of OS X shipped with (yet another deal breaker for me since I
recompile Python each time there's a new OpenSSL release for
starters)

Anyway, there's a fair chance that that subdirectory from /usr/local
is a Homebrew thing.


Regards,
Ben


 


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users