[arch-general] Pacman makepkg and signatures
Since I don't listen in on irc conversations and haven't picked up on this being discussed on the mailing list, I thought I would go ahead and ask a seemingly dumb question. When building a pacakge from core, extra, or community with makepkg should I locate the signature key for the source tarball and import it into the pacman-key database, or will there be a mechanism for this in the future, or since the same package is used by the devs is it completely unnecessry for me to worry about? Obviously the build completes after issuing the warning about a problem with signature verification and being sure you trust the package so it's not a problem, I'm just trying to stay ahead of the curve. Myra -- Life's fun when your sick and psychotic!
On 24/10/11 14:10, Myra Nelson wrote:
Since I don't listen in on irc conversations and haven't picked up on this being discussed on the mailing list, I thought I would go ahead and ask a seemingly dumb question. When building a pacakge from core, extra, or community with makepkg should I locate the signature key for the source tarball and import it into the pacman-key database, or will there be a mechanism for this in the future, or since the same package is used by the devs is it completely unnecessry for me to worry about? Obviously the build completes after issuing the warning about a problem with signature verification and being sure you trust the package so it's not a problem, I'm just trying to stay ahead of the curve.
pacman-key's gpg database is only for use with pacman. I assume you are rebuilding packages using ABS and have run into a case with the source files have signatures. These are checked using your users gpg keyring, not the pacman one. If you want to verify the signatures are good, then you will need to import the key to your local keyring. Or you could trust the developers have checked it and assume the provided checksum is enough... Depends how paranoid you are. Allan
On Sun, Oct 23, 2011 at 23:24, Allan McRae <allan@archlinux.org> wrote:
On 24/10/11 14:10, Myra Nelson wrote:
Since I don't listen in on irc conversations and haven't picked up on this being discussed on the mailing list, I thought I would go ahead and ask a seemingly dumb question. When building a pacakge from core, extra, or community with makepkg should I locate the signature key for the source tarball and import it into the pacman-key database, or will there be a mechanism for this in the future, or since the same package is used by the devs is it completely unnecessry for me to worry about? Obviously the build completes after issuing the warning about a problem with signature verification and being sure you trust the package so it's not a problem, I'm just trying to stay ahead of the curve.
pacman-key's gpg database is only for use with pacman.
I assume you are rebuilding packages using ABS and have run into a case with the source files have signatures. These are checked using your users gpg keyring, not the pacman one. If you want to verify the signatures are good, then you will need to import the key to your local keyring. Or you could trust the developers have checked it and assume the provided checksum is enough... Depends how paranoid you are.
Allan
I suppose it would count as ABS. I use svn checkout --depth empty the use svn update to get my package builds etc. Then do the terrible thing of running trunk builds for my box on my base and core packages with my makepkg config set to my machine instead of generic. Occassional breakage but Arch has taught me how to fix it and keep going without asking too many dumb questions. As to how paranoid I am, not paranoid enough not to trust the developers or I wouldn't be using Arch. Thanks again for your assistance. Myra -- Life's fun when your sick and psychotic!
A slight variation here; I just upgraded to pacman 4 and did the 'pacman-key --init' as directed but now I get validation errors for all keys while doing a pacman -Syuw'. It looks like this. error: vim-runtime: signature from "Eric Belanger <eric@archlinux.org>" is unknown trust I got this for every package I'm trying to download. During my first attempt to do this upgrade, I got prompted to import keys from the repo. I answered 'y' to all of them. When I tried to do a 'pacman-key --refresh-keys', it showed that I have 12 keys and all are current and supposedly valid. So why the errors and how can I get through this?
2011/10/25 Steve Holmes <steve.holmes88@gmail.com>:
A slight variation here; I just upgraded to pacman 4 and did the 'pacman-key --init' as directed but now I get validation errors for all keys while doing a pacman -Syuw'.
It looks like this. error: vim-runtime: signature from "Eric Belanger <eric@archlinux.org>" is unknown trust I got this for every package I'm trying to download. During my first attempt to do this upgrade, I got prompted to import keys from the repo. I answered 'y' to all of them. When I tried to do a 'pacman-key --refresh-keys', it showed that I have 12 keys and all are current and supposedly valid.
So why the errors and how can I get through this?
In /etc/pacman.conf, uncomment : SigLevel = Optional TrustAll -- Frederic Bezies fredbezies@gmail.com
On Tue, Oct 25, 2011 at 03:00:50PM +0200, fredbezies wrote:
In /etc/pacman.conf, uncomment :
SigLevel = Optional TrustAll
Yeah, I saw that and understand that is appropriate for local packages. But now that I uncomment it, what if I want to tighten up the sig tests in the future. How does one correct the errors. In this current situation, it appears that this signature verification stuff doesn't work. What am I missing? At least at the moment, I can go ahead and upgrade these 126 packages:).
On Tue, Oct 25, 2011 at 11:15 AM, Steve Holmes <steve.holmes88@gmail.com> wrote:
On Tue, Oct 25, 2011 at 03:00:50PM +0200, fredbezies wrote:
In /etc/pacman.conf, uncomment :
SigLevel = Optional TrustAll
Yeah, I saw that and understand that is appropriate for local packages. But now that I uncomment it, what if I want to tighten up the sig tests in the future. How does one correct the errors. In this current situation, it appears that this signature verification stuff doesn't work. What am I missing?
At least at the moment, I can go ahead and upgrade these 126 packages:).
If you want to tighten up, you should use TrustedOnly, instead of TrusAll. That would only consider as valid a signature whose key is present in pacman's keyring and also either signed explicitly by you or trusted by a key from someone you already trusts. The latter is what OpenPGP calls Web of Trust (you can read about it on the web, it's a very interesting subject) I didn't understand what you mean by "correct the errors" and "signature verification stuff doesn't work". Would you mind to elaborate on that? -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On 10/25/11, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
I didn't understand what you mean by "correct the errors" and "signature verification stuff doesn't work". Would you mind to elaborate on that?
I meant that when I did the first updates this morning, I got an eror on every package because the key for each package (signature) wasn't valid. I figured that meant it couldn't be verified or something. Yes, I know little about overall pgp and web of trust so have a lot to learn there. At this point, I'm more enclined to "trust" the signatures or keys from the 12 Arch devs than anyone else right now. I really don't know of anyone with a pgp key I could assume as a trusted party. If I'm using wrong terms here or acting ignorant, it is probably because I am:). So for now I'm using trustall but wonder if that is generally a good idea since someone else could come along with a netharious package and blow the whole thing.
On (10/25/11 10:19), Steve Holmes wrote: -~> On 10/25/11, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote: -~> > -~> > I didn't understand what you mean by "correct the errors" and -~> > "signature verification stuff doesn't work". Would you mind to -~> > elaborate on that? -~> -~> I meant that when I did the first updates this morning, I got an eror -~> on every package because the key for each package (signature) wasn't -~> valid. I figured that meant it couldn't be verified or something. -~> Yes, I know little about overall pgp and web of trust so have a lot to -~> learn there. At this point, I'm more enclined to "trust" the -~> signatures or keys from the 12 Arch devs than anyone else right now. -~> I really don't know of anyone with a pgp key I could assume as a -~> trusted party. If I'm using wrong terms here or acting ignorant, it -~> is probably because I am:). So for now I'm using trustall but wonder -~> if that is generally a good idea since someone else could come along -~> with a netharious package and blow the whole thing. OK, remarks here: 1. Web of trust is something relevant when people actually know each other either directly or indirectly (e.g. through mutual friends). When developers are concerned, for any distro, this concept looses its meaning, because you have no way of knowing them and just have to trust them. This is why the likes fedora and debian don'teven have this TrustAll option (at least I am unaware of such) -- the keys are trusted always. You either have to blindly trust devs key at the gpg level, or use TrustAll. 2. Don't just import keys when pacman asks you, because this opens you to an attack you described. Instead, import keys from the website manually and then be cautious when pacman says that a key is invalid/missing. 3. Due to (1) TrustAll is likely to stay, but you can always replace Optional with Required in due time. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Tue, Oct 25, 2011 at 3:44 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
OK, remarks here: 1. Web of trust is something relevant when people actually know each other either directly or indirectly (e.g. through mutual friends). When developers are concerned, for any distro, this concept looses its meaning, because you have no way of knowing them and just have to trust them. This is why the likes fedora and debian don'teven have this TrustAll option (at least I am unaware of such) -- the keys are trusted always. You either have to blindly trust devs key at the gpg level, or use TrustAll.
2. Don't just import keys when pacman asks you, because this opens you to an attack you described. Instead, import keys from the website manually and then be cautious when pacman says that a key is invalid/missing.
3. Due to (1) TrustAll is likely to stay, but you can always replace Optional with Required in due time.
The trust problem is complex, indeed, but we can at least mitigate it doing the following (it's what I do): 1. set TrustedOnly, instead of TrustAll 2. import the keys when pacman asks 3. # pacman-key --edit-key <email or id for key>. That will open a gpg session. 4. go to http://www.archlinux.org/developers/ and/or http://www.archlinux.org/trustedusers/ to check the new signatures 5. sign the key, checking if the fingerprint is correct, according to the websites from step 4 5. perform save to apply the changes That way, one can be a little more secure when trusting the keys. The point is always checking with different places. Today, there are the keyservers and the Arch developer info pages. Some day, there could be more options (read-only wiki page, fixed BBS posts), so if one is compromised, the others can serve as checkpoints for integrity. IMHO, I don't like TrustAll very much (and the equivalents concepts in other distributions). It takes the responsibility from the users, who are the ultimate decision makers of their systems. But that is just my opinion (not an invitation to a long pointless discussion). We have options enough to satisfy everyone. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On 26/10/11 04:38, Denis A. Altoé Falqueto wrote:
On Tue, Oct 25, 2011 at 3:44 PM, Leonid Isaev<lisaev@umail.iu.edu> wrote:
OK, remarks here: 1. Web of trust is something relevant when people actually know each other either directly or indirectly (e.g. through mutual friends). When developers are concerned, for any distro, this concept looses its meaning, because you have no way of knowing them and just have to trust them. This is why the likes fedora and debian don'teven have this TrustAll option (at least I am unaware of such) -- the keys are trusted always. You either have to blindly trust devs key at the gpg level, or use TrustAll.
2. Don't just import keys when pacman asks you, because this opens you to an attack you described. Instead, import keys from the website manually and then be cautious when pacman says that a key is invalid/missing.
3. Due to (1) TrustAll is likely to stay, but you can always replace Optional with Required in due time.
The trust problem is complex, indeed, but we can at least mitigate it doing the following (it's what I do):
1. set TrustedOnly, instead of TrustAll 2. import the keys when pacman asks 3. # pacman-key --edit-key<email or id for key>. That will open a gpg session. 4. go to http://www.archlinux.org/developers/ and/or http://www.archlinux.org/trustedusers/ to check the new signatures 5. sign the key, checking if the fingerprint is correct, according to the websites from step 4 5. perform save to apply the changes
That way, one can be a little more secure when trusting the keys. The point is always checking with different places. Today, there are the keyservers and the Arch developer info pages. Some day, there could be more options (read-only wiki page, fixed BBS posts), so if one is compromised, the others can serve as checkpoints for integrity.
IMHO, I don't like TrustAll very much (and the equivalents concepts in other distributions). It takes the responsibility from the users, who are the ultimate decision makers of their systems. But that is just my opinion (not an invitation to a long pointless discussion). We have options enough to satisfy everyone.
This is something that will be improved over time... Although it is not finally decided yet, there will likely be a limited number of Arch master keys that a user would have to verify, import and locally sign. These would be very widely published so the user has confidence they are importing the correct key. The master keys would then be used to sign all the devs keys, so the dev keys become trusted through the web of trust rather than having to manually trust them. But all this takes time. We will get there eventually... Allan
On 10/25/11, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
The trust problem is complex, indeed, but we can at least mitigate it doing the following (it's what I do):
1. set TrustedOnly, instead of TrustAll 2. import the keys when pacman asks 3. # pacman-key --edit-key <email or id for key>. That will open a gpg session. 4. go to http://www.archlinux.org/developers/ and/or http://www.archlinux.org/trustedusers/ to check the new signatures 5. sign the key, checking if the fingerprint is correct, according to the websites from step 4 5. perform save to apply the changes
That way, one can be a little more secure when trusting the keys. The point is always checking with different places. Today, there are the keyservers and the Arch developer info pages. Some day, there could be more options (read-only wiki page, fixed BBS posts), so if one is compromised, the others can serve as checkpoints for integrity.
IMHO, I don't like TrustAll very much (and the equivalents concepts in other distributions). It takes the responsibility from the users, who are the ultimate decision makers of their systems. But that is just my opinion (not an invitation to a long pointless discussion). We have options enough to satisfy everyone.
Thanks for the suggested steps. That tells me a bit more about the process. I may give that a try fairly soon.I've done very little with pgp; just setup a personal pgp key pair several years ago and use it with some of my e-mail but other than that, just pretty much left it alone. It seemed like any time I read much about this encryption stuff, it seemed to rise right up way over my head. I suppose I should try and get my head more around this encryption stuff sooner than later.
participants (6)
-
Allan McRae
-
Denis A. Altoé Falqueto
-
fredbezies
-
Leonid Isaev
-
Myra Nelson
-
Steve Holmes