gnupg-2.2.4: how to deal with failed tests

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 am not hip on using a binary that fails its tests.

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

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

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

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,

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

> 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

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

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

Privacy vs. security

On 01/16/2018 06:05 PM, Andrew Gallagher - andr...@andrewg.com wrote: Ultimately, the PGP ecosystem prioritises security over privacy. They are not the same thing, and in some cases they are in conflict. Somewhat of a generalization, but essentially correct. More precisely - if I may - it's

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

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 running locally, which is the current modus > operandus.

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

> On 16 Jan 2018, at 22:26, Leo Gaspard wrote: > > It could also help limit the impact of the nightmare scenario RJH has > described, by making sure all the data is “cryptographically valid and > matching”, thus making it harder to just propagate arbitrary data down >

DRM

Robert J. Hansen rjh at sixdemonbag.org wrote on Tue Jan 16 17:42:29 CET 2018 : ... >> The mechanism to prove you are the owner of a public key is pretty much >> in place :-). A mechanism where you can have a signed statement saying >> "on 2018-01-16, I allow my key to show up on keyservers" >It

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

On 01/16/2018 10:56 PM, Kristian Fiskerstrand wrote: > On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote: > >> The keyserver network (or some future variant of it) can of course play >> a role in parallel to any or all of these. for example, keyservers are >> particularly well-situated to offer

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

On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote: > The keyserver network (or some future variant of it) can of course play > a role in parallel to any or all of these. for example, keyservers are > particularly well-situated to offer key revocation, updates to expiry, > and subkey rotation,

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

On Tue 2018-01-16 01:02:11 +, listo factor via Gnupg-users wrote: > Burning it down is not what I was advocating. I am advocating orderly > evacuation and replacement of a system that has clearly outlived its > usefulnesses. If it is not replaced in time, it will, at some point, > burn ignited

Re: DRM?

On 01/16/2018 10:33 PM, Matthias Mansfeld wrote: > On 16 Jan 2018 at 20:08, Kristian Fiskerstrand wrote: > >> On 01/16/2018 07:50 PM, Andrew Gallagher wrote: >>> Agreed. I was thinking more along the lines of having some method of >>> causing signature vandalism to expire. >> They don't really

Re: Remove public key from keyserver

On 01/16/2018 11:40 AM, Stefan Claas wrote: > Am 16.01.2018 um 11:12 schrieb Kristian Fiskerstrand: > >> On 01/15/2018 09:23 PM, Stefan Claas wrote: >>> No? I for one would like to be sure that i am the only person who >>> can upload my public key to a key server directory. >> This seems to be

Re: Remove public key from keyserver

On 01/16/2018 08:37 PM, Stefan Claas wrote: >> I know, but keybase.io's goal is (or was, back when I tested it) to >> use those connections to somehow prove an identity. It is a neat >> idea for the facebook generation. Privacy is something different. > Agreed. But the word privacy would then

Re: DRM?

On 16 Jan 2018 at 20:08, Kristian Fiskerstrand wrote: > On 01/16/2018 07:50 PM, Andrew Gallagher wrote: > > Agreed. I was thinking more along the lines of having some method of > > causing signature vandalism to expire. > > They don't really constitute an issue either for security or privacy, >

