[arch-general] aur/solr: Unknown PGP key
Hello, when trying to install the solr package from aur, installation fails because of an unknown PGP key ("051A0FAF76BC6507", according to comment should be "Adrien Grand (CODE SIGNING KEY) <jpountz@apache.org>"). 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? Kind regards Peter
https://wiki.archlinux.org/index.php/Makepkg#Signature_checking -- Morten Linderud PGP: 9C02FF419FECBE16
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
On 07/26/2018 05:45 PM, Peter Nabbefeld wrote:
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* the key is unknown. Have you tried troubleshooting by downloading the key using gpg --recv-keys manually? I don't really see how this has anything to do with solr.
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? -- Eli Schwartz Bug Wrangler and Trusted User
On Thu, 26 Jul 2018 23:45:32 +0200, Peter Nabbefeld wrote:
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.
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'
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 Thu, 26 Jul 2018 23:45:32 +0200, Peter Nabbefeld wrote:
With aura, I've the option to acceppt the package anyway, but I'd prefer to know the correct way.
'makepkg' provides a lot of 'skip' options
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. 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?
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
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
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
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'.
Ah, so, as I expected, it was just a standard prototypical offtopic derail. Thanks for clarifying.
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. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
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
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 ;).
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.
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
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. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
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
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/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 Sat, 28 Jul 2018 23:01:07 -0400, Eli Schwartz via arch-general wrote:
"omg someone uses auto-key-retrieve quickly let me rant about how it is evil"
You are polemic. Netiquette requires to assume good faith. I didn't rant at all, I just informed. You are now trying to mitigate your pitful attitude by continuing snideness. You seemingly need to sent such an off-topic constant howling to the Arch mailing lists, to enhance your personality. I am sorry for you! Most of us have a life apart from computers, which clearly helps to feel good without the need of smug self-satisfaction.
On Sat, 28 Jul 2018 23:01:22 -0400, Eli Schwartz via arch-general wrote:
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.
While I was uncertain, I can only agree with that now. Keep in mind, I anyway import keys knowingly, manually. Try to understand that what you consider trolling, a rant, off-topic, is just a hint. There's no need to read a Wiki, if you know something, as I do in this case. Have you ever take care about the content of your replies? You spend more than 50% of the content by many replies from you, also for topics I'm completely not involved, to degrade skills of other. I bet that a lot of us absolutely don't care, if they have more or less skills than another. Mind your attitude. Why is it that important to you to comment everything somebody sends to the list, that might not apply to whatsoever policy? You can't ignore it? If so, you only hurt yourself. With your childish comments you don't hurt or tutor anybody.
Hi Eli,
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.
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.
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
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. 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. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
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
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
Hi Eli,
I'll ignore zsh on the grounds that no one *actually* writes programs in zsh...
No, true. But tcl(1) has `source filename'. :-)
Patches welcome! ... (and, coincidentally, a sneaky way to trick people into becoming contributors :D).
Quite right, I need to get better organised and try to contribute. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
participants (5)
-
Eli Schwartz
-
Morten Linderud
-
Peter Nabbefeld
-
Ralf Mardorf
-
Ralph Corderoy