Re: Will gpg 1.x remain supported for the foreseeable future?

[Dan Kegel]

On Sat, Jan 20, 2018 at 4:08 PM, Todd Zullinger  wrote:
> I think that's https://dev.gnupg.org/T2290

Thanks.

Say, anyone know how to get bug tracker problems resolved?
Somehow my email address there lacks a dot before .com,
so I can't get confirmation emails.
- Dan

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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Todd Zullinger]

Dan Kegel wrote:
> - might save time and anguish if apt-key (and thus gpg[v]?) accepted
> armored keyrings even if filename ends in .gpg

I think that's https://dev.gnupg.org/T2290, in case you want
to follow it or submit a patch to implement it.  Werner did
provide some details about how it would ideally be done.

If I was more capable with C, I'd give it a try since I'd
like to see gpgv work with armored keyrings too.

-- 
Todd
~~
Progress isn't made by early risers. It's made by lazy men trying to
find easier ways to do something.
-- Robert Heinlein



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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Dan Kegel]

On Thu, Jan 18, 2018 at 7:58 PM, Dan Kegel  wrote:
>> The keys referred to via signed-by are the only acceptable keys for the
>> associated apt repo.
>>
>> does that make sense?
>
> That'd be great if it worked.  Since it's hard to explain what's broken
> without a simple script showing exactly what I'm doing, let's just
> hold that thought until I post one.

I spent a little while cleaning up my script and found the problem, whew!

Here's part of the log:

+ gpg2 -q --pinentry-mode loopback --passphrase
--personal-digest-preferences SHA256 --gen-key gpg.in.tmp
+ gpg2 --armor --export temp-r...@example.com
...
+ sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp
APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get  update
...
Preparing to exec:  /usr/bin/apt-key --quiet --readonly --keyring
/tmp/obs_localbuild_keyrings_dank.tmp/keyrings/localhost.gpg verify
--status-fd 3 /tmp/apt.sig.nD3tum /tmp/apt.data.OVJLiX
Read: [GNUPG:] ERRSIG 505A301EE37484C6 1 8 01 1516484740 9
Got ERRSIG
Read: [GNUPG:] NO_PUBKEY 505A301EE37484C6

Even with apt debug logging on, that wasn't enough to make the problem
obvious.  I had to add

exec 2> /tmp/apt-key.log.$$
set -x

to the top of /usr/bin/apt-key.  Grepping for that key in /tmp/apt-key*, I found

+ gpgv --homedir /tmp/tmp.oM7RZ707db --keyring
/tmp/obs_localbuild_keyrings_dank.tmp/keyrings/localhost.gpg
--ignore-time-conflict --status-fd 3 /tmp/apt.sig.nD3tum
/tmp/apt.data.OVJLiX
gpgv: Signature made Sat Jan 20 13:45:40 2018 PST using RSA key ID E37484C6
gpgv: [don't know]: invalid packet (ctb=2d)
gpgv: keydb_search failed: invalid packet
gpgv: Can't check signature: public key not found

Well, well.  That 'invalid packet' appears to be a telltale sign of
using --armor where one shouldn't, and looking at my first log, you
can see a --armor.  Removing it made everything happy.
So this was a case of a) dumb user and b) poor diagnostics from apt.

Also, now that I've ripped out all gpg1 support from my script, I
realize that gpg-agent is nearly well behaved.
Only possible rough spots I ran into were:
- having to enable pinentry (ubuntu 16.04's gpg is old)
- not knowing a clean way to tidy up an old gnupghome and its agent
without hanging if the agent is missing
- the gpg man page says --dearmor isn't very useful.  I beg to differ :-)
- might save time and anguish if apt-key (and thus gpg[v]?) accepted
armored keyrings even if filename ends in .gpg

Thanks for the encouragement.
All's well that ends well.
I'm sure I'll trip over my shoelaces again soon enough!
- Dan

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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Dan Kegel]

