Am 26.07.2018 um 23:07 schrieb Morten Linderud via arch-general:

https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

Thank You Morten! But I still have problems: From the wiki I understand, I should set "keyserver-options auto-key-retrieve" in ~/.gnupg/gpg.conf, which is set. IIUC, this should automate the magic to fetch the PGP key. But building still fails. With aura, I've the option to acceppt the package anyway, but I'd prefer to know the correct way. Kind regards Peter

Am 27.07.2018 um 00:04 schrieb Eli Schwartz via arch-general:

...

Am 26.07.2018 um 23:07 schrieb Morten Linderud via arch-general:

...

https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

Thank You Morten! But I still have problems: From the wiki I understand, I should set "keyserver-options auto-key-retrieve" in ~/.gnupg/gpg.conf, which is set. IIUC, this should automate the magic to fetch the PGP key. But building still fails. With aura, I've the option to acceppt the package anyway, but I'd prefer to know the correct way. If you are getting "unknown key", then you need to ask yourself *why*

On 07/26/2018 05:45 PM, Peter Nabbefeld wrote: the key is unknown. Have you tried troubleshooting by downloading the key using gpg --recv-keys manually? My fault. Tried the two gnupg example servers, but not the "alternative key server" from wiki: #keyserver hkp://keys.gnupg.net #keyserver http://http-keys.gnupg.net

Should be: keyserver pool.sks-keyservers.net Probably this should not be mentiond as "alternative" key server, but just be recommended for building PGP-signed packages.

I don't really see how this has anything to do with solr. Seems it's just my first AUR package using a PGP key.

...

Was this key removed from database for any reason, or did it just change? Or does the package have security issues, and I shouldn't install it? I've literally got no clue what you're trying to imply here. Database? What database?

Just used as a synonym for a collection of several data records, no matter if it's backed by some real database or just a text file, as this doesn't really matter here. Kind regards Peter

On 07/26/2018 06:14 PM, Ralf Mardorf wrote:

On Thu, 26 Jul 2018 23:45:32 +0200, Peter Nabbefeld wrote:

...

Thank You Morten! But I still have problems: From the wiki I understand, I should set "keyserver-options auto-key-retrieve" in ~/.gnupg/gpg.conf, which is set. IIUC, this should automate the magic to fetch the PGP key. But building still fails. With aura, I've the option to acceppt the package anyway, but I'd prefer to know the correct way.

I can't comment on the Wiki, since I didn't read it. Note, auto-key-retrieve means that any software automatically will retrieve new keys from the default keyserver. An excerpt from the gpg mangape, that belongs to auto-key-retrieve:

$ man gpg | grep '\"web bug\" l' -A1 Note that this option makes a "web bug" like behavior possible. Keyserver or Web Key Directory operators can see which keys you request, so by sending you a message signed by a brand new key (which you naturally will not have on your local keyring), the operator can tell both your IP address and the time when you verified the signature.

I'm using an alias to manually add new keys:

$ grep gkey= .bashrc alias gkey='gpg --keyserver hkp://pgp.uni-mainz.de --recv-keys'

What does the "web bug" have to do with this discussion? -- Eli Schwartz Bug Wrangler and Trusted User

On 07/26/2018 06:50 PM, Ralf Mardorf wrote:

On Thu, 26 Jul 2018 18:30:01 -0400, Eli Schwartz via arch-general wrote:

...

What does the "web bug" have to do with this discussion?

It's a hint that not every user likes 'auto-key-retrieve', but instead only manually retrieve keys, if it makes sense to the user to retrieve a key. I don't see a valid reason, to e.g. retrieve the keys that belong to an unknown signature of an email send via a mailing list, just to get automatically keys when building something from AUR. I'm surprised that you don't question the recommendation to use 'auto-key-retrieve' without providing this hint. I don't care much about a privacy risk, but I don't see a reason to collect unneeded keys.

Ah, so, as I expected, it was just a standard prototypical offtopic derail. Thanks for clarifying.

Could you explain why it's useful to collect each key that belongs to an email signature, that is completely irrelevant to you, just to automatically add keys that are required to build a package from AUR, too?

echo 'GNUPGHOME="$HOME"/.gnupg-makepkg' >> "$HOME"/.config/pacman/makepkg.conf Problem solved. -- Eli Schwartz Bug Wrangler and Trusted User

On Fri, 2018-07-27 at 08:10 +0100, Ralph Corderoy wrote:

Hi Ralf,

Eli wrote:

...

...

It's a hint that not every user likes 'auto-key-retrieve', but instead only manually retrieve keys, if it makes sense to the user to retrieve a key.

Thanks, I found it on topic, given Peter explicitly mentioned the option, and very helpful. I've added a note to the suggestion in https://wiki.archlinux.org/index.php/GnuPG#Use_a_keyserver

Thank you Ralph, for editing the Wiki.

...

...

