Please, check hashes and keys before downloading packages!
Posts: 440
Just noticed someone making the same point at linuxquestions.org forum which I tried to make here: a worrisome oddity of MEPIS compared with some comparable distros is that by default MEPIS apparently does not support checking md5sum or sha checksums, much less check gpg signatures (if any) of packages before downloading them via a frontend for apt such as synaptic. Debian.org makes a point of stressing that they urge all their developers to provide gpg signatures for all packages, and I believe that in any case they always make checksums available. When I have downloaded e.g. MEPIS iso image, I always check the md5sum and would also check a gpg signature if I could. Same for software (weakest-link and all that). Some might say the risk is small, but I feel very strongly that it is worth making the effort to ameliorate the risk of downloading maliciously altered software. Remember that (to adopt a pseudo-mathematical notation)
Risk = (probability) x (consequences)
Here, the consequences of downloading trojaned packages are undeniably disastrous, so even if the probability is small, the risk could be substantial.
I see this as prudence, not paranoia.
feheeszeno
Is this the same issue
Posts: 380
Is this the same issue discussed here? http://www.mepislovers.com/forums/index.php?topic=2511
Note distinction between verifying hashes and verifying sigs
Posts: 440
Hi,
drlizau and/or Dave_L: there are two seperate issues here:
drlizau: By "package signatures", do you mean MD-5 or SHA-1 hashes, or do you mean GnuPG (gpg) signatures? (kgpg is the KDE front-end for GnuPG, the open-source version of pgp.) Not all packages have gpg signatures, although the Debian project strongly encourages developers to supply a gpg signature, but all should have hashes. MEPIS should check both hashes and signatures by default, in my opinion. I think you might be saying that you believe that MD-5 hashes are verified automatically (that sounds plausible!), and if an MD-5 hash didn't match, I'd get a warning about that. But the warnings I am getting refer to failure to verify gpg signatures, not MD-5 or SHA-1 hashes, I think.
Dave_L: the second issue (gpg signatures) is indeed the one discussed in the thread you cited. My attempts to import the keyring have also failed, as reported by others in that thread:
gpg --keyserver keyring.debian.org --recv 4F368D5D
gpg: requesting key 4F368D5D from hkp server keyring.debian.org
gpg: keyserver timed out
gpg: keyserver receive failed: keyserver error
On the other hand, pinging keyring.debian.org shows that this server is in fact up. Does anyone know how I can check that this key is still valid?
Note that http://www.debian-administration.org/articles/174 seems to suggest that downloading just one Debian developers keyring should suffice, but in the cited thread, it seems that at least one poster felt the solutoin lies in importing individual keys one by one as the need arises in using synaptic. I am about to try that (predicated upon being able to access the repos!).
I feel that it is unacceptable to let either of these issues drop without obtaining good answers. I always take the trouble to verify the MD-5 hash when making a CD backup; this is a complete waste of time if I am installing software I haven't verified at the same level of trust. Does anyone know if MEPIS supports at least automatic checking of MD5 or SHA-1 hashes? If not, I need to know how to fix this BEFORE starting in on my MEPIS 6.0 install.
I also feel that the attitude in the cited thread about the gpg signature verification issue does not sit very well with the hacker creed. "We can't figure out how to do this in five minutes, so we'll just let it drop". Well, you can't LET IT DROP--- security issues are just too important!
feheeszeno
The command "gpg
Posts: 4077
The command "gpg --keyserver keyring.debian.org --recv 4F368D5D" worked for me, try again.
As for MD5s I think that's a feature of apt-get, I don't think MEPIS disables that, where did you get that idea?
--
Check out Mepis wiki: www.mepis.org/docs
Community site: www.mepislovers.com/forums
My Forum Search...
Posts: 66
...on "debian keys" yielded the following as a confirmed, if not somewhat aged, solution:
apt-get install debian-archive-keyring
By default (at least on my 6.0 installations), signatures are automatically confirmed, BTW.
In another thread, which I cannot seem to locate at the moment, I mentioned that I was going to look at the exim4 issue with respect to my servers.
The state of affairs is such that my server MTAs all seem to be sendmail, and I don't have the time to set up another test machine for delving into it at the moment (maybe in a few weeks). In the meantime, you may find some useful information here: http://www.nabble.com/Exim-f13822.html
Website: http://www.gabston-howell.org/
WebLog: http://www.gabston-howell.org/wl/
Must Reads for Newbies:
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.tldp.org/
Hurrah! Erm... Uh-Oh! Uhm... say WHAT?!!
Posts: 440
AdrianTM, you are right, it just worked for me! I think:
gpg: requesting key 4F368D5D from hkp server keyring.debian.org
gpg: key 4F368D5D: public key "Debian Archive Automatic Signing Key (2005)
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
Do I now need to do something to indicate my moderate level of trust of the signature?
Yesterday, when I pinged the server, it was up, but apparently I kept timing out waiting for a response to my request to import the signing key.
Actually, as I said somewhere else, I also suspected all along that apt DOES verify hashes by default (certainly it downloads them and keeps them in its database on localhost), but I wanted someone to show me that this is in fact the case since I couldn't verify this on my own. My guess about my own situation was that I had misconfigured something cryptographic or atp-ic and consequently apt was unable to verify the hashes even though it has been downloading and storing them.
If those error messages about not being able to verify authenticity now go away, of course, I'll be much more willing to assume they DID refer to GnuPG signing key verification after all, and then to assume that importing the previously missing key ring solved the problem.
I forgot to say that I noticed yesterday that two key directories were empty on my machine:
Policies Directory - /etc/debsig/policies
Keyrings Directory - /usr/share/debsig/keyrings
Hmm... they still are empty! Am I supposed to manually move something from somewhere else into these directories, or what?
Hmm.... Oh dear! Just tried updating azureus (which I don't use) as a test, and got the same old warning which scrolls too quickly for me to copy it here, but something to the effect that apg can't verify the authenticity of the package.
Allan: actually, I already installed that package using synaptic or kpackage (can't recall which), so lack of this can't be the problem either. Right now I am pretty confused about what could be causing my error messages.
Ermm... wait a second... noticed some more problems (?): the allegedly imported key was not in my GnuPG keyring. When I tried using the Kgpg key server dialog to import that key and edit it to "marginally trusted", I discovered that it was only valid from 1 Jan 2005 to 1 Jan 2006! No doubt THIS explains the problem! The only public key I know for the Debian developers has EXPIRED!!!!
Any suggestions?
(Allan: about Exim4, yes, thanks in advance, I forget which thread that was in also, but I am still trying to fix the problem where programs expecting to email the root user for localhost at some email address are unable to reach that user, possibly because I am not running a mail server--- and wish not to do so if I can avoid it--- or possibly because I have terribly misconfigured MTAs, or something. For example, if I can become confident that I have cryptology set up properly for outbound mail, perhaps I can arrange to designate my root user's email address as my external email address. On the other hand, if trying to debug this requires me to install a mail server I am quite willing to try that at least as a test to see it solves my "internal system mail" problem. This would be a huge advance for me!)
feheeszeno
Errors from kpackage including mismatched MD-5 sums!
Posts: 440
While writing the preceeding I was trying to update (not upgrade) kpackage. Is this the kind of thing which can be put down to the repos being busy, or what?
apt-get update;echo RESULT=$?
Ign http://apt.mepis.org etch Release.gpg
Get:1 http://security.debian.org etch/updates Release.gpg [189B]
Hit http://apt.mepis.org etch Release
Get:2 http://security.debian.org etch/updates Release [24.3kB]
Ign http://apt.mepis.org etch/main Packages/DiffIndex
Ign http://apt.mepis.org etch/main Packages
Hit http://apt.mepis.org etch/main Packages
Get:3 ftp://ftp.debian.org testing Release.gpg [189B]
Ign http://security.debian.org etch/updates/main Packages/DiffIndex
Ign http://security.debian.org etch/updates/contrib Packages/DiffIndex
Ign http://security.debian.org etch/updates/non-free Packages/DiffIndex
Hit http://security.debian.org etch/updates/main Packages
Hit http://security.debian.org etch/updates/contrib Packages
Hit http://security.debian.org etch/updates/non-free Packages
Get:4 ftp://ftp.debian.org testing Release [74.4kB]
Get:5 ftp://ftp.debian.org testing/main Packages [4190kB]
Get:6 ftp://ftp.debian.org testing/contrib Packages/DiffIndex [2023B]
Get:7 ftp://ftp.debian.org testing/non-free Packages [75.9kB]
Get:8 2006-10-21-1330.36.pdiff [554B]
Get:9 2006-10-21-1330.36.pdiff [554B]
Get:10 2006-10-21-1330.36.pdiff [554B]
Get:11 2006-10-22-1332.30.pdiff [534B]
Get:12 2006-10-22-1332.30.pdiff [534B]
Get:13 2006-10-22-1332.30.pdiff [534B]
Get:14 2006-10-23-1628.44.pdiff [965B]
Get:15 2006-10-23-1628.44.pdiff [965B]
Get:16 2006-10-23-1628.44.pdiff [965B]
Fetched 4369kB in 19m22s (3759B/s)
Failed to fetch ftp://ftp.debian.org/debian/dists/testing/non-free/binary-i386/Packages.bz2 MD5Sum mismatch
Failed to fetch ftp://ftp.debian.org/debian/dists/testing/contrib/binary-i386/PackagesIndex MD5Sum mismatch
Reading package lists... Done
E: Some index files failed to download, they have been ignored, or old ones used instead.
RESULT=100
Only a few days ago I was getting RESULT=0, and I don't know if I broke something or if the problem is beyond my control. If the latter, I don't know what to do next in trying to solve my keyring problem, since even experimenting seems to require working package management.
At least we know that my apt IS checking hashes, as we all thought all along; see the above lines about "MD5Sum mismatch". Of course, the real problem is: did someone hack into the debian repo? Or is this a problem with the data being mangled in transit? (Hopefully the latter, but I seem to recall that bz2 has been trojaned on at least one previous occasion. At least, as I read this, apt cowardly refused to download the packages with faulty sums! Good for you, apt! Paranoid apt is good. Gullible apt would be bad.)
Can anyone explain lines like
Ign http://apt.mepis.org etch Release.gpg
I just tried pinging and these guys to seem to be up and running.
Suggestions?
feheeszeno
it's automated
Posts: 4864
package signatures are checked
if they are not check-able, you get a warning