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

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

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

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

Re: "right to be forgotten" nonsense

On 16-01-2018 15:16, Phil Susi wrote: > There isn't merit. It became public, not private, the moment you > published it. I have the right to free speech, the EU be damned. Are > these numbnuts going to demand that libraries black out newspaper > articles on microfilm because they mention

Re: gnupg-2.2.4: how to deal with failed tests

On Wed, 17 Jan 2018 15:18, nbsd4e...@gmail.com said: > "gpg: importing secret keys not allowed" Which means you are trying to import from a keyserver, WKD, DANE etc. That is very strange. How did you build gnupg, did you checked the signature of the source, is there anything special in your

Re: key distribution/verification/update mechanisms other than keyservers

On 17/01/18 15:32, Daniel Kahn Gillmor wrote: > i don't think you need an extension to OpenPGP at all to do this -- you > just need policy. The policy could be (for example): The main technical question is where should this policy be applied? 1. At upload stage - easy to implement, but requires

Re: key distribution/verification/update mechanisms other than keyservers

On Wed 2018-01-17 09:58:21 +0100, Werner Koch wrote: > On Tue, 16 Jan 2018 22:56, kristian.fiskerstr...@sumptuouscapital.com > said: > >>> (c) rejected all third-party certifications -- so data attached to a >>> given primary key is only accepted when certified by that primary >>> key.

Re: Remove public key from keyserver

On Wed, 17 Jan 2018 09:42:07 +0100, Werner Koch wrote: > On Tue, 16 Jan 2018 20:37, stefan.cl...@posteo.de said: > > > users who uploaded their public keys on key servers would not > > reveal that they know each other as shown with their signatures, > > which the classical WoT somehow requires,

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

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

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

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

Re: gnupg-2.2.4: how to deal with failed tests

Thank you very much. The log files seem to indicate there is some problem involving import of "secret keys". Still, I have no idea how to solve this problem. Excerpts from those files below. -- Henry issue2346.scm.log, ssh-export.scm.log,and ecc.scm.log all have in common the following: "gpg:

Re: key distribution/verification/update mechanisms other than keyservers

Werner Koch [2018-01-17 09:58:21+01] wrote: >>> (c) rejected all third-party certifications -- so data attached to >>> a given primary key is only accepted when certified by that primary >>> key. > This can help to avoid DoS attacks. I would love to see that to get my > key down to a

help using netpgpverify anyone?

There was a post recently which introduced NetPGP. Is there someone who has used it successfully to verify the signiture on a binary file? I could use help on how to form a working command line. I tried `netpgpverify -k ~/.gnupg/pubring.gpg gnupg-1.4.22.tar.bz2.sig` in a directory containing

Re: gnupg-2.2.4: how to deal with failed tests

On 01/17/2018 07:50 AM, Henry wrote: > I finally got gnugp2 built without any fatal errors. > Most of the tests passed, but the following tests failed: > tests/openpgp/issue2346.scm > tests/openpgp/ssh-export.scm > tests/openpgp/export.scm > tests/openpgp/ecc.scm > tests/openpgp/armor.scm > > I

Re: gnupg-2.2.4: how to deal with failed tests

On Wed, 17 Jan 2018 07:50, nbsd4e...@gmail.com said: > tests/openpgp/armor.scm There will be a file tests/openpgp/armor.scm.log which should give you some more insight. You can alos run single tests or all in a more verbose mode. See the ERADME file in the tests directory. > Grateful for

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

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

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

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

Re: key distribution/verification/update mechanisms other than keyservers

On Tue, 16 Jan 2018 22:56, kristian.fiskerstr...@sumptuouscapital.com said: >> (c) rejected all third-party certifications -- so data attached to a >> given primary key is only accepted when certified by that primary >> key. >> > > thanks for this post Daniel, my primary question

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote: > On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote: >> thanks for this post Daniel, my primary question would be what advantage >> is gained by this verification being done by an arbitrary third party >> rather by a trusted client

Re: Remove public key from keyserver

On Tue, 16 Jan 2018 20:37, stefan.cl...@posteo.de said: > users who uploaded their public keys on key servers would not > reveal that they know each other as shown with their signatures, > which the classical WoT somehow requires, instead of using local sigs. I do not know most of the people