From bjk at luxsci.net  Sun Mar  1 17:55:47 2020
From: bjk at luxsci.net (Ben Kibbey)
Date: Sun, 1 Mar 2020 08:55:47 -0800
Subject: poldi: [PATCH] Add option 'killscd'.
Message-ID: <1583081749-822831.871122991.f021Gtltf021132@rs146.luxsci.com>

According to the manual page of scdaemon, when 'card-timeout' is
non-zero in /etc/poldi/scdaemon.conf the card should be powered down
after the next timer tick. This doesn't seem to work: I can lock my X
session, then unlock it without the pin of the card. I am using
xlockmore as the screen locker.

The attached patch fixes things by sending KILLSCD to scdaemon when
'killscd' is set in /etc/poldi/poldi.conf.

-- 
Ben Kibbey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-option-killscd.patch
Type: text/x-diff
Size: 5917 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200301/53aa2b7c/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200301/53aa2b7c/attachment.sig>

From gniibe at fsij.org  Mon Mar  2 05:55:06 2020
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 02 Mar 2020 13:55:06 +0900
Subject: poldi: [PATCH] Add option 'killscd'.
In-Reply-To: <1583081749-822831.871122991.f021Gtltf021132@rs146.luxsci.com>
References: <1583081749-822831.871122991.f021Gtltf021132@rs146.luxsci.com>
Message-ID: <87sgircq51.fsf@iwagami.gniibe.org>

Ben Kibbey <bjk at luxsci.net> wrote:
> According to the manual page of scdaemon, when 'card-timeout' is
> non-zero in /etc/poldi/scdaemon.conf the card should be powered down
> after the next timer tick.

Yes.  The option is deprecated.  I pushed the change of the manual in
master, perhaps, I need to apply the change to 2.2, too.

> This doesn't seem to work: I can lock my X session, then unlock it
> without the pin of the card. I am using xlockmore as the screen
> locker.

IIUC, a single process of xlockmore keeps running under a user's
session.  If so, the behaviour can be explained.

> The attached patch fixes things by sending KILLSCD to scdaemon when
> 'killscd' is set in /etc/poldi/poldi.conf.

I see your intention of killing scdaemon.  But, I'm afraid if it really
matches (a typical) expected behaviour with screen locker / sudo.

I think that the card should reset (to nullify existing verification
status) _before_ poldi tries to use it for the authentication.  And
after unlocking a screen, it is OK (or good) to keep card's verification
status; A user can use the card for SSH with no further verification.
-- 


From gniibe at fsij.org  Mon Mar  2 08:33:13 2020
From: gniibe at fsij.org (Niibe Yutaka)
Date: Mon, 02 Mar 2020 16:33:13 +0900
Subject: poldi: [PATCH] Add option 'killscd'.
In-Reply-To: <87sgircq51.fsf@iwagami.gniibe.org>
References: <1583081749-822831.871122991.f021Gtltf021132@rs146.luxsci.com>
 <87sgircq51.fsf@iwagami.gniibe.org>
Message-ID: <871rqb1a9y.fsf@jumper.gniibe.org>

NIIBE Yutaka wrote:
>> This doesn't seem to work: I can lock my X session, then unlock it
>> without the pin of the card. I am using xlockmore as the screen
>> locker.
>
> IIUC, a single process of xlockmore keeps running under a user's
> session.  If so, the behaviour can be explained.

Sorry, I was confused.  There are two modes running Poldi: by root
and by normal user.

For screen locker and sudo, Poldi accesses scdaemon through gpg-agent,
thus, the verification status is kept.
-- 


From bjk at luxsci.net  Mon Mar  2 17:38:21 2020
From: bjk at luxsci.net (Benjamin Kibbey)
Date: Mon, 02 Mar 2020 16:38:21 +0000
Subject: poldi: [PATCH] Add option 'killscd'.
In-Reply-To: <871rqb1a9y.fsf@jumper.gniibe.org>
References: <1583081749-822831.871122991.f021Gtltf021132@rs146.luxsci.com>
 <87sgircq51.fsf@iwagami.gniibe.org> <871rqb1a9y.fsf@jumper.gniibe.org>
Message-ID: <1583167107-9016372.13420717.f022GcPD3025036@rs146.luxsci.com>

On March 2, 2020 7:33:13 AM UTC, Niibe Yutaka <gniibe at fsij.org> wrote:
>NIIBE Yutaka wrote:
>>> This doesn't seem to work: I can lock my X session, then unlock it
>>> without the pin of the card. I am using xlockmore as the screen
>>> locker.
>>
>> IIUC, a single process of xlockmore keeps running under a user's
>> session.  If so, the behaviour can be explained.
>
>Sorry, I was confused.  There are two modes running Poldi: by root
>and by normal user.
>
>For screen locker and sudo, Poldi accesses scdaemon through gpg-agent,
>thus, the verification status is kept.


-- 
Ben Kibbey


From bjk at luxsci.net  Mon Mar  2 17:46:11 2020
From: bjk at luxsci.net (Benjamin Kibbey)
Date: Mon, 02 Mar 2020 16:46:11 +0000
Subject: poldi: [PATCH] Add option 'killscd'.
In-Reply-To: <87sgircq51.fsf@iwagami.gniibe.org>
References: <1583081749-822831.871122991.f021Gtltf021132@rs146.luxsci.com>
 <87sgircq51.fsf@iwagami.gniibe.org>
Message-ID: <1583167576-2134407.10368692.f022GkFUE001896@rs146.luxsci.com>

On March 2, 2020 4:55:06 AM UTC, NIIBE Yutaka <gniibe at fsij.org> wrote:

>I think that the card should reset (to nullify existing verification
>status) _before_ poldi tries to use it for the authentication.  And
>after unlocking a screen, it is OK (or good) to keep card's verification
>status; A user can use the card for SSH with no further verification.

I think this makes more sense. Unfortunately no time for me to patch poldi myself. 

Thank you,


-- 
Ben Kibbey


From gniibe at fsij.org  Tue Mar  3 03:12:16 2020
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 03 Mar 2020 11:12:16 +0900
Subject: poldi: [PATCH] Add option 'killscd'.
In-Reply-To: <1583167576-2134407.10368692.f022GkFUE001896@rs146.luxsci.com>
References: <1583081749-822831.871122991.f021Gtltf021132@rs146.luxsci.com>
 <87sgircq51.fsf@iwagami.gniibe.org>
 <1583167576-2134407.10368692.f022GkFUE001896@rs146.luxsci.com>
Message-ID: <875zfmdw5b.fsf@iwagami.gniibe.org>

Benjamin Kibbey <bjk at luxsci.net> wrote:
> On March 2, 2020 4:55:06 AM UTC, NIIBE Yutaka <gniibe at fsij.org> wrote:
>
>>I think that the card should reset (to nullify existing verification
>>status) _before_ poldi tries to use it for the authentication.  And
>>after unlocking a screen, it is OK (or good) to keep card's verification
>>status; A user can use the card for SSH with no further verification.
>
> I think this makes more sense. Unfortunately no time for me to patch
> poldi myself.

OK.  I will try to improve Poldi this month.  My plan is doing
two things.

(1) As you pointed out (and we agree): a change of Poldi

Always require user's PIN input.

(2) Adding a command to scdaemon so that an application can be notified
    for card removal.

Currently, we have "scd-event" feature, but it is not well-designed.
I'm thinking about adding WATCH command which informs status change.


I'll report about changes here.
-- 


From bernhard at intevation.de  Tue Mar  3 08:50:15 2020
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 3 Mar 2020 08:50:15 +0100
Subject: [PATCH] gpgme: Add Python 3.9 to the build machinery
In-Reply-To: <bebfb625-827e-a81f-36da-e46c29a8da49@redhat.com>
References: <bebfb625-827e-a81f-36da-e46c29a8da49@redhat.com>
Message-ID: <202003030850.19670.bernhard@intevation.de>

Miro,

Am Donnerstag 13 Februar 2020 14:17:29 schrieb Miro Hron?ok via Gnupg-devel:
> Patch from https://github.com/gpg/gpgme/pull/4 attached.

thanks for the patch!
For completeness: Werner added python3.9 detection on the 14th.

Regards,
Bernhard


-- 
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200303/f49d9de5/attachment.sig>

From bernhard at intevation.de  Tue Mar  3 09:07:38 2020
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 3 Mar 2020 09:07:38 +0100
Subject: Automatic WKD via keys.openpgp.org
In-Reply-To: <2WY8RUQTR48GK.3HUAIATZ4FXES@my.amazin.horse>
References: <2WY8RUQTR48GK.3HUAIATZ4FXES@my.amazin.horse>
Message-ID: <202003030907.38352.bernhard@intevation.de>

Hi Vincent,

Am Sonntag 02 Februar 2020 23:36:42 schrieb Vincent Breitmoser via 
Gnupg-devel:
>  It works well for folks who want to
> publish their keys on WKD, but don't want to go through the hassle of
> maintaining the directory on their server. (like me, incidentally :)

it is good to have another possibility (if your mail provider is not yet 
providing one). 


Most people here understand that this has security drawbacks because it 
becomes a central keyserver with the ability to see whom tries to communicate 
with whom and a potential place to be monitored. Thus using a decentral way
to offer WKD seems to make the whole system more resilient and people using a 
decentral way via their mail provider a bit more secure.

How to we educate people about these significant drawbacks?
(And seriously shouldn't you set a good example and maintin the directory on 
your mail server? >;) It is just running one script in case your public key 
changes.)


Am Montag 03 Februar 2020 00:55:52 schrieb Vincent Breitmoser via Gnupg-devel:
> is deployed for my address. You can test it with commands like:

> > gpg  --no-default-keyring --locate-keys --auto-key-locate
> > clear,nodefault,wkd look at my.amazin.horse

gives me
gpg: error retrieving 'look at my.amazin.horse' via WKD: No data
gpg: error reading key: No data
(probably because gnupg2 from Debian oldstable, fetching pubkeys from many 
other sources work though.)

Regards,
Bernhard

-- 
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200303/c53413bd/attachment.sig>

From look at my.amazin.horse  Tue Mar  3 12:06:51 2020
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Tue, 03 Mar 2020 12:06:51 +0100
Subject: Automatic WKD via keys.openpgp.org
In-Reply-To: <202003030907.38352.bernhard@intevation.de>
References: <202003030907.38352.bernhard@intevation.de>
 <2WY8RUQTR48GK.3HUAIATZ4FXES@my.amazin.horse>
Message-ID: <3VXX9IT091Z58.2TQ2EFSAX13NE@my.amazin.horse>


Hi Bernhard,

> it is good to have another possibility (if your mail provider is not yet
> providing one).

Indeed :)

> Most people here understand that this has security drawbacks because it
> becomes a central keyserver with the ability to see whom tries to communicate
> with whom and a potential place to be monitored.

Right.

> Thus using a decentral way to offer WKD seems to make the whole system more
> resilient and people using a decentral way via their mail provider a bit more
> secure.

I'm not sure it's that clear cut. You do leak metadata to Hagrid, but also you
don't discover the public key for email encryption from servers of the same
party that handles the actual email transmission (although the CNAME is of
course still controlled by them).

Ultimately it's the same tradeoff as with any other "cloud service" - if you let
someone else take care of it, things become easier but you lose some control.
People who can set up CNAME records are hopefully at least roughly aware of
that.

That said, this sure is a stopgap solution for people who'd otherwise not have
WKD at all (like me - see below).

> (And seriously shouldn't you set a good example and maintin the directory on
> your mail server? >;) It is just running one script in case your public key
> changes.)

The reason I didn't have WKD set up before was that it's too inconvenient to
manage, and also tends to get out of sync. This opinion was shared by several
folks I talked to - who either didn't have WKD set up for the same reason, or
whose experience was something along the lines of "sure it's easy to set up,
here I wrote my own python script for the job".

That's where the idea came from in the first place, to pick up people for the
technology who don't care to do anything more complex themselves. Ideally, this
will help along with the chicken-and-egg-problem.

As a more general thought, if we have to force ourselves "to set a good
example", that's ok but we should make sure to take a second and consider "why
do I need to force myself?". If there isn't at least the trend that a tech will
work at some point without idealism fuel, it's valuable to think about why that
is and correct course.

> gpg: error retrieving 'look at my.amazin.horse' via WKD: No data
> gpg: error reading key: No data
> (probably because gnupg2 from Debian oldstable, fetching pubkeys from many
> other sources work though.)

Just tested this, works for me as expected. Please try `killall dirmngr`, that
typically fixes things.

Otherwise, you could check that setup is correct using curl:
> http://openpgpkey.my.amazin.horse/.well-known/openpgpkey/my.amazin.horse/hu/hnjtm6on474983a8w6zwkwruw8brysb5

If that works as expected but GnuPG doesn't, the next step would be to increase
the log level to see what's going on.

Cheers

 - V


From look at my.amazin.horse  Tue Mar  3 15:58:26 2020
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Tue, 03 Mar 2020 15:58:26 +0100
Subject: Automatic WKD via keys.openpgp.org
In-Reply-To: <3VXX9IT091Z58.2TQ2EFSAX13NE@my.amazin.horse>
References: <3VXX9IT091Z58.2TQ2EFSAX13NE@my.amazin.horse>
 <202003030907.38352.bernhard@intevation.de>
 <2WY8RUQTR48GK.3HUAIATZ4FXES@my.amazin.horse>
Message-ID: <256USIZSE0O16.20GS6AOZO1CAJ@my.amazin.horse>


> If that works as expected but GnuPG doesn't, the next step would be to
> increase the log level to see what's going on.

Someone noted that if you are using Debian oldstable, the problem might simply
be that your GnuPG does not support the WKD advanced method, which is necessary
for the domain delegation that WKDaaS relies on.

That's a problem we can't do much about, but that will resolve itself, at the
latest in July this year when strech is no longer supported as oldstable :)

 - V



From bernhard at intevation.de  Wed Mar  4 08:52:58 2020
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 04 Mar 2020 08:52:58 +0100
Subject: WKDaaS  (Re: Automatic WKD via keys.openpgp.org)
In-Reply-To: <256USIZSE0O16.20GS6AOZO1CAJ@my.amazin.horse>
References: <3VXX9IT091Z58.2TQ2EFSAX13NE@my.amazin.horse>
 <2WY8RUQTR48GK.3HUAIATZ4FXES@my.amazin.horse>
 <256USIZSE0O16.20GS6AOZO1CAJ@my.amazin.horse>
Message-ID: <4032089.olR1BtCHOv@kymo.gruen>

Am Dienstag, 3. M?rz 2020, 15:58:26 CET schrieb Vincent Breitmoser via Gnupg-
devel:
> Someone noted that if you are using Debian oldstable, the problem might
> simply be that your GnuPG does not support the WKD advanced method, which
> is necessary for the domain delegation that WKDaaS relies on.

Probably, however many elder GnuPG version stay around in production.
 
> That's a problem we can't do much about, but that will resolve itself, at
> the latest in July this year when strech is no longer supported as
> oldstable :)

A lot of people keep using oldoldstable of Debian or distributions based on 
Debian, so it is another drawback that people using WKDaaS have to be aware 
of.

Regards,
Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner




From bernhard at intevation.de  Wed Mar  4 09:23:35 2020
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 04 Mar 2020 09:23:35 +0100
Subject: Easy WKD setup and contributing to overall ecosystem (Re: Automatic
 WKD via keys.openpgp.org)
In-Reply-To: <3VXX9IT091Z58.2TQ2EFSAX13NE@my.amazin.horse>
References: <202003030907.38352.bernhard@intevation.de>
 <2WY8RUQTR48GK.3HUAIATZ4FXES@my.amazin.horse>
 <3VXX9IT091Z58.2TQ2EFSAX13NE@my.amazin.horse>
Message-ID: <5760806.am7NHvfkx9@kymo.gruen>

Hi Vincent,

Am Dienstag, 3. M?rz 2020, 12:06:51 CET schrieb Vincent Breitmoser via Gnupg-
devel:
> > (And seriously shouldn't you set a good example and maintain the directory
> > on your mail server? >;) It is just running one script in case your
> > public key changes.)
> 
> The reason I didn't have WKD set up before was that it's too inconvenient to
> manage, and also tends to get out of sync. 

Can you be more specific?
Each time our pubkey is changed, you need to run one script.
Scripts were public on wiki.gnupg.org/WKD for a long while.
Even for a smaller organisation, pubkey do not change that often, and if they 
do there are usually a set of things you need to do anyway.

And if running one script is not easy enough, the wks scripts and a decent 
mail client like KMail would make it even less hassle.

> This opinion was shared by
> several folks I talked to - who either didn't have WKD set up for the same
> reason, or whose experience was something along the lines of "sure it's
> easy to set up, here I wrote my own python script for the job".

Did you find out in more detail what the problems where?
If they were able to write their own script, did they share it?
(Often people did not find the scripts that we were publishing
or where lacking some info.)

> That's where the idea came from in the first place, to pick up people for
> the technology who don't care to do anything more complex themselves.
> Ideally, this will help along with the chicken-and-egg-problem.

Only if we motivate people that can do it, to actually delopy WKD and not 
WKDaaS. I've updated the wiki.gnupg.org entry to reflect our exchange better.

> As a more general thought, if we have to force ourselves "to set a good
> example", that's ok but we should make sure to take a second and consider
> "why do I need to force myself?". If there isn't at least the trend that a
> tech will work at some point without idealism fuel, it's valuable to think
> about why that is and correct course.

To me that is about responsibility. We (as the developers of the OpenPGP 
ecosystem - where I do include people that care  for it on several levels, 
like people on this list) should try to look at the larger issue and care for 
others that may not have that interest. And as always, the people doing the 
maintainance of technology have to work hard to make it easier for others.
It about doing what is considered best for the ecosystem, not about what I 
like personally.

Regards,
Bernhard
-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200304/f55e3e76/attachment.sig>

From bernhard at intevation.de  Wed Mar  4 09:36:59 2020
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 04 Mar 2020 09:36:59 +0100
Subject: WKDaaS drawbacks (Re: Automatic WKD via keys.openpgp.org)
In-Reply-To: <3VXX9IT091Z58.2TQ2EFSAX13NE@my.amazin.horse>
References: <202003030907.38352.bernhard@intevation.de>
 <2WY8RUQTR48GK.3HUAIATZ4FXES@my.amazin.horse>
 <3VXX9IT091Z58.2TQ2EFSAX13NE@my.amazin.horse>
Message-ID: <24361946.yc3mWDGLBI@kymo.gruen>

Am Dienstag, 3. M?rz 2020, 12:06:51 CET schrieb Vincent Breitmoser via Gnupg-
devel:

> I'm not sure it's that clear cut. You do leak metadata to Hagrid, but also
> you don't discover the public key for email encryption from servers of the
> same party that handles the actual email transmission (although the CNAME
> is of course still controlled by them).

The long term business interest of your email provider can often be understood 
quite easily. It also allows someone to judge if it is long-lasting and 
economic (so costs are covered). What about keys.openpgp.net?

It maybe cool if it were a real WKDaaS with a subscription fee like
one ? a year. And if it would be separate from a public keyserver 
functionality.

> Ultimately it's the same tradeoff as with any other "cloud service" - if you
> let someone else take care of it, things become easier but you lose some
> control. People who can set up CNAME records are hopefully at least roughly
> aware of that.

I've tried to write down the drawbacks you've  listed on wiki.gnupg.org.
Adding one more party towards the control and the possiblity to get a lot 
communication metadata seems a significant drawback.

What is your take on my question?
| How to we educate people about these significant drawbacks?

> That said, this sure is a stopgap solution for people who'd otherwise not
> have WKD at all (like me - see below).

I still maintain that your technical skill were good enough to run a WKD
if you wanted to. ;)



Regards,
Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200304/f3f9f91c/attachment.sig>

From bernhard at intevation.de  Wed Mar  4 10:12:29 2020
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 04 Mar 2020 10:12:29 +0100
Subject: Fixing GMime usage of gpgme
Message-ID: <3326685.ryYhsLKbGV@kymo.gruen>

Hi,
a MIME library for C/C++ based on glib uses gpgme.
I helped yesterday to identify and fix a defect where
pubkeys with expired subkeys would not be found and used for encryption in
the MUA astroidmail.

https://github.com/jstedfast/gmime/issues/88

Writting this here because I believe we on this list care how people use gpgme
and we should help developers using gpgme. 

While we try to understand what gpgme is used for and how we can help. In this 
case the idea was to identify a pubkey for encryption, there is more room for 
improvement in the function used, which was inspired from a different Free 
Software MUA.. Finding the best availalbe pubkey to encrypt for an email 
address is something that would be a comfort function candidate for gpgme.

Best,
Bernhard
-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200304/c9a76784/attachment.sig>

From bernhard at intevation.de  Wed Mar  4 10:15:25 2020
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 04 Mar 2020 10:15:25 +0100
Subject: Speading WKD: Adding WKD sending for password resets/reminders
Message-ID: <1624197.pdpjo3sm7F@kymo.gruen>

Moin,
quite a few software package use email as a way to confirm an account or a 
password reset. Sometimes this even has a temporary password or pin.

With WKD there is a good pubkey to just automatically encrypt.
So if we build this into package, like Mailman, WKD users will get some extra 
benefit. Okay, it is just a little bit of extra security, but why not?

(An idea coming up at the Intevation lunch table. ;) )

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200304/d569f905/attachment.sig>

From wiktor at metacode.biz  Wed Mar  4 10:25:21 2020
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Wed, 4 Mar 2020 10:25:21 +0100
Subject: Speading WKD: Adding WKD sending for password resets/reminders
In-Reply-To: <1624197.pdpjo3sm7F@kymo.gruen>
References: <1624197.pdpjo3sm7F@kymo.gruen>
Message-ID: <098b6049-d412-a178-5c6e-fdf844ab8fff@metacode.biz>