I don't see a valid reason, to e.g. retrieve the keys that belong to an unknown signature of an email send via a mailing list, just to get automatically keys when building something from AUR.

Me neither, but https://wiki.archlinux.org/index.php/Pacman/Package_signing doesn't suggest `auto-key-retrieve'.

I didn't read all related Wiki pages, but seemingly non, including https://wiki.archlinux.org/index.php/makepkg mention Eli's hint, to use echo 'GNUPGHOME="$HOME"/.gnupg-makepkg' >> "$HOME"/.config/pacman/makepkg.conf Fortunately the manpage does. $ man makepkg | grep GNUPGHOME GNUPGHOME="/path/to/directory" I'm short in time and apart from this I'm uncertain, if it's worth to add this to the Arch Wiki. Regards, Ralf

On Sat, 2018-07-28 at 01:38 +0200, Ralf Mardorf wrote:

JFTR by accident Ralph wrote "Eli wrote:", while it should read "Ralf wrote:". Most likely he selected my reply quoted by Eli's mail, before invoking the reply to Eli's mail. My apologies, I also didn't notice this, when I replied to Ralph's mail, so I didn't fix it. A thing like that could happen ;).

Oops, it were nested quotes, my bad.

On 07/28/2018 05:13 AM, Ralph Corderoy wrote:

Hi Ralf,

...

I didn't read all related Wiki pages, but seemingly non, including https://wiki.archlinux.org/index.php/makepkg mention Eli's hint, to use

echo 'GNUPGHOME="$HOME"/.gnupg-makepkg' >> "$HOME"/.config/pacman/makepkg.conf

It's just common sense IMHO. It's not even remotely makepkg-specific. This is just basic "using different gnupg keyrings for different purposes", the only thing special about putting it in makepkg.conf instead of creating a shell alias: alias makepkg="GNUPGHOME="$HOME"/.gnupg-makepkg makepkg" is, well, to take advantage of the fact that makepkg.conf is a bash-compatible configuration file and save on the aliases cluttering up your shell environment. (Also I usually have makepkg aliased to something else, that being my pacman.git copy which I hack on.)

...

Fortunately the manpage does.

$ man makepkg | grep GNUPGHOME GNUPGHOME="/path/to/directory"

It mentions that environment variable, defined by gpg(1), but makepkg.conf(5) says

Configuration options for makepkg are stored in makepkg.conf. This file is sourced so you can include any special compiler flags you wish to use. This is helpful when building for different architectures or with different optimizations. However, only the variables described below are exported to the build environment.

`GNUPGHOME' isn't described so I wouldn't expect it to be exported. I suppose it's stated as being `sourced', and makepkg(1) says it's a script, and looking at /usr/bin/makepkg shows it's a bash script, so you could whack an `export' in makepkg.conf too, but it would be nice if makepkg.conf(5) gave explicit approval to arbitrary environment variables if that's intended.

The man page is entirely correct. The file is sourced, and anything sourced in there is, well, sourced, regardless of how "arbitrary" it is. To export something is completely different, how many variables there will desperately need to be marked as something inheritable by child processes? makepkg does not export anything on its own, except for the minimal things which actually need to be, which means compiler things like {C,CXX,LD,MAKE}FLAGS, CHOST, DISTCC_HOSTS Exporting e.g. BUILDDIR could be quite harmful and is in fact the reason why some packages (which depressingly use this generic name as an internal Makefile constant) will not build correctly using yaourt. GNUPGHOME is definitively unlikely to be the same sort of issue... but that's still no reason to declare random things as officially supported and then source them just in case. That being said, it is indeed a good point that I was incorrect and you'd need to: echo 'export GNUPGHOME="$HOME"/.gnupg-makepkg' >> "$HOME"/.config/pacman/makepkg.conf in order to make this work properly. I consider this to be eminently reasonable without further modifications to makepkg.conf(5), since it is described as being sourced after all. -- Eli Schwartz Bug Wrangler and Trusted User

On 07/30/2018 12:23 PM, Ralph Corderoy wrote:

I'll be more clear.

makepkg(1) says `makepkg is a script'. It doesn't say what kind of script, e.g. sh(1), bash(1), ...

makepkg.conf(5) says `This file is sourced', but again doesn't state the language.

Well, on the other hand the actual makepkg.conf contains a *bash* shebang. :) Anyway my default rule when a file is "sourced" is to stick with the lowest common denominator, that is to say, POSIX sh, since it would therefore work regardless. However, in this case makepkg.conf lists a number of options that are part of makepkg.conf's formal API, which are represented by shell arrays, which indicates that POSIX sh is insufficient and you need bash. One who notices this could easily infer without leaving the configuration file, that it is bash. I'll ignore zsh on the grounds that no one *actually* writes programs in zsh... ... So, two points that definitively confirm it is bash, and a guaranteed-safe fallback in sh for people who don't notice this.

