I'm trying to commit an update to cppcheck, but $ git push key_from_blob: remaining bytes in key blob 36 cert_parse: Invalid signature key type unknown (11) key_from_blob: can't parse cert data cannot decode server_host_key_blob fatal: The remote end hung up unexpectedly This makes me think it's an issue with the certificate, but the check is also broken $ fedora-cert Traceback (most recent call last): File "/usr/bin/fedora-cert", line 85, in <module> main(opts) File "/usr/bin/fedora-cert", line 52, in main if fedora_cert.certificate_expired(): File "/usr/lib/python2.6/site-packages/fedora_cert/__init__.py", line 83, in certificate_expired if my_cert.has_expired(): AttributeError: 'NoneType' object has no attribute 'has_expired' I was able to get new certificates by \rm ~/.fedora*.cert and rerunning fedora-packager-setup, but I'm still getting the git push error.
Reassigning to patrick. Infrastructure made changes that break the ability of rhel6 and older machines to communicate via ssh. We would need patrick to undo those changes for RHEL 6 to be used a a packager platform.
It could be fine just to hint for a workaround. Personally, to work with fedora infrastructure from el6 machine, I was already compelled to install new krb5 package (derived from el7 version) into /usr/local and play with it. All works fine then. Probably, now I need new openssh-6.x as well? I see I even cannot "ssh ssh.fedorapeople.org" with some similar error reports... IOW, if it seems not reasonable to handle el6 properly (too few users etc.), please, describe a workarounds -- i.e. what packages whould be overriden (f.e. by /usr/local) what config files to change etc.
Well, after installing openssh-6.6 (hackishly derived from RHEL7), "fedpkg clone" and "fedpkg push" work well, as well as "ssh ssh.fedorapeople.org". "fedpkg new-sources" still not working, no idea what to do firther... :(
Well, "fedpkg new-sources" start to work after manually removing ~.fedora*.cert files.
MY WAY to cause things work under EL6 : 1) New krb5 >= 1.14 , compiled and installed in /usr/local It is needed at least because the system krb5-1.10 does not understand things like "kdc = https://some_kdc_proxy_url" . I use vanilla upstream tarball (seems enough for me), use "%configure --libdir=/usr/local/lib64", only libraries (whole) and /usr/local/bin/{kinit,kdestroy} are actually needed. Since system krb5 does not support "include" in config files, I have to manually move /etc/krb5.conf.d/*fedoraproject_org data to the main /etc/krb5.conf, to allow both kerberoses to use the same config file. Then create wrapper /usr/local/bin/fedpkg, which just calls the system one after the exporting LD_LIBRARY_PATH=/usr/local/lib64:/lib64:/usr/lib64 2) New OpenSSH >= 6.6 I use a source derived from RHEL7 srpm: rpmbuild -bp openssh.spec --nodeps then build manually: LIBS='-lkrb5 -lkrb5support -lk5crypto -lcom_err' CFLAGS=-I/usr/include/gssapi CPPFLAGS=-I/usr/include/gssapi ./configure --with-kerberos5=/usr make -j4 then foo on failed linking of sshd binary, since ssh binary already done (Uggly...), then place just builded "ssh" binary as /usr/local/bin/ssh 3) Manually remove ~/.fedora*cert files, probably making sure the file ~.fedora.upn exists and contains your FAS login name (without the ending newline). I very hope that by collecting such user experiencies some special rpms could be done in future.
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version. Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version. Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version, you are encouraged to change the 'version' to a later version prior this bug is closed as described in the policy above.
EPEL el6 changed to end-of-life (EOL) status on 2020-11-30. EPEL el6 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of EPEL please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.