Hide Forgot
Description of problem: RPM does not allow the Source: tags to have any reference to a possible checksum. For certain issues like: http://bugs.mysql.com/bug.php?id=69512 this means it is impossible to verify that the source provided to build a package is indeed the appropriate one, and this may lead to confusion or incorrectly built packages. Some other package managers do have such a facility and it would be useful to add this functionality I believe. Version-Release number of selected component (if applicable): all versions. How reproducible: Completely. Steps to Reproduce: 1. Build a package using for example mysql-5.6.12.tar.gz, 2. unpack the source tar ball and change something, and repack, build again. 3. There is no possible check in rpm to catch this, so it's not possible to see that the 2 binary packages may indeed be (completely) different. Actual results: Expected results: If a source file had a checksum verification mechanism then it would be immediately obvious that the source file had been modified. Additional info: Obviously this is new functionality and should not break existing packaging but perhaps some sort of _optional_ tag: SourceX_MD5Sum: bad2f6832db3a3feec7ccdbc79d436ba would provide a mechanism for rpmbuild to verify the source files are indeed the expected ones. It doesn't really matter what checksum mechanism is used: MD5, SHA etc are all fine. All we want to know is that the source file is not the expected one and this should prevent rpmbuild from continuing, and it should give a sensible error message like Source4: md5sum checksum failed for mysql-1.2.3.tar.gz. Expected XXXXX, file checksum was YYYYY.
Related to https://bugzilla.redhat.com/show_bug.cgi?id=624123 I guess. Perhaps this needs reporting upstream, but upstream is pretty much owned (partially at least) by RedHat so if this is perceived as useful then I guess it will get implemented. It would also be useful for ensuring that source files are not intentionally tampered with as the checksum would differ on a "tampered" source file, and thus the build from the spec file would fail.
Another reference to show that having different source files with the same name really can happen, I guess in this case unintentionally: http://bugs.mysql.com/bug.php?id=69987
Yes this would be the same thing as bug 624123. From upstream perspective, the feature is considered useful / nice to have but this seems more like rhel-7 material to me at this point. If/when the feature has actually been implemented, the feasibility of backporting could be (re)considered. Note that such a feature needs to have flexible support for multiple digest types, md5sums are considered deprecated from security POV.
I do not tend to write many bug reports for RHEL so if this is categorised incorrectly please adjust as appropriate. I also understand this would be a new feature so is unlikely to go into RHEL6 unless backported from a newer version.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
I dont see this happening in RHEL-6. The RFE itself is entirely reasonable and continues to be tracked on upstream and/or Fedora side of things, but closing this one as DEFERRED.
I have bumped into this again, similar issue. If this can not be fixed in RHEL6 which is no longer the latest version of RHEL, is it possible to fix in a later version of RHEL? Or if not to fix "upstream" (in rpm) so that this issue will eventually make it downstream into the normal rpm distributions? If I should be pushing this via a different route please make it clear to me how or where I should do that as I rarely interact with RH directly even if I do use (and have used) RH Linux and rpm since '94 or so. Many thanks.