Right, that add up to thirty-odd variables. I wasn't arguing that `GNUPGHOME' should be magically exported just be being assigned in makepkg.conf, but stating it won't be exported because, quite reasonably, it isn't in makepkg.conf(5)'s list. Thus some method of exporting it would be required.

But makepkg.conf(5) just shows variable assignments because it's explicit they'll all be exported so the export syntax for this unknown language isn't shown.

It is, technically, a lie that they'll be exported, since many are not but it doesn't specify what it actually means there and basically implies that everything on that page is in fact exported to all subprocesses. Although I'm not sure if this generally matters as the ones used for internal state won't surprise people when some Makefile does not honor them, and moreover, half of them are arrays which aren't variables and cannot be exported as environment *variables*.

Besides, it's a lot more clear to have makepkg.conf(5) say it's bash(1) syntax and any bash code is acceptable, than see it's a list of `VAR=value' and wonder if deviating from that would be fragile and break in the future even if it's OK today. mkinitcpio.conf(5) has the same issue.

Patches welcome! Developers often do not realize that what seems obvious to us (cf. my above inferences regarding the language syntax) are non-obvious to others. When confusion arises, this is a good opportunity to get outside perspective on the matter (and, coincidentally, a sneaky way to trick people into becoming contributors :D). -- Eli Schwartz Bug Wrangler and Trusted User

On 07/27/2018 07:28 PM, Ralf Mardorf wrote:

$ man makepkg | grep GNUPGHOME GNUPGHOME="/path/to/directory"

I'm short in time and apart from this I'm uncertain, if it's worth to add this to the Arch Wiki.

I see no reason to duplicate even more gnupg documentation on the makepkg wiki page. Anyway, it's indicated pretty clearly in the manpage already. -- Eli Schwartz Bug Wrangler and Trusted User

On 07/27/2018 03:10 AM, Ralph Corderoy wrote:

Thanks, I found it on topic, given Peter explicitly mentioned the option, and very helpful. I've added a note to the suggestion in https://wiki.archlinux.org/index.php/GnuPG#Use_a_keyserver

Yes, clearly jumping down the throat of anyone who dares mention they use such an option is super useful, because "it's fair game, they mentioned the option". Because no one ever, like, reads the manpage to understand what they're actually doing or why it helps. Oh well, at least you unlike Mr. Mardorf actually read the wiki page and are therefore qualified to point out that it suggests using an option without also giving the other side of the argument. This is a helpful way to approach things, thank you for noticing and for fixing it. :) Had this been the tone of conversation from the start I would have had no issues whatsoever. This is entirely different from "omg someone uses auto-key-retrieve quickly let me rant about how it is evil".

Am I alone in finding Eli's comments unnecessarily sarcastic and tiresome? I'm happy the Arch Linux community values a succinct and frank exchange of views, but it could still be high signal without the low-wit sarcasm by a few, and would be that bit nicer.

Some people make me more exasperated than others, usually when they make a trend of consistently unhelpful commentary. I'm generally okay with people who don't know a lot, and in fact I hang out in #archlinux-newbie and #archlinux-classroom on Freenode, helping to guide new users when I have the time. It's an entirely different matter when I see something which I don't regard as reasonable at any skill level. I consider this to be compatible with the Arch Linux philosophy of valuing common sense, pragmatism, and users with a do-it-yourself attitude who try to understand how things work... but does not have any goal, either implicit or explicit, of valuing bikesheds, valueless discussion, help vampires, trolls, the enforcement of foreign ideologies (FSF-style freedom is always a popular rallying point), and others. Your subsequent response about the wiki being lacking was useful, high-signal content! That does not absolve the person who jumps into the conversation with "I can't comment on the Wiki, since I didn't read it" from being decidedly low-signal, *continuing what I feel to be a general trend on a personal level*, and thus fair game for my sarcasm, "low-wit" or not. For I consider that to have been trolling. The fact that it had a useful result was entirely accidental and surprising. -- Eli Schwartz Bug Wrangler and Trusted User

Hi Eli,

Yes, clearly jumping down the throat of anyone who dares mention they use such an option is super useful, because "it's fair game, they mentioned the option".

Peter mentioned auto-key-retrieve and in return got Note, auto-key-retrieve means that any software automatically will retrieve new keys from the default keyserver. followed by a pertinent extract of a man page from Ralf. That isn't `jumping down the throat'.

Had this been the tone of conversation from the start I would have had no issues whatsoever.

It was Ralf's first post on the thread AFAICS.

This is entirely different from "omg someone uses auto-key-retrieve quickly let me rant about how it is evil".

There was no rant. When you asked why pointing out auto-key-retrieve's side effects were relevant, Ralf explained his reasoning and politely asked you to explain yours.

Some people make me more exasperated than others, usually when they make a trend of consistently unhelpful commentary.

Then perhaps user support isn't your forte? :-) Personally, for me, its those that won't learn to fish that annoy. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy