Re: --verify with foo.gpg file does not assume signed data in foo?

[Peter Lebbing]

On 18/02/18 20:45, Ray Satiro via Gnupg-users wrote:
> I know for xxx.sig
> files it would strip that extension and then "gpg: assuming signed data
> in xxx"

I'd like to suggest you shouldn't do it anyway. If somebody supplies you a
non-detached signed file with just a subtly different name, the only difference
will be this line "assuming..." is missing, it will still report a valid
signature. If you're human, like me, you won't notice, but just think "ha, a
valid signature" and continue to use the non-verified file. At this point, your
attacker has already managed to serve you the wrong .sig file, they also
probably supplied you the wrong file it was supposed to have signed.

I'm saying "a subtly different name" because otherwise GnuPG will still warn 
you:
gpg: WARNING: not a detached signature; file 'xxx' was NOT verified!

But it can't catch those cases where look-alike characters are used, and Unicode
is a vast collection of sometimes similar shapes.

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 



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

--verify with foo.gpg file does not assume signed data in foo?

[Ray Satiro via Gnupg-users]

I downloaded an Ubuntu preview ISO [1] recently along with its hash and
signature, SHA256SUMS and SHA256SUMS.gpg. I expected to be able to do this:

gpg --verify SHA256SUMS.gpg
gpg: no signed data
gpg: can't hash datafile: No data

Instead I have to do this:

gpg --verify SHA256SUMS.gpg SHA256SUMS

My question is why is that necessary with gpg files? I know for xxx.sig
files it would strip that extension and then "gpg: assuming signed data
in xxx"

[1]: http://cdimage.ubuntu.com/ubuntu/daily-live/current/


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

Re: How can we utilize latest GPG from RPM repository?

[Peter Lebbing]

On 18/02/18 00:06, helices wrote:
> I will probably never understand why wanting to run the most current
> version of gnupg on a plethora of servers is controversial.

I don't think it is. I'm sorry your question didn't get answered
satisfactorily; that's just how things can go on community mailing lists.

I appreciate your well-formulated arguments for running GnuPG v.2.2.

> However, let it be said here and now, if the gnupg community wants the
> use of gnupg to spread far further than a clique of geeks, making its
> use easier for non-geeks is probably the simplest and most direct way.

I really don't think that it is the task for any upstream to provide
packages for distributions. That truly is what the distributions
themselves are for. For some upstreams it might make sense to provide
their own packages for certain distributions, but I think it's more the
exception that the norm.

> Are there any other questions before I get a direct answer to my
> original subject question?

Since nobody answered with "Oh yeah I happen to package it myself, if
you trust me, you can get it here" or "Oh yeah I know of this person who
packages them", etcetera, my guess is that nobody knows of such a
packaging effort. It's hard to answer affirmatively if you don't know
the affirmative answer :-).

Can I point out that even though you did not like Jeffrey Lightner's
response, Dirk Gottschalk and Konstantin Ryabitsev also replied? If you
could indeed just recompile the Fedora packages, that seems like a
pretty direct route. You do become responsible for updates and "security
support" yourself (in what sense is it still support if you do it
yourself, but hey).

And I wonder if perhaps your interpretation of Jeffrey Lightner's words
was a bit more abrasive than he intended them to be when he wrote those
words, but that is something only Jeffrey Lightner himself can
definitively answer.

Back to the matter at hand. Is it possible for CentOS to provide newer
packages than RHEL? I surmise RHEL will probably not listen to you
unless you get a paid support contract. If CentOS cannot significantly
deviate from RHEL, there doesn't seem to be a gratis way to influence
package versions for CentOS, right? You're dependent on someone
providing packages outside of the distribution proper.

Note, by the way, that interoperability between GnuPG 1.4 and 2.1/2.2 is
not that great, and that often distributions rely on GnuPG in their
internals, meaning there might not be a way to remove GnuPG 1.4 from a
system. It's why Debian deprecated 1.4 before packaging 2.1, so people
would not usually have a system where both are installed. If CentOS 7
relies on GnuPG 1.4, you will need to be careful with 2.1/2.2. Their
keyrings can get out-of-sync.

I'm sorry I don't have a ready answer; if I did, I'd have offered it
days ago...

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 



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

Re: Modernizing Web-of-trust for Organizations

[Ben McGinnes]