On 04.03.2020 10:15, Bernhard Reiter wrote:
> With WKD there is a good pubkey to just automatically encrypt.
> So if we build this into package, like Mailman, WKD users will get some extra
> benefit. Okay, it is just a little bit of extra security, but why not?

Yep, this is definitely a good idea!

I proposed something similar to GitLab: when provisioning the account 
with e-mail address automatically fetch GPG keys. Also: derive SSH keys 
from GPG authentication subkeys.

WKD has a lot of underutilized potential ;)

The issue link:

https://gitlab.com/gitlab-org/gitlab-foss/issues/48751

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200304/b0e1db5c/attachment.sig>

From andrewg at andrewg.com  Mon Mar  9 14:02:55 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 9 Mar 2020 13:02:55 +0000
Subject: Remote forwarding gnupg extra-socket?
Message-ID: <b8ca7450-6a48-f301-182b-27aebeece85b@andrewg.com>

It used to be that we could tell gpg-agent to create an extra-socket
(with restricted functionality) and then tell ssh to forward that socket
to a remote machine, giving gpg an equivalent agent forwarding
functionality to that of ssh.

In fact, you can still configure all of the above, but doing so is now
next to useless. Since v2.1 there is no way to tell the remote gpg
instance to use a non-default socket, and there is no reliable way to
tell ssh to mount the forwarded socket on the default location -- the
default is now under XDG_RUNTIME_DIR which is unpredictable in
principle, and ssh does not allow the use of remote envars in
RemoteForward directives.

Not only that, but if you are already logged in to the remote machine by
other means you MUST NOT use the default socket location lest you break
the existing session.

Can we please PLEASE have GPG_AGENT_SOCK back in the short term?

In the long term, it might be more productive to overload ssh-agent. IFF
the forwarded ssh-agent is really a gnupg-agent with enable-ssh-support,
it could optionally support a protocol extension allowing it to tunnel
extra-socket commands back to the originating gpg-agent over the
ssh-agent connection. The gpg on the remote machine could then test for
this protocol extension and if found use the ssh-agent socket instead.
This would remove the need for any custom ssh shenanigans (which only
sort-of work, even now).

The ssh-agent protocol allows for vendor-specific protocol extensions,
which would appear to be perfectly suited for this:

https://tools.ietf.org/id/draft-miller-ssh-agent-01.html#rfc.section.4.7

What do we think?

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200309/175e7ee9/attachment-0001.sig>

From marcelf at selfnet.de  Wed Mar 11 12:03:37 2020
From: marcelf at selfnet.de (Marcel Fest)
Date: Wed, 11 Mar 2020 12:03:37 +0100
Subject: hkp4py hkp|hkps bindings for python.
In-Reply-To: <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>
References: <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>
Message-ID: <8ffd54f6-2a86-e193-c8e4-f25e353263ff@selfnet.de>

Hey all,

I added basic support for the Hagrid Keyserver API or as the protocol
names itself `vks`.

Can someone look into it. I am currently curious if it breaks current stuff.
https://github.com/Selfnet/hkp4py/tree/feature/gpg-vks

I also want to know if hkp4py`s further releases need to support python
2.7.x and python 3.5.x and older.

@Ben McGinnes.


Best Regards


Marcel Fest

On 9/18/18 10:45 PM, Marcel Fest wrote:
> Hey folks, hey Ben,
>
> I have split up my project in to hkp4py and multivault.
>
> The python2 support will be added in 1 or 2 days.
>
> hkp4py is a simple library to get keys from the gpg/pgp keyservers via
> the specified API.
>
>
>
> The project gets available in the next days under MIT License on GitHub.
>
>
> https://github.com/Selfnet/hkp4py
>
>
> and later on pypi....
>
>
> Best Regards
>
> Marcel
>
>
> PS: Ben I added proxy and header support for you.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200311/9de633df/attachment.sig>

From deloptes at gmail.com  Wed Mar 11 21:03:29 2020
From: deloptes at gmail.com (deloptes)
Date: Wed, 11 Mar 2020 21:03:29 +0100
Subject: [PATCH pinentry 4/4] tqt: Disable echoing if backspace is pressed
 first.
In-Reply-To: <20180804212411.7895-5-dgouttegattat@incenp.org>
References: <20180804212411.7895-1-dgouttegattat@incenp.org>
 <20180804212411.7895-5-dgouttegattat@incenp.org>
Message-ID: <CAJJ4Ra+2DvC4rfFUkMEeVx8ZJHmNgsZMgxbg5ECJ=Gtn-6OAOw@mail.gmail.com>

Hi Damien, all,
long time passed since we worked on this together.
As the TDE release 14.1 is planned to happen by the end of this year, I was
wondering if we have to do something to finalize the work already done.

pinentry-tqt is working perfectly well on the TDE desktop and I am
wondering how we can integrate it into the TDE project.

Was it merged in gnupg? Can and should it be merged?

How we can setup our repository to follow the main branch?

Thank you in advance for your answers, ideas and directions.

regards


On Sat, Aug 4, 2018 at 11:24 PM Damien Goutte-Gattat via Gnupg-devel <
gnupg-devel at gnupg.org> wrote:

> * tqt/secqlineedit.h (backspacePressed): New signal.
> * tqt/secqinternal.cpp (SecTQLineEdit::backspace): Emit new signal.
> * tqt/pinentrydialog.h (_got_input): New member field.
> (onBackspace): New slot.
> * tqt/pinentrydialog.cpp (onBackspace): New slot.
> (PinEntryDialog::updateQuality): Prevent echo disabling as soon as
> the text has been edited.
>
> GnuPG-bug-id: 3428
> Signed-off-by: Damien Goutte-Gattat <dgouttegattat at incenp.org>
> ---
>  tqt/pinentrydialog.cpp | 14 +++++++++++++-
>  tqt/pinentrydialog.h   |  2 ++
>  tqt/secqlineedit.cpp   |  2 ++
>  tqt/secqlineedit.h     |  1 +
>  4 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/tqt/pinentrydialog.cpp b/tqt/pinentrydialog.cpp
> index 069eeaf..6a2ae12 100644
> --- a/tqt/pinentrydialog.cpp
> +++ b/tqt/pinentrydialog.cpp
> @@ -32,7 +32,8 @@
>
>  PinEntryDialog::PinEntryDialog( TQWidget* parent, const char* name,
>                                  bool modal, bool enable_quality_bar )
> -  : TQDialog( parent, name, modal, TQt::WStyle_StaysOnTop ), _grabbed(
> false )
> +  : TQDialog( parent, name, modal, TQt::WStyle_StaysOnTop ), _grabbed(
> false ),
> +    _got_input( false )
>  {
>    TQBoxLayout* top = new TQVBoxLayout( this, 6 );
>    TQBoxLayout* upperLayout = new TQHBoxLayout( top );
> @@ -89,6 +90,8 @@ PinEntryDialog::PinEntryDialog( TQWidget* parent, const
> char* name,
>            this, SIGNAL( rejected() ) );
>    connect( _edit, SIGNAL( textModified(const SecTQString&) ),
>            this, SLOT( updateQuality(const SecTQString&) ) );
> +  connect (_edit, SIGNAL (backspacePressed()),
> +          this, SLOT (onBackspace ()));
>    connect (this, SIGNAL (accepted ()),
>            this, SLOT (accept ()));
>    connect (this, SIGNAL (rejected ()),
> @@ -131,6 +134,8 @@ void PinEntryDialog::updateQuality( const SecTQString
> & txt )
>    int percent;
>    TQPalette pal;
>
> +  _got_input = true;
> +
>    if (!_have_quality_bar || !_pinentry_info)
>      return;
>    pin = (char*)txt.utf8();
> @@ -159,6 +164,13 @@ void PinEntryDialog::updateQuality( const SecTQString
> & txt )
>  }
>
>
> +void PinEntryDialog::onBackspace()
> +{
> +  if (!_got_input)
> +    _edit->setEchoMode( SecTQLineEdit::NoEcho );
> +}
> +
> +
>  void PinEntryDialog::setDescription( const TQString& txt )
>  {
>    _desc->setText( txt );
> diff --git a/tqt/pinentrydialog.h b/tqt/pinentrydialog.h
> index d6f20c6..eb4d332 100644
> --- a/tqt/pinentrydialog.h
> +++ b/tqt/pinentrydialog.h
> @@ -63,6 +63,7 @@ public:
>
>  public slots:
>    void updateQuality(const SecTQString &);
> +  void onBackspace();
>
>  signals:
>    void accepted();
> @@ -86,6 +87,7 @@ private:
>    bool       _grabbed;
>    bool       _have_quality_bar;
>    pinentry_t _pinentry_info;
> +  bool       _got_input;
>  };
>
>
> diff --git a/tqt/secqlineedit.cpp b/tqt/secqlineedit.cpp
> index ee95c8d..da0637a 100644
> --- a/tqt/secqlineedit.cpp
> +++ b/tqt/secqlineedit.cpp
> @@ -719,6 +719,8 @@ void SecTQLineEdit::backspace()
>             d->del( TRUE );
>      }
>      d->finishChange( priorState );
> +
> +    emit backspacePressed();
>  }
>
>  /*!
> diff --git a/tqt/secqlineedit.h b/tqt/secqlineedit.h
> index bd28cec..126f231 100644
> --- a/tqt/secqlineedit.h
> +++ b/tqt/secqlineedit.h
> @@ -187,6 +187,7 @@ signals:
>      void returnPressed();
>      void lostFocus();
>      void selectionChanged();
> +    void backspacePressed();
>
>  protected:
>      bool event( TQEvent * );
> --
> 2.14.4
>
>
> _______________________________________________
> 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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200311/00838dca/attachment.html>

From dgouttegattat at incenp.org  Wed Mar 11 22:08:17 2020
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Wed, 11 Mar 2020 21:08:17 +0000
Subject: [PATCH pinentry 4/4] tqt: Disable echoing if backspace is
 pressed first.
In-Reply-To: <CAJJ4Ra+2DvC4rfFUkMEeVx8ZJHmNgsZMgxbg5ECJ=Gtn-6OAOw@mail.gmail.com>
References: <20180804212411.7895-1-dgouttegattat@incenp.org>
 <20180804212411.7895-5-dgouttegattat@incenp.org>
 <CAJJ4Ra+2DvC4rfFUkMEeVx8ZJHmNgsZMgxbg5ECJ=Gtn-6OAOw@mail.gmail.com>
Message-ID: <20200311210817.ae5gfnbkq65kxdwl@dynein.local.incenp.org>

On Wed, Mar 11, 2020 at 09:03:29PM +0100, deloptes wrote:
>pinentry-tqt is working perfectly well on the TDE desktop

Since I don?t use TDE myself and therefore can?t fully test pinentry-tqt 
in its ?natural? environment, I am glad to read that.


>Was it merged in gnupg? Can and should it be merged?

Yes, I merged it into the main branch back in November 2017, it is part 
of the last pinentry release (1.1.0, published in December 2017).


>As the TDE release 14.1 is planned to happen by the end of this year, I
>was wondering if we have to do something to finalize the work already
>done.

At the source level, I don?t think so, especially since you say that 
pinentry-tqt is working well.

I guess the hurdle that TDE users will need to overcome though is 
getting pinentry-tqt installed on their system. A quick search through 
the repositories of some common GNU/Linux distributions (Debian, Ubuntu, 
Fedora, Arch) tells me that none of them are packaging pinentry-tqt, and 
this is unlikely to change since they don?t package TQt either.

I see that the TDE project provides its own packages for the most common 
distributions, so it would make sense for you to provide a binary 
package for pinentry-tqt as well. Make a binary package that provides 
*only* pinentry-tqt (disable all other pinentries at the configure 
step), and provide it along with the other TDE packages.


>How we can setup our repository to follow the main branch?

Not sure I understand your question here.

If you have changes to pinentry-tqt (e.g. fixes for bugs reported by TDE 
users), the ?standard? workflow would be to clone the pinentry main 
branch from git.gnupg.org, do your development on a dedicated branch, 
them send the patches to gnupg-devel. From there I (or another GnuPG 
developer) would take care of merging them.


Regards,

- Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200311/dace673c/attachment.sig>

From deloptes at gmail.com  Thu Mar 12 00:12:39 2020
From: deloptes at gmail.com (deloptes)
Date: Thu, 12 Mar 2020 00:12:39 +0100
Subject: [PATCH pinentry 4/4] tqt: Disable echoing if backspace is pressed
 first.
In-Reply-To: <20200311210817.ae5gfnbkq65kxdwl@dynein.local.incenp.org>
References: <20180804212411.7895-1-dgouttegattat@incenp.org>
 <20180804212411.7895-5-dgouttegattat@incenp.org>
 <CAJJ4Ra+2DvC4rfFUkMEeVx8ZJHmNgsZMgxbg5ECJ=Gtn-6OAOw@mail.gmail.com>
 <20200311210817.ae5gfnbkq65kxdwl@dynein.local.incenp.org>
Message-ID: <CAJJ4RaJ20suLeSpPOFeobQBcV7Nd9HsVE2v7dByvLs7qFTuAhQ@mail.gmail.com>

Hi Damien,
thank you for your swift response.

On Wed, Mar 11, 2020 at 10:08 PM Damien Goutte-Gattat <
dgouttegattat at incenp.org> wrote:

> On Wed, Mar 11, 2020 at 09:03:29PM +0100, deloptes wrote:
> >pinentry-tqt is working perfectly well on the TDE desktop
>
> Since I don?t use TDE myself and therefore can?t fully test pinentry-tqt
> in its ?natural? environment, I am glad to read that.
>
> Shame on you :) (joking)


>
> >Was it merged in gnupg? Can and should it be merged?
>
> Yes, I merged it into the main branch back in November 2017, it is part
> of the last pinentry release (1.1.0, published in December 2017).
>
>
Thank you for confirming this.


>
> >As the TDE release 14.1 is planned to happen by the end of this year, I
> >was wondering if we have to do something to finalize the work already
> >done.
>
> At the source level, I don?t think so, especially since you say that
> pinentry-tqt is working well.
>
> I guess the hurdle that TDE users will need to overcome though is
> getting pinentry-tqt installed on their system. A quick search through
> the repositories of some common GNU/Linux distributions (Debian, Ubuntu,
> Fedora, Arch) tells me that none of them are packaging pinentry-tqt, and
> this is unlikely to change since they don?t package TQt either.
>
> I see that the TDE project provides its own packages for the most common
> distributions, so it would make sense for you to provide a binary
> package for pinentry-tqt as well. Make a binary package that provides
> *only* pinentry-tqt (disable all other pinentries at the configure
> step), and provide it along with the other TDE packages.
>
> Yes, this is exactly what the TDE team will do - provide a binary package
for the supported distros only for pinentry-tqt.
I must make a note here that I am just a contributor to the project and not
a speaker for the team.


>
> >How we can setup our repository to follow the main branch?
>
> Not sure I understand your question here.
>
> If you have changes to pinentry-tqt (e.g. fixes for bugs reported by TDE
> users), the ?standard? workflow would be to clone the pinentry main
> branch from git.gnupg.org, do your development on a dedicated branch,
> them send the patches to gnupg-devel. From there I (or another GnuPG
> developer) would take care of merging them.
>
>  You understood correctly. I am more interested on how to follow changes
by upstream and if you have some special requirements for such process, but
the workflow described is sufficient for the beginning. I'll share the
answers with the TDE team and come back to you if more questions emerge.

Thank you once again

regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200312/4077e3ae/attachment-0001.html>

From James.Bottomley at HansenPartnership.com  Thu Mar 19 00:22:31 2020
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 18 Mar 2020 16:22:31 -0700
Subject: [BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6
Message-ID: <1584573751.3504.36.camel@HansenPartnership.com>

openSUSE zypper uses gpg via gpgme to check signatures on the
repository archives against a list of accepted keys.  It uses gpgme in
libzypp to do this.  For all versions of gpg > 2.2.6 a signature check
failure is observed with strace confirming that gpgme_op_verify is
returning GPG_ERR_GENERAL.

After bisecting, the problem patch turns out to be:

commit e2bd152a928d79ddfb95fd2f7911c80a1a8d5a21 (refs/bisect/bad)
Author: Werner Koch <wk at gnupg.org>
Date:   Thu Apr 12 11:49:36 2018 +0200

    gpg: Relax printing of STATUS_FAILURE.

And reverting this patch on the openSUSE version of gnupg-2.2.19 allows
zypper to function again.

It's entirely unclear to me why this is the problem, and I so far
haven't succeeded in producing a simplified test case.

James



From wk at gnupg.org  Thu Mar 19 10:11:36 2020
From: wk at gnupg.org (Werner Koch)
Date: Thu, 19 Mar 2020 10:11:36 +0100
Subject: [BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6
In-Reply-To: <1584573751.3504.36.camel@HansenPartnership.com> (James Bottomley
 via Gnupg-devel's message of "Wed, 18 Mar 2020 16:22:31 -0700")
References: <1584573751.3504.36.camel@HansenPartnership.com>
Message-ID: <87d098d7zr.fsf@wheatstone.g10code.de>

On Wed, 18 Mar 2020 16:22, James Bottomley said:

>     gpg: Relax printing of STATUS_FAILURE.

That is a followup patch for fixing https://dev.gnupg.org/T3872

commit 0336e5d1a7b9d46e06c838e6a98aecfcc9542882
Author:     Werner Koch <wk at gnupg.org>
AuthorDate: Fri Apr 6 17:32:08 2018 +0200

    gpg: Emit FAILURE stati now in almost all cases.
    
    * g10/cpr.c (write_status_failure): Make it print only once.
    * g10/gpg.c (wrong_args): Bump error counter.
    (g10_exit): Print a FAILURE status if we ever did a log_error etc.
    (main): Use log_error instead of log_fatal at one place.  Print a
    FAILURE status for a bad option.  Ditto for certain exit points so
    that we can see different error locations.
    --
    
    This makes it easier to detect errors by tools which have no way to
    get the exit code (e.g. due to double forking).

Can you please give me a pointer to libzypp so that I can check what is
done there?

Running

  GPGME_DEBUG=9:/foo/bar/gpgme.log  zypper

should give a large tracefile; I can can have a look at it if you like.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200319/d6760e1f/attachment.sig>

From James.Bottomley at HansenPartnership.com  Thu Mar 19 16:21:19 2020
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 19 Mar 2020 08:21:19 -0700
Subject: [BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6
In-Reply-To: <87d098d7zr.fsf@wheatstone.g10code.de>
References: <1584573751.3504.36.camel@HansenPartnership.com>
 <87d098d7zr.fsf@wheatstone.g10code.de>
Message-ID: <1584631279.3610.11.camel@HansenPartnership.com>

On Thu, 2020-03-19 at 10:11 +0100, Werner Koch wrote:
> Running
> 
>   GPGME_DEBUG=9:/foo/bar/gpgme.log  zypper
> 
> should give a large tracefile; I can can have a look at it if you
> like.

First reply is stuck in moderation.  This has the compressed gpgme log

James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gpgme.log.gz
Type: application/gzip
Size: 38416 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200319/f2f43755/attachment-0001.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200319/f2f43755/attachment-0001.sig>

From James.Bottomley at HansenPartnership.com  Thu Mar 19 16:25:03 2020
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 19 Mar 2020 08:25:03 -0700
Subject: [BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6
In-Reply-To: <1584631279.3610.11.camel@HansenPartnership.com>
References: <1584573751.3504.36.camel@HansenPartnership.com>
 <87d098d7zr.fsf@wheatstone.g10code.de>
 <1584631279.3610.11.camel@HansenPartnership.com>
Message-ID: <1584631503.3610.14.camel@HansenPartnership.com>

On Thu, 2020-03-19 at 08:21 -0700, James Bottomley via Gnupg-devel
wrote:
> On Thu, 2020-03-19 at 10:11 +0100, Werner Koch wrote:
> > Running
> > 
> >   GPGME_DEBUG=9:/foo/bar/gpgme.log  zypper
> > 
> > should give a large tracefile; I can can have a look at it if you
> > like.
> 
> First reply is stuck in moderation.  This has the compressed gpgme
> log

I should add for the first reply that when I go in and run gpg manually
over exactly the directories and files the gpgme code is using,
verification succeeds, and when I try to do the same thing using a test
programme built on gpgme everything also succeeds, so whatever is
happening seems to be something to do with the sequence of prior
operations zypper did.

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200319/e2b729b2/attachment.sig>

From wk at gnupg.org  Fri Mar 20 17:51:09 2020
From: wk at gnupg.org (Werner Koch)
Date: Fri, 20 Mar 2020 17:51:09 +0100
Subject: [Announce] GnuPG 2.2.20 released
Message-ID: <87h7yj7ywy.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.2.20.  This is maintenace release fixing a minor security
problem and adding a new OpenPGP feature.  See below for details.


About GnuPG
===========

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  A wealth of frontend applications and libraries
making use of GnuPG are available.  As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.2.20
====================================

  * Protect the error counter against overflow to guarantee that the
    tools can't be tricked into returning success after an error.

  * gpg: Make really sure that --verify-files always returns an error.

  * gpg: Fix key listing --with-secret if a pattern is given.  [#4061]

  * gpg: Fix detection of certain keys used as default-key.  [#4810]

  * gpg: Fix default-key selection when a card is available.  [#4850]

  * gpg: Fix key expiration and key usage for keys created with a
    creation date of zero.  [#4670]

  * gpgsm: Fix import of some CR,LF terminated certificates.  [#4847]

  * gpg: New options --include-key-block and --auto-key-import to
    allow encrypted replies after an initial signed message.  [#4856]

  * gpg: Allow the use of a fingerprint with --trusted-key. [#4855]

  * gpg: New property "fpr" for use by --export-filter.

  * scdaemon: Disable the pinpad if a KDF DO is used.  [#4832]

  * dirmngr: Improve finding OCSP certificates.  [#4536]

  * Avoid build problems with LTO or gcc-10. [#4831]

  Release-info: https://dev.gnupg.org/T4860


Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG 2.2.20 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.20.tar.bz2 (6627k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.20.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.20_20200320.exe (4144k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.20_20200320.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.

A new version of GnuPG's full installer for Windows (aka Gpg4win)
featuring several frontends and plugins will be released shortly.


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.2.20.tar.bz2 you would use this command:

     gpg --verify gnupg-2.2.20.tar.bz2.sig gnupg-2.2.20.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.2.20.tar.bz2, you run the command like this:

     sha1sum gnupg-2.2.20.tar.bz2

   and check that the output matches the next line:

d5290f0781df5dc83302127d6065fb59b35e53d7  gnupg-2.2.20.tar.bz2
a8b47222875b31661f79c1e7414657b02b44da78  gnupg-w32-2.2.20_20200320.tar.xz
e6547a9bd2cdca3264ccb36d64f755ba6c8da2ba  gnupg-w32-2.2.20_20200320.exe


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, French, German, Japanese,
Norwegian, Polish, Russian, and Ukrainian being almost completely
translated.


Documentation and Support
=========================

If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at

  https://gnupg.org/faq/whats-new-in-2.1.html

The file gnupg.info has the complete reference manual of the system.
Separate man pages are included as well but they miss some of the
details available only in thee manual.  The manual is also available
online at

  https://gnupg.org/documentation/manuals/gnupg/

or can be downloaded as PDF at

  https://gnupg.org/documentation/manuals/gnupg.pdf .

You may also want to search the GnuPG mailing list archives or ask on
the gnupg-users mailing list for advise on how to solve problems.  Most
of the new features are around for several years and thus enough public
experience is available.  https://wiki.gnupg.org has user contributed
information around GnuPG and relate software.

In case of build problems specific to this release please first check
https://dev.gnupg.org/T4860 for updated information.

Please consult the archive of the gnupg-users mailing list before
reporting a bug: <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>.  If you need commercial
support go to <https://gnupg.com> or <https://gnupg.org/service.html>.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.


Thanks
======

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project currently employs two full-time developers and one
contractor.  They all work exclusively on GnuPG and closely related
software like Libgcrypt, GPGME and Gpg4win.

We have to thank all the people who helped the GnuPG project, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.

Many thanks to our numerous financial supporters, both corporate and
individuals.  Without you it would not be possible to keep GnuPG in a
good shape and to address all the small and larger requests made by our
users.  Thanks.


Happy hacking,

   Your GnuPG hackers



p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users'at'gnupg.org mailing list.

p.p.s
List of Release Signing Keys:
To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these three keys:

  rsa2048 2011-01-12 [expires: 2021-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048 2014-10-29 [expires: 2020-10-30]
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

  rsa3072 2017-03-17 [expires: 2027-03-15]
  Key fingerprint = 5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (Release Signing Key)

The keys are available at <https://gnupg.org/signature_key.html> and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200320/984e8c91/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From gnupg-devel at spodhuis.org  Mon Mar 23 00:10:46 2020
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Sun, 22 Mar 2020 19:10:46 -0400
Subject: [Announce] GnuPG 2.2.20 released
In-Reply-To: <87h7yj7ywy.fsf@wheatstone.g10code.de>
References: <87h7yj7ywy.fsf@wheatstone.g10code.de>
Message-ID: <20200322231046.GA15059@fullerene>

On 2020-03-20 at 17:51 +0100, Werner Koch via Gnupg-devel wrote:
> We are pleased to announce the availability of a new GnuPG release:
> version 2.2.20.

There appears to be a regression in handling keyserver directives, in
~/.gnupg/gpg.conf or on the command-line.

    % gpg --recv-key $my_key
    gpg: keyserver receive failed: Invalid URI

As near as I can determine, anything hkps: triggers this, as does
`keys.openpgp.org`, but if I can find another functioning non-HKPS HKP
keyserver, then I can use that.

For `keys.openpgp.org`, `hkp://`, `hkps://`, or bare hostname, all
trigger this.