Re: a step in the right direction

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18-01-16 10:54 AM, Robert J. Hansen wrote: >> (Oh, by the way, usually when I talk about DRM, I'm talking about >> giving somebody data but restricting the ways in which they can >> use that data. It's not clear to me how DRM applies when you

Re: DRM?

Can anyone explain in the context of this discussion just what “public” in “public key” is supposed to mean explicitly and implicitly? James R. Cutler james.cut...@consultant.com PGP keys at http://pgp.mit.edu ___ Gnupg-users mailing list

Re: WKD was Remove public key from keyserver

On Tue, 16 Jan 2018 19:51:17 +0100, Werner Koch wrote: > We definitely want to refine some things there but that requires a > wider deployment. I will for sure follow the WKD development and hope that also more mail providers will offer a WKD service. > > i have with posteo's WKD

Re: Remove public key from keyserver

On Tue, 16 Jan 2018 19:36:30 +0100, Werner Koch wrote: > On Tue, 16 Jan 2018 16:34, stefan.cl...@posteo.de said: > > > the public key. He / she is not forced to provide any identity via > > other web sites etc. Doing this is a method they have implemented > > as sort > > I know, but

Re: DRM?

On 01/16/2018 07:50 PM, Andrew Gallagher wrote: > Agreed. I was thinking more along the lines of having some method of > causing signature vandalism to expire. They don't really constitute an issue either for security or privacy, though. If looking at keyserver directly (which you really

Re: DRM?

> On 16 Jan 2018, at 18:15, Kristian Fiskerstrand > wrote: > >> On 01/16/2018 07:12 PM, Andrew Gallagher wrote: >>> On 16/01/18 17:19, Leo Gaspard wrote: >>> “on 2018-04-01, please expose only the master key and its revocation >>> certificate(s) to

Re: Remove public key from keyserver

On Tue, 16 Jan 2018 16:34, stefan.cl...@posteo.de said: > the public key. He / she is not forced to provide any identity via other > web sites etc. Doing this is a method they have implemented as sort I know, but keybase.io's goal is (or was, back when I tested it) to use those connections to

Re: DRM?

On 01/16/2018 07:17 PM, Leo Gaspard wrote: > That said, thanks for the link! Just curious, I never saw information > about this in enigmail, do you know whether it has been implemented yet? First and foremost you'd have to establish the robot-ca with an API of some sort. I'm not aware of any

Re: DRM?

On 01/16/2018 07:12 PM, Andrew Gallagher wrote: > On 16/01/18 17:19, Leo Gaspard wrote: >> “on 2018-04-01, please expose only the master key and its revocation >> certificate(s) to clients” > > IF you wanted to go this route, it would be easier for keyservers to > only serve the master key +

Re: DRM?

On 16/01/18 17:19, Leo Gaspard wrote: > Well, if such requests were honored, this would fix the OP's answer (ie. > “how do I hide the fact I mistakenly associated two unrelated UIDs on my > key”, if I understood correctly), as well as requests pertaining to the > EU's “right to be forgotten” The

Re: DRM?

On 01/16/2018 06:19 PM, Leo Gaspard wrote: > Also, there are flaws with this approach (like after a private key > compromise, it would allow to prevent dissemination of the revocation > certificate) [1], but fixes like allowing the statement to be “on > 2018-04-01, please expose only the master

Re: DRM?

On 01/16/2018 05:42 PM, Robert J. Hansen wrote: >> The mechanism to prove you are the owner of a public key is pretty much >> in place :-). A mechanism where you can have a signed statement saying >> "on 2018-01-16, I allow my key to show up on keyservers" > > It is theoretically and practically

Re: DRM?

On 16/01/18 17:42, Robert J. Hansen wrote: > [...] what many people want is *enforcement*. Now, /that/ would be DRM, I agree. I just considered "what well-configured keyservers in the keyserver pool should do" as the boundary of the problem statement. Just like a well-configured webserver will

Re: DRM?

On 16/01/18 17:47, Kristian Fiskerstrand wrote: > I'm somewhat interested in hearing how this scheme would work in the > case of a compromised private key. Mainly; I was merely using the description of the basics of it as a means to show how it would be access control rather than DRM. All the

Re: DRM?

> The mechanism to prove you are the owner of a public key is pretty much > in place :-). A mechanism where you can have a signed statement saying > "on 2018-01-16, I allow my key to show up on keyservers" It is theoretically and practically possible to have a keyserver that honors such requests,

Re: a step in the right direction

> while i agree with rjh that destruction of the current SKS-based > keyserver network (either by technical or legal means) would today be a > net loss, this statement goes too far. I welcome the correction, but I stand by my statement. Many users, particularly in corporate environments, roll

Re: a step in the right direction

On Mon 2018-01-15 17:45:49 -0500, Robert J. Hansen wrote: > _Literally every major FOSS package manager breaks. Updates become > impossible._ while i agree with rjh that destruction of the current SKS-based keyserver network (either by technical or legal means) would today be a net loss, this

Re: Remove public key from keyserver

> Understood, but what speaks against a (syncing) public key server > system like the old pgp.com key server was, compared to the regular > key servers, which don't allow deletion of a key, by the owner and if > i remember correctly also only upload by the owner. The pgp.com keyserver had some

Re: "right to be forgotten" nonsense

