On Oct 22, 2012, at 9:56 AM, Jan Rękorajski <[email protected]> wrote:
> On Mon, 22 Oct 2012, Jeffrey Johnson wrote: > >> >> On Oct 22, 2012, at 6:44 AM, Jan Rękorajski wrote: >> >>> >>> Rebuilding ~8500 packages is not an option, unfortunately :( >>> >> >> Um … you managed to *build* ~8500 packages using a buggy >> rpmbuild in rpm-5.4.10. >> >> What makes *rebuilding* harder than building? >> >> Note that not all 8500 packages are affected (only %config iirc). > > rpm5 with hmac verification intact (notice package was built with rpm4): > > $ rpm -q -yaml rc-scripts | grep Rpmversion > Rpmversion: 4.5 > > $ rpm -V --nohmacs rc-scripts > .M...... g /var/log/dmesg > > $ rpm -V rc-scripts > ..5..... c /etc/adjtime > ..5..... c /etc/sysconfig/cpusets/cpuset-test > ..5..... c /etc/sysconfig/hwprof > ..5..... c /etc/sysconfig/i18n > ..5..... c /etc/sysconfig/init-colors > ..5..... c /etc/sysconfig/interfaces/down.d/ppp/logger > ..5..... c /etc/sysconfig/interfaces/ifcfg-eth0 > ..5..... c /etc/sysconfig/interfaces/up.d/ppp/logger > ..5..... c /etc/sysconfig/isapnp/isapnp-kernel.conf > ..5..... c /etc/rc.d/rc.local > ..5..... c /etc/crypttab > ..5..... c /etc/sysconfig/network > ..5..... c /etc/sysconfig/static-arp > ..5..... c /etc/sysconfig/static-nat > ..5..... c /etc/sysconfig/static-routes > ..5..... c /etc/sysconfig/static-routes6 > ..?..... c /etc/sysconfig/system > ..5..... c /etc/init/allowlogin.conf > ..5..... c /etc/init/cpusets.conf > ..5..... c /etc/init/cryptsetup.conf > ..5..... c /etc/init/local.conf > ..5..... c /etc/init/modules.conf > ..5..... c /etc/init/random.conf > ..5..... c /etc/sysctl.conf > ..5..... c /etc/init/rc.conf > ..5..... c /etc/init/rcS-sulogin.conf > ..5..... c /etc/init/rcS.conf > ..5..... c /etc/init/sys-chroots.conf > ..5..... c /etc/init/udev.conf > ..5..... c /etc/initlog.conf > ..5..... c /etc/inittab > ..5..... c /etc/modules > .M...... g /var/log/dmesg > > rpm5 with Adam's patch applied (i.e. hmac ripped out): > > $ ./rpm -V rc-scripts > ..5..... c /etc/sysconfig/interfaces/ifcfg-eth0 > ..5..... c /etc/adjtime > ..5..... c /etc/sysconfig/network > ..5..... c /etc/sysconfig/static-routes > ..5..... c /etc/sysconfig/static-routes6 > ..?..... c /etc/sysconfig/system > ..5..... c /etc/sysctl.conf > ..5..... c /etc/inittab > ..5..... c /etc/modules > .M...... g /var/log/dmesg > ..5..... c /etc/sysconfig/i18n > Thanks for details. There are many aspects that need testing for full transparent interoperability as a "fix" is devised. >>>> * second, fix the verification process only, drop hmac support and do it >>>> the good old way. >>> >>> Quick question, does passing '--nohmacs' option give the same effect as >>> your patch to lib/verify.c? In that case we could just make it default >>> and add '--hmacs' option. >>> >> >> Implementing --nohmac as a disabler was the intent. > > It doesn't work as intended then as it disables file digest verification > entirely. > It might be --nohmac or --nohmacs: rghe intent was to have a specific disabler. I'm sure I looked when implementing, but not at the much harder/wider context of interoperability, particularly with rpm-4.5 interoperability. >> Meanwhile adding --nohmac, or patching rpm or counting the no of pkgs isn't >> gointg to repair the headers that do not have the right flag bits. >> >> And if you don't fix the metadata soon, then the problem will persist >> forever, >> and need to be dealt with again and again, because the affected packages >> will be deployed and nothing can change except wait 2-3y. > > Metadata will fix itself over time. The problem here is broken file > digest verification. > Not quite: Claiming "broken file digest verification" claims a boken digest implementation. The issue is a logic incompatibility testing metadata bit(s), not a broken implementation. The fix for a broken digest implementation is quite different, and much harder. E.g. RPM managed to mis-implement both MD5 and SHA1 way back when and had to carry the broken algorithms around for >5y in order to deploy a fix. Broken flag bits are a simpler matter to fix, particularly in the narrower context of "PLD only" with only a recent change from rpm-4.5 <-> rpm-5.4.10 to handle. Fixing the metadata is usually the best option. This may require a patch to rpm build in rpm-4.5 as the most expedient solution as well. How to deploy a fix isn't fully understood (at least by me) quite yet. 73 de Jeff _______________________________________________ pld-devel-en mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
