Spec URL: http://www.benhur.prf.cuni.cz/medved-7/wydobitki/fedora/CVE-2008-0166_fingerprints/CVE-2008-0166_fingerprints.spec SRPM URL: http://www.benhur.prf.cuni.cz/medved-7/wydobitki/fedora/CVE-2008-0166_fingerprints/CVE-2008-0166_fingerprints-0.1-1.fc11.src.rpm Description: Fingerprints of the keys affected by CVE-2008-0166
FAIL no upstream - please put these results to your web page, perhaps to jfch.fedorapeople.org - create a short page for the package - giving back to the comunity OK package meets naming and versioning guidelines. OK specfile is properly named, is cleanly written and uses macros consistently. OK dist tag is present. OK build root is correct. OK license field matches the actual license. OK license is open source-compatible, license text included in package. OK latest version is being packaged. OK BuildRequires are proper. OK no compiler flags OK %clean is present. OK package builds in mock. OK package installs properly. OK no debuginfo FAIL rpmlint complains W: no URL: tag After creating a page for the project, please add "URL:" tag to the spec file OK no provides nor requires OK no %check, no test suite OK no shared libraries are added to the regular linker search paths. OK owns the directories it creates. OK doesn't own any directories it shouldn't. OK no duplicates in %files. OK file permissions are appropriate. OK no scriptlets present. OK code, not content. -- Well, this requires a comment: the package contains data exclusively. The data are precomputed list of compromised keys, as created on computers affected by CVE-2008-0166. The programs made to defend security cannot work without this list, so this package is more similar to a game level data than to a "content". (cf http://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content) OK documentation is small, so no -docs subpackage is necessary. OK %docs are not necessary for the proper functioning of the package. OK no headers, no pkgconfig, .la, nor desktop files. Please fix the two FAIL issues above and I'll approve the package.
What is the benefit of having this packaged in Fedora? Do you plan to package some tool that will actually make use of them in any way? Where do those fingerprints come from? Can the package possibly get some better name? ;)
(In reply to comment #2) > What is the benefit of having this packaged in Fedora? Do you plan to package > some tool that will actually make use of them in any way? Yes, one or two such packages should follow soon. > Where do those fingerprints come from? Jan has computed big part of them, some parts of the list are downloaded from various sources. Yes, that is something that has to be fixed: the sources should be acknowledged. > Can the package possibly get some better name? ;) Do you have any idea? ;-) I wrote my OK when I realized I cannot come to a better name.
(In reply to comment #3) > > What is the benefit of having this packaged in Fedora? Do you plan to package > > some tool that will actually make use of them in any way? > > Yes, one or two such packages should follow soon. Feel free to CC me on bugs for those. Will that be for SSL only or SSH too? > > Can the package possibly get some better name? ;) > > Do you have any idea? ;-) > I wrote my OK when I realized I cannot come to a better name. I had no specific suggestion in mind, Debian/Ubuntu named their packages as open(ssh|ssl|vpn)-blacklist.
(In reply to comment #4) > (In reply to comment #3) > > Feel free to CC me on bugs for those. Will that be for SSL only or SSH too? this is SSH keys > > > I had no specific suggestion in mind, Debian/Ubuntu named their packages as > open(ssh|ssl|vpn)-blacklist. Debian users knows the problem, redhats, may not. I preffer have the matter of weakness mentioned in the name.
(In reply to comment #5) > > I had no specific suggestion in mind, Debian/Ubuntu named their packages as > > open(ssh|ssl|vpn)-blacklist. > Debian users knows the problem, redhats, may not. I preffer have the matter of > weakness mentioned in the name. I do see some of the files seem to come from Debian openssh-blacklist packages (have identical creation dates). Why not getting remaining key sizes included in openssh-blacklist upstream tarball and name Fedora package after it?
Also, is there any good reason why le32_rsa_8192 contains only 5083 fingerprints, rather than full space of ~2^15 keys? It's obviously derived from the HDMoore's *incomplete* set of 8192 bit LE32 keys [1], which, if I remember correctly, was published as incomplete due to time constraints at the time of publication. [1] http://www.metasploit.com/users/hdm/tools/debian-openssl/
> > I do see some of the files seem to come from Debian openssh-blacklist packages > (have identical creation dates). Why not getting remaining key sizes included > in openssh-blacklist upstream tarball and name Fedora package after it? because the next package with full keys will follow instead of debian. > Also, is there any good reason why le32_rsa_8192 contains only 5083 > fingerprints, rather than full space of ~2^15 keys? It's obviously derived > from the HDMoore's *incomplete* set of 8192 bit LE32 keys [1], which, if I > remember correctly, was published as incomplete due to time constraints at the > time of publication. > > [1] http://www.metasploit.com/users/hdm/tools/debian-openssl/ generating 8192 keys is extremly slow both 8192 keys are incomplete, the le64 I finish before release.
I've changed name of package as propossed to openssh-blacklist, aded URL to upstream. Now the package is awailable at Spec URL: http://www.benhur.prf.cuni.cz/medved-7/wydobitki/fedora/openssh-blacklist/openssh-blacklist.spec SRPM URL: http://www.benhur.prf.cuni.cz/medved-7/wydobitki/fedora/openssh-blacklist/openssh-blacklist-0.7-1.fc12.src.rpm
Yeah, like it. APPROVED
New Package CVS Request ======================= Package Name: openssh-blacklist Short Description: Fingerprints of the openssh keys affected by CVE-2008-0166 Owners: jfch2222 Branches: F-10 F-11 InitialCC:
You set fedora-review?, I guess you wanted fedora-cvs? => correcting.
CVS done.
Uhoh... 1 gig SRPM?! Is that intentional? I presume source tar.gz now contains all keys, not only fingerprints. But still, 1 gig SRPM to build 14 meg RPM...
Not all but all generated yet (cca 1/2). I need the contributors espcially for be32 arch. The subpackage with private keys will follow in cca 2 weeks.
Do you plan to introduce some other tool besides iwak that will use those private keys?
Yes me or one of my students want to port some of CR0 tools (http://www.cr0.org/progs/sshfun/) and maybe more.
Ok. This still does not seem to have a very good 'required disk space on mirrors' vs. 'expected number of users of the package' ratio, but maybe it's just me. I'd still consider splitting those private keys subpackages into one with expected keys sizes (1024, 2048, 4096) and those of size less likely to be used in the wild (1023, 2047). Have you seen any research on most commonly used ssh key sizes? Do you have a tool that can be given a pid range and it'll generate all keys in the range? So the effort in generating missing keys can be split across multiple systems?
(In reply to comment #18) > Ok. This still does not seem to have a very good 'required disk space on > mirrors' vs. 'expected number of users of the package' ratio, but maybe it's > just me. Its not only you. If this ends up in the updates repos anyway (shudder) then please at least do it appropriately: no dist tag, single package/build inherited for the different supported releases.
No. If this is only packaging the fingerprints, *only ship the fingerprints in the source*. Frankly, the private/public stuff should be generated on demand if it's that much data.
Replacement of this package will be published soon. There will be only downloader from the website.
Thanks for a very interesting post. What else may I get that kind of info written in such a perfect approach? I’ve got an undertaking that I am simply now operating on, and I have been on the lookout for such info. https://krunkerio.io