I spent several days thinking and investigating several issues about SHA256.
https://fedorahosted.org/spacewalk/wiki/Sha256Support
Fedora 11 Clients with sha256 supported content should be able to
interact with spacewalk and proxy as expected
and on several places we talk about rpm checksum.
We always talk about sha256 checksum. But it noteworthy that exists two
kind of checksums! (I did not know it few days ago):
- one checksum is rpm header and it checksums rpm payload
- second checksum is checksum of whole rpm file.
Spacewalk only store/handle/care about the second one - that is the one,
which is stored in db, primary.xml.gz.
F11 use sha256 for both checksums now. But generally it possible to have
first checksum with in sha256 and secong in md5. And vice versa.
Checksum in header is created when package is build -> we can not change it.
Checksum of whole file is created when repo is created (either
createrepo or our repomd logic), this we can influence.
First bad news. If rpm header contains SHA256, it could not be installed
on RHEL5. Ever. No way. No mixed content if you have package with sha256
in rpm header. Such package can be installed only on F11 and later.
Unless somebody patch directly /bin/rpm.
So if we speak about channels with mixed content, we will speak only
about packages with sha1 or md5 checksum in rpm header.
So only worries which we can have is about checksums in repomd.xml and
primary.xml.gz.
I'm leaving aside only plain channel (only RHEL, or only F11). Just talk
about the problematic one. Mixed content. Channel we want to read on
both RHEL5 and F11. We have following options.
1. We generate only MD5 or SHA1 (rather sha1) checksum.
Pros: It can be parsed by both systems.
Cons: We will have lower security on F11 when it can handle sha256.
2. We generate only SHA256 checksum.
- yum-rhn-plugin will require python-hashlib (which is in epel).
Then yum on EL5 will understand SHA256
Pros: better security
Cons: we force customers to install another package, we will have
another package to test, customers who do not want (or can not -
z-stream) to upgrade will have problem.
3. We generate both MD5/SHA1 and SHA256 checksum.
Pros: no problem, clients will work automagicaly
Cons: little biger repomd
I wrote patch for yum to handle more checksums (now yum pickup last
checksum), but maintainers are hesitate to accept it. They do not see it
as benefit for yum.
It may be possible to parse such repo in yum-rhn-plugin, but there is
danger that we will start draw apart from yum in future.
4. Genereate two repos and based on heuristic serve repo with MD5/SHA1
to EL5 clients and serve repo with SHA256 to F11 clients.
I do not see any other options. And you?
My personal preferences are (from best to worse): 2, 3, 1, 4.
Please share your opinions about this.
--
Miroslav Suchy
Red Hat Satellite Engineering
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
