Gnupg-devel Digest, Vol 159, Issue 5
brian huffman
findaphone40 at gmail.com
Mon Dec 5 19:01:10 CET 2016
What is this?
On Dec 5, 2016 5:59 AM, <gnupg-devel-request at gnupg.org> wrote:
> Send Gnupg-devel mailing list submissions to
> gnupg-devel at gnupg.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> or, via email, send a message with subject or body 'help' to
> gnupg-devel-request at gnupg.org
>
> You can reach the person managing the list at
> gnupg-devel-owner at gnupg.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gnupg-devel digest..."
>
> Today's Topics:
>
> 1. Re: [openpgp-email] On Signed-Only Mails (Bjarni Runar Einarsson)
> 2. Re: [openpgp-email] On Signed-Only Mails (Werner Koch)
> 3. Was gnupg-2.1.16.tar.bz2.sig updated? (Roman Bogorodskiy)
> 4. Re: Was gnupg-2.1.16.tar.bz2.sig updated? (Werner Koch)
> 5. [PATCH] python: default op_keylist_start parameters.
> (Tobias Mueller)
> 6. Re: [PATCH] python: default op_keylist_start parameters.
> (Justus Winter)
> 7. Re: [PATCH] python: define a macro for wrapping fragile
> result objects. (Justus Winter)
>
>
> ---------- Forwarded message ----------
> From: Bjarni Runar Einarsson <bre at pagekite.net>
> To: OpenPGP-based Email Encryption <openpgp-email at enigmail.net>
> Cc: GnuPG Development List <gnupg-devel at gnupg.org>
> Date: Fri, 02 Dec 2016 19:49:50 -0000
> Subject: Re: [openpgp-email] On Signed-Only Mails
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello!
>
> Thanks Vincent for starting an interesting discussion.
>
> Bernhard Reiter <bernhard at intevation.de> wrote:
> > > https://github.com/mailpile/Mailpile/issues/1693
> >
> > Here it also is irritation.
>
> Not so much irritation, as recognizing that sending non-technical
> people detached signatures (or keys) causes confusion, because
> usually when people are sent attachments the attachments are
> important and useful. So they make an effort to open them up,
> without much luck. We're wasting peoples' time, which is impolite
> at best.
>
> Wasting peoples' time may be justified if there is some education
> to be derived from it; sadly most signature.asc files (and keys)
> don't have much educational value today! Mailpile is
> experimenting with adding a very small HTML wrapper around the
> PGP content to rectify that.
>
> In-line signatures do not appear to cause the same confusion,
> people are used to ignoring junk at the bottom of the message.
> This is a data point that supports Mailpile's current recommended
> default of using inline signatures when the message only has a
> single text part, upgrading to PGP/MIME only for more complex
> messages.
>
> I wanted to highlight this specifically, since if I recall
> correctly, Mailpile is going against the GnuPG community's "best
> practices" by avoiding PGP/MIME and I've had heated discussions
> about this with people in the past. I don't know if this will
> change anyone's mind, but I feel it is a useful data point all
> the same.
>
>
> > == Better email-clients are a key success factor
> ...
> > Given a possible solution by improved clients, we should try
> > first to make them happen before giving up on signed-only
> > emails, which is the solution you proposed. You may say: But
> > this hasn't work for many years. I'd agree with this notion,
> > but because of the non-linear nature we don't know how close we
> > are to the tipping point.
>
> I think this is an interesting point. I also feel that signed
> e-mail has value, in that it raises the bar and has the potential
> to make it harder to impersonate people. That benefit also won't
> really be realized until after a tipping point is reached -
> encryption (and signatures) need to be commonplace enough that an
> unsigned message can be treated as an anomaly, at least in some
> contexts.
>
> We're not there yet. Even someone like me who uses a PGP-enabled
> mail client 90% of the time still reaches for the mobile GMail
> app now and then, sending unsigned mail. Every time I do, I
> weaken the signal sent by my normal signatures.
>
> Until we reach the tipping point, Vincent's argument that
> signatures are basically just cognitive load and bloat is largely
> correct.
>
> Better tools can help. Better interfaces can help; I'm on the
> fence in part because Mailpile wants to be one of those better
> tools. But I don't think Vincent is wrong to offer his users a
> simplified interface in the meantime.
>
> The interesting question is, whether his simplified interfaces
> will help us reach a tipping point sooner. They might!
>
> All the best,
> - Bjarni
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJYQdBHAAoJEI4ANxYAz5SRz9wH/1X+wMlRgtss0ewun8G0fNHq
> gibBnI2FyYecKMLEP7IiaQvIQf9aTq/8s1Nk+5g+X42YVVUQNZIKJJejiHZ9O6Lk
> bZNDtTyL0ThMCRZ/yVeWF7SFpSMA16ux2M5dy381NsoMsG9v+XAl1HxlJjvbGYlQ
> MqBX2EJ4r7OtoU5oiwXEnX6HklxYOgxCbynwItWhm9cqqc+NeKsup3NPvfr/N7WB
> ochxM5QsqCC6Wx9+cN15EoBlkwBHGU+lU5hAN/iJ9zXo/Fxfg1BMw6eYFkHtYVit
> r+kV4b6RIjHvhb26f5i+QKi2C2uqe0s8GDH14XnfM4EBJza32l8rt/hFgQry3MA=
> =UY+L
> -----END PGP SIGNATURE-----
>
>
> ---------- Forwarded message ----------
> From: Werner Koch <wk at gnupg.org>
> To: OpenPGP-based Email Encryption <openpgp-email at enigmail.net>
> Cc: gnupg-devel at gnupg.org
> Date: Sat, 03 Dec 2016 16:24:02 +0100
> Subject: Re: [openpgp-email] On Signed-Only Mails
> On Fri, 2 Dec 2016 14:10, look at my.amazin.horse said:
>
> > another mechanism like keyservers. We don't even get the whole
> > fingerprint as an identifier, but instead have to assume that if the
> > signature checks out we have the right key.
>
> Depends on your OpenPGP implementation. GnuPG already uses the
>
> #### Issuer Fingerprint
>
> (1 octet key version number, N octets of fingerprint)
>
> The OpenPGP Key fingerprint of the key issuing the signature. This
> subpacket SHOULD be included in all signatures. If the version of the
> issuing key is 4 and an Issuer subpacket is also included in the
> signature, the key ID of the Issuer subpacket MUST match the low
> 64 bits of the fingerprint.
>
> Note that the length N of the fingerprint for a version 4 key is 20
> octets.
>
> which we agreed upon in the WG. I hope that OpenKeychain will add that
> signature subpacket soon.
>
>
> Shalom-Salam,
>
> Werner
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
>
>
> ---------- Forwarded message ----------
> From: Roman Bogorodskiy <bogorodskiy at gmail.com>
> To: gnupg-devel at gnupg.org
> Cc:
> Date: Sat, 3 Dec 2016 19:00:53 +0300
> Subject: Was gnupg-2.1.16.tar.bz2.sig updated?
> Hi,
>
> It looks like gnupg-2.1.16.tar.bz2.sig was updated after releasing of
> gnupg 2.1.16.
>
> At time of release it was:
>
> SHA256 (gnupg-2.1.16.tar.bz2.sig.orig) =
> 91dd1279956a533a721f3e2dc06a092248cea8bd9a5259dc19f8d7573c1d3d12
>
> Now it is:
> SHA256 (gnupg-2.1.16.tar.bz2.sig) =
> b00b297eed7dcbbb259e960b9e4442de031124f41ea870efa5e7a367a9779fa7
>
> It looks like an additional signature was added:
>
> $ gpg2 --verify gnupg-2.1.16.tar.bz2.sig.orig /usr/ports/distfiles/gnupg-2.
> 1.16.tar.bz2
> gpg: Signature made пятница, 18 ноября 2016 г. 18:58:06
> gpg: using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6
> gpg: Good signature from "Werner Koch (dist sig)" [ultimate]
>
> $ gpg2 --verify gnupg-2.1.16.tar.bz2.sig /usr/ports/distfiles/gnupg-2.
> 1.16.tar.bz2
> gpg: Signature made пятница, 18 ноября 2016 г. 18:58:06
> gpg: using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6
> gpg: Good signature from "Werner Koch (dist sig)" [ultimate]
> gpg: Signature made суббота, 19 ноября 2016 г. 07:18:00
> gpg: using RSA key 2071B08A33BD3F06
> gpg: Good signature from "NIIBE Yutaka (GnuPG Release Key) <
> gniibe at fsij.org>" [expired]
> gpg: Note: This key has expired!
> Primary key fingerprint: 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06
>
> Also, the new sig is reported as expired.
>
> Was that an intentional change?
>
> The reason I'm asking is that both release tarball and the sig are used
> by the FreeBSD port [1], and when a checksum changes for any of the
> files, port refuses to use it (unless there's some mirror with the old
> file or unless user explicitly forces it to continue).
>
> 1:
> https://svnweb.freebsd.org/ports/head/security/gnupg/
> distinfo?revision=426573&view=co
>
> Roman Bogorodskiy
>
>
> ---------- Forwarded message ----------
> From: Werner Koch <wk at gnupg.org>
> To: Roman Bogorodskiy <bogorodskiy at gmail.com>
> Cc: gnupg-devel at gnupg.org
> Date: Sat, 03 Dec 2016 21:23:54 +0100
> Subject: Re: Was gnupg-2.1.16.tar.bz2.sig updated?
> On Sat, 3 Dec 2016 17:00, bogorodskiy at gmail.com said:
>
> > It looks like gnupg-2.1.16.tar.bz2.sig was updated after releasing of
> > gnupg 2.1.16.
>
> Sure. We do this very often as soon as a co-developer has verified the
> released package. We consider it better to have more than one
> signature.
>
> > Also, the new sig is reported as expired.
>
> Gniibe has prolonged the expiration time of his key and thus with a
> fresh copy of the key it won't claim that it is expired. Refreshing the
> keys on a regular base is anyway a good idea to get notice of
> revocations.
>
> > The reason I'm asking is that both release tarball and the sig are used
> > by the FreeBSD port [1], and when a checksum changes for any of the
>
> Well, the signature file is the checksum of tarball and as such the
> signature file should be used as is and not be used as a trigger for
> updates.
>
>
> Salam-Shalom,
>
> Werner
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
>
>
> ---------- Forwarded message ----------
> From: Tobias Mueller <muelli at cryptobitch.de>
> To: gnupg-devel at gnupg.org
> Cc:
> Date: Sat, 3 Dec 2016 23:12:37 +0100
> Subject: [PATCH] python: default op_keylist_start parameters.
> * lang/python/gpgme.i: Added gpgme_op_keylist_start with defaults
> * lang/python/tests/t-keylist.py: Added tests for default parameters
> --
>
> To increase the ease of use, op_keylist_start
> parameters default to sensible values.
> The empty string matches all keys.
> We assume that the user wants to retrieve public keys most of the time,
> so we default to public keys rather than secret keys.
>
> Signed-off-by: Tobias Mueller <muelli at cryptobitch.de>
> ---
> lang/python/gpgme.i | 9 +++++++++
> lang/python/tests/t-keylist.py | 12 ++++++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/lang/python/gpgme.i b/lang/python/gpgme.i
> index 783531f..0e2feec 100644
> --- a/lang/python/gpgme.i
> +++ b/lang/python/gpgme.i
> @@ -586,6 +586,15 @@
> }
> }
>
> +
> +/* With SWIG, you can define default arguments for parameters.
> + * While it's legal in C++ it is not in C, so we cannot change the
> + * already existing gpgme.h. We need, however, to declare the function
> + * *before* SWIG loads it from gpgme.h. Hence, we define it here. */
> +gpgme_error_t gpgme_op_keylist_start (gpgme_ctx_t ctx,
> + const char *pattern="",
> + int secret_only=0);
> +
> /* Include the unmodified <gpgme.h> for cc, and the cleaned-up local
> version for SWIG. We do, however, want to hide certain fields on
> some structs, which we provide prior to including the version for
> diff --git a/lang/python/tests/t-keylist.py b/lang/python/tests/t-keylist.
> py
> index ea2a724..5077ca6 100755
> --- a/lang/python/tests/t-keylist.py
> +++ b/lang/python/tests/t-keylist.py
> @@ -219,6 +219,18 @@ result = c.op_keylist_result()
> assert not result.truncated, "Key listing unexpectedly truncated"
>
>
> +# We test for a parameter-less keylist
> +keyring_length = len(list(c.op_keylist_all()))
> +assert keyring_length > 1,\
> + "Expected to find some keys, but got %r" % keyring_length
> +
> +# Then we do want to call with a pattern, only
> +# i.e. without giving secret=0
> +alpha_keys = list(c.op_keylist_all(b"Alpha"))
> +assert len(alpha_keys) == 1, "Expected only one key for 'Alpha', got %r"
> % len(alpha_keys)
> +
> +
> +
> for i, key in enumerate(c.keylist()):
> try:
> if len(keys[i]) == 4:
> --
> 2.7.4
>
>
>
>
> ---------- Forwarded message ----------
> From: Justus Winter <justus at g10code.com>
> To: Tobias Mueller <muelli at cryptobitch.de>, gnupg-devel at gnupg.org
> Cc:
> Date: Mon, 05 Dec 2016 12:55:50 +0100
> Subject: Re: [PATCH] python: default op_keylist_start parameters.
> Tobias Mueller <muelli at cryptobitch.de> writes:
>
> > * lang/python/gpgme.i: Added gpgme_op_keylist_start with defaults
> > * lang/python/tests/t-keylist.py: Added tests for default parameters
>
> ...
>
> > +/* With SWIG, you can define default arguments for parameters.
> > + * While it's legal in C++ it is not in C, so we cannot change the
> > + * already existing gpgme.h. We need, however, to declare the function
> > + * *before* SWIG loads it from gpgme.h. Hence, we define it here. */
> > +gpgme_error_t gpgme_op_keylist_start (gpgme_ctx_t ctx,
> > + const char *pattern="",
> > + int secret_only=0);
>
> Interesting, I didn't know that. Is SWIG using C++ under the hood, or
> are they parsing this and changing the prologue of the generated wrapper
> function?
>
>
> I'm not sure whether we want to do this or not. Currently, we provide a
> very faithful "C-like API", and a idiomatic Python API on top. And
> indeed, in the idiomatic key listing API we provide exactly these
> defaults:
>
> def keylist(self, pattern=None, secret=False):
> """List keys
>
> Keyword arguments:
> pattern -- return keys matching pattern (default: all keys)
> secret -- return only secret keys
>
> Your patch deviates from that pattern.
>
>
> Thoughts?
> Justus
>
>
> ---------- Forwarded message ----------
> From: Justus Winter <justus at g10code.com>
> To: Tobias Mueller <muelli at cryptobitch.de>, gnupg-devel at gnupg.org
> Cc:
> Date: Mon, 05 Dec 2016 12:59:07 +0100
> Subject: Re: [PATCH] python: define a macro for wrapping fragile result
> objects.
> Tobias Mueller <muelli at cryptobitch.de> writes:
>
> > * lang/python/gpgme.i: defined a wrapresult macro
>
> Merged, thanks!
>
> Justus
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161205/8fcff198/attachment-0001.html>
More information about the Gnupg-devel
mailing list