I haven't yet found a common trigger to isolate this, unless it's
existence of MX records in DNS, which seems unlikely.

-Phil


From dkg at fifthhorseman.net  Mon Mar 23 20:29:29 2020
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 23 Mar 2020 15:29:29 -0400
Subject: regression handling keyserver directives [was: Re: [Announce] GnuPG
 2.2.20 released]
In-Reply-To: <20200322231046.GA15059@fullerene>
References: <87h7yj7ywy.fsf@wheatstone.g10code.de>
 <20200322231046.GA15059@fullerene>
Message-ID: <87v9mu98fa.fsf@fifthhorseman.net>

On Sun 2020-03-22 19:10:46 -0400, Phil Pennock via Gnupg-devel wrote:
> On 2020-03-20 at 17:51 +0100, Werner Koch via Gnupg-devel wrote:
>> We are pleased to announce the availability of a new GnuPG release:
>> version 2.2.20.
>
> There appears to be a regression in handling keyserver directives, in
> ~/.gnupg/gpg.conf or on the command-line.
>
>     % gpg --recv-key $my_key
>     gpg: keyserver receive failed: Invalid URI

I've just built and tested and uploaded 2.2.20 for debian, and i'm not
seeing this particular failure here.

> As near as I can determine, anything hkps: triggers this, as does
> `keys.openpgp.org`, but if I can find another functioning non-HKPS HKP
> keyserver, then I can use that.
>
> For `keys.openpgp.org`, `hkp://`, `hkps://`, or bare hostname, all
> trigger this.
>
> I haven't yet found a common trigger to isolate this, unless it's
> existence of MX records in DNS, which seems unlikely.

Have you stopped any older already-running instances of dirmngr?

I'd be happy to help debug further, but maybe it would help to post some
logs from dirmngr or something to see what might be going wrong.

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200323/83ffc417/attachment-0001.sig>

From gnupg-devel at spodhuis.org  Mon Mar 23 23:14:41 2020
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Mon, 23 Mar 2020 18:14:41 -0400
Subject: regression handling keyserver directives [was: Re: [Announce]
 GnuPG 2.2.20 released]
In-Reply-To: <87v9mu98fa.fsf@fifthhorseman.net>
References: <87h7yj7ywy.fsf@wheatstone.g10code.de>
 <20200322231046.GA15059@fullerene>
 <87v9mu98fa.fsf@fifthhorseman.net>
Message-ID: <20200323221441.GA18635@fullerene>

On 2020-03-23 at 15:29 -0400, Daniel Kahn Gillmor wrote:
> I've just built and tested and uploaded 2.2.20 for debian, and i'm not
> seeing this particular failure here.

Drat.

> Have you stopped any older already-running instances of dirmngr?

Not only that, I'd even rebooted since.

> I'd be happy to help debug further, but maybe it would help to post some
> logs from dirmngr or something to see what might be going wrong.

Sure.  I considered holding off for debugging but I didn't have time
then, so figured it was worth saying something in case it was an easy
fix.  Also: sorry for not changing the mail subject.

The packages are my own builds, these are the version numbers:

    gmp          6.2.0
    gnupg        2.2.20
    gnutls       3.6.12
    libassuan    2.5.3
    libgcrypt    1.8.5
    libgpg-error 1.37
    libksba      1.3.5
    nettle       3.5.1
    npth         1.6
    pinentry     1.1.0

With verbose / debug-all / gnutls-debug 9 :