On Fri, Jan 05, 2018 at 08:47:29AM -0800, Lou Wynn wrote:
> On 01/04/2018 02:28 PM, Ben McGinnes wrote:
> > It seems to me, though, that the idea was to provide a means for the
> > company to repudiate an employee's key even if the employee was no
> > longer available.
> 
> This is just one of the benefits enabled by my goals which I stated at
> the beginning, and it is most related to central management of keys.

I see ...

> There are systems that have attempted to solve one or two of them with
> the cost of sacrificing others. My take is doing them all with the new
> trust model and its supporting mechanisms.

So you took a system built from the outset on a security model founded
entirely on public key exchanges between distributed and federated
(both self-determining and self-governing) nodes ... and then spent a
considerable amount of time and effort making that system centralised
in order to meet certain types of common business use cases ...

... with a software package which ships with a complete implementation
of S/MIME as well ...

...

...

Hmm ...

Okay, I just have one question:

*Why?!*


Regards,
Ben


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

Re: Huawei manual about Gnupg

[Ben McGinnes]

On Thu, Feb 15, 2018 at 10:36:28AM +0800, Genghuang Wang wrote:
> Hello, everybody as the Gnupg user

Well, Robert made an excellent point in his response and, indeed, it
is a point of view I share.

However, I felt in need of a laugh, so I at least had a look at this
thing and I certainly did get to laugh ...

> I download the Huawei manual about Gnupg from
> http://support.huawei.com/enterprise/en/tool/software-digital-signature-validation-tool-(pgp-verify)-TL100054/TV100016
> 
> The English version is the OpenPGP_Signature_Verification_Guide.pdf

Yeah, there's some kind of special in there ... and so many things wrong.

Robert mentioned licensing issues in his post and I can confirm that
there's no concerns regarding any licensing breach in relation to
GnuPG.  Nor is there any use of GnuPG documentation in that file.

> Could you please take a look at it and make some suggestions to
> Huawei to improve it. Thank you!

I could ... but I won't because they're not paying me anywhere near
enough to fix that.

> http://www.huawei.com/en/contact-us

LOL, no ...

For everyone else, though, it's really quite easy to avoid licensing
conflicts if you compile your custom thing against the OpenSSL library
instead of any of the GnuPG ones.  How useful such theing might be
when dealing with OpenPGP compliant data can be left as an exercise t
for others.


Regards,
Ben


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

Re: Configuration for offline usage - best practice tips?

[Daniel Kahn Gillmor]

On Thu 2018-02-15 21:33:05 +0100, Juergen Christoffel wrote:

> I'm looking for best practice tips for offline usage of GnuPG. What Do I
> mean by offline usage? I plan to encrypt backups or files on my machines
> with GnuPG and generate weekly or monthly keys for that purpose so backups
> for example can run unattended and simply encrypt with today's public key.
> As the backups need to be compatible with my software only, I could
> possibly choose different configuration options than for my "online" usage.

GnuPG's defaults should be fine for the common, simple backup case.

However, i note that you're talking about "today's public key" -- that
suggests that you're imagining a regularly-updated key that your backup
tooling will know about.  This is in some sense antithetical to "offline
usage" -- how will the backup scripts learn about the new keys if they
can't go online to fetch them?

It sounds like you're proposing an OpenPGP primary key that has a series
of relatively short-lived, expiring encryption-capable subkeys.  Is that
correct?

For further clarity, it'd be useful to understand what you see as the
goal of key rotation here.  Do you plan on deleting older secret
subkeys?  if so, how will you recover backups that were encrypted to the
destroyed secrets?

In an e-mail or messaging context, you can decrypt messages as they
arrive, caching either the cleartext or the session keys; this allows
you to rotate the asymmetric keys, destroying the old asymmetric secrets
as they expire, which provides something approximating "forward
secrecy".  (see the recent improvements in version 0.26 of the notmuch
mail user agent as an example of first steps on the way to implementing
this strategy).

But for backups, this is a slightly more complicated story.  It
certainly can be useful if you want to be able to robustly *destroy*
backups that might be stored on servers that you don't have full control
over.  That is: encrypt the backup to public key X, send the encrypted
copy to "the cloud", and then when you're sure you don't need it any
more, delete the secret key corresponding to X to ensure that it's not
recoverable.  But most people have a hard time just getting their
backups to happen on a reasonable schedule, and don't have a reliable
schedule for backup destruction.  Do you have such a plan?  Or do you
envision some other reason for the proposed key rotation?

 --dkg


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