On 1/15/2018 10:24 PM, listo factor via Gnupg-users wrote: > If there is merit to the principle that an Internet server operator > can not keep publicly serving private data over the objections of > the owner (the same as today, after many battles, he can no longer There isn't merit. It became

WKD was Remove public key from keyserver

On Tue, 16 Jan 2018 08:52:44 +0100, Werner Koch wrote: > On Mon, 15 Jan 2018 20:21, stefan.cl...@posteo.de said: > > > O.k. Werner invented WKD which solves those problems, if i'm not > > mistaken, but is it besides keybase.io widely deployed? > > Nope. The Web Key Directory solves exactly

Re: Remove public key from keyserver

> O.K. than it is a feature request. You also triggered something in me > with the words "which you think belongs to you". That's because you think information *does* belong to you. But information doesn't belong to anyone: the nature of information is that it has no owners. You can place

Re: Remove public key from keyserver

On Tue, 16 Jan 2018 08:52:44 +0100, Werner Koch wrote: > I wonder why you seem to suggest the US based keybase.io as a better > solution. After all keybase.io is a service which connects private > data to private data of other sites and that all in the public. I > would consider this a real

Re: a step in the right direction

> (Oh, by the way, usually when I talk about DRM, I'm talking about giving > somebody data but restricting the ways in which they can use that data. > It's not clear to me how DRM applies when you want to simply not give > data at all, to anybody. But this is not really pertinent to the >

My MISTAKE! not a bug Re: BUG report gnupg-2.2.4 (or npth)

I'm very, very sorry to have wasted people's time. The problem was that I configured GNUpth incorrectly. I used "enable-pthread option when I should have done the opposite, disable. Many apologies, Henry 2018-01-15 10:47 GMT+09:00 NIIBE Yutaka : > Hello, > > I think that you

Re: a step in the right direction

Am 16.01.2018 um 13:38 schrieb Andrew Gallagher: On 16/01/18 12:34, Stefan Claas wrote: I don't know if such software already exists but how about using key servers as message storing/retrival system, so that people can avoid the classic smtp route for their PGP encrypted messages. Well, just

Re: a step in the right direction

On 16/01/18 12:34, Stefan Claas wrote: > I don't know if such software already exists but how about using key > servers > as message storing/retrival system, so that people can avoid the classic > smtp > route for their PGP encrypted messages. Well, just a thought... Isn't that called USENET? --

Re: a step in the right direction

Am 16.01.2018 um 12:51 schrieb Andrew Gallagher: So we have to distinguish between what is available if one is sufficiently motivated to go and look, and what is shown to the majority of users. The vandalism problem is solved by clients not displaying unverified content. Whereas the "nightmare

Re: a step in the right direction

On 16/01/18 10:57, Stefan Claas wrote: > And do people always look into blockchain data, when using their wallet to > do transactions? With public WWW key servers it is imho different. This is an important distinction. Ordinary users should not be browsing the raw data. They should be using

Re: a step in the right direction

Am 16.01.2018 um 11:35 schrieb Peter Lebbing: On 16/01/18 04:24, listo factor via Gnupg-users wrote: Considering the possibility that this particular system will be forced to conform to a more contemporary (and I would argue more enlightened) legislative framework in respect to the right to

Re: Remove public key from keyserver

Am 16.01.2018 um 11:12 schrieb Kristian Fiskerstrand: On 01/15/2018 09:23 PM, Stefan Claas wrote: No? I for one would like to be sure that i am the only person who can upload my public key to a key server directory. This seems to be based on a misconception whereby you're attributing

Re: a step in the right direction

On 16/01/18 04:24, listo factor via Gnupg-users wrote: > Considering the possibility that this particular system will > be forced to conform to a more contemporary (and I would argue > more enlightened) legislative framework in respect to the right to > privacy (cf.,

Re: Remove public key from keyserver

On 01/15/2018 09:23 PM, Stefan Claas wrote: > No? I for one would like to be sure that i am the only person who > can upload my public key to a key server directory. This seems to be based on a misconception whereby you're attributing properties of a certificate authority to the keyservers.

Re: Remove public key from keyserver

Am 16.01.2018 um 10:18 schrieb Werner Koch: On Tue, 16 Jan 2018 09:46, stefan.cl...@posteo.de said: and add some funny things to "your" public key. This would be also interesting to see how many signatures a public key can bear. You may look at my key to see funny things and thousands of key

Re: Remove public key from keyserver

On Tue, 16 Jan 2018 09:46, stefan.cl...@posteo.de said: > and add some funny things to "your" public key. This would be > also interesting to see how many signatures a public key can bear. You may look at my key to see funny things and thousands of key signatures from made up users. They print

Re: a step in the right direction

On 01/16/2018 09:20 AM, Robert J. Hansen wrote:>> should not be viewed as "discussing a [...] nightmare scenario", > > I am darkly amused at someone who has not done the research into what > the nightmare scenario *is* telling me that it's not a nightmare scenario. > > The nightmare scenario is

Re: Remove public key from keyserver

Am 16.01.2018 um 00:32 schrieb Robert J. Hansen: (Responding here because Stefan's message hasn't hit my mail server yet) My previous message to you and the list was bounced from your mail server. It's from 2003. It doesn't need modernization. No? I for one would like to be sure that i am

Re: a step in the right direction

> I'd suggest speaking up over at sks-de...@gnu.org, where people have Correction: sks-de...@nongnu.org ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

(I originally composed this on a mobile device and it was held for moderation. Re-sending it from my laptop.) = (Apologies for the terseness: on a mobile device) > should not be viewed as "discussing a [...] nightmare scenario", I am darkly amused at someone who has not done the research

Re: Remove public key from keyserver

On Mon, 15 Jan 2018 20:21, stefan.cl...@posteo.de said: > O.k. Werner invented WKD which solves those problems, if i'm not > mistaken, but is it besides keybase.io widely deployed? Nope. The Web Key Directory solves exactly one problem: How to initially map a mail address to a key. This