Re: [suse-security] SuSE ftp and checksums
Are you talking about MD5 sums in a list file on the FTP server? In that case this wouldn't make any sense: who is able to change the RPM packages, would be able to change the list file too...
Just one of the reasons why those MD5 sums are not so useful, which I had argued a few times before on this list.
And perhaps this could then be PGP signed?
Good point! I remember we had this topic here already, and IIRC
Yep
They publish the MD5's in securty announcements that are sent to Bugtraq/etc. These MD5 sums are available in many places, such as my weekly
Fine, but packages are updated on the ftp server for which there is never any advisory. Yet another reason why those MD5s aren't so useful. They would be if they were handled properly, but that is very unlikely to happen.
I seem to rmeber that too. In any case I'll be doing a review of it when it comes out and they'll be roasted (just like I did Debian =) if packages are not signed.
Turn your oven on:
Date: Sun, 06 Aug 2000 22:43:12 +0200 (MEST) From: Roman Drahtmueller <draht@suse.de> Subject: Re: [suse-security] SuSE security reputation, etc.. Cc: suse-security@suse.com [...]
a waste of time anyway. USE GPG-SIGNING - NOW!
Is on its way. But not for 7.0 any more - time was too tight.
:-( On the other hand, I keep in mind that SuSE has, and solves, a large pile of problems Red Hat simply doesn't have (e.g. languages). But I strongly suggested taht MD5s are useless and package signing a necessity when 6.3 was hot off the press!! Volker
Fine, but packages are updated on the ftp server for which there is never any advisory. Yet another reason why those MD5s aren't so useful.
And so, back to my original point: when you have taken the minimal care to include checksums in the advisory, please at least make sure that they are updated when the package itself is later updated. To make this point yet more explicit, I downloaded some packages whose checksums did not match the checksums in the advisories. I made the plausible inference that since their dates of posting were much after the advisory dates, the packages had been updated in the meantime, but not the checksums. Needless to say this is not much of a model of security, if security is your concern... and someone who is downloading patches for security advisories has, on the face of it, a concern for security.
[...]
a waste of time anyway. USE GPG-SIGNING - NOW!
Is on its way. But not for 7.0 any more - time was too tight.
:-(
I'm not sure I can imagine what the grave logistical impediment to introducing signatures is. But we'll have to be happy with a firm promise that they will be used in 7.1! -- Corvin Russell <corvinr@sympatico.ca>
As an example, I just downloaded both k_deflt.rpm and lx_suse.rpm of the 2.2.16 kernel. Since the advisory, which is at http://www.suse.com/de/support/security/suse_security_announce_54.txt the packages have been updated. So have the checksums. You can find the new pckages and checksums at ftp://ftp.suse.com/pub/suse/i386/update/6.4/kernel-2.2.16/ But the problem is that whereas the old checksums are signed as part of the advisory, the new checksums are not. If you read the advisory, "be sure to verify the checksums," and then, e.g., you see that what is listed in the advisory as SuSE Kernel Source Code: 41bde34659d93214af2cf5da6e7e2896 ftp.suse.com/pub/suse/i386/update/6.4/kernel-2.2.16/lx_suse.rpm actually checksums as: c8ecc307942b90e84c4e6058e3ade419 lx_suse.rpm then what is the point? I know the new checksums have been given on the ftp site, but it would be much more reassuring if the checksum list, at least, were signed. Once the checksums have changed, the original signature on the advisory is also fairly useless. Corvin -- Corvin Russell <corvinr@sympatico.ca>
participants (2)
-
Corvin Russell -
Volker Kuhlmann