On Thu, Jan 18, 2018 at 7:52 PM, Daniel Kahn Gillmor
 wrote:
> if this is the only thing happening, apt will indeed fail, because it
> has never heard of the "new key" that was just created -- why should it
> accept signatures from that new key?
>
> how are you configuring the target system to point to the repo?  how are
> you telling it where to find the key?

By installing my package, which drops the key into /usr/share/keyrings
and creates the lists.d entries with signed-by.  That ought to suffice,
I gather, but I'm tripping over shoelaces somewhere.

> this looks strange to me -- you seem to be using a --keyring that is
> *inside* the GNUPGHOME that you've set
> (/tmp/obs_localbuild_gnupghome_dank.tmp/).
>
> that GnuPG homedir is really not part of the GnuPG API contract -- and
> anything you put in that homedir could potentially be overwritten by
> GnuPG itself.   How is
> /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg being
> generated?

It's just a regression test script. I'm cleaning it up and will post
it once it's legible and avoids sins like that.

> The keys referred to via signed-by are the only acceptable keys for the
> associated apt repo.
>
> does that make sense?

That'd be great if it worked.  Since it's hard to explain what's broken
without a simple script showing exactly what I'm doing, let's just
hold that thought until I post one.
- Dan

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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Daniel Kahn Gillmor]

On Wed 2018-01-17 20:58:21 -0800, Dan Kegel wrote:
> Does one even need --import and --export while building foobar-archive;
> aren't the thing being imported and the thing being exported
> the same format?

i don't know -- what are you importing?  if the thing you're importing
is already a clean Transferable Public Key, then you are right: you can
deploy it with /bin/cp or /bin/cat or /usr/bin/install :)

> (I saw a note about stripping off trust packets, since they're less
> portable.  Wonder if that's related.)

trust packets aren't part of a Transferable Public Key -- if you're
seeing trust packets, then the thing you're working with was never a
Transferable Public Key in the first place :/

> What I am missing is how dropping a key into /usr/share/keyrings,
> and then pointing to it with signed-by=, actually establishes
> trust.

hm, that pesky "trust" word again ;) -- let's be clear what we mean
about it.

The actions you describe above mean that the user is willing to rely on
this key to certify the archive listing from your APT repository.

this is a narrowly-scoped "trust", because it also means that the user
will *not* accept signatures from the key in question on any *other*
repository.

This is good -- in the security sense of "trusted", we want to *reduce*
trust, not expand it, right?  things that you trust can violate that
trust and you're helpless.


> I mean, it makes sense and all, but when I write a
> regression test script that :
> - sets GNUPGHOME to an empty directory
> - generates a key
> - creates a repo using reprepro signed by that key
> - creates a dummy package
> - adds it to the repo
> - tries to access the repo with 'apt-get update'

if this is the only thing happening, apt will indeed fail, because it
has never heard of the "new key" that was just created -- why should it
accept signatures from that new key?

how are you configuring the target system to point to the repo?  how are
you telling it where to find the key?

I'd expect somewhere in there to be a "gpg --export" of the
newly-created key, into a simple file that can be picked up later.

> + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp 
> APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get -q -q update
> inside VerifyGetSigners
> Preparing to exec:  /usr/bin/apt-key --quiet --readonly --keyring
> /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg verify
> --status-fd 3 /tmp/apt.sig.UbNAaM /tmp/apt.data.5w6fyj
> Read: [GNUPG:] ERRSIG 77D1F0D4EC3422C4 1 8 01 1516232802 9
> Got ERRSIG
> Read: [GNUPG:] NO_PUBKEY 77D1F0D4EC3422C4
> Got NO_PUBKEY

this looks strange to me -- you seem to be using a --keyring that is
*inside* the GNUPGHOME that you've set
(/tmp/obs_localbuild_gnupghome_dank.tmp/).

that GnuPG homedir is really not part of the GnuPG API contract -- and
anything you put in that homedir could potentially be overwritten by
GnuPG itself.   How is
/tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg being
generated?

