I'm unhappy that I have to claim for your help again but I'm encountering some trouble installing LXDE. The problem ist discribed precisely in the internet and there are workarounds given to get things straighten out but I think, there might be some drawbacks.
One place the error is discribed is in the bugsection of this page. The bug is marked as closed over there giving the reason that it's fixed. Nevertheless I keep encountering that error. As an additional comment about closing "archlinux-keyring 20130525-2" is given. I checked that package. It is already installed on my machine.
As aforementiones ther are some workarounds. One is given by flexiondotorg who suggest to just reenable the relevant key. That might work for sure but I guess there is a reason for the key being disabled. Maybe there are some pagages, maybe malicious ones, signed using that key without authorization. That it would be advisable not to reenable that key, wouldn't it?
Now I'm left alone with two questions I'm not able to find a satisfying answer for myself. First of all I'm wondering, why the bug report is closed and marked as fixed, while I continue to get exactly the same error. Is it going to be fixed anyway or it's just me who doesn't see the point how it is fixed?
The second arising question is whether there is a way to get the LXDE package anyway making sure that the package is not manipulated using a stolen key from Mr. Wallace.
Last edited by disjunkt (2013-07-04 05:07:45)
That didn't change anything. But thanks for your effort anyway.
If I understand alright, there will be some revoked files to be supposed to disable the keys hold by that file. But for whatever reason it's disabling also keys not hold by that file. Eventually I'm not able to proof whether the very key is disabled intentionaly or accidentally. The suggested workaround ist exactly the same I mentioned beforehand.
Maybe I am wrong on this, but as far as I understand falconindys comments in the thread, the problem was that some older versions of pacman, when prompted to disable specific sub-keys, didn´t check the full fingerprints of the keys, but only partial ones. (This got fixed here). So this could lead to problems as yours. The key in question was accidentally disabled because of this behavior. So there should be no danger in reenableing it, as the "workaround" suggests.
Anyway, you can always check the fingerprint of Mr Wallace key. If anyone had tampered with his public keys, it would be different.
Hope I don´t produce just white noise with my answers
Last edited by kyogen (2013-06-25 15:26:11)
I hadn't checked the fingerprints manually until now. But the insight is kind of interesting. Apparently the key in question that I'm advised to reenable is a sub uid that is actually not signed by one of the five master keys. On the other hand the uid that pacman complains about as being disabled is signed by all five master keys.
If I understand alright again, the only revoked thing in this UPG key is a redundant selfsigning of a uid. That uid is not signed by any of the master keys, yet it's not used to sign the lxde package. At this point I'm confused about why pacman and gpg respectively are checking on that uid while another uid is actually used to singn that package. Moreover I'm wondering why pacman will state that the key is disabled if the key is itself is not but just not signed by anoter (master) key.
I actually don't get it yet. Seems to me, like I have some further reading on the gpg thing to do later this week.
Ok, i did my homework and got some enlightments. You can disable, revoke and delete a key and their components respectively. But each one of these mean a (slightly) different thing obviously.
If you have to void a key, for whatever reason, you'll have to delete or rather revoke the key. However there are some advantages to revoking the key. I'm not going to carry that out in detail, but you can do some reading about that stuff in The GNU Privacy Handbook. By the way, the "redundant selfsigning" ist not a redundant selfsigning, but a rovoking of the uid. That's also explained in the Privacy Handbook.
Disabling a key on the other hand is not described in the Privacy Handbook but there is a brief description in the GnuPG (2.0) manual stating that you can "Disable or enable an entire key. A disabled key can not normally be used for encryption." If i understand alright, that will be just a local setting. If you disable a key, won't be used for encryption on your machine, but it would not effect others. Disabling and enabling a key or a key component doesn't change anything with that key. A revoked key will stay revoked.
Finally I'm not 100% sure, but I think re-enabling a key shouldn't affect any security concerns. Please correct me, if I'm misled. Or if you can confirm that for sure, you'll be very welcome to do that as well. Besides that I can't think about a reason why you disable a key. Maybe someone can also point me in a direction here.
I don't want to be rude, but i think this thread is going off topic. Your questions are about encryption in general, and no longer about your original problem. Please mark this thread as solved (or closed). Or rephrase your question, if you still don't know what to do about the lxde-packages, so maybe someone can help you. Moderators on the forum are very quick in shooting down threads which are no longer focused on the problem in the title.
But nevertheless, i'm trying to answer your question the best i can: disableing a key can be usefull when it gets compomised (i.e. the associated private key gets stolen). A revokation-certificate is just a way of telling everyone else, who uses your public key, that this key should be disabled and no longer be used. (So disableing keys is something you would normally only do with public keys from other people.)
In the case of Daniel Wallace key, a certain user-id (email-address) in his key was to be disabled (as you said: it's not used to sign the packages; maybe it got introduced erroneously), not the whole key itself. But a bug in pacman led to the whole key being disabled, not just the one id associated with it. This resulted in some users being no longer able to verify the signature on the lxde-packages. Reenableing the key will just give you back the possibility to verify this signatures.
So, to break it down: reenable the key. It won't affect the security of the packages you download.
Last edited by kyogen (2013-07-01 19:40:15)