You rock, Cos! I confirm that the centos 6 and fedora repo are also working properly now. Thanks for taking time fixing up the repos!
2015-09-03 12:40 GMT+08:00 Konstantin Boudnik <[email protected]>: > Oh, the new key Id is 0xFA08B173 in case somebody needs to look it up. It > is > signed with my primary key that is the part of Apache WOT. > > Cos > > On Wed, Sep 02, 2015 at 09:31PM, Konstantin Boudnik wrote: > > Ok, as I suspected there's a long standing (at least from 2006) bug in > RPM > > that doesn't allow to validate RPM signature if a subkey has been used > for > > signing. > > > > I ended up generating a new key pair (just for this purpose) and > resigning all > > binaries with it; then resyncing everything with s3. I also have updated > KEYS > > file with the new one. I have quickly ran a test on centos7 by installing > > bigtop-utils on an empty container and everything worked, including > automatic > > import of the keys and the validation/installation of the package. Looks > like > > we are in the clear. > > > > Please shout if you see otherwise. Thanks everyone for your patience! > > Cos > > > > On Wed, Sep 02, 2015 at 02:27PM, Konstantin Boudnik wrote: > > > I think there's a difference between how you've signed the pkgs and > how I did > > > it. I signed with sub-key (as I mentioned before) and yum doesn't > recognize > > > it. Seemingly, it expects that the master key was used for signing. > > > > > > Also, in your repo file below > > > gpgkey=http://archive.apache.org/dist/bigtop/KEYS > > > points to the old keys. The location should be > > > gpgkey=https://dist.apache.org/repos/dist/release/bigtop/KEYS > > > > > > I am pretty sure I have exported my key with --armor option back in > the day. > > > But I will repeat it and see if I can fix the situation, which I also > observer > > > following your steps. If that's the only issue I will update the KEYS > and we > > > should be completed by tonight ;) > > > > > > Thanks for your help! > > > Cos > > > > > > On Wed, Sep 02, 2015 at 03:11PM, Evans Ye wrote: > > > > This is the same issue we're trying to solve in the mailing thread > > > > "convenience artifacts are signed and uploaded". I've built a sample > repo > > > > which works properly by using my own key "Evans Ye" to sign and to > export > > > > GPG KEY. So I believe the following steps should be the right way to > sign > > > > packages and export the gpgkey: > > > > > > > > $ find -name *.rpm | xargs rpm --define="%_gpg_name Evans Ye" > --addsign > > > > > > > > $ gpg --armor --output KEYS --export 'Evans Ye' > > > > I've verified that the hash is matched now in our official repo. > > > > So I guess the main issue left is using non-armored gpg key, if we > manually > > > > import the gpgkey in the repo file: > > > > > > > > [bigtop] > > > > name=Bigtop > > > > enabled=1 > > > > gpgcheck=1 > > > > type=NONE > > > > baseurl= > http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/6/x86_64 > > > > gpgkey=http://archive.apache.org/dist/bigtop/KEYS > > > > > > > > [root@48723d98dc1b ~]# rpm --import > > > > https://dist.apache.org/repos/dist/release/bigtop/KEYS > > > > error: https://dist.apache.org/repos/dist/release/bigtop/KEYS: key > 2 not an > > > > armored public key. > > > > > > > > It gets error. > > > > However, my own exported armored key can be imported without an > error. > > > > That's the different. > > > > > > > > Can you confirm that the gpgkey( > http://archive.apache.org/dist/bigtop/KEYS) > > > > is exported with --armor flag? > > > > > > > > 2015-09-02 13:25 GMT+08:00 Konstantin Boudnik <[email protected]>: > > > > > > > > > Looks like I have figured out what's wrong with my key. And it is > > > > > _nothing_. > > > > > However, it seems that I can not sign RPMs with subkey as YUM can > not find > > > > > the > > > > > key while importing. Can anyone confirm or disprove my train of > thoughts? > > > > > > > > > > Thanks! > > > > > Cos > > > > > > > > > > On Wed, Sep 02, 2015 at 07:42AM, Konstantin Boudnik wrote: > > > > > > I've resynced the repodata once again and I don't see this issue > on the > > > > > > centos7 anymore. However, yum still complains about the key > being no > > > > > > available, but there's a workaround by setting gpgcheck=0 And I > am going > > > > > to > > > > > > figure out what to do with it and why my key isn't working as > expected. > > > > > > > > > > > > I also have discovered that the gpgkey file URL is using the old > > > > > incubation > > > > > > KEYS. Fixed that as well. > > > > > > > > > > > > Please let me know if you still see the issue with checksums > mismatch. > > > > > > Thanks, > > > > > > Cos > > > > > > > > > > > > On Tue, Sep 01, 2015 at 12:44PM, Konstantin Boudnik wrote: > > > > > > > I think this is the consequences of me fighting with the > package > > > > > signing... ;( > > > > > > > A couple of days ago I have re-ran 'createrepo' for all the > RPM-based > > > > > distros > > > > > > > and uploaded new repo files to the release. Not sure why the > checksums > > > > > differ > > > > > > > now... > > > > > > > > > > > > > > I will take a look into this again tonight. > > > > > > > Cos > > > > > > > > > > > > > > On Tue, Sep 01, 2015 at 09:39PM, Olaf Flebbe wrote: > > > > > > > > I can second it: > > > > > > > > > > > > > > > > I added to /etc/yum.repo.d/meins.repo > > > > > > > > > > > > > > > > [meins] > > > > > > > > name=Bigtop epo > > > > > > > > baseurl= > > > > > http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/7/x86_64/ > > > > > > > > enabled=1 > > > > > > > > gpgcheck=0 > > > > > > > > priority=1 > > > > > > > > > > > > > > > > and got > > > > > > > > ............ > > > > > > > > Downloading packages: > > > > > > > > hbase-0.98.12-1.el7.centos.noa FAILED > > > > > =============================================-] 849 kB/s > | 62 > > > > > MB 00:00:00 ETA > > > > > > > > > > > > > > http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/7/x86_64/hbase/noarch/hbase-0.98.12-1.el7.centos.noarch.rpm > : > > > > > [Errno -1] Package does not match intended download. Suggestion: > run yum > > > > > --enablerepo=meins clean metadata > > > > > > > > Trying other mirror. > > > > > > > > ............. > > > > > > > > > > > > > > > > Olaf > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