~~~~~~~~~~~~~~~~~~~~~~~~~~~8< log.dirmngr >8~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2020-03-23 18:11:38 dirmngr[20128.0] permanently loaded certificates: 66
2020-03-23 18:11:38 dirmngr[20128.0]     runtime cached certificates: 0
2020-03-23 18:11:38 dirmngr[20128.0]            trusted certificates: 66 (65,0,0,1)
2020-03-23 18:11:38 dirmngr[20128.6] handler for fd 6 started
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> # Home: /home/pdp/.gnupg
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> # Config: /home/pdp/.gnupg/dirmngr.conf
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> OK Dirmngr 2.2.20 at your service
2020-03-23 18:11:38 dirmngr[20128.6] connection from process 20127 (1000:1000)
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 <- GETINFO version
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> D 2.2.20
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> OK
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 <- KEYSERVER --clear hkps://keys.openpgp.org
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> OK
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 <- KEYSERVER
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> S KEYSERVER hkps://keys.openpgp.org
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> OK
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 <- KS_GET -- 0x4833892924C60A7AE666D32A1DA3E68F41CEECAC
2020-03-23 18:11:38 dirmngr[20128.6] DBG: dns: libdns initialized
2020-03-23 18:11:38 dirmngr[20128.6] DBG: dns: getsrv(_pgpkey-https._tcp.keys.openpgp.org) -> 0 records
2020-03-23 18:11:38 dirmngr[20128.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
2020-03-23 18:11:38 dirmngr[20128.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-03-23 18:11:38 dirmngr[20128.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-03-23 18:11:38 dirmngr[20128.6] command 'KS_GET' failed: Invalid URI
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> ERR 167772207 Invalid URI <Dirmngr>
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 <- BYE
2020-03-23 18:11:38 dirmngr[20128.6] DBG: chan_6 -> OK closing connection
2020-03-23 18:11:38 dirmngr[20128.6] handler for fd 6 terminated
~~~~~~~~~~~~~~~~~~~~~~~~~~~8< log.dirmngr >8~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-Phil


From wk at gnupg.org  Tue Mar 24 10:09:03 2020
From: wk at gnupg.org (Werner Koch)
Date: Tue, 24 Mar 2020 10:09:03 +0100
Subject: regression handling keyserver directives [was: Re: [Announce]
 GnuPG 2.2.20 released]
In-Reply-To: <20200323221441.GA18635@fullerene> (Phil Pennock via
 Gnupg-devel's message of "Mon, 23 Mar 2020 18:14:41 -0400")
References: <87h7yj7ywy.fsf@wheatstone.g10code.de>
 <20200322231046.GA15059@fullerene> <87v9mu98fa.fsf@fifthhorseman.net>
 <20200323221441.GA18635@fullerene>
Message-ID: <87h7ye5dcg.fsf@wheatstone.g10code.de>

Hi!

I just tried with 2.2.21-beta1 (which is identical to 2.2.20) using
both, ntbtls and gnutls and could niot see any problems.  I tried to
specify the keyserver with gpg, dirmngr, ans also with the default.

> getsrv(_pgpkey-https._tcp.keys.openpgp.org) -> 0 records
> 2020-03-23 18:11:38 dirmngr[20128.6] DBG: dns:
> resolve_dns_name(keys.openpgp.org): Success
> 2020-03-23 18:11:38 dirmngr[20128.6] resolve_dns_addr for
> 'keys.openpgp.org': 'keys.openpgp.org' [already known]
> 2020-03-23 18:11:38 dirmngr[20128.6] resolve_dns_addr for
> 'keys.openpgp.org': 'keys.openpgp.org' [already known]
> 2020-03-23 18:11:38 dirmngr[20128.6] command 'KS_GET' failed: Invalid URI

It seems to be a DNS problem with a wrong error code emitted.  Did you
used

  debug dns,network
  verbose

in your dirmngr.conf?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200324/baf3b81a/attachment.sig>

From jmohsenm at gmail.com  Tue Mar 24 22:10:05 2020
From: jmohsenm at gmail.com (Mohsen Mohammadi)
Date: Tue, 24 Mar 2020 17:10:05 -0400
Subject: Willing to contribute to the project
Message-ID: <CABzChq6Qcr=+37=oKwTU-4W07a3DxbbnhqJpj-uHHSXff+DXWw@mail.gmail.com>

Dear GnuPG Developing Community,

I am willing to contribute to the project and wanted to know what are the
best first steps to take. I've already read the "How to Help the GNU
Project" and I'm reading the code, for now, to get more familiar with the
project implementation.

A bit about me: I have recently got my Master's degree in Computer Science.
In my studies, I've been focusing on computer architecture and operating
systems and I've been using C++ and C as my main programming languages.

Looking forward to starting to push commits.

Best,
Mohsen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200324/3eae9597/attachment.html>

From gnupg-devel at spodhuis.org  Wed Mar 25 03:27:42 2020
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Tue, 24 Mar 2020 22:27:42 -0400
Subject: regression handling keyserver directives [was: Re: [Announce]
 GnuPG 2.2.20 released]
In-Reply-To: <87h7ye5dcg.fsf@wheatstone.g10code.de>
References: <87h7yj7ywy.fsf@wheatstone.g10code.de>
 <20200322231046.GA15059@fullerene>
 <87v9mu98fa.fsf@fifthhorseman.net>
 <20200323221441.GA18635@fullerene>
 <87h7ye5dcg.fsf@wheatstone.g10code.de>
Message-ID: <20200325022742.GA32589@fullerene>

On 2020-03-24 at 10:09 +0100, Werner Koch via Gnupg-devel wrote:
> It seems to be a DNS problem with a wrong error code emitted.  Did you
> used
> 
>   debug dns,network
>   verbose
> 
> in your dirmngr.conf?

I wrote:
} With verbose / debug-all / gnutls-debug 9

That is:

    log-file /home/pdp/.gnupg/log.dirmngr
    verbose
    debug-all
    gnutls-debug 9

Moving aside ~/.gnupg/gpg.conf to use defaults, I get the failure from
the default of `hkps://hkps.pool.sks-keyservers.net`; I see the same for
`hkps://keys.openpgp.org` and `hkp://keys.openpgp.org`.

A bare `--keyserver pool.sks-keyservers.net` works.

I'm using systemd's resolved as the DNS resolver, and do not have IPv6
connectivity at home (sigh).

Compilation environment and configure args:

      "env": [
        "PKG_CONFIG_PATH=#{prefix}/lib/pkgconfig",
        "LDFLAGS=-L#{prefix}/lib -Wl,-R#{prefix}/lib"
      ],
      "params": [
        "--disable-nls",
        "--disable-ldap",
        "--enable-noexecstack",
        "--enable-key-cache=32768",
        "--enable-wks-tools",
        "--with-pinentry-pgm=#{prefix}/bin/pinentry-curses",
        "--with-libgpg-error-prefix=#{prefix}",
        "--with-libassuan-prefix=#{prefix}",
        "--with-libgcrypt-prefix=#{prefix}",
        "--with-ksba-prefix=#{prefix}",
        "--with-npth-prefix=#{prefix}"
      ],

    plus --prefix=/opt/gnupg

My attempts to add more logging seem to have triggered a switch to a
different error code so I'm doing something wrong and can't spend more
time on this now to chase further, sorry.  (I saw the error switch to
"Syntax error in URI" and do_parse_uri() trying to parse a URI from
the 0xFingerprint, not seeing what I changed to cause _that_).

-Phil


From andrewg at andrewg.com  Wed Mar 25 10:27:46 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 25 Mar 2020 09:27:46 +0000
Subject: Instructions for confirming WKS requests manually
Message-ID: <ab80604a-d8e5-e6d0-5239-c2c5ec99b51b@andrewg.com>

Hi, all.

gpg-wks-server sends a confirmation email with the following text/plain
alternative part:

```
This message has been send to confirm your request
to publish your key.  If you did not request a key
publication, simply ignore this message.

Most mail software can handle this kind of message
automatically and thus you would not have seen this
message.  It seems that your client does not fully
support this service.  The web page

       https://gnupg.org/faq/wkd.html

explains how you can process this message anyway in
a few manual steps.
```

The FAQ merely references the following page on the wiki:

https://wiki.gnupg.org/WKD

... and there are no instructions there for manual verification. Were
there instructions there before?

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200325/f13f95f1/attachment-0001.sig>

From wk at gnupg.org  Wed Mar 25 12:05:50 2020
From: wk at gnupg.org (Werner Koch)
Date: Wed, 25 Mar 2020 12:05:50 +0100
Subject: Instructions for confirming WKS requests manually
In-Reply-To: <ab80604a-d8e5-e6d0-5239-c2c5ec99b51b@andrewg.com> (Andrew
 Gallagher's message of "Wed, 25 Mar 2020 09:27:46 +0000")
References: <ab80604a-d8e5-e6d0-5239-c2c5ec99b51b@andrewg.com>
Message-ID: <87lfno4ru9.fsf@wheatstone.g10code.de>

On Wed, 25 Mar 2020 09:27, Andrew Gallagher said:

> https://wiki.gnupg.org/WKD
>
> ... and there are no instructions there for manual verification. Were
> there instructions there before?

I am not sure about the wiki pages; tehre is a history, though.  The
easiest way on a Unix box to handle the message is by adding

--8<---------------cut here---------------start------------->8---
application/vnd.gnupg.wks; /usr/local/libexec/gpg-wks-client \
   -v --read --send; needsterminal; description=WKS message
--8<---------------cut here---------------end--------------->8---

to /etc/mailcap.  You may need to use /usr/lib/gpg-wks-client or so if
you are using the distros version of GnuPG.

Manual verification requires reading the specs and in the end you will
use gpg-wks-cleint anyway.  Except for the option --send the tool also
works on Windows and on Unices with no installed sendmail You merely fee
the entire mail into gpg-wks-tool and it writes the confirmation mail to
stdout.  --read expect an already decrypted message while --receive
would do that for you.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200325/521f2344/attachment.sig>

From andrewg at andrewg.com  Wed Mar 25 12:38:33 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 25 Mar 2020 11:38:33 +0000
Subject: Instructions for confirming WKS requests manually
In-Reply-To: <87lfno4ru9.fsf@wheatstone.g10code.de>
References: <ab80604a-d8e5-e6d0-5239-c2c5ec99b51b@andrewg.com>
 <87lfno4ru9.fsf@wheatstone.g10code.de>
Message-ID: <1c9cf6a9-c71e-9338-1a70-4eec3a3ba38c@andrewg.com>

On 25/03/2020 11:05, Werner Koch wrote:
> 
> Manual verification requires reading the specs and in the end you will
> use gpg-wks-cleint anyway.  Except for the option --send the tool also
> works on Windows and on Unices with no installed sendmail You merely fee
> the entire mail into gpg-wks-tool and it writes the confirmation mail to
> stdout.
It's the next step that I'm struggling with. If I have access to a
sendmail elsewhere then sure, I can cut and paste the stdout. But I'm
more concerned with use cases that lack local delivery or terminal
access, and rely on e.g. Mailvelope. If one has 2fa enabled on mail
accounts port 25 is going to be a world of pain, and won't work from
inside most corporate firewalls anyway...

I've tried various permutations of attaching the output from
gpg-wks-client to a webmail message but it always seems to get wrapped
in MIME parts that contradict the real content type, and gpg-wks-server
invariably treats it as cruft.

Is there any way that I can reliably get the PGP block through a
misbehaving webmail and have it understood at the server end?

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200325/d4d6f170/attachment.sig>

From wk at gnupg.org  Wed Mar 25 12:44:21 2020
From: wk at gnupg.org (Werner Koch)
Date: Wed, 25 Mar 2020 12:44:21 +0100
Subject: regression handling keyserver directives
In-Reply-To: <20200325022742.GA32589@fullerene> (Phil Pennock via
 Gnupg-devel's message of "Tue, 24 Mar 2020 22:27:42 -0400")
References: <87h7yj7ywy.fsf@wheatstone.g10code.de>
 <20200322231046.GA15059@fullerene> <87v9mu98fa.fsf@fifthhorseman.net>
 <20200323221441.GA18635@fullerene>
 <87h7ye5dcg.fsf@wheatstone.g10code.de>
 <20200325022742.GA32589@fullerene>
Message-ID: <87h7yc4q22.fsf_-_@wheatstone.g10code.de>

On Tue, 24 Mar 2020 22:27, Phil Pennock said:

> } With verbose / debug-all / gnutls-debug 9

Just wanted to make sure and also to seed the search engines that using
"debug KEYWORDLIST" (try "help") is a better way to enable debugging.

> I'm using systemd's resolved as the DNS resolver, and do not have IPv6
> connectivity at home (sigh).

I checke the code and it does not seem to be a DNS issue.  also the
chnages related to dirmngr between 2.2.19 and 2.2.20 are minimal and not
related to your problem.

> time on this now to chase further, sorry.  (I saw the error switch to
> "Syntax error in URI" and do_parse_uri() trying to parse a URI from
> the 0xFingerprint, not seeing what I changed to cause _that_).

A candidate for GPG_ERR_INV_URI ("Invalid URI") is:

 - A HTTP proxy using "https:".  We support only "http:", "socks4:", and
   "socks5h".

Candidates for GPG_ERR_BAD_URI ("Syntax error in URI") are:

 - Well, a syntax errors.  Like bad characters, being longer that about
   10000 characters, bad escape sequences, or a binary Nul after
   de-escaping.


Sorry, for not beeing abale to provide more help.  Stepping though the
code would be the fastest way to track it down.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200325/7e726a6c/attachment.sig>

From dkg at fifthhorseman.net  Thu Mar 26 13:45:46 2020
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 26 Mar 2020 08:45:46 -0400
Subject: [PATCH] Add rpath so the Qt libs are found at runtime
In-Reply-To: <2017691.irdbgypaU6@asterixp50>
References: <2017691.irdbgypaU6@asterixp50>
Message-ID: <87bloj8eth.fsf@fifthhorseman.net>

On Sun 2019-12-22 10:11:56 +0100, David Faure wrote:
> Subject: [PATCH] Add rpath so the Qt libs are found at runtime
>
> This is necessary when Qt is installed into a custom prefix.
 [?]
> --- a/m4/qt.m4
> +++ b/m4/qt.m4
> @@ -57,6 +57,11 @@ AC_DEFUN([FIND_QT],
>        PINENTRY_QT_CFLAGS="$PINENTRY_QT_CFLAGS -std=c++11"
>      fi
>  
> +    qtlibdir=`"$PKG_CONFIG" --variable libdir Qt5Core`
> +    if test -n "$qtlibdir"; then
> +        PINENTRY_QT_LDFLAGS="$PINENTRY_QT_LDFLAGS -Wl,-rpath \"$qtlibdir\""
> +    fi
> +

hm, this *isn't* actually necessary on some platforms (debian, at least)
where "pkg-config --variable libdir Qt5Core" is non-empty.

    0 dkg at alice:~$ pkg-config --variable libdir Qt5Core
    /usr/lib/x86_64-linux-gnu
    0 dkg at alice:~$ 

(pinentry-qt does work fine on debian, without this patch)

Furthermore, RPATH is discouraged on debian, and has been for ages.
Details here:

    https://wiki.debian.org/RpathIssue

I'd rather not have to revert this patch in debian; is there some better
test that can be used?  or can we add a flag to configure that will
avoid setting rpath?

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200326/3a865be2/attachment-0001.sig>

From dkg at fifthhorseman.net  Thu Mar 26 14:44:48 2020
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 26 Mar 2020 09:44:48 -0400
Subject: [BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6
In-Reply-To: <1584631503.3610.14.camel@HansenPartnership.com>
References: <1584573751.3504.36.camel@HansenPartnership.com>
 <87d098d7zr.fsf@wheatstone.g10code.de>
 <1584631279.3610.11.camel@HansenPartnership.com>
 <1584631503.3610.14.camel@HansenPartnership.com>
Message-ID: <877dz78c33.fsf@fifthhorseman.net>

On Thu 2020-03-19 08:25:03 -0700, James Bottomley via Gnupg-devel wrote:
> On Thu, 2020-03-19 at 08:21 -0700, James Bottomley via Gnupg-devel wrote:
>> First reply is stuck in moderation.  This has the compressed gpgme
>> log
>
> I should add for the first reply that when I go in and run gpg manually
> over exactly the directories and files the gpgme code is using,
> verification succeeds, and when I try to do the same thing using a test
> programme built on gpgme everything also succeeds, so whatever is
> happening seems to be something to do with the sequence of prior
> operations zypper did.

Thanks for this log, James.

From the log, there are 5 gpgme invocations: gpgme_op_import,
gpgme_op_keylist, gpgme_op_import, gpgme_op_keylist, gpgme_op_verify.

It looks to me like the failure is in the final call to gpgme_op_verify.

In that call, gpgme is feeding the signature via fd 12 (0xc)
successfully to the spawned gpg process's fd 11.  This is correct, given
the first non-option argument -&11.  But it also needs to send the data
via fd 14 (0xe) to gpg's fd 13, given the second non-option argument
-&13.

However it looks like it feeds it the empty string instead of any data
that might have been signed:

GPGME 2020-03-19 08:19:04 <0x3839>    _gpgme_data_outbound_handler: enter: dh=0x55aada91b5c0, fd=0xe
GPGME 2020-03-19 08:19:04 <0x3839>      gpgme_data_read: enter: dh=0x55aada91b5c0, buffer=0x55aada91b5cc, size=4096
GPGME 2020-03-19 08:19:04 <0x3839>      gpgme_data_read: leave: result=0
GPGME 2020-03-19 08:19:04 <0x3839>      _gpgme_io_close: enter: fd=0xe
GPGME 2020-03-19 08:19:04 <0x3839>      _gpgme_io_close: check: fd=0xe, invoking close handler 0x7f1e4272bfe0/0x55aadaa39aa0
GPGME 2020-03-19 08:19:04 <0x3839>        _gpgme_remove_io_cb: call: data=0x55aada9ac5c0, setting fd 0xe (item=0x55aada8d2890) done
GPGME 2020-03-19 08:19:04 <0x3839>      _gpgme_io_close: leave: result=0
GPGME 2020-03-19 08:19:04 <0x3839>    _gpgme_data_outbound_handler: leave


Is it possible that the data object being passed to gpgme is corrupted
somehow?

Also, you say that zypper works if you revert this patch.  have you
tested this "working" configuration against a deliberately tampered
message body?  To test that it is working, it's best to verify both that
a valid message is accepted *and* that a tampered message is rejected.

This is gpg's status response, fwiw:

[GNUPG:] PROGRESS -&11 ? 0 0 B
[GNUPG:] PROGRESS -&11 ? 481 0 B
[GNUPG:] PROGRESS -&13 ? 0 0 B
[GNUPG:] NEWSIG
[GNUPG:] KEY_CONSIDERED F17A9BC0C01F2AEE49F779EE668EA451E1B7CFAD 0
[GNUPG:] KEY_CONSIDERED F17A9BC0C01F2AEE49F779EE668EA451E1B7CFAD 0
[GNUPG:] BADSIG 668EA451E1B7CFAD home:jejb1:Tumbleweed OBS Project <home:jejb1:Tumbleweed at build.opensuse.org>
[GNUPG:] VERIFICATION_COMPLIANCE_MODE 23
[GNUPG] FAILURE gpg-exit 33554433


I've looked at the libzypp codebase on
https://github.com/openSUSE/libzypp.git, and it seems that verification
is happening in KeyManagerCtx::Impl::readSignaturesFprsOptVerify in
zypp/KeyManager.cc.

It looks to me like that private function declaration is:

    std::list<std::string> readSignaturesFprsOptVerify( const Pathname & signature_r, const Pathname & file_r = "/dev/null", bool * verify_r = nullptr );

Note the default for file_r !

that's only called by two member functions:

    /** Return all fingerprints found in \a signature_r. */
    std::list<std::string> readSignaturesFprs( const Pathname & signature_r )
    { return readSignaturesFprsOptVerify( signature_r ); }

    /** Tries to verify the \a file_r using \a signature_r. */
    bool verifySignaturesFprs( const Pathname & file_r, const Pathname & signature_r )
    {
      bool verify = false;
      readSignaturesFprsOptVerify( signature_r, file_r, &verify );
      return verify;
    }

which are in turn implementations of
KeyManagerCtx::readSignatureFingerprints and KeyManagerCtx::verify.


Is the failure happening for you in a call to
KeyManagerCtx::readSignatureFingerprints or in a call to
KeyManagerCtx::verify ?  (or maybe KeyRing::readSignatureKeyId or
KeyRing::verifyFileSignature, which wrap those functions) ?

a backtrace of the code around the call to gpgme_op_verify would be
helpful.

Regards,

          --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200326/15fadc06/attachment.sig>

From dkg at fifthhorseman.net  Thu Mar 26 14:54:02 2020
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 26 Mar 2020 09:54:02 -0400
Subject: gpgsm --gen-key with existing key from "ssh-add" fails
Message-ID: <874kub8bnp.fsf@fifthhorseman.net>

This was originally reported over on https://dev.gnupg.org/T4892, but it
was requested to move it to the mailing list, so i'm repeating it here.

This was reported by a user on the #gnupg IRC channel on freenode.

With a fresh GNUPGHOME, and gpg-agent acting as ssh-agent:

    ssh-keygen -f ssh-key -N ''
    ssh-add ssh-key
    gpgsm --gen-key

then choose "existing key" and select the keygrip found in sshcontrol. The result is:

    Create self-signed certificate? (y/N) y
    These parameters are used:
        Key-Type: RSA
        Key-Length: 1024
        Key-Grip: 0B4329C87AD80CDCCA1D04C9F0B4FE11378A6F74
        Key-Usage: sign, encrypt
        Serial: random
        Name-DN: CN=Alice
        Name-Email: alice at example.biz

    Proceed with creation? (y/N) y
    Now creating self-signed certificate.  This may take a while ...
    gpgsm: error setting the public key: Invalid S-expression
    gpgsm: error creating certificate request: Invalid S-expression <KSBA>

note that the key created by ssh-key is 3072-bit RSA, not 1024.

Using nettle-bin's sexp-conv, i see:

    2 dkg at alice:/tmp/cdtemp.6ckvQX$ sexp-conv < private-keys-v1.d/A61AD73FB26752B4DAB90F007E6F76467659A19B.key 
    (protected-private-key (rsa (n |AL3C+/cNPCsJ+xKZXOG/u+f1eGM/VsMA7Gs7y1w/
                                    ki3y7fXeVCgV8KXaVQq/4ylfR04aXj3gsrmSDHYX
                                    KYBo69OoGx8tLhhi20ugMAc1qlRuMgmQZDjYGc8U
                                    m4ftOpwKoyKolfPV+PayoXQF0G7aeTC9+kmXxLfv
                                    ZD5DL8UWx/nFTly+5LctlQGshN1+1AZ6U9f4qdRi
                                    by2RpiMa7gdVD1M41RVm+Q2KoMYCs4WMeFgV4+Kj
                                    vxU32O8lLMQ+RpB6Z7Ra/756FeXyATrY7Q2hTGAd
                                    9V9X+vxupsX5MROlg1OfsSRClHVpK1kjiauM+0Zl
                                    oxXEBorRn+qZ51SrimXBaYlAri0zBw0HWg/cc1Xx
                                    pbxWqPrWh5rRrC+wukDG1XiM5LZdWBrZJiT0nYxZ
                                    hzczd9jgjj45XpvcrgK6uiXUWpYPpyjCRAVP/sW1
                                    ZVcm4x8RyYjuvwjh/vKg4F7kludEctnyavQI0utY
                                    62nwESLUuQhKgNvN23Th20iVXGMWOik1GQ==|)
                                (e |AQAB|)
                                (protected openpgp-s2k3-sha1-aes-cbc
                                           ((sha1 |aFmt6IeekIM=|
                                                  "72943616") |cT9DP9U3fOSXE
                                                               elRUvQW1Q==|)
                                           |2BrkPE2deaC3tf+d5rwG2x8QGdilAh+Z
                                            WOoHa/KVlZhvBBIFCfA8g12DamARZTZd
                                            MYIKcjIMDNTlj3I/xJZayzWcm5XliA0O
                                            WqvZJnedJWvjanHLWIu4z5ik+T85fL7E
                                            24/4nrQhTaTFtYo27cgdFgvGxeXbZx9f
                                            VCAhF/Kf12NHDkVEI3qMRBFNd0ofGeTq
                                            4xMtnGd0OfbSG2V51iK0GaexmW4ySkyt
                                            LYpyfMK4Tx/AdwZQAUacJqSs1/ZkoB+R
                                            hTAhW/EsWjHCYeuESZYizUZSuTX9vsGq
                                            If/bVZctTkGQ8jG0qjSpDY9qc8Kjf1wH
                                            ejN1L3qAvXwhDk1bSY+M5XuZ3WgYJgM5
                                            1XL02xQnJl4Eq60lfO9wkRqZEe56PcF+
                                            N4jpNwHcNAHHp58aROm9hsl7u3txAAu2
                                            4d59iGbzkZZFC+3EkC8AxHvhpMCN2vnL
                                            BH/3+THthzcJp4MA8GI5sGsjunHDesT4
                                            LYifUnk99+5bFeCtnnPCNc9kTUDWR0lY
                                            uGYJlmT7frIN+B2EYfaLvlVDlEkoUkM3
                                            aNP8OyViQpQEoLqpTI73/pDMMqOgJWPv
                                            9OgdPk21Ns0/MrKbHxnvKV1Kt7YOZiRI
                                            e7eHjs5PKp2Dk2KxDggwh4B+49o1N+4q
                                            ne/pizT8xNv0kfHaqFj6kfGSA2xevBUK
                                            tLUFvrtenTLV/WtuiLiB56xdG2rDPrmO
                                            VPyzw9B1j2AV2DEfQI6co88rUHO8pLVK
                                            FFqy5nMFnekUrqLITwmSZFPYW24Cf9os
                                            mpeZS/NXfbWITXY+A57mD4l5HGxq3+fu
                                            E5yYNaYoBYkWHTiYDZjdDU5XzU+XoO9A
                                            nFPYrP505dI5aN9QkOdH8HUFp7Qc+6za
                                            j/2MwrULF1BwzT8Lk+Zi6tKE1/K7jH1G
                                            kF5mDjvIfdJktcZU6pLzfIhLHG/egvzy
                                            dzliIDdS72mvsv9l5bWwxqhRNehXn43D
                                            lbSo8mGl1J70EXlXOlXaXnbW8tthlV9c
                                            IXUR1LLHsY5tXuw2UU+aAzlHDxWWlO58
                                            3UPhPUR+ESZCJ3c7uG1MPsIcphAOUVp1
                                            AuqIwYEA77mBvHMjHO1nW+7AS+vyNMOK
                                            iYCnHFZbvDCWHW+8VotsHwSc/8amILBy
                                            AESAbZllfu6nNYNOf4ai2BScUZPu3jNx
                                            /AhWiEK5Vqgv6xWrEi6Xx7/eTR0HhzXE
                                            U0/s5yfl7Rh9ax+2xWz00VEo5l2xHASX
                                            WDGTuhjREufMCgVwccxlMWMVLHiabYi8
                                            rKCtWDJp6c/DgSbGNz6Jy1IL40LPqjaJ
                                            viMmbQKnhmycMyCm+rVcKacVL1a9bYnZ
                                            yqrOplQm4DThEGPSVXn36W+8uSfgosJI
                                            ENvoCme0XnpozjnK5fBI3l1mLFcSvBtp
                                            7RG57f5s/MPNb+5MvrgPSM5xEoeXgyfC|)
                                (protected-at "20200326T010201"))
                           (comment "test at host"))


Any suggestions on what is going wrong here?

    --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200326/90acb16e/attachment.sig>

From dkg at fifthhorseman.net  Thu Mar 26 15:22:55 2020
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 26 Mar 2020 10:22:55 -0400
Subject: [Announce] GnuPG 2.2.18 released
In-Reply-To: <20191210014955.GA4106446@zeromail.org>
References: <87sgmbacmf.fsf@wheatstone.g10code.de>
 <20191130070027.GA3555115@zeromail.org>
 <20191210014955.GA4106446@zeromail.org>
Message-ID: <871rpf8abk.fsf@fifthhorseman.net>

On Tue 2019-12-10 02:49:55 +0100, ilf wrote:
> This is still present in 2.2.19. Do you disagree? Or should I open an 
> issue to track this?

Thanks, i've logged the report at https://dev.gnupg.org/T4893.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200326/0259022f/attachment.sig>

From look at my.amazin.horse  Thu Mar 26 16:27:51 2020
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Thu, 26 Mar 2020 16:27:51 +0100
Subject: Spelling (was: Correction of typo in documentation of KEY_CONSIDERED)
Message-ID: <3Q0J216DKDWCS.251PRM2E2AY4J@my.amazin.horse>


> Typos in source code comments are not relevant for the users and development
> is done on master were rarely done typo and grammar fixes for comments are
> acceptable.

I understand the feeling that these things are ultimately unimportant. But the
long term effect of this attitude is certainly noticeable in the codebase:

https://fossies.org/linux/misc/gnupg-2.2.20.tar.bz2/codespell.html

 - V


From James.Bottomley at HansenPartnership.com  Thu Mar 26 17:57:16 2020
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 26 Mar 2020 09:57:16 -0700
Subject: [BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6
In-Reply-To: <877dz78c33.fsf@fifthhorseman.net>
References: <1584573751.3504.36.camel@HansenPartnership.com>
 <87d098d7zr.fsf@wheatstone.g10code.de>
 <1584631279.3610.11.camel@HansenPartnership.com>
 <1584631503.3610.14.camel@HansenPartnership.com>
 <877dz78c33.fsf@fifthhorseman.net>
Message-ID: <1585241836.3610.27.camel@HansenPartnership.com>

On Thu, 2020-03-26 at 09:44 -0400, Daniel Kahn Gillmor wrote:
> On Thu 2020-03-19 08:25:03 -0700, James Bottomley via Gnupg-devel
> wrote:
> > On Thu, 2020-03-19 at 08:21 -0700, James Bottomley via Gnupg-devel
> > wrote:
> > > First reply is stuck in moderation.  This has the compressed
> > > gpgme log
> > 
> > I should add for the first reply that when I go in and run gpg
> > manually over exactly the directories and files the gpgme code is
> > using, verification succeeds, and when I try to do the same thing
> > using a test programme built on gpgme everything also succeeds, so
> > whatever is happening seems to be something to do with the sequence
> > of prior operations zypper did.
> 
> Thanks for this log, James.

There are actually more details in the email that's stuck in moderation
if you can unstick it ... it's only about 40k over the list limit.

> From the log, there are 5 gpgme invocations: gpgme_op_import,
> gpgme_op_keylist, gpgme_op_import, gpgme_op_keylist, gpgme_op_verify.
> 
> It looks to me like the failure is in the final call to
> gpgme_op_verify.
> 
> In that call, gpgme is feeding the signature via fd 12 (0xc)
> successfully to the spawned gpg process's fd 11.  This is correct,
> given the first non-option argument -&11.  But it also needs to send
> the data via fd 14 (0xe) to gpg's fd 13, given the second non-option
> argument -&13.
> 
> However it looks like it feeds it the empty string instead of any
> data that might have been signed:
> 
> GPGME 2020-03-19 08:19:04 <0x3839>    _gpgme_data_outbound_handler:
> enter: dh=0x55aada91b5c0, fd=0xe
> GPGME 2020-03-19 08:19:04 <0x3839>      gpgme_data_read: enter:
> dh=0x55aada91b5c0, buffer=0x55aada91b5cc, size=4096
> GPGME 2020-03-19 08:19:04 <0x3839>      gpgme_data_read: leave:
> result=0
> GPGME 2020-03-19 08:19:04 <0x3839>      _gpgme_io_close: enter:
> fd=0xe
> GPGME 2020-03-19 08:19:04 <0x3839>      _gpgme_io_close: check:
> fd=0xe, invoking close handler 0x7f1e4272bfe0/0x55aadaa39aa0
> GPGME 2020-03-19 08:19:04 <0x3839>        _gpgme_remove_io_cb: call:
> data=0x55aada9ac5c0, setting fd 0xe (item=0x55aada8d2890) done
> GPGME 2020-03-19 08:19:04 <0x3839>      _gpgme_io_close: leave:
> result=0
> GPGME 2020-03-19 08:19:04 <0x3839>    _gpgme_data_outbound_handler:
> leave
> 
> 
> Is it possible that the data object being passed to gpgme is
> corrupted somehow?

It must be ... and it's something to do with the sequence, not just
individual signatures.  All the test cases I constructed so far using
exactly the same data as zypper pass just fine.

> Also, you say that zypper works if you revert this patch.  have you
> tested this "working" configuration against a deliberately tampered
> message body?  To test that it is working, it's best to verify both
> that a valid message is accepted *and* that a tampered message is
> rejected.

I can check ... I just have to set up a corrupt repo, hang on.

> This is gpg's status response, fwiw:
> 
> [GNUPG:] PROGRESS -&11 ? 0 0 B
> [GNUPG:] PROGRESS -&11 ? 481 0 B
> [GNUPG:] PROGRESS -&13 ? 0 0 B
> [GNUPG:] NEWSIG
> [GNUPG:] KEY_CONSIDERED F17A9BC0C01F2AEE49F779EE668EA451E1B7CFAD 0
> [GNUPG:] KEY_CONSIDERED F17A9BC0C01F2AEE49F779EE668EA451E1B7CFAD 0
> [GNUPG:] BADSIG 668EA451E1B7CFAD home:jejb1:Tumbleweed OBS Project
> <home:jejb1:Tumbleweed at build.opensuse.org>
> [GNUPG:] VERIFICATION_COMPLIANCE_MODE 23
> [GNUPG] FAILURE gpg-exit 33554433
> 
> 
> I've looked at the libzypp codebase on
> https://github.com/openSUSE/libzypp.git, and it seems that
> verification
> is happening in KeyManagerCtx::Impl::readSignaturesFprsOptVerify in
> zypp/KeyManager.cc.
> 
> It looks to me like that private function declaration is:
> 
>     std::list<std::string> readSignaturesFprsOptVerify( const
> Pathname & signature_r, const Pathname & file_r = "/dev/null", bool *
> verify_r = nullptr );
> 
> Note the default for file_r !
> 
> that's only called by two member functions:
> 
>     /** Return all fingerprints found in \a signature_r. */
>     std::list<std::string> readSignaturesFprs( const Pathname &
> signature_r )
>     { return readSignaturesFprsOptVerify( signature_r ); }
> 
>     /** Tries to verify the \a file_r using \a signature_r. */
>     bool verifySignaturesFprs( const Pathname & file_r, const
> Pathname & signature_r )
>     {
>       bool verify = false;
>       readSignaturesFprsOptVerify( signature_r, file_r, &verify );
>       return verify;
>     }
> 
> which are in turn implementations of
> KeyManagerCtx::readSignatureFingerprints and KeyManagerCtx::verify.
> 
> 
> Is the failure happening for you in a call to
> KeyManagerCtx::readSignatureFingerprints or in a call to
> KeyManagerCtx::verify ?  (or maybe KeyRing::readSignatureKeyId or
> KeyRing::verifyFileSignature, which wrap those functions) ?
> 
> a backtrace of the code around the call to gpgme_op_verify would be
> helpful.

It's in the missing email ... if you can't free it from moderation, I
can break it up.

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200326/e737dccc/attachment.sig>

From look at my.amazin.horse  Thu Mar 26 18:10:43 2020
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Thu, 26 Mar 2020 18:10:43 +0100
Subject: hkp4py hkp|hkps bindings for python.
In-Reply-To: <8ffd54f6-2a86-e193-c8e4-f25e353263ff@selfnet.de>
References: <8ffd54f6-2a86-e193-c8e4-f25e353263ff@selfnet.de>
 <7c28519a-6ea7-b705-f749-6ad0a6e74df7@selfnet.de>
Message-ID: <2UHNFX5J5WT5R.2J2WD4CG67ZW6@my.amazin.horse>


Hi Marcel,

thanks for working on VKS support :)

> Can someone look into it. I am currently curious if it breaks current stuff.
> https://github.com/Selfnet/hkp4py/tree/feature/gpg-vks

Looks good to me, only remarks I have is you probably don't need to quote the
key id, and the "host" variable should be called "baseURI" or something, "if not
host.startswith("hkp"):" looks odd. On that last bit, checks like that should
always include the :, you don't want to match an "hkpkpkp" schema.

The "vks" schema is kind of an informal thing that comes from Enigmail.
I wonder if we should adopt it (slightly) more formally in our API docs.

> I also want to know if hkp4py`s further releases need to support python
> 2.7.x and python 3.5.x and older.

python2 is EOL, and projects that still rely on it shouldn't invest development
time into anything other than fixing that.

Cheers!

 - V


From dkg at fifthhorseman.net  Fri Mar 27 05:09:58 2020
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 27 Mar 2020 00:09:58 -0400
Subject: Remote forwarding gnupg extra-socket?
In-Reply-To: <b8ca7450-6a48-f301-182b-27aebeece85b@andrewg.com>
References: <b8ca7450-6a48-f301-182b-27aebeece85b@andrewg.com>
Message-ID: <87tv2a7815.fsf@fifthhorseman.net>

Hi Andrew--

On Mon 2020-03-09 13:02:55 +0000, Andrew Gallagher wrote:
> It used to be that we could tell gpg-agent to create an extra-socket
> (with restricted functionality) and then tell ssh to forward that socket
> to a remote machine, giving gpg an equivalent agent forwarding
> functionality to that of ssh.

the extra-socket is created automatically these days, and doesn't need
to be enabled explicitly.

> In fact, you can still configure all of the above, but doing so is now
> next to useless. Since v2.1 there is no way to tell the remote gpg
> instance to use a non-default socket, and there is no reliable way to
> tell ssh to mount the forwarded socket on the default location -- the
> default is now under XDG_RUNTIME_DIR which is unpredictable in
> principle, and ssh does not allow the use of remote envars in
> RemoteForward directives.

There has been some discussion about this over on the SSH bugtracker:

https://bugzilla.mindrot.org/show_bug.cgi?id=3018
https://bugzilla.mindrot.org/show_bug.cgi?id=2740
https://bugzilla.mindrot.org/show_bug.cgi?id=3014
https://bugzilla.mindrot.org/show_bug.cgi?id=3140

> Can we please PLEASE have GPG_AGENT_SOCK back in the short term?

I'm not convinced that this is a good idea; more configurability means
more ways that people can break their setups, and debugging is even
harder.

> In the long term, it might be more productive to overload ssh-agent. IFF
> the forwarded ssh-agent is really a gnupg-agent with enable-ssh-support,
> it could optionally support a protocol extension allowing it to tunnel
> extra-socket commands back to the originating gpg-agent over the
> ssh-agent connection. The gpg on the remote machine could then test for
> this protocol extension and if found use the ssh-agent socket instead.
> This would remove the need for any custom ssh shenanigans (which only
> sort-of work, even now).
>
> The ssh-agent protocol allows for vendor-specific protocol extensions,
> which would appear to be perfectly suited for this:
>
> https://tools.ietf.org/id/draft-miller-ssh-agent-01.html#rfc.section.4.7

this is a very interesting suggestion, but i'm not sure exactly how it
would work.  can you describe it in more detail?  At the beginning of
this message, it looks like you were talking about forwarding the
extra-socket, and now it looks like you're talking about forwarding the
ssh-agent emulation.  Are you talking about the same concern here?
they're (at least subtly) different.

Also, how is the remote gpg-agent supposed to know that there is some
other backend it should talk to (for either ssh-agent or any of the
gpg-agent sockets)?

          --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/d3c04b3a/attachment.sig>

From dkg at fifthhorseman.net  Fri Mar 27 05:21:41 2020
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 27 Mar 2020 00:21:41 -0400
Subject: [PATCH] Add rpath so the Qt libs are found at runtime
In-Reply-To: <5598651.lOV4Wx5bFT@asterixp50>
References: <2017691.irdbgypaU6@asterixp50> <87bloj8eth.fsf@fifthhorseman.net>
 <5598651.lOV4Wx5bFT@asterixp50>
Message-ID: <87r1xe77hm.fsf@fifthhorseman.net>

On Thu 2020-03-26 22:36:28 +0100, David Faure wrote:
>  - provide a way to turn it all off

this sounds a lot simpler than trying to guess whether a given library
path is expected to be a system path.  I'd even argue for default-off
(not default-on), but i could live with either.

I'd really rather avoid having to patch the pinentry sources to avoid
this though.

> Unfortunately my autoconf abilities are too limited for me to provide this....

Perhaps wrapping the line in configure.ac with an "--with-qt-rpath" flag
or something?  I would also happily yield to someone with better
autoconf skills than myself here.

> I could provide a cmake port though ;-)

no comment ;)

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/e940a448/attachment.sig>

From dkg at fifthhorseman.net  Fri Mar 27 05:23:59 2020
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 27 Mar 2020 00:23:59 -0400
Subject: [BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6
In-Reply-To: <1585241836.3610.27.camel@HansenPartnership.com>
References: <1584573751.3504.36.camel@HansenPartnership.com>
 <87d098d7zr.fsf@wheatstone.g10code.de>
 <1584631279.3610.11.camel@HansenPartnership.com>
 <1584631503.3610.14.camel@HansenPartnership.com>
 <877dz78c33.fsf@fifthhorseman.net>
 <1585241836.3610.27.camel@HansenPartnership.com>
Message-ID: <87o8si77ds.fsf@fifthhorseman.net>

On Thu 2020-03-26 09:57:16 -0700, James Bottomley wrote:
> It's in the missing email ... if you can't free it from moderation, I
> can break it up.

I don't have any control over the mailing list,  but feel free to send
me details privately if you like.  or break up the pieces and send them
as individual messages to this thread.  that seems a little silly, but
so it goes.

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/5281b0ff/attachment-0001.sig>

From James.Bottomley at HansenPartnership.com  Thu Mar 19 16:17:18 2020
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 19 Mar 2020 08:17:18 -0700
Subject: [BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6
In-Reply-To: <87d098d7zr.fsf@wheatstone.g10code.de>
References: <1584573751.3504.36.camel@HansenPartnership.com>
 <87d098d7zr.fsf@wheatstone.g10code.de>
Message-ID: <1584631038.3610.10.camel@HansenPartnership.com>

On Thu, 2020-03-19 at 10:11 +0100, Werner Koch wrote:
> On Wed, 18 Mar 2020 16:22, James Bottomley said:
> 
> >     gpg: Relax printing of STATUS_FAILURE.
> 
> That is a followup patch for fixing https://dev.gnupg.org/T3872
> 
> commit 0336e5d1a7b9d46e06c838e6a98aecfcc9542882
> Author:     Werner Koch <wk at gnupg.org>
> AuthorDate: Fri Apr 6 17:32:08 2018 +0200
> 
>     gpg: Emit FAILURE stati now in almost all cases.
>     
>     * g10/cpr.c (write_status_failure): Make it print only once.
>     * g10/gpg.c (wrong_args): Bump error counter.
>     (g10_exit): Print a FAILURE status if we ever did a log_error
> etc.
>     (main): Use log_error instead of log_fatal at one place.  Print a
>     FAILURE status for a bad option.  Ditto for certain exit points
> so
>     that we can see different error locations.
>     --
>     
>     This makes it easier to detect errors by tools which have no way
> to
>     get the exit code (e.g. due to double forking).
> 
> Can you please give me a pointer to libzypp so that I can check what
> is done there?

Yes, it's here:

https://github.com/openSUSE/libzypp

Pretty much all of the key management and signature checking is in

zypp/KeyManager.cc
zypp/KeyRing.cc

> Running
> 
>   GPGME_DEBUG=9:/foo/bar/gpgme.log  zypper
> 
> should give a large tracefile; I can can have a look at it if you
> like.

I can get that for you (it's huge, it was the first thing I tried, but
I couldn't even get it to pinpoint the failure.  I'll send it under a
separate email).  But the way I debugged the issue was to couple the
output of the zypper log (which has quite a few convenient debug
statements) to an strace -s 256 -f which shows the commands going over
the gpg socket.

I've attached the full zypper log of

zypper ref -f

which forces zypper to download every repo.  It stops at the first repo
 signature check.  The relevant line is this one second from bottom:

2020-03-19 08:08:14 <3> jarvis.int.hansenpartnership.com(13858) [zypp::gpg] KeyManager.cc(readSignaturesFprsOptVerify):174 <GnuPG> General error

Which is coming from the gpgme_op_verify in KeyManager.cc

Strace tells me this is what zypper is seeing (22822 is the zypper process and 22869 is gpg2 under gpgme control):

22822 <... select resumed> )            = 1 (in [8], left {tv_sec=0, tv_usec=0})
22869 <... open resumed> )              = 3
22822 read(8,  <unfinished ...>
22869 fstat(3,  <unfinished ...>
22822 <... read resumed> "[GNUPG:] NEWSIG\n", 1024) = 16
22869 <... fstat resumed> {st_mode=S_IFREG|0644, st_size=2836, ...}) = 0
22822 select(9, [8], [], NULL, {tv_sec=1, tv_usec=0} <unfinished ...>
22869 fstat(3, {st_mode=S_IFREG|0644, st_size=2836, ...}) = 0
22869 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 2836
22869 lseek(3, -1802, SEEK_CUR)         = 1034
22869 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 1802
22869 close(3)                          = 0
22869 write(2, "gpg: Signature made Fri Mar 13 1"..., 48) = 48
22869 write(2, "\n", 1)                 = 1
22869 write(2, "gpg:                using RSA ke"..., 50) = 50
22869 write(2, "\n", 1)                 = 1
22869 openat(AT_FDCWD, "/var/tmp/zypp.PPpVVx/PublicKey/pubring.kbx", O_RDONLY) = 3
22869 lseek(3, 0, SEEK_CUR)             = 0
22869 fstat(3, {st_mode=S_IFREG|0644, st_size=937, ...}) = 0
22869 read(3, "\0\0\0 \1\1\0\2KBXf\0\0\0\0^p\tM^p\tM\0\0\0\0\0\0\0\0"..., 4096) = 937
22869 lseek(3, 0, SEEK_CUR)             = 937
22869 write(9, "[GNUPG:] KEY_CONSIDERED F17A9BC0"..., 67 <unfinished ...>
22822 <... select resumed> )            = 1 (in [8], left {tv_sec=0, tv_usec=999217})
22869 <... write resumed> )             = 67
22822 select(9, [8], [], NULL, {tv_sec=0, tv_usec=0}) = 1 (in [8], left {tv_sec=0, tv_usec=0})
22822 read(8, "[GNUPG:] KEY_CONSIDERED F17A9BC0"..., 1024) = 67
22822 select(9, [8], [], NULL, {tv_sec=1, tv_usec=0} <unfinished ...>
22869 openat(AT_FDCWD, "/var/tmp/zypp.PPpVVx/PublicKey/pubring.kbx", O_RDONLY) = 4
22869 lseek(4, 0, SEEK_CUR)             = 0
22869 fstat(4, {st_mode=S_IFREG|0644, st_size=937, ...}) = 0
22869 read(4, "\0\0\0 \1\1\0\2KBXf\0\0\0\0^p\tM^p\tM\0\0\0\0\0\0\0\0"..., 4096) = 937
22869 lseek(4, 0, SEEK_CUR)             = 937
22869 write(9, "[GNUPG:] KEY_CONSIDERED F17A9BC0"..., 67 <unfinished ...>
22822 <... select resumed> )            = 1 (in [8], left {tv_sec=0, tv_usec=999504})
22869 <... write resumed> )             = 67
22822 select(9, [8], [], NULL, {tv_sec=0, tv_usec=0} <unfinished ...>
22869 close(4 <unfinished ...>
22822 <... select resumed> )            = 1 (in [8], left {tv_sec=0, tv_usec=0})
22869 <... close resumed> )             = 0
22822 read(8, "[GNUPG:] KEY_CONSIDERED F17A9BC0"..., 1024) = 67
22869 stat("/var/tmp/zypp.PPpVVx/PublicKey/trustdb.gpg",  <unfinished ...>
22822 select(9, [8], [], NULL, {tv_sec=1, tv_usec=0} <unfinished ...>
22869 <... stat resumed> {st_mode=S_IFREG|0600, st_size=1200, ...}) = 0
22869 openat(AT_FDCWD, "/var/tmp/zypp.PPpVVx/PublicKey/trustdb.gpg", O_RDWR) = 4
22869 lseek(4, 0, SEEK_SET)             = 0
22869 read(4, "\1gpg\3\3\1\5\1\2\0\0^p\tM\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 0, SEEK_SET)             = 0
22869 read(4, "\1gpg\3\3\1\5\1\2\0\0^p\tM\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 40, SEEK_SET)            = 40
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 80, SEEK_SET)            = 80
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 120, SEEK_SET)           = 120
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 160, SEEK_SET)           = 160
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 200, SEEK_SET)           = 200
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 240, SEEK_SET)           = 240
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 280, SEEK_SET)           = 280
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 320, SEEK_SET)           = 320
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 360, SEEK_SET)           = 360
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 400, SEEK_SET)           = 400
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 440, SEEK_SET)           = 440
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 480, SEEK_SET)           = 480
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 520, SEEK_SET)           = 520
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 560, SEEK_SET)           = 560
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 600, SEEK_SET)           = 600
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 640, SEEK_SET)           = 640
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 680, SEEK_SET)           = 680
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 720, SEEK_SET)           = 720
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 760, SEEK_SET)           = 760
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 800, SEEK_SET)           = 800
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 840, SEEK_SET)           = 840
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 880, SEEK_SET)           = 880
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 920, SEEK_SET)           = 920
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 960, SEEK_SET)           = 960
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 1000, SEEK_SET)          = 1000
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 1040, SEEK_SET)          = 1040
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 1080, SEEK_SET)          = 1080
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 1120, SEEK_SET)          = 1120
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 1160, SEEK_SET)          = 1160
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 1200, SEEK_SET)          = 1200
22869 read(4, "", 40)                   = 0
22869 lseek(4, 0, SEEK_SET)             = 0
22869 read(4, "\1gpg\3\3\1\5\1\2\0\0^p\tM\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 0, SEEK_SET)             = 0
22869 read(4, "\1gpg\3\3\1\5\1\2\0\0^p\tM\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 0, SEEK_SET)             = 0
22869 read(4, "\1gpg\3\3\1\5\1\2\0\0^p\tM\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 lseek(4, 1080, SEEK_SET)          = 1080
22869 read(4, "\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
22869 write(9, "[GNUPG:] BADSIG 668EA451E1B7CFAD"..., 110) = 110
22822 <... select resumed> )            = 1 (in [8], left {tv_sec=0, tv_usec=996542})
22869 write(2, "gpg: BAD signature from \"home:je"..., 111 <unfinished ...>
22822 select(9, [8], [], NULL, {tv_sec=0, tv_usec=0} <unfinished ...>
22869 <... write resumed> )             = 111
22822 <... select resumed> )            = 1 (in [8], left {tv_sec=0, tv_usec=0})
22869 write(2, "]\n", 2 <unfinished ...>
22822 read(8,  <unfinished ...>
22869 <... write resumed> )             = 2
22822 <... read resumed> "[GNUPG:] BADSIG 668EA451E1B7CFAD"..., 1024) = 110
22869 write(9, "[GNUPG:] VERIFICATION_COMPLIANCE"..., 41 <unfinished ...>
22822 select(9, [8], [], NULL, {tv_sec=1, tv_usec=0} <unfinished ...>
22869 <... write resumed> )             = 41
22822 <... select resumed> )            = 1 (in [8], left {tv_sec=0, tv_usec=999998})
22869 write(9, "[GNUPG:] FAILURE gpg-exit 335544"..., 35 <unfinished ...>

James

---

2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] main.cc(main):97 ===== Hi, me zypper 1.14.33
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] main.cc(main):98 ===== 'zypper' 'ref' '-f' =====
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zconfig] ZConfig.cc(_autodetectSystemArchitecture):73 Uname architecture is 'x86_64'
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zconfig] ZConfig.cc(_autodetectTextLocale):202 Found LANG=en_US.UTF-8
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zconfig] ZConfig.cc(_autodetectTextLocale):209 Default text locale is 'en_US'
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zconfig] ZConfig.cc(Impl):342 libzypp: 17.19.0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/zypp.conf[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/zypp.conf[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#1|/etc/zypp/zypp.conf}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zconfig] ZConfig.cc(Impl):618 ZConfig singleton created.
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zconfig] ZConfig.cc(ZConfig):819 libzypp: 17.19.0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zconfig] ZConfig.cc(ZConfig):819 libsolv: 0.7.10
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zconfig] ZConfig.cc(ZConfig):819 zypp.conf: '/etc/zypp/zypp.conf'
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zconfig] ZConfig.cc(ZConfig):819 TextLocale: 'en_US' (en_US)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zconfig] ZConfig.cc(ZConfig):819 SystemArchitecture: 'x86_64' (x86_64)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(assert_dir):354 mkdir /var/tmp/zypp.SwKyrE/zypper 00755
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] Zypper.cc(Zypper):189 Zypper instance created.
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] media.h(MediaCallbacks):204 Set media callbacks..
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] Zypper.cc(processGlobalOptions):300 START
2020-03-19 08:08:12 <5> jarvis.int.hansenpartnership.com(13858) [Measure] Measure.cc(log):178 START MEASURE(ReadConfig)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] Augeas.cc(Augeas):539 Going to read zypper config using Augeas...
2020-03-19 08:08:12 <2> jarvis.int.hansenpartnership.com(13858) [zypper] Augeas.cc(Augeas):607 MISS config file: /root/.zypper.conf
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] Augeas.cc(Augeas):601 READ config file: /etc/zypp/zypper.conf
2020-03-19 08:08:12 <5> jarvis.int.hansenpartnership.com(13858) [Measure] Measure.cc(log):178 ELAPSED(ReadConfig) 0 (u 0.01 s 0.00 c 0.00)
2020-03-19 08:08:12 <5> jarvis.int.hansenpartnership.com(13858) [Measure] Measure.cc(log):178 MEASURE(ReadConfig) 0 (u 0.01 s 0.00 c 0.00) [0 (u 0.00 s 0.00 c 0.00)]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper++] Zypper.cc(processGlobalOptions):311 Verbosity 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper++] Zypper.cc(processGlobalOptions):312 Output type 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper++] Zypper.cc(processGlobalOptions):350 repos.d dir = /etc/zypp/repos.d
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper++] Zypper.cc(processGlobalOptions):351 cache dir = /var/cache/zypp
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper++] Zypper.cc(processGlobalOptions):352 raw cache dir = /var/cache/zypp/raw
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper++] Zypper.cc(processGlobalOptions):353 solv cache dir = /var/cache/zypp/solv
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper++] Zypper.cc(processGlobalOptions):354 package cache dir = /var/cache/zypp/packages
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] Zypper.cc(processGlobalOptions):358 Repositories enabled
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] Zypper.cc(processGlobalOptions):361 DONE
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] Zypper.cc(doCommand):487 START
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ZYppFactory.cc(_openLockFile):168 Open lockfile /var/run/zypp.pid
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ZYppFactory.cc(readLockFile):223 read: Lockfile /var/run/zypp.pid has pid 0 (our pid: 13858) 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ZYppFactory.cc(writeLockFile):235 write: Lockfile /var/run/zypp.pid got pid 13858
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ZYppFactory.cc(_closeLockFile):186 Close lockfile /var/run/zypp.pid
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ZYppImpl.cc(ZYppImpl):71 libzypp: 17.19.0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ZYppImpl.cc(ZYppImpl):71 libsolv: 0.7.10
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ZYppImpl.cc(ZYppImpl):71 zypp.conf: '/etc/zypp/zypp.conf'
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ZYppImpl.cc(ZYppImpl):71 TextLocale: 'en_US' (en_US)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ZYppImpl.cc(ZYppImpl):71 SystemArchitecture: 'x86_64' (x86_64)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ZYppImpl.cc(ZYppImpl):72 Initializing keyring...
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(Impl):188 Current KeyRing::DefaultAccept: 0000000000
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ZYppFactory.cc(ZYpp):312 ZYpp is on...
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] Zypper.cc(doCommand):629 Going to process command refresh
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] Zypper.cc(doCommand):638 Found new style command << refresh
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] basecommand.cc(parseArguments):124 Done parsing options.
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] basecommand.cc(run):239 run: refresh
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper++] basecommand.cc(defaultSystemSetup):163 FLAGS:[ResetRepoManager]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(dirForEach):553 readdir /etc/zypp/services.d 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(dirForEach):553 readdir /usr/lib/zypp/plugins/services 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(init_knownRepositories):829 start construct known repos
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_dir):307 directory /etc/zypp/repos.d
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(dirForEach):553 readdir /etc/zypp/repos.d 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/repo-update.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/repo-update.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/repo-update.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#2|/etc/zypp/repos.d/repo-update.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : repo-update
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - name        : openSUSE-Leap-15.1-Update
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://download.opensuse.org/update/leap/15.1/oss/
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - path        : /
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : rpm-md
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : D(Y) repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - keeppackages: 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/repo-update.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/repo-update-non-oss.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/repo-update-non-oss.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/repo-update-non-oss.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#3|/etc/zypp/repos.d/repo-update-non-oss.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : repo-update-non-oss
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - name        : openSUSE-Leap-15.1-Update-Non-Oss
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://download.opensuse.org/update/leap/15.1/non-oss/
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - path        : /
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : rpm-md
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : D(Y) repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - keeppackages: 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/repo-update-non-oss.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/repo-non-oss.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/repo-non-oss.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/repo-non-oss.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#4|/etc/zypp/repos.d/repo-non-oss.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : repo-non-oss
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - name        : openSUSE-Leap-15.1-Non-Oss
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - path        : /
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : rpm-md
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : D(Y) repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - keeppackages: 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/repo-non-oss.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/repo-debug.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/repo-debug.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/repo-debug.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#5|/etc/zypp/repos.d/repo-debug.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : repo-debug
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - name        : openSUSE-Leap-15.1-Debug
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://download.opensuse.org/debug/distribution/leap/15.1/repo/oss/
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - path        : /
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : rpm-md
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : D(Y) repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - keeppackages: 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/repo-debug.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/repo-debug-non-oss.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/repo-debug-non-oss.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/repo-debug-non-oss.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#6|/etc/zypp/repos.d/repo-debug-non-oss.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : repo-debug-non-oss
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - name        : openSUSE-Leap-15.1-Debug-Non-Oss
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://download.opensuse.org/debug/distribution/leap/15.1/repo/non-oss/
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - path        : /
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : NONE
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : D(Y) repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - keeppackages: 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/repo-debug-non-oss.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/repo-debug-update.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/repo-debug-update.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/repo-debug-update.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#7|/etc/zypp/repos.d/repo-debug-update.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : repo-debug-update
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - name        : openSUSE-Leap-15.1-Update-Debug
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://download.opensuse.org/debug/update/leap/15.1/oss/
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - path        : /
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : rpm-md
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : D(Y) repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - keeppackages: 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/repo-debug-update.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/repo-debug-update-non-oss.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/repo-debug-update-non-oss.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/repo-debug-update-non-oss.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#8|/etc/zypp/repos.d/repo-debug-update-non-oss.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : repo-debug-update-non-oss
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - name        : openSUSE-Leap-15.1-Update-Debug-Non-Oss
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://download.opensuse.org/debug/update/leap/15.1/non-oss/
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - path        : /
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : NONE
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : D(Y) repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - keeppackages: 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/repo-debug-update-non-oss.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/repo-source.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/repo-source.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/repo-source.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#9|/etc/zypp/repos.d/repo-source.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : repo-source
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - name        : openSUSE-Leap-15.1-Source
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://download.opensuse.org/source/distribution/leap/15.1/repo/oss/
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - path        : /
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : NONE
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : D(Y) repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - keeppackages: 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/repo-source.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/repo-source-non-oss.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/repo-source-non-oss.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/repo-source-non-oss.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#10|/etc/zypp/repos.d/repo-source-non-oss.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : repo-source-non-oss
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - name        : openSUSE-Leap-15.1-Source-Non-Oss
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://download.opensuse.org/source/distribution/leap/15.1/repo/non-oss/
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - path        : /
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : NONE
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : D(Y) repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - keeppackages: 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/repo-source-non-oss.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/packman.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/packman.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/packman.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#11|/etc/zypp/repos.d/packman.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : packman
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.1/
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : rpm-md
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : D(Y) repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/packman.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/jejb-tumbleweed.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/jejb-tumbleweed.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/jejb-tumbleweed.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#12|/etc/zypp/repos.d/jejb-tumbleweed.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : jejb-tumbleweed
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - name        : jejb-tumbleweed
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : rpm-md
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : Y repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/jejb-tumbleweed.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/jejb-tumbleweed-gnome.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/jejb-tumbleweed-gnome.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/jejb-tumbleweed-gnome.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#13|/etc/zypp/repos.d/jejb-tumbleweed-gnome.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : jejb-tumbleweed-gnome
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - name        : jejb-tumbleweed-gnome
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed:/gnome-leap-15/openSUSE_Leap_15.1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : rpm-md
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : D(Y) repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/jejb-tumbleweed-gnome.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(repositories_in_file):289 repo file: /etc/zypp/repos.d/repo-install.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):84 Start parsing /etc/zypp/repos.d/repo-install.repo[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] IniParser.cc(parse):138 Done parsing /etc/zypp/repos.d/repo-install.repo[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#14|/etc/zypp/repos.d/repo-install.repo}END
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 --------------------------------------
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - alias       : repo-install
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - name        : openSUSE-Leap-15.1-1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - enabled     : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - autorefresh : 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - url         : http://download.opensuse.org/distribution/leap/15.1/repo/oss/
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - path        : /
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - type        : rpm-md
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - priority    : 99
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - gpgcheck    : D(Y) repoD(Y)* sig? pkgD(Y)* 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - keeppackages: 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 - filePath:     /etc/zypp/repos.d/repo-install.repo
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoFileReader.cc(repositories_in_stream):191 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(dirForEach):553 readdir /var/cache/zypp/raw 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(dirForEach):553 readdir /var/cache/zypp/solv 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(dirForEach):553 readdir /var/cache/zypp/packages 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(init_knownRepositories):889 end construct known repos
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] refresh.cc(execute):132 going to refresh repositories
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper++] basecommand.cc(defaultSystemSetup):163 FLAGS:[InitTarget]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] repos.cc(init_target):981 Initializing target
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ZYppImpl.cc(initializeTarget):122 initTarget( /)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb] librpmDb.cc(globalInit):148 librpm init done: (_target:x86_64-linux) (_dbpath:/usr/lib/sysimage/rpm)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb] RpmDb.cc(initDatabase):345 Calling initDatabase: '(/)/var/lib/rpm'
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb] librpmDb.cc(unblockAccess):344 Unblock access
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] librpmDb.cc(DbDirInfo):522 '(/)/var/lib/rpm':
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] librpmDb.cc(DbDirInfo):522   Dir:    /var/lib/rpm{d 0755 0/0}
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] librpmDb.cc(DbDirInfo):522   V4:     /var/lib/rpm/Packages{- 0644 0/0 size 227815424}
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] librpmDb.cc(DbDirInfo):522   V3:     /var/lib/rpm/packages.rpm{[2-No such file or directory]}
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] librpmDb.cc(DbDirInfo):522   V3ToV4: /var/lib/rpm/packages.rpm3{[2-No such file or directory]}
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb] RpmDb.cc(internal_initDatabase):468 Found rpm4 database in /var/lib/rpm{d 0755 0/0}
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] RpmDb.cc(internal_initDatabase):485 Initial state: V4(X--)V3(---): '(/)/var/lib/rpm'[librpmDb CLOSED '(/)/var/lib/rpm']
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb] librpmDb.cc(dbAccess):240 Set new database location: '(/)/var/lib/rpm'
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] librpmDb.cc(D):100 DBACCESS {NULL(/)/var/lib/rpm}
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] RpmDb.cc(internal_initDatabase):504 Access state: V4(X--)V3(---): '(/)/var/lib/rpm'[ReferenceCounted(@0x55c07fac1900<=1){NULL(/)/var/lib/rpm}]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] librpmDb.cc(dbRelease):311 dbRelease: release, outstanding 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb] RpmDb.cc(initDatabase):426 Synchronizing keys with zypp keyring
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb] RpmDb.cc(syncTrustedKeys):961 Going to sync trusted keys...
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] librpmDb.cc(D):100 DBACCESS {NULL(/)/var/lib/rpm}
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] librpmDb.cc(dbRelease):311 dbRelease: release, outstanding 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] RpmDb.cc(computeKeyRingSync):941 gpg-pubkey-1abd1afb-54176598 R_
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] RpmDb.cc(computeKeyRingSync):941 gpg-pubkey-307e3d54-5aaa90a5 R_
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] RpmDb.cc(computeKeyRingSync):941 gpg-pubkey-39db7c82-5847eb1f R_
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] RpmDb.cc(computeKeyRingSync):941 gpg-pubkey-3dbdc284-53674dd4 R_
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] RpmDb.cc(computeKeyRingSync):941 gpg-pubkey-e1b7cfad-5c52e23e R_
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb] RpmDb.cc(syncTrustedKeys):993 Rpm keys to export into zypp trusted keyring: 5
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb] RpmDb.cc(syncTrustedKeys):994 Zypp trusted keys to import into rpm database: 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb] RpmDb.cc(syncTrustedKeys):1000 Exporting rpm keyring into zypp trusted keyring
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] librpmDb.cc(D):100 DBACCESS {NULL(/)/var/lib/rpm}
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::gpg++] KeyManager.cc(createForOpenPGP):239 createForOpenPGP(/var/tmp/zypp.SwKyrE/zypp-trusted-krM8rgLG)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::gpg] KeyManager.cc(initGpgme):44 Initialized libgpgme version: 1.10.0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::gpg++] KeyManager.cc(createForOpenPGP):239 createForOpenPGP(/var/tmp/zypp.SwKyrE/zypp-trusted-krM8rgLG)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(getData):166 Found keys: {
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(getData):166   [668EA451E1B7CFAD-5c52e23e] [home:jejb1:Tumbleweed OBS Project <home:jejb1:Tumbleweed at build.opensuse.org>] [expires: 2021-04-10]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(getData):166   [45A1D0671ABD1AFB-54176598] [PackMan Project (signing key) <packman at links2linux.de>] [expires: 2024-09-12]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(getData):166   [B88B2FD43DBDC284-53674dd4] [openSUSE Project Signing Key <opensuse at opensuse.org>] [expires: 2024-05-02]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(getData):166   [70AF9E8139DB7C82-5847eb1f] [SuSE Package Signing Key <build at suse.de>] [expires: 2020-12-06]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(getData):166   [E3A5C360307E3D54-5aaa90a5] [SuSE Package Signing Key <build at suse.de>] [expires: 2022-03-14]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(getData):166 }
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(publicKeyExists):366 Found key [e1b7cfad] in keyring /var/tmp/zypp.SwKyrE/zypp-trusted-krM8rgLG
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(publicKeyExists):366 Found key [1abd1afb] in keyring /var/tmp/zypp.SwKyrE/zypp-trusted-krM8rgLG
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(publicKeyExists):366 Found key [3dbdc284] in keyring /var/tmp/zypp.SwKyrE/zypp-trusted-krM8rgLG
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(publicKeyExists):366 Found key [39db7c82] in keyring /var/tmp/zypp.SwKyrE/zypp-trusted-krM8rgLG
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(publicKeyExists):366 Found key [307e3d54] in keyring /var/tmp/zypp.SwKyrE/zypp-trusted-krM8rgLG
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(unlink):659 unlink /var/tmp/zypp.SwKyrE/TmpFile.Y0jksL
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] TmpPath.cc(~Impl):78 TmpPath cleaned up /var/tmp/zypp.SwKyrE/TmpFile.Y0jksL{- 0600 0/0 size 7250}
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb++] librpmDb.cc(dbRelease):311 dbRelease: release, outstanding 0
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb] RpmDb.cc(syncTrustedKeys):1057 Trusted keys synced.
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [librpmDb] RpmDb.cc(initDatabase):435 InitDatabase: RpmDb[V4(X--)V3(---): '(/)/var/lib/rpm']
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] HistoryLog.cc(setRoot):173 installation log file /var/log/zypp/history
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] TargetImpl.cc(TargetImpl):698 Initialized target on /
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(dirForEach):553 readdir /etc/products.d 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] TargetImpl.cc(buildCache):853 Read cookie: /var/cache/zypp/solv/@System/cookie{- 0644 0/0 size 52}
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] TargetImpl.cc(buildCache):860 Read cookie: /var/cache/zypp/solv/@System/cookie says: uptodate
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] refresh.cc(refreshRepository):147 going to refresh repo 'jejb-tumbleweed'
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypper] refresh.cc(refreshRepository):154 calling refreshMetadata, forced
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(checkIfToRefreshMetadata):971 Going to try to check whether refresh is needed for http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 (rpm-md)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(checkIfToRefreshMetadata):991 Forced refresh!
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(refreshMetadata):1110 Going to refresh metadata from http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(probe):1410 going to probe the repo type at http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 ()
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaAccess.cc(open):117 Trying scheme 'http'
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaCurl.cc(MediaCurl):549 MediaCurl::MediaCurl(http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1, )
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaMultiCurl.cc(MediaMultiCurl):1164 MediaMultiCurl::MediaMultiCurl(http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1, )
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaAccess.cc(open):197 Opened: http(http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 not attached; localRoot "")
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(open):258 Opened new media access using id 1 to http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaSetAccess.cc(provide):253 Going to try to provide  file /repodata/repomd.xml from media number 1
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(attach):376 attach(id=1)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(createAttachPoint):391 Create attach point: attach root is not a writable directory: '/var/adm/mount'
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(createAttachPoint):400 Look for orphaned attach points in /var/tmp{d 1777 0/0}
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(dirForEach):553 readdir /var/tmp 
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaHandler.cc(createAttachPoint):374 Created default attach point /var/tmp/AP_0x8OiTXN
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ProductFileReader.cc(parse):219 +++/etc/products.d/baseproduct[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] Reader.cc(Reader):113 Start Parsing /etc/products.d/baseproduct[g___]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] Reader.cc(~Reader):137 Done Parsing /etc/products.d/baseproduct[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ProductFileReader.cc(parse):245 ---0 - /etc/products.d/baseproduct[_eF_]
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] ProxyInfoLibproxy.cc(getProxyFactory):66 Build Libproxy Factory from /etc/sysconfig/proxy
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(setupEasy):829 Proxy: not explicitly set
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(setupEasy):830 Proxy: libcurl may look into the environment
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(chmod):1051 assert_file_mode 00600 /var/lib/YaST2/cookieschmod /var/lib/YaST2/cookies 00600
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaHandler.cc(attach):691 Attached: http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 attached; localRoot "/var/tmp/AP_0x8OiTXN"
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):96 checkDesired(1): desired (report by zypp::media::NoVerifier)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(1): desired (cached)
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(doGetDoesFileExist):1190 /repodata/repomd.xml
2020-03-19 08:08:12 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(doGetDoesFileExist):1200 URL: http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1/repodata/repomd.xml
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaCurl.cc(doGetDoesFileExist):1281 perform code: 0 [ No error ]
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(1): desired (cached)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(probe):1436 Probed type RPMMD at http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 ()
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(close):288 Close to access handler using id 1 requested
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(release):751 Request to release attached media http<http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1>, use count=1
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(release):758 Releasing media http<http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1>
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaHandler.cc(disconnect):730 Disconnected: http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 attached; localRoot "/var/tmp/AP_0x8OiTXN"
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(removeAttachPoint):181 MediaHandler - checking if to remove attach point
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(recursive_rmdir):426 recursive_rmdir /var/tmp/AP_0x8OiTXN 
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaHandler.cc(removeAttachPoint):193 Deleted default attach point /var/tmp/AP_0x8OiTXN
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaHandler.cc(release):812 Released: http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 not attached; localRoot ""
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaAccess.cc(close):248 Close: http(http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 not attached; localRoot "") (OK)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(release):744 Request to release media - not attached; eject ''
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(removeAttachPoint):181 MediaHandler - checking if to remove attach point
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] RepoManager.cc(refreshMetadata):1158 Creating downloader for [ jejb-tumbleweed ]
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher++] Fetcher.cc(addCachePath):316 Adding fetcher cache: '/var/cache/zypp/raw/jejb-tumbleweed'.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher++] Fetcher.cc(addCachePath):316 Adding fetcher cache: '/var/cache/zypp/raw/jejb-tumbleweed-gnome'.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher++] Fetcher.cc(addCachePath):316 Adding fetcher cache: '/var/cache/zypp/raw/packman'.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher++] Fetcher.cc(addCachePath):316 Adding fetcher cache: '/var/cache/zypp/raw/repo-debug'.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher++] Fetcher.cc(addCachePath):316 Adding fetcher cache: '/var/cache/zypp/raw/repo-debug-update'.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher++] Fetcher.cc(addCachePath):316 Adding fetcher cache: '/var/cache/zypp/raw/repo-install'.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher++] Fetcher.cc(addCachePath):316 Adding fetcher cache: '/var/cache/zypp/raw/repo-non-oss'.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher++] Fetcher.cc(addCachePath):316 Adding fetcher cache: '/var/cache/zypp/raw/repo-update'.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher++] Fetcher.cc(addCachePath):316 Adding fetcher cache: '/var/cache/zypp/raw/repo-update-non-oss'.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher] Fetcher.cc(downloadAndReadIndexList):690 No indexes to read.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher] Fetcher.cc(provideToDest):518 Not found in cache, retrieving...
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaAccess.cc(open):117 Trying scheme 'http'
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaCurl.cc(MediaCurl):549 MediaCurl::MediaCurl(http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1, )
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaMultiCurl.cc(MediaMultiCurl):1164 MediaMultiCurl::MediaMultiCurl(http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1, )
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaAccess.cc(open):197 Opened: http(http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 not attached; localRoot "")
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(open):258 Opened new media access using id 2 to http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaSetAccess.cc(provide):253 Going to try to provide optional file /media.1/media from media number 1
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(attach):376 attach(id=2)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(createAttachPoint):391 Create attach point: attach root is not a writable directory: '/var/adm/mount'
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaHandler.cc(createAttachPoint):374 Created default attach point /var/tmp/AP_0xCglbPW
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(setupEasy):829 Proxy: not explicitly set
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(setupEasy):830 Proxy: libcurl may look into the environment
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(chmod):1051 assert_file_mode 00600 /var/lib/YaST2/cookieschmod /var/lib/YaST2/cookies 00600
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaHandler.cc(attach):691 Attached: http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 attached; localRoot "/var/tmp/AP_0xCglbPW"
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):96 checkDesired(2): desired (report by zypp::media::NoVerifier)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(2): desired (cached)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(2): desired (cached)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(assert_dir):354 mkdir /var/tmp/AP_0xCglbPW/media.1 00755
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1334 dest: /var/tmp/AP_0xCglbPW/media.1/media
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1335 temp: /var/tmp/AP_0xCglbPW/media.1/media.new.zypp.MKR2f1
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(doGetFileCopyFile):1486 /media.1/media
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(doGetFileCopyFile):1496 URL: http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1/media.1/media
2020-03-19 08:08:13 <3> jarvis.int.hansenpartnership.com(13858) [zypp] MediaCurl.cc(doGetFileCopyFile):1561 curl error: 22: The requested URL returned error: 404 Not Found, temp file size 0 bytes.
2020-03-19 08:08:13 <5> jarvis.int.hansenpartnership.com(13858) [zypp] Exception.cc(log):166 MediaCurl.cc(evaluateCurlCode):1119 THROW:    File '/media.1/media' not found on medium 'http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1'
2020-03-19 08:08:13 <5> jarvis.int.hansenpartnership.com(13858) [zypp] Exception.cc(log):166 MediaCurl.cc(doGetFileCopyFile):1577 RETHROW:  File '/media.1/media' not found on medium 'http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1'
2020-03-19 08:08:13 <5> jarvis.int.hansenpartnership.com(13858) [zypp] Exception.cc(log):166 MediaMultiCurl.cc(doGetFileCopy):1363 RETHROW:  File '/media.1/media' not found on medium 'http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1'
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(unlink):659 unlink /var/tmp/AP_0xCglbPW/media.1/media.new.zypp.MKR2f1
2020-03-19 08:08:13 <5> jarvis.int.hansenpartnership.com(13858) [zypp] Exception.cc(log):166 MediaCurl.cc(getFileCopy):1006 RETHROW:  File '/media.1/media' not found on medium 'http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1'
2020-03-19 08:08:13 <5> jarvis.int.hansenpartnership.com(13858) [zypp] Exception.cc(log):166 MediaSetAccess.cc(provide):266 CAUGHT:   File '/media.1/media' not found on medium 'http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1'
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(2): desired (cached)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(getDetectedDevices):1398 No devices for this medium
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaSetAccess.cc(provide):278 Media couldn't provide file /media.1/media , releasing.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(release):447 release(id=2)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(release):751 Request to release attached media http<http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1>, use count=1
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(release):758 Releasing media http<http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1>
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaHandler.cc(disconnect):730 Disconnected: http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 attached; localRoot "/var/tmp/AP_0xCglbPW"
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(removeAttachPoint):181 MediaHandler - checking if to remove attach point
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(recursive_rmdir):426 recursive_rmdir /var/tmp/AP_0xCglbPW 
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaHandler.cc(removeAttachPoint):193 Deleted default attach point /var/tmp/AP_0xCglbPW
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaHandler.cc(release):812 Released: http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 not attached; localRoot ""
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaSetAccess.cc(provide):314 Can't provide file. Non-Interactive mode.
2020-03-19 08:08:13 <5> jarvis.int.hansenpartnership.com(13858) [zypp] Exception.cc(log):166 MediaSetAccess.cc(provide):315 RETHROW:  File '/media.1/media' not found on medium 'http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1'
2020-03-19 08:08:13 <5> jarvis.int.hansenpartnership.com(13858) [zypp] Exception.cc(log):166 Fetcher.cc(provideToDest):549 CAUGHT:   File '/media.1/media' not found on medium 'http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1'
2020-03-19 08:08:13 <2> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher] Fetcher.cc(provideToDest):550 optional resource [1]/media.1/media{19.1 MiB|NoCheckSum} could not be transferred.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#15|}END
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher] Fetcher.cc(downloadAndReadIndexList):690 No indexes to read.
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher] Fetcher.cc(provideToDest):518 Not found in cache, retrieving...
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaSetAccess.cc(provide):253 Going to try to provide optional file /repodata/repomd.xml.asc from media number 1
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(attach):376 attach(id=2)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(createAttachPoint):391 Create attach point: attach root is not a writable directory: '/var/adm/mount'
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaHandler.cc(createAttachPoint):374 Created default attach point /var/tmp/AP_0xOFkuw6
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(setupEasy):829 Proxy: not explicitly set
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(setupEasy):830 Proxy: libcurl may look into the environment
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(chmod):1051 assert_file_mode 00600 /var/lib/YaST2/cookieschmod /var/lib/YaST2/cookies 00600
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] MediaHandler.cc(attach):691 Attached: http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1 attached; localRoot "/var/tmp/AP_0xOFkuw6"
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):96 checkDesired(2): desired (report by zypp::media::NoVerifier)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(2): desired (cached)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(2): desired (cached)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(assert_dir):354 mkdir /var/tmp/AP_0xOFkuw6/repodata 00755
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1334 dest: /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.asc
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1335 temp: /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.asc.new.zypp.8G9YMb
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(doGetFileCopyFile):1486 /repodata/repomd.xml.asc
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(doGetFileCopyFile):1496 URL: http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1/repodata/repomd.xml.asc
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(progressCallback):1284 looks_like_metalink_fd: 0
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1373 HTTP response: 200
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(looks_like_metalink):1240 looks_like_metalink(/var/tmp/AP_0xOFkuw6/repodata/repomd.xml.asc.new.zypp.8G9YMb): 0
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(rename):701 rename /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.asc.new.zypp.8G9YMb -> /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.asc
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1493 done: /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.asc{- 0644 0/0 size 481}
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(provideFile):1015 provideFile(/repodata/repomd.xml.asc)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(2): desired (cached)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher] Fetcher.cc(validate):366 Checking job [/var/tmp/AP_0xOFkuw6/repodata/repomd.xml.asc] (0 checkers )
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(assert_dir):354 mkdir /var/cache/zypp/raw/jejb-tumbleweedSd4soS/repodata 00755
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(hardlinkCopy):869 hardlinkCopy /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.asc -> /var/cache/zypp/raw/jejb-tumbleweedSd4soS/repodata/repomd.xml.asc
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaSetAccess.cc(releaseFile):88 Going to release file /repodata/repomd.xml.asc from media number 1
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(unlink):659 unlink /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.asc
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher] Fetcher.cc(provideToDest):518 Not found in cache, retrieving...
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaSetAccess.cc(provide):253 Going to try to provide optional file /repodata/repomd.xml.key from media number 1
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(2): desired (cached)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(2): desired (cached)
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1334 dest: /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.key
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1335 temp: /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.key.new.zypp.S1F4Zh
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(doGetFileCopyFile):1486 /repodata/repomd.xml.key
2020-03-19 08:08:13 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(doGetFileCopyFile):1496 URL: http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1/repodata/repomd.xml.key
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(progressCallback):1284 looks_like_metalink_fd: 0
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1373 HTTP response: 200
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(looks_like_metalink):1240 looks_like_metalink(/var/tmp/AP_0xOFkuw6/repodata/repomd.xml.key.new.zypp.S1F4Zh): 0
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(rename):701 rename /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.key.new.zypp.S1F4Zh -> /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.key
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1493 done: /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.key{- 0644 0/0 size 1121}
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(provideFile):1015 provideFile(/repodata/repomd.xml.key)
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(2): desired (cached)
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher] Fetcher.cc(validate):366 Checking job [/var/tmp/AP_0xOFkuw6/repodata/repomd.xml.key] (0 checkers )
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(hardlinkCopy):869 hardlinkCopy /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.key -> /var/cache/zypp/raw/jejb-tumbleweedSd4soS/repodata/repomd.xml.key
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaSetAccess.cc(releaseFile):88 Going to release file /repodata/repomd.xml.key from media number 1
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(unlink):659 unlink /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.key
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [Progress++] ProgressData.cc(report):88 {#16|}END
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::gpg] PublicKey.cc(Impl):396 Taking pubkey from /var/cache/zypp/raw/jejb-tumbleweedSd4soS/repodata/repomd.xml.key of size 1121 and sha1 4b76f8e3965fe663a637ef6ce0f53513662db7e4
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(unlink):659 hardlinkCopy /var/cache/zypp/raw/jejb-tumbleweedSd4soS/repodata/repomd.xml.key -> /var/tmp/TmpFile.gTtEcpunlink /var/tmp/TmpFile.gTtEcp
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(hardlinkCopy):869 
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::gpg] PublicKey.cc(readFromFile):442 Reading pubkey from /var/tmp/TmpFile.gTtEcp of size 1121 and sha1 4b76f8e3965fe663a637ef6ce0f53513662db7e4
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(assert_dir):354 mkdir /var/tmp/zypp.SwKyrE/PublicKey 00755
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::gpg++] KeyManager.cc(createForOpenPGP):239 createForOpenPGP(/var/tmp/zypp.SwKyrE/PublicKey)
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(clean_dir):447 clean_dir /var/tmp/zypp.SwKyrE/PublicKey 
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::gpg] PublicKey.cc(readFromFile):465 Read pubkey from /var/tmp/TmpFile.gTtEcp: [668EA451E1B7CFAD-5c52e23e] [home:jejb1:Tumbleweed OBS Project <home:jejb1:Tumbleweed at build.opensuse.org>] [expires: 2021-04-10]
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::gpg++] KeyManager.cc(createForOpenPGP):239 createForOpenPGP(/var/tmp/zypp.SwKyrE/zypp-general-kriTBY4I)
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(importKey):302 Imported key [668EA451E1B7CFAD-5c52e23e] [home:jejb1:Tumbleweed OBS Project <home:jejb1:Tumbleweed at build.opensuse.org>] [expires: 2021-04-10] to generalKeyRing
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(unlink):659 unlink /var/tmp/TmpFile.gTtEcp
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] TmpPath.cc(~Impl):78 TmpPath cleaned up /var/tmp/TmpFile.gTtEcp{- 0644 0/0 size 1121}
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher] Fetcher.cc(downloadAndReadIndexList):690 No indexes to read.
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher] Fetcher.cc(provideToDest):518 Not found in cache, retrieving...
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaSetAccess.cc(provide):253 Going to try to provide  file /repodata/repomd.xml from media number 1
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(2): desired (cached)
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(2): desired (cached)
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1334 dest: /var/tmp/AP_0xOFkuw6/repodata/repomd.xml
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1335 temp: /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.new.zypp.O8avzw
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(doGetFileCopyFile):1486 /repodata/repomd.xml
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaCurl.cc(doGetFileCopyFile):1496 URL: http://download.opensuse.org/repositories/home:/jejb1:/Tumbleweed/openSUSE_Leap_15.1/repodata/repomd.xml
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(progressCallback):1284 looks_like_metalink_fd: 0
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1373 HTTP response: 200
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(looks_like_metalink):1240 looks_like_metalink(/var/tmp/AP_0xOFkuw6/repodata/repomd.xml.new.zypp.O8avzw): 0
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp] PathInfo.cc(rename):701 rename /var/tmp/AP_0xOFkuw6/repodata/repomd.xml.new.zypp.O8avzw -> /var/tmp/AP_0xOFkuw6/repodata/repomd.xml
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1493 done: /var/tmp/AP_0xOFkuw6/repodata/repomd.xml{- 0644 0/0 size 1715}
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaHandler.cc(provideFile):1015 provideFile(/repodata/repomd.xml)
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp++] MediaManager.cc(checkDesired):98 checkDesired(2): desired (cached)
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp:fetcher] Fetcher.cc(validate):366 Checking job [/var/tmp/AP_0xOFkuw6/repodata/repomd.xml] (1 checkers )
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [FileChecker] FileChecker.cc(operator()):138 checking /var/tmp/AP_0xOFkuw6/repodata/repomd.xml file validity using digital signature..
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(verifyFileSignatureWorkflow):408 Going to verify signature for repomd.xml ( /var/tmp/AP_0xOFkuw6/repodata/repomd.xml ) with /var/cache/zypp/raw/jejb-tumbleweedSd4soS/repodata/repomd.xml.asc
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(readSignatureKeyId):611 Determining key id of signature /var/cache/zypp/raw/jejb-tumbleweedSd4soS/repodata/repomd.xml.asc
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::gpg++] KeyManager.cc(createForOpenPGP):239 createForOpenPGP(/var/tmp/zypp.SwKyrE/PublicKey)
2020-03-19 08:08:14 <3> jarvis.int.hansenpartnership.com(13858) [zypp::gpg] KeyManager.cc(readSignaturesFprsOptVerify):174 <GnuPG> General error
2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(verifyFileSignatureWorkflow):515 File [/var/tmp/AP_0xOFkuw6/repodata/repomd.xml] ( repomd.xml ) signed with unknown key []


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200319/cab06647/attachment-0001.sig>

From wk at gnupg.org  Fri Mar 27 09:23:58 2020
From: wk at gnupg.org (Werner Koch)
Date: Fri, 27 Mar 2020 09:23:58 +0100
Subject: [BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6
In-Reply-To: <1585241836.3610.27.camel@HansenPartnership.com> (James Bottomley
 via Gnupg-devel's message of "Thu, 26 Mar 2020 09:57:16 -0700")
References: <1584573751.3504.36.camel@HansenPartnership.com>
 <87d098d7zr.fsf@wheatstone.g10code.de>
 <1584631279.3610.11.camel@HansenPartnership.com>
 <1584631503.3610.14.camel@HansenPartnership.com>
 <877dz78c33.fsf@fifthhorseman.net>
 <1585241836.3610.27.camel@HansenPartnership.com>
Message-ID: <87r1xe2okh.fsf@wheatstone.g10code.de>

On Thu, 26 Mar 2020 09:57, James Bottomley said:

> There are actually more details in the email that's stuck in moderation
> if you can unstick it ... it's only about 40k over the list limit.

Approved.  Sorry, that I can't timely reply to your mails.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/a4db0891/attachment.sig>

From andrewg at andrewg.com  Fri Mar 27 12:07:09 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 27 Mar 2020 11:07:09 +0000
Subject: Remote forwarding gnupg extra-socket?
In-Reply-To: <87tv2a7815.fsf@fifthhorseman.net>
References: <b8ca7450-6a48-f301-182b-27aebeece85b@andrewg.com>
 <87tv2a7815.fsf@fifthhorseman.net>
Message-ID: <0cdcb197-8ee5-cabe-62d0-e34c6b3dd3a4@andrewg.com>

Hi, Daniel.

On 27/03/2020 04:09, Daniel Kahn Gillmor wrote:
>
> There has been some discussion about this over on the SSH bugtracker:

I think token support is a good plan. Thanks.

>> Can we please PLEASE have GPG_AGENT_SOCK back in the short term?
> 
> I'm not convinced that this is a good idea; more configurability means
> more ways that people can break their setups, and debugging is even
> harder.

I absolutely agree that removing this is a good idea in the medium/long
term; the problem is that in the short term we have lost functionality.

>> The ssh-agent protocol allows for vendor-specific protocol extensions,
>> which would appear to be perfectly suited for this:
>>
>> https://tools.ietf.org/id/draft-miller-ssh-agent-01.html#rfc.section.4.7
> 
> this is a very interesting suggestion, but i'm not sure exactly how it
> would work.  can you describe it in more detail?  At the beginning of
> this message, it looks like you were talking about forwarding the
> extra-socket, and now it looks like you're talking about forwarding the
> ssh-agent emulation.  Are you talking about the same concern here?
> they're (at least subtly) different.

I'm suggesting that the ssh-agent emulation protocol could encapsulate
the extra-socket protocol using a vendor extension, removing any need to
forward the extra-socket.

So in pseudo-protocol, with "gnupg-agent at gnupg.org" as the vendor
extension, and the encoded gnupg-agent messages serialised as an array
of octets:

```
SSH_AGENTC_EXTENSION "gnupg-agent at gnupg.org" gnupg_agent_request
```

This would return:

```
SSH_AGENT_SUCCESS gnupg_agent_response
```

or

```
SSH_AGENT_EXTENSION_FAILURE gnupg_agent_response
```

> Also, how is the remote gpg-agent supposed to know that there is some
> other backend it should talk to (for either ssh-agent or any of the
> gpg-agent sockets)?

It wouldn't be a remote gpg-agent, it would be a remote gpg client. If
it detected SSH_AUTH_SOCK in its environment it would make an ssh `query
extension` request on SSH_AUTH_SOCK, as per
https://tools.ietf.org/id/draft-miller-ssh-agent-01.html#rfc.section.4.7.1

```
SSH_AGENTC_EXTENSION "query"
```

To which a successful reply would be something like

```
SSH_AGENT_SUCCESS "gnupg-agent at gnupg.org"
```

Otherwise it would fall back on normal behaviour.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/17974aa8/attachment.sig>

From wk at gnupg.org  Fri Mar 27 14:20:35 2020
From: wk at gnupg.org (Werner Koch)
Date: Fri, 27 Mar 2020 14:20:35 +0100
Subject: Remote forwarding gnupg extra-socket?
In-Reply-To: <b8ca7450-6a48-f301-182b-27aebeece85b@andrewg.com> (Andrew
 Gallagher's message of "Mon, 9 Mar 2020 13:02:55 +0000")
References: <b8ca7450-6a48-f301-182b-27aebeece85b@andrewg.com>
Message-ID: <87369u2au4.fsf@wheatstone.g10code.de>

On Mon,  9 Mar 2020 13:02, Andrew Gallagher said:

> In fact, you can still configure all of the above, but doing so is now
> next to useless. Since v2.1 there is no way to tell the remote gpg
> instance to use a non-default socket, and there is no reliable way to

Actually --extra-socket was introduced with 2.1.1 and the /var/run
standard location was introduced with 2.1.13.  So I don't understand why
you think anything has changed for --extra-socket except that it is now
always generated unless you configure "extra-socket /dev/null"


> tell ssh to mount the forwarded socket on the default location -- the
> default is now under XDG_RUNTIME_DIR which is unpredictable in
> principle, and ssh does not allow the use of remote envars in

XDG_RUNTIME_DIR is not used:

  /* It has been suggested to first check XDG_RUNTIME_DIR envvar.
   * However, the specs state that the lifetime of the directory MUST
   * be bound to the user being logged in.  Now GnuPG may also be run
   * as a background process with no (desktop) user logged in.  Thus
   * we better don't do that.  */

We use /run/user/<uid> instead.

[Site note: It seems that this directory is sometimes used for
 XDG_RUNTIME_DIR or at least handled in that way.  Which is a pretty
 annoying misfeature.  I often fall into this trap:

  foo-box$ ssh -X bar-box
  bar-box$ ssh foo-box
  foo-box$ exit
  bar-box$

 After the "exit" elogind removes /run/user/<uid> and futher work (in
 paricular new ssh connections) stop working because SSH_AUTH_SOCK
 points to a now non-existing socket.
 Mitigation is "loginctl enable-linger".
]


> Not only that, but if you are already logged in to the remote machine by
> other means you MUST NOT use the default socket location lest you break
> the existing session.

You mean you are running a gpg-agent on the remote box as well?  Right
in this case you should use a different home directory for the remote use
of gpg-agent.  gpgconf has options to help you with that.  And of course
you should use

   --no-autostart

     Do not start the gpg-agent or the dirmngr if it has not yet been
     started and its service is required.  This option is mostly useful
     on machines where the connection to gpg-agent has been redirected
     to another machines.  If dirmngr is required on the remote machine,
     it may be started manually using gpgconf --launch dirmngr.

with your remote gpg.

> Can we please PLEASE have GPG_AGENT_SOCK back in the short term?

No, the removal solved so many problems that it will definitely not be
added again.  The rule is: one gnupg homedir - one socket directory.

> In the long term, it might be more productive to overload ssh-agent. IFF
> the forwarded ssh-agent is really a gnupg-agent with enable-ssh-support,

That is a misunderstanding: gpg-agent does not emulate ssh-agent but
implements the ssh-agent-protocol; in that protocol gpg-agent is the
server and ssh is the client.

> The ssh-agent protocol allows for vendor-specific protocol extensions,
> which would appear to be perfectly suited for this:

Yes, it would be nice if the client site (ssh)  would send certain
environment variables via the ssh-agent-protocol, so that gpg-agent
knows hows where to pop up the pinentry (that is what the gpg does).
It would also be very nice if ssh could be extended to call a configured
tool if it does not find an agent and then try again.  This way we would
get auto start also via ssh.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/d7cb1c52/attachment.sig>

From andrewg at andrewg.com  Fri Mar 27 15:41:23 2020
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 27 Mar 2020 14:41:23 +0000
Subject: Remote forwarding gnupg extra-socket?
In-Reply-To: <87369u2au4.fsf@wheatstone.g10code.de>
References: <b8ca7450-6a48-f301-182b-27aebeece85b@andrewg.com>
 <87369u2au4.fsf@wheatstone.g10code.de>
Message-ID: <50b5c308-c25d-267a-9846-8084da703149@andrewg.com>

On 27/03/2020 13:20, Werner Koch wrote:
> 
> Actually --extra-socket was introduced with 2.1.1 and the /var/run
> standard location was introduced with 2.1.13.  So I don't understand why
> you think anything has changed for --extra-socket except that it is now
> always generated unless you configure "extra-socket /dev/null"

It's the standard location that causes the issue, so it is since 2.1.13,
yes.

> XDG_RUNTIME_DIR is not used:
...
> We use /run/user/<uid> instead.

OK, but this is unpredictable for the same reasons that XDG_RUNTIME_DIR
is unpredictable - you cannot tell what $UID is from the remote side, so
you don't know where to tell ssh to create the extra socket.

> You mean you are running a gpg-agent on the remote box as well?

Maybe, depending on whether I left myself logged in on the physical console.

> Right
> in this case you should use a different home directory for the remote use
> of gpg-agent.

Yes, but won't all gpgs on the remote machine expect the extra-socket to
be under /var/run/$UID, regardless of $GNUPGHOME? And even if we solve
the local vs remote issue, we don't solve the issue of two simultaneous
remote connections, unless we create many $GNUPGHOMEs and track them
manually (a slightly contrived example, but it shows that the "solution"
is only a workaround).

The extra-socket only works reliably if it is unique per-session, but it
is not stored in a per-session location.

> gpg-agent does not emulate ssh-agent but
> implements the ssh-agent-protocol

Yes, that's what I meant. Apologies for the sloppy terminology.

>> The ssh-agent protocol allows for vendor-specific protocol extensions,
>> which would appear to be perfectly suited for this:
> 
> Yes, it would be nice if the client site (ssh)  would send certain
> environment variables via the ssh-agent-protocol, so that gpg-agent
> knows hows where to pop up the pinentry (that is what the gpg does).
> It would also be very nice if ssh could be extended to call a configured
> tool if it does not find an agent and then try again.  This way we would
> get auto start also via ssh.

Sending environment variables would require code changes to ssh(d),
whereas vendor extensions would only require changes to gpg(-agent) -
they are treated as black boxes by ssh(d) and passed verbatim.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/4145ca5f/attachment-0001.sig>

From James.Bottomley at HansenPartnership.com  Fri Mar 27 20:37:00 2020
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Fri, 27 Mar 2020 12:37:00 -0700
Subject: [BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6
In-Reply-To: <1585241836.3610.27.camel@HansenPartnership.com>
References: <1584573751.3504.36.camel@HansenPartnership.com>
 <87d098d7zr.fsf@wheatstone.g10code.de>
 <1584631279.3610.11.camel@HansenPartnership.com>
 <1584631503.3610.14.camel@HansenPartnership.com>
 <877dz78c33.fsf@fifthhorseman.net>
 <1585241836.3610.27.camel@HansenPartnership.com>
Message-ID: <1585337820.28835.11.camel@HansenPartnership.com>

On Thu, 2020-03-26 at 09:57 -0700, James Bottomley via Gnupg-devel
wrote:
> On Thu, 2020-03-26 at 09:44 -0400, Daniel Kahn Gillmor wrote:
[...]
> > Also, you say that zypper works if you revert this patch.  have you
> > tested this "working" configuration against a deliberately tampered
> > message body?  To test that it is working, it's best to verify both
> > that a valid message is accepted *and* that a tampered message is
> > rejected.
> 
> I can check ... I just have to set up a corrupt repo, hang on.

OK, I've created a repo under my control and pointed zypper to it and
verified it works OK.  Corrupting the repomd.xml file to cause the
signature to fail gets a warning message from zypper and signing it
with a different key also gets a message asking me to accept the new
key, so I think its operating correctly with the patch reverted.

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/0ab4dd63/attachment.sig>

From dkg at fifthhorseman.net  Fri Mar 27 23:21:11 2020
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 27 Mar 2020 18:21:11 -0400
Subject: [BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6
In-Reply-To: <1585241836.3610.27.camel@HansenPartnership.com>
References: <1584573751.3504.36.camel@HansenPartnership.com>
 <87d098d7zr.fsf@wheatstone.g10code.de>
 <1584631279.3610.11.camel@HansenPartnership.com>
 <1584631503.3610.14.camel@HansenPartnership.com>
 <877dz78c33.fsf@fifthhorseman.net>
 <1585241836.3610.27.camel@HansenPartnership.com>
Message-ID: <87a741782w.fsf@fifthhorseman.net>

On Thu 2020-03-26 09:57:16 -0700, James Bottomley wrote:
>> a backtrace of the code around the call to gpgme_op_verify would be
>> helpful.
>
> It's in the missing email ... if you can't free it from moderation, I
> can break it up.

thanks Werner for releasing the message from moderation.

The relevant bits seem to be (i've tried to un-linewrap them, pls let me
know if i got it wrong):

  2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(readSignatureKeyId):611 Determining key id of signature /var/cache/zypp/raw/jejb-tumbleweedSd4soS/repodata/repomd.xml.asc
  2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::gpg++] KeyManager.cc(createForOpenPGP):239 createForOpenPGP(/var/tmp/zypp.SwKyrE/PublicKey)
  2020-03-19 08:08:14 <3> jarvis.int.hansenpartnership.com(13858) [zypp::gpg] KeyManager.cc(readSignaturesFprsOptVerify):174 <GnuPG> General error
  2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(verifyFileSignatureWorkflow):515 File [/var/tmp/AP_0xOFkuw6/repodata/repomd.xml] ( repomd.xml ) signed with unknown key []

So it is indeed failing during an attempt not to verify the signature,
but an attempt to verify the key IDs *in* the signature.

I can try to debug this in gpgme further, but i want to point out a
problem with the pattern that libzypp (or maybe zypper itself) is using
here.

the workflow seems to be:

 - verify that <sig> contains a valid signature over <data>
 
 - get a list of keys that are present in <sig>, and ensure that some
   key is in a "known good" list. 

(maybe not in that order -- it doesn't matter)

The risk is that <sig> could contain multiple signatures.  Some of them
could be from the known-good list, and others not.

I don't have the time right now to try to attack zypper or libzypp right
now, to make sure that it's not vulnerable, but if i were responsible
for that tool, i'd want to audit it much more closely, and make a few
different test cases of attempted attacks, to make sure that they fail.

Feel free to contact me privately if you want to talk about this kind of
auditing/testing in a less public channel.

The better way to do the check you're trying to do is to get the list of
signing keys from the verification result itself. Do you see how this is
a security improvement?

As a side benefit, if you do this the way i describe above, you'll avoid
this extra attempt to get a list of key IDs from <sig> itself, which is
where the code is failing today.

These tools are still pretty clumsy and *way* too difficult to use
correctly, even for capable programmers like yourself.  It's not your
fault for "holding it wrong" -- i'm just trying to help you think
through ways that you could do it better.

If you're interested thinking through simpler programmatic ways to do
what i think libzypper is trying to do (verify signature(s) that are
expected to come from one or more OpenPGP certificates in a curated
keyring), i'd welcome your feedback on
https://tools.ietf.org/html/draft-dkg-openpgp-stateless-cli.

Regards,

    --dkg
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/27470353/attachment.sig>

From wk at gnupg.org  Sat Mar 28 11:34:26 2020
From: wk at gnupg.org (Werner Koch)
Date: Sat, 28 Mar 2020 11:34:26 +0100
Subject: Remote forwarding gnupg extra-socket?
In-Reply-To: <50b5c308-c25d-267a-9846-8084da703149@andrewg.com> (Andrew
 Gallagher's message of "Fri, 27 Mar 2020 14:41:23 +0000")
References: <b8ca7450-6a48-f301-182b-27aebeece85b@andrewg.com>
 <87369u2au4.fsf@wheatstone.g10code.de>
 <50b5c308-c25d-267a-9846-8084da703149@andrewg.com>
Message-ID: <87imio22fh.fsf@wheatstone.g10code.de>

On Fri, 27 Mar 2020 14:41, Andrew Gallagher said:
> On 27/03/2020 13:20, Werner Koch wrote:
>> 
>> Actually --extra-socket was introduced with 2.1.1 and the /var/run
>> standard location was introduced with 2.1.13.  So I don't understand why
>> you think anything has changed for --extra-socket except that it is now
>> always generated unless you configure "extra-socket /dev/null"
>
> It's the standard location that causes the issue, so it is since 2.1.13,
> yes.
>
>> XDG_RUNTIME_DIR is not used:
> ...
>> We use /run/user/<uid> instead.
>
> OK, but this is unpredictable for the same reasons that XDG_RUNTIME_DIR
> is unpredictable - you cannot tell what $UID is from the remote side, so
> you don't know where to tell ssh to create the extra socket.

What's wrong with

  $ ssh kerckhoffs.g10code.com gpgconf --list-dirs agent-ssh-socket
  /run/user/1000/gnupg/S.gpg-agent.ssh

>> You mean you are running a gpg-agent on the remote box as well?
>
> Maybe, depending on whether I left myself logged in on the physical console.

The standard use case is to run gpg on a server which you don't trust to
hold your private key.  When ssh-ing to anther desktop (I have to do
this now often to my other office) you need to script something.  Yes,
it would be cool if you could advice ssh with a simple option to send
some meta information to the server to be evaluated in .bashrc; but you
can do this also with an ssh wrapper and a dedicated envvar you allow in
sshd_config's AcceptEnv option.


> Yes, but won't all gpgs on the remote machine expect the extra-socket to
> be under /var/run/$UID, regardless of $GNUPGHOME? And even if we solve

There is a mechanism which allows this.  For example if I do a manual
test in a dedicated homedir:

 mybox:~/b/gnupg/test-card(GnuPGTest)$ gpgconf --list-dirs agent-ssh-socket
 /run/user/1000/gnupg/d.ex81qn9mjkp3y5c94htkx8hy/S.gpg-agent.ssh

That is the homedir is hashed and appended to the standard socket dir.
Although things work automagically, gpgconf has two options to support
this:

  --create-socketdir
    Create a directory for sockets below /run/user or /var/run/user.
    This is command is only required if a non default home directory is
    used and the /run based sockets shall be used.  For the default home
    directory GnuPG creates a directory on the fly.

  --remove-socketdir
    Remove a directory created with command --create-socketdir.

[I just noticed that I should update the description, it is actually
 only needed if you want to create the directory prior to starting any
 GnuPG daemon.]

> The extra-socket only works reliably if it is unique per-session, but it
> is not stored in a per-session location.

A session is defined by the GNUPGHOME envar or --homedir options.  That
works the same on all platforms.

> Sending environment variables would require code changes to ssh(d),
> whereas vendor extensions would only require changes to gpg(-agent) -
> they are treated as black boxes by ssh(d) and passed verbatim.

And how do you set this vendor extensions with ssh(1)?


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200328/2c985185/attachment.sig>

From dkg at fifthhorseman.net  Sat Mar 28 01:16:02 2020
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 27 Mar 2020 20:16:02 -0400
Subject: gpgsm --gen-key with existing key from "ssh-add" fails
In-Reply-To: <874kub8bnp.fsf@fifthhorseman.net>
References: <874kub8bnp.fsf@fifthhorseman.net>
Message-ID: <871rpd72rh.fsf@fifthhorseman.net>

On Thu 2020-03-26 09:54:02 -0400, Daniel Kahn Gillmor via Gnupg-devel wrote:
> This was originally reported over on https://dev.gnupg.org/T4892

Over there, Werner wrote:

> I would also suggest to use GnuPG master

The original reporter (in Cc) has now tried the same process with GnuPG
master, and reports that they see the same misbehavior on GnuPG master.

What is the next step for debugging this?  It seems clearly buggy to me
(on both STABLE-BRANCH-2-2 and master).

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/79df9e45/attachment.sig>

From wk at gnupg.org  Sun Mar 29 18:16:03 2020
From: wk at gnupg.org (Werner Koch)
Date: Sun, 29 Mar 2020 18:16:03 +0200
Subject: gpgsm --gen-key with existing key from "ssh-add" fails
In-Reply-To: <874kub8bnp.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
 Gnupg-devel's message of "Thu, 26 Mar 2020 09:54:02 -0400")
References: <874kub8bnp.fsf@fifthhorseman.net>
Message-ID: <877dz316ik.fsf@wheatstone.g10code.de>

On Thu, 26 Mar 2020 09:54, Daniel Kahn Gillmor said:

>     Now creating self-signed certificate.  This may take a while ...
>     gpgsm: error setting the public key: Invalid S-expression
>     gpgsm: error creating certificate request: Invalid S-expression <KSBA>
>
> note that the key created by ssh-key is 3072-bit RSA, not 1024.

> Using nettle-bin's sexp-conv, i see:

Better don't use Nettle's tool because it encodes un("|....|") but GnuPG
only implements only hex encoding ("#...#").  Binary output would thus
be easier to analyze, or put

  enable-extended-key-format

into gpg-agent.conf and change the passphrase so that that the file gets
rewritten.  I fear that single stepping is the best way to track this
down.


BTW, That option is anyway the default in 2.3 because it allows to add
meta data with an editor, like

 Label: My key on the green painted yubikey.
 Key: ....

The Label for example is shown by the pinentry.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200329/7530b912/attachment-0001.sig>

From dkg at fifthhorseman.net  Mon Mar 30 01:06:35 2020
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 29 Mar 2020 19:06:35 -0400
Subject: gpgsm --gen-key with existing key from "ssh-add" fails
In-Reply-To: <877dz316ik.fsf@wheatstone.g10code.de>
References: <874kub8bnp.fsf@fifthhorseman.net>
 <877dz316ik.fsf@wheatstone.g10code.de>
Message-ID: <87lfni69s4.fsf@fifthhorseman.net>

On Sun 2020-03-29 18:16:03 +0200, Werner Koch wrote:
> Better don't use Nettle's tool because it encodes un("|....|") but GnuPG
> only implements only hex encoding ("#...#").  Binary output would thus
> be easier to analyze, or put
>
>   enable-extended-key-format

if gpg can't read base64-encoded s-expressions, nettle's sexp-conv can
also use hex encoding insteadwith "-s hex", fwiw.

Anyway, I can't imagine that the format used by nettle-sexp is the issue
here, but to avoid confusion, i've repeated the experiment using
enable-extended-key-format (see the postscript here for examples).

The point of the bug report has to do with gpgsm, and it failing to
generate an X.509 certificate as expected, though.  The initial report
includes enough to reproduce the bug.  Have you been unable to reproduce
it?

    export GNUPGHOME=$(mktemp -d)
    export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
    echo enable-extended-key-format > $GNUPGHOME/gpg-agent.conf
    gpgconf --start gpg-agent
    ssh-keygen -f test.key -N ''
    ssh-add test.key
    grip=$(ls $GNUPGHOME/private-keys-v1.d | cut -f1 -d.)
    gpgsm --gen-key

(in gpgsm, select "existing key" and put in the generated keygrip)

I started trying to write up a --batch generation script to make a
fully-automated reproducer for this bug report, but i ran into a
different bug (https://dev.gnupg.org/T4895) so i gave up.

Regards,

        --dkg

PS here is the extended-key format, and an OpenSSH private key that was
added via ssh-add:

Key: (private-key (rsa (n #009DFE0B31B096178536EB8EB18C81899D54B65C5D21
 740B87E0F58215F7F72C94E1F3530493DB12681C9FABA527E79FD45D55C572A57AD7AA
 BE6D8E918E1612680393560E5E6532F6180DCA442F54C7CE2D4A8D40B3E94B5323CDE8
 6E366F973CFABC4A5104C7A64B84DD9CCC1608EA33F18B1C930006104393A3E059943F
 901B1275E4B2CA8D3156F09BD0074B5EE928449A59E8DF36353BDFAA82F64DBC9BA87B
 C054935E0A8A601F84F027E41605238E43D3E1FD371ED3B1ABD4D69322A221D6D3087F
 655783B1556AE64F1BC7D705BEB8F516F0E2E5A79535B903AF259AC3DB5E03DBEF4A4D
 139CC9F54CA2AD6277A54C20AC0B640D03F582897F4A537D275067B5AFE271189D7FB5
 2530DE07493FD815E1C66B24823C4C0B1C9CD8ED76AD9F9363EB597BB2F1825C63A1D8
 8D8FF54C00D5EC1297B763EDA472DBF95625E2D404B88A4099CD35486F8F9E44135307
 A10073146246F1D81B7ED323C93DB53C9E592CB79C5F97ABC042E4C3FCBB6B7286364C
 EAFE3AE3DA1BC0C5CCCE636763#)(e #010001#)(d
  #7CB3D802106F67812E281F28E4CE19E0A4CC8B7AB6BCF19CFE62C99AAD6DDB326865
 B65116A3039449837DE78DE7B4AFDA3BA8ED24D0210A13E445737DC2CE246B2E0FEEA7
 73191645461D30546B8689A6160207DFF9740ADB67DADDA2F9D155C0527E1614BFC0F2
 3A9CF0F5E52E842D1BA9C19405A0C3959322F621BE71AD3CB1057CCDE2322F8F7FBA7C
 2845C55423048310144E9A6ACA27705E8E2A2D846F27BE57033A66F771876F565F2618
 7B55E52484490BA44620B14BFF629E1FE7F7B0060F820CBC2F200CF370A9CE830F108B
 B81C66D30515DACA0C1E774109A89E32E041EA699D07A7A8FB5AD02D4CE26AFB095108
 85937D87E7FFD7867BE48E049654F84D224CEC9DE0D5A86C4A5DF0B4343AA8416CD138
 6DE929F8D7C0C46D126472ED867AB15B348017C98BFF6B351116FC643EC182AF156E12
 5EC3E4D9DC8D6D61F52A4861603254F786B7BF0947C13A9D4F77C116B98651FDEE7524
 D976E4C4735EEAD6F8F6A8BEF01006FC668BA3D3EE03F43996BCDD21278A18F0C27A81
 #)(p #00C2EA695EDDD0D35DB9EA10B91D0085A2E8B5F3636612A3212291B90285D988
 E757C9ACFBAC40E05A9ED9917F846DB13A0A9D4A2507FEBEA984BF8EC51D1E09F6F085
 78EA998684C5787DE290779323CBB1AC8BACC8FC17D60C3A7C563B3949560E99C59CD5
 2DE7C2CE35733AAC6B7C14BA8BABFD5FCB75FAB50C1296050D1F113A67BFBBF658E3BC
 BC1AA3A7BEBB053E701A8E43EE851D4C954475374C57B29F0B4F673D3BB598AA9FAEAB
 F3BE9E88DF66C4D173249A2191B4743A97D028F16F#)(q
  #00CF815E64E21EE6592B71026AD827100ABB0BEA07E01D42EBF6214E24523AFF5F6D
 2D9D602A4B7517C57760F9065996333E69BAF66441BCC1FC2A50ED3BA50CAE2CEBE78F
 12269A99A4EE86290E96B1D5D6856278DDB0D29BED811DB19FDC55744D67C0B476E213
 35DA7EC8F370E868F0441BA185FD4D66964A5F7576A2576E5AC697A76C82BB9A95FA95
 DF9D2C6AB850953B0B96CDCBD5828504EA7589BBAB0C2330DF1029D9AD1ECB18B36F05
 E7A24E3C41C65D55F88A9905A48A412233474D#)(u
  #00B6159877B4D68ACEE41836ABCE62C34CE2B56FF2080FCF0646FB53A55B6E23B38E
 F70BB54C2B394DA1A68A32FD44F04C2E69DBAEBAEC46D1F41E1CA0811B770CF94D8943
 9B8EC36946F22100D494C02F161ED155B6D7F0516D9978C90DF6AB0B6AA334BE6B4DF5
 5FEC50B5F5A71BAEE5726040E55E9D2533D37638FDCEB49B673B184B0CE1FDED29AB6D
 C20FC3EF72F9DC57C938CBACC2E59E61113D6259AF246B198484CA931667FA1176EE0C
 E39A83BB9099FD86C0D8AFE0F0D0A882022059#))(comment "dkg at alice"))


i had used ssh-add on this key:

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEAnf4LMbCWF4U2646xjIGJnVS2XF0hdAuH4PWCFff3LJTh81MEk9sS
aByfq6Un55/UXVXFcqV616q+bY6RjhYSaAOTVg5eZTL2GA3KRC9Ux84tSo1As+lLUyPN6G
42b5c8+rxKUQTHpkuE3ZzMFgjqM/GLHJMABhBDk6PgWZQ/kBsSdeSyyo0xVvCb0AdLXuko
RJpZ6N82NTvfqoL2TbybqHvAVJNeCopgH4TwJ+QWBSOOQ9Ph/Tce07Gr1NaTIqIh1tMIf2
VXg7FVauZPG8fXBb649Rbw4uWnlTW5A68lmsPbXgPb70pNE5zJ9UyirWJ3pUwgrAtkDQP1
gol/SlN9J1Bnta/icRidf7UlMN4HST/YFeHGaySCPEwLHJzY7Xatn5Nj61l7svGCXGOh2I
2P9UwA1ewSl7dj7aRy2/lWJeLUBLiKQJnNNUhvj55EE1MHoQBzFGJG8dgbftMjyT21PJ5Z
LLecX5erwELkw/y7a3KGNkzq/jrj2hvAxczOY2djAAAFgHsPPvF7Dz7xAAAAB3NzaC1yc2
EAAAGBAJ3+CzGwlheFNuuOsYyBiZ1UtlxdIXQLh+D1ghX39yyU4fNTBJPbEmgcn6ulJ+ef
1F1VxXKleteqvm2OkY4WEmgDk1YOXmUy9hgNykQvVMfOLUqNQLPpS1MjzehuNm+XPPq8Sl
EEx6ZLhN2czBYI6jPxixyTAAYQQ5Oj4FmUP5AbEnXkssqNMVbwm9AHS17pKESaWejfNjU7
36qC9k28m6h7wFSTXgqKYB+E8CfkFgUjjkPT4f03HtOxq9TWkyKiIdbTCH9lV4OxVWrmTx
vH1wW+uPUW8OLlp5U1uQOvJZrD214D2+9KTROcyfVMoq1id6VMIKwLZA0D9YKJf0pTfSdQ
Z7Wv4nEYnX+1JTDeB0k/2BXhxmskgjxMCxyc2O12rZ+TY+tZe7LxglxjodiNj/VMANXsEp
e3Y+2kctv5ViXi1AS4ikCZzTVIb4+eRBNTB6EAcxRiRvHYG37TI8k9tTyeWSy3nF+Xq8BC
5MP8u2tyhjZM6v4649obwMXMzmNnYwAAAAMBAAEAAAGAfLPYAhBvZ4EuKB8o5M4Z4KTMi3
q2vPGc/mLJmq1t2zJoZbZRFqMDlEmDfeeN57Sv2juo7STQIQoT5EVzfcLOJGsuD+6ncxkW
RUYdMFRrhommFgIH3/l0Cttn2t2i+dFVwFJ+FhS/wPI6nPD15S6ELRupwZQFoMOVkyL2Ib
5xrTyxBXzN4jIvj3+6fChFxVQjBIMQFE6aasoncF6OKi2Ebye+VwM6Zvdxh29WXyYYe1Xl
JIRJC6RGILFL/2KeH+f3sAYPggy8LyAM83CpzoMPEIu4HGbTBRXaygwed0EJqJ4y4EHqaZ
0Hp6j7WtAtTOJq+wlRCIWTfYfn/9eGe+SOBJZU+E0iTOyd4NWobEpd8LQ0OqhBbNE4bekp
+NfAxG0SZHLthnqxWzSAF8mL/2s1ERb8ZD7Bgq8VbhJew+TZ3I1tYfUqSGFgMlT3hre/CU
fBOp1Pd8EWuYZR/e51JNl25MRzXurW+PaovvAQBvxmi6PT7gP0OZa83SEnihjwwnqBAAAA
wQC2FZh3tNaKzuQYNqvOYsNM4rVv8ggPzwZG+1OlW24js473C7VMKzlNoaaKMv1E8Ewuad
uuuuxG0fQeHKCBG3cM+U2JQ5uOw2lG8iEA1JTALxYe0VW21/BRbZl4yQ32qwtqozS+a031
X+xQtfWnG67lcmBA5V6dJTPTdjj9zrSbZzsYSwzh/e0pq23CD8PvcvncV8k4y6zC5Z5hET
1iWa8kaxmEhMqTFmf6EXbuDOOag7uQmf2GwNiv4PDQqIICIFkAAADBAM+BXmTiHuZZK3EC
atgnEAq7C+oH4B1C6/YhTiRSOv9fbS2dYCpLdRfFd2D5BlmWMz5puvZkQbzB/CpQ7TulDK
4s6+ePEiaamaTuhikOlrHV1oVieN2w0pvtgR2xn9xVdE1nwLR24hM12n7I83DoaPBEG6GF
/U1mlkpfdXaiV25axpenbIK7mpX6ld+dLGq4UJU7C5bNy9WChQTqdYm7qwwjMN8QKdmtHs
sYs28F56JOPEHGXVX4ipkFpIpBIjNHTQAAAMEAwuppXt3Q01256hC5HQCFoui182NmEqMh
IpG5AoXZiOdXyaz7rEDgWp7ZkX+EbbE6Cp1KJQf+vqmEv47FHR4J9vCFeOqZhoTFeH3ikH
eTI8uxrIusyPwX1gw6fFY7OUlWDpnFnNUt58LONXM6rGt8FLqLq/1fy3X6tQwSlgUNHxE6
Z7+79ljjvLwao6e+uwU+cBqOQ+6FHUyVRHU3TFeynwtPZz07tZiqn66r876eiN9mxNFzJJ
ohkbR0OpfQKPFvAAAACWRrZ0BhbGljZQE=
-----END OPENSSH PRIVATE KEY-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200329/003f79dd/attachment.sig>

From wk at gnupg.org  Mon Mar 30 17:05:24 2020
From: wk at gnupg.org (Werner Koch)
Date: Mon, 30 Mar 2020 17:05:24 +0200
Subject: gpgsm --gen-key with existing key from "ssh-add" fails
In-Reply-To: <87lfni69s4.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
 Gnupg-devel's message of "Sun, 29 Mar 2020 19:06:35 -0400")
References: <874kub8bnp.fsf@fifthhorseman.net>
 <877dz316ik.fsf@wheatstone.g10code.de>
 <87lfni69s4.fsf@fifthhorseman.net>
Message-ID: <87d08tzxvv.fsf@wheatstone.g10code.de>

Hi,

I found the problem:

(public-key 
 (rsa 
  (n #00B1[...]#)
  (e #010001#)
 )
 (comment ./test.key)
)

This is passed to Libksba but Libksba does not grok the comment part and
bails out on this.  I pushed a change to Libksba

  commit 1e903fe558bd6583c5447fbebe2ef019229dbfdc 
  Allow optional elements in keyinfo objects.

We are planning a new libksba release anyway, which has a a bunch of
smaller fixes collected since the last release in 2016.

Thanks for identifying this bug.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200330/d197ec79/attachment.sig>