This seems like the sticking point to me.

> or forgetting to mark the key I just generated as trusted

there's no need to mark any keys as "trusted" with GnuPG for apt's sake.
Apt represents its "trust" (willingness to rely on a key to generate
acceptable signatures over an archive) in one of two ways:

 a) placement in /etc/apt/trusted.gpg or /etc/apt/trusted.gpg.d/*.gpg

 b) placement elsewhere in the filesystem, pointed to by a signed-by
option in a line in /etc/apt/sources.list or
/etc/apt/sources.list.d/*.list; or pointed to by a Signed-By: header
in a stanza in /etc/apt/sources.list.d/*.source (see sources.list(5)
for more details about the way that signed-by can be presented).

the keys placed in the filesystem at the locations described in (a) are
acceptable for making signatures over *every* apt repository configured
on the system, except those with an explicit signed-by directive, which
are more constrained.

The keys referred to via signed-by are the only acceptable keys for the
associated apt repo.

does that make sense?

 --dkg

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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Dan Kegel]

On Wed, Jan 17, 2018 at 8:58 PM, Dan Kegel  wrote:
> Here's the bit where it explodes,
>
> + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp
> APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get -q -q
> update
> inside VerifyGetSigners
> Preparing to exec:  /usr/bin/apt-key --quiet --readonly --keyring
> /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg verify
> --status-fd 3 /tmp/apt.sig.UbNAaM /tmp/apt.data.5w6fyj
> Read: [GNUPG:] ERRSIG 77D1F0D4EC3422C4 1 8 01 1516232802 9
> Got ERRSIG
> Read: [GNUPG:] NO_PUBKEY 77D1F0D4EC3422C4
> Got NO_PUBKEY

One little clue: apt evidently runs apt-key as user _apt, and
/tmp/obs_localbuild_gpghome_dank.tmp/ is owned by me,
with permissions 700.  So apt-key can't read it.  Whee!

And if I try creating it with permissions 755, gpg complains
about unsafe permissions.

I'm still stuck in a twisty maze of little passages, all different.
I probably should boil down my test to a simple linear
script so I can ask for help properly...
- Dan

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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Daniel Kahn Gillmor]

On Wed 2018-01-17 15:09:45 -0800, Dan Kegel wrote:
> Yes to all four questions.  Here's the user story.

cool, your user story all makes sense to me except this bit:

> - The package depends on debian-archive-keyring (to leverage
> the web of trust as suggested in 'man secure-apt')

(itym 'man apt-secure', right?)

if you're expecting ubuntu (or any other non-debian) users to install
this, then you're actually increasing their attack surface, because this
package will place debian archive keys as "trusted" keys automatically
(meaning "any archive that is signed by them is considered legitimate),
when they weren't present on the system before.

I don't see the part of apt-secure(8) that says anything about needing
this, and i don't see how it "leverages the web of trust" -- can you
explain this more?  Without a clear justification, i think you should
remove this dependency.

> I also have to support a range of versions of gpg, can't insist
> on the latest.  Happily, in preparation for supporting Ubuntu 17.10,
> I verified that I can drop support for versions of gpg and apt
> older than the ones in Ubuntu 16.04.

what i'm not hearing is an explicit example of how you are using gpg --
as the archive maintainer, surely you manage the archive itself on a
system of your choice.  for me, that would be a debian stable system,
with reprepro or something like that, which should already know how to
call out to gpg.

as the developer of the foobar-archive package, you shouldn't need to
invoke gpg at all in your package build scripts other than just --import
and --export, which should be pretty standard across all versions of
gpg.

your end users don't actually need full-blown gpg at all -- modern
versions of apt depend explicitly (and minimally) on gpgv, since all
they do is verify signatures based on a set of acceptable keys.

> While my foobar-archive.deb may seem superficially similar to
> debian-archive-keyring.deb, the latter does things
> in its postinstall step that establish trust at the system
> level in a way that doesn't seem like a good example for
> third party apt repositories to use as an example.

yep, agreed.  (which is why i'm surprised to see your dependency on
debian-archive-keyring) You may also be interested in
https://bugs.debian.org/861695, fwiw.

All the best,

--dkg


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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Dan Kegel]

On Tue, Jan 16, 2018 at 8:31 PM, Daniel Kahn Gillmor
 wrote:
> On Tue 2018-01-16 20:10:38 -0800, Dan Kegel wrote:
> > When I try to use gpg to manipulate secure apt repositories in the
> > real world, my head explodes.
>
> hi there!  what kind of manipulation are you doing of secure apt
> repositories with gpg?
>
> are you talking about signing the repo as an author? or about
> configuring for a client? or distributing public keys for the repo?  or
> about verifying signatures as a client?

Yes to all four questions.  Here's the user story.
- I maintain a secure apt repository at pkgs.foobar.com following best
practices in
https://wiki.debian.org/DebianRepository/UseThirdParty
- the key that signs my repository is trusted by debian developers
in the pgp web of trust
- To my users, I send via a trusted offline mechanism a copy of
a package foobar-archive.deb
- When they install that package, it installs the files
/usr/share/keyrings/foobar-archive.gpg,
and /etc/apt/sources.list.d/foobar-archive.list
- The latter file's entries say signed-by=/usr/share/keyrings/foobar-archive.gpg
- The package depends on debian-archive-keyring (to leverage
the web of trust as suggested in 'man secure-apt')
- My users are happy that simply installing one package
establishes trust and lets them apt-get from my repo
with no pesky errors from ubuntu 17.10 about
my server having an invalid or untrusted signature
- Updates to foobar-archive are delivered via secure apt.

So much magic.  It took me a while to figure that path out, and
I'm still not quite sure I've got it right, still working on getting
my regression tests to pass.  There don't seem to be a wealth
of accurate examples that are both kosher and up to date.

Most of my angst comes from having to come up two learning
curves simultaneously with tools that are used by fairly small
communities and thus have some rough edges still
(debian packaging and gpg commandline tools), and have lots
of stale stories out on the web about how to work around
problems that no longer exist.
I also have to support a range of versions of gpg, can't insist
on the latest.  Happily, in preparation for supporting Ubuntu 17.10,
I verified that I can drop support for versions of gpg and apt
older than the ones in Ubuntu 16.04.

While my foobar-archive.deb may seem superficially similar to
debian-archive-keyring.deb, the latter does things
in its postinstall step that establish trust at the system
level in a way that doesn't seem like a good example for
third party apt repositories to use as an example.

That package is not to be confused with the similarly
named debian-keyring package, which is completely
kosher and just installs key(ring)s into /usr/share/keyrings,
but does not of itself establish trust.
- Dan

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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Daniel Kahn Gillmor]

On Tue 2018-01-16 20:10:38 -0800, Dan Kegel wrote:
> When I try to use gpg to manipulate secure apt repositories in the
> real world, my head explodes.

hi there!  what kind of manipulation are you doing of secure apt
repositories with gpg?

are you talking about signing the repo as an author? or about
configuring for a client? or distributing public keys for the repo?  or
about verifying signatures as a client?

each use case is slightly different, but there should be reasonable,
non-head-explode-y tooling available for all of them.

--dkg

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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Daniel Kahn Gillmor]

On Tue 2018-01-16 16:26:49 -0800, Dan Kegel wrote:
> I worked hard to jump through hoops to use version 2 in such
> an environment, but then I ran into the fact that even the latest apt
> from debian does not support version 2's keybox format, so I had
> to drop back to gpg version 1 anyway.

apt always uses the "transferable public key" form for its OpenPGP
dependencies, which is specified in RFC 4880.  a simple linear
concatenation of these transferable public keys is a "keyring", which
apt knows how to ingest.

The "keybox" format is not used by any tool outside of the GnuPG suite,
and it doesn't have nearly as much documentation or history as the
transferable public key format.

i tend to treat *.kbx the same way i treat private-keys-v1.d -- as part
of GnuPG internals, not as part of its public interface.

If you want to generate a clean "keyring" it should be straightforward
to do so with any version of GnuPG just by using --export.  You can
import a keyring into any version of GnuPG with --import.

if you're in the habit of using GnuPG in order to create some file
within its internal "home directory" and then extract that for some
other use (like sending handing some internal file from there to apt) --
please don't do that.  The internals of the GnuPG homedir have never
explicitly been part of the publicly-exposed API.

 --dkg


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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Werner Koch]

On Wed, 17 Jan 2018 01:26, d...@kegel.com said:

> I'm starting to suspect that using version 2.x of gnupg is simply not
> a good idea when writing shell scripts that have to run unattended
> and not touch system keychains or agents.

Actually 2.2 is much easier to script than 2.1.  Watch out for all these
new --quick-foo commands.  There are also very useful new
--export-options and --import-options.

Regarding the passphrase to protect private keys: Please rethink your
design if you need a passphrase for unattended systems.  If that does
not work for you: --pinentry-mode=loopback works reasonable well.

> from debian does not support version 2's keybox format, so I had
> to drop back to gpg version 1 anyway.

I am stating this for nearly 20 years: The format of pubring.gpg or
pubring.kbx is intern to the gpg implementation and does not constitute
any specified API.  The same goes for most files in GnuPG's home
directory.  To work with public or private keys the --import and
--export commands are to be used.

Just in case: Always use --batch, --status-fd, and --with-colon in
scripts.


Salam-Shalom,

   Werner

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


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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Werner Koch]

On Wed, 17 Jan 2018 03:52, r...@sixdemonbag.org said:

> The game plan has always been to retire 1.4 as soon as practical.  Do
> not rely on it existing in the future.

Kind of: 1.4 will be kept alive for use with PGP 2 encrypted and
signated data and maybe for old platforms.  However, modern algorithms
won't be added to 1.4.


Shalom-Salam,

   Werner

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


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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Dan Kegel]

On Tue, Jan 16, 2018 at 7:37 PM, Robert J. Hansen  wrote:
> * it's not going away in the near future
> * we know people like to use it for servers
> * it's a lot of work to keep two codebases going
> * new crypto, like ECC, will not be backported to 1.4
> * new features will probably not be backported
> * if you need 1.4 support, contact g10 Code GmbH

Thanks.

When I try to use gpg to manipulate secure apt repositories in the
real world, my head explodes.
I'm sure it will all seem reasonable after I figure things out.
I've only been at it off and on for a couple years.
- Dan

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

Re: Will gpg 1.x remain supported for the foreseeable future?

[gnupg]

Robert J. Hansen wrote:

> > Is version 1 going to remain available, I hope?  Version 2 simply
> > seems a poor fit for scripting.
> 
> The game plan has always been to retire 1.4 as soon as practical.  Do
> not rely on it existing in the future.

that's a shame. i hope someone creates a non-gui, non-curses
pinentry program before that happens (that can work inside a
gvim window).

cheers,
raf


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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Robert J. Hansen]

> Is version 1 going to remain available, I hope?  Version 2 simply
> seems a poor fit for scripting.

The game plan has always been to retire 1.4 as soon as practical.  Do
not rely on it existing in the future.

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

Will gpg 1.x remain supported for the foreseeable future?

[Dan Kegel]

Hey all,
I'm starting to suspect that using version 2.x of gnupg is simply not
a good idea when writing shell scripts that have to run unattended
and not touch system keychains or agents.

I worked hard to jump through hoops to use version 2 in such
an environment, but then I ran into the fact that even the latest apt
from debian does not support version 2's keybox format, so I had
to drop back to gpg version 1 anyway.

Is version 1 going to remain available, I hope?  Version 2 simply
seems a poor fit for scripting.

Thanks,
Dan

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