Spec URL: http://sagarun.fedorapeople.org/SPECS/cowpatty.spec SRPM URL: http://sagarun.fedorapeople.org/SRPMS/cowpatty-4.6-1.fc12.src.rpm Description: cowpatty is designed to audit the pre-shared key (PSK) selection for WPA networks based on the TKIP protocol. It can perform both dictionary and computed rainbow table attacks.
A few quick notes on your specfile: * You should use macros in the Source URL in line 9: http://wirelessdefence.org/Contents/Files/%{name}-%{version}.tgz * I think using the macro in the description (line 14) is not an appropriate elegant solution * You should use make, rm and install directly instead of the macros (lines 25, 28, 29, 30 and 34) * The BuildRoot-tag in line 10 is not necessary anymore as per guideline [1], you can remove it at your option unless you like to push your package also in EPEL * You can use the name macro in the target paths in lines 29 and 40 instead of writing "cowpatty" * You have 79 chars per line for your description, but you're actually using just 53 per line. Maybe you like to improve that :) [1] http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag
(In reply to comment #1) > A few quick notes on your specfile: > * You should use macros in the Source URL in line 9: > http://wirelessdefence.org/Contents/Files/%{name}-%{version}.tgz Agreed :-) . I don't know how i missed it. > * I think using the macro in the description (line 14) is not an appropriate > elegant solution Agreed. > * You should use make, rm and install directly instead of the macros (lines 25, > 28, 29, 30 and 34) Before people have recommended using macros instead of direct commands. May i know the reason for your suggestion? > * The BuildRoot-tag in line 10 is not necessary anymore as per guideline [1], > you can remove it at your > option unless you like to push your package also in EPEL Agreed. Will remove that line. > * You can use the name macro in the target paths in lines 29 and 40 instead of > writing "cowpatty" Agreed . Will use macros. > * You have 79 chars per line for your description, but you're actually using > just 53 per line. Maybe you like > to improve that :) > Will make use of 79 chars per line :-)
Hi Arun, thanks for helping us with the security spin. Some comments on the macros in your spec. I have to say I don't full agree with Dominic. Generally speaking you should use macros where it makes things easier for you, for example for things that change a lot or for code that can be shared between spec files. For example I maintain a lot of xfce4-panel plugins and all have a page in the Xfce wiki, so I can use http://goodies.xfce.org/projects/panel-plugins/%{name} while I normally would use the full URL. > %{name} is designed to audit the pre-shared key (PSK) no need to use a macro here as this only appears once in the spec, will never change and cannot be copied over to another spec. > %{_bindir}/cowpatty Here it might make sense to use %{_bindir}/%{name} because it is a common phrase in many specs. Please don't use macros for trivial things like %{__install} or %{__rm}. This has recently been discussed on the devel mailing list: http://lists.fedoraproject.org/pipermail/devel/2010-March/133466.html
> Please don't use macros for trivial things like %{__install} or %{__rm}. This > has recently been discussed on the devel mailing list: > http://lists.fedoraproject.org/pipermail/devel/2010-March/133466.html Thanks for pointing this out Christoph. That saved me searching the source for my answer to Arun. ;) Arun, unfortunately I'm facing serious building problems with cowpatty. First, there is to say, rpmlint claims a debuginfo-without-sources error message on the debuginfo package. This basically is easily solved, by passing the optflags to configure - what the %configure macro actually already does. Since your upstream tarball doesn't provide a configure script at all, there is an alternate way to compile programs with the optflags, you can change your build command in the %build section to the following: make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" Unfortunately trying to build with that, that causes some openssl problems, even with having openssl-devel installed (Note you will first have to add missing BuildRequires for openssl-devel and libpcap-devel also). I will attach the concerning output here. Could you have a look at those and fix them - maybe in coorporation with upstream? I didn't finish the review yet, also because of the above mentioned compiler problems, but there are two more small things I noticed: * The INSTALL file doesn't need to be installed with the package, since there is no useful documentation for the user after he already installed the package. * There were some compiler warnings, but I guess upstream should already know about them
Created attachment 405760 [details] output of rpmbuild or rather gcc when trying to build cowpatty
*** Bug 231011 has been marked as a duplicate of this bug. ***
Hi, Sorry for the late reply. I will write regarding this problem to upstream. Is there any way this could be solved? We should use autotools?
I unfortunately couldn't find out the reason for this issue. I guess a deeper look into the sources will be necessary and this actually will be easier for upstream who know their sources. There is no explicit need for usage of autotools or an alternate build-system (e.g. waf) as long as the program would build without a build system and just with a Makefile. Anything else would unnecessary bloat the tarball. :)
I contacted the upstream, no response yet, However i added the following flags (borrowed from makefile) in %build section of the spec %build make %{?_smp_mflags} CFLAGS="%{optflags} -pipe -Wall -DOPENSSL -O2 -g3 -ggdb" Now there is no problem building it. I am wondering whether adding such flags after optflags is acceptable?
It actually should be enough to write it like this: make %{?_smp_mflags} CFLAGS="%{optflags} -DOPENSSL" since there are some flags already included in the %{optflags} macro. You can check that out with 'rpm --eval %{optflags}'. :) Could you try if that works for you too and then provide a current specfile and srpm? I will do the formal review then. :)
SPEC URL: http://sagarun.fedorapeople.org/SPECS/cowpatty.spec SRPM URL: http://sagarun.fedorapeople.org/SRPMS/cowpatty-4.6-2.fc12.src.rpm
$ rpmlint cowpatty.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. $ rpmlint cowpatty-4.6-2.fc12.src.rpm cowpatty.src: W: spelling-error %description -l en_US pre -> per, ore, pee 1 packages and 0 specfiles checked; 0 errors, 1 warnings. This spelling-error can be ignored. "pre-shared key" is a correct and common term. $ rpmlint cowpatty-4.6-2.fc12.x86_64.rpm cowpatty-debuginfo-4.6-2.fc12.x86_64.rpm cowpatty.x86_64: W: spelling-error %description -l en_US pre -> per, ore, pee 2 packages and 0 specfiles checked; 0 errors, 1 warnings. The spelling-error is okay, see above. Package Review ============== Key: - = N/A x = Check ! = Problem ? = Not evaluated === REQUIRED ITEMS === [x] Package is named according to the Package Naming Guidelines [x] Specfile name matches %{name}.spec [x] Package seems to meet Packaging Guidelines [x] Package successfully compiles and builds into binary RPMs on at least one supported architecture. Tested on: Fedora 12/x86_64 [x] Rpmlint output: source RPM: see above binary RPM: see above [x] Package is not relocatable. [x] License in specfile matches actual License and meets Licensing Guidelines License: GPLv2 [x] License file is included in %doc. [x] Specfile is legible and written in AE [x] Sourcefile in the Package is the same as provided in the mentioned Source SHA1SUM of Source: 2dc09d725e4131a68a33c8717d3a7317e5616df2 [x] Package compiles successfully [x] All build dependencies are listed in BuildRequires [-] Specfile handles locales properly [-] ldconfig called in %post and %postun if required [x] Package owns directorys it creates [-] Package requires other packages for directories it uses. [x] Package does not list a file more than once in the %files listing [x] %files section includes %defattr and permissions are set properly [x] %clean section is there and contains rm -rf %{buildroot} [x] Macros are consistently used [x] Package contains code, or permissable content. [-] Large documentation files are in a -doc subpackage [x] Program runs properly without files listed in %doc [-] Header files are in a -devel package [-] Static libraries are in a -static package [-] Package requires pkgconfig if .pc files are present [-] .so-files are put into a -devel subpackage [-] Subpackages include fully versioned dependency for the base package [-] Any libtool archives (*.la) are removed [-] contains desktop file (%{name}.desktop) if it is a GUI application [x] Package does not own files or directories owned by other packages. [x] %{buildroot} is removed at beginning of %install [-] Filenames are encoded in UTF-8 === SUGGESTED ITEMS === [x] Package contains latest upstream version [x] Package does not include license text files separate from upstream. [-] non-English translations for description and summary [x] Package builds in mock Tested on: F12/x86_64 [!] Package should compile and build into binary RPMs on all supported architectures. tested build with koji, does not work, see below [x] Program runs [-] Scriptlets must be sane, if used. [-] pkgconfig (*.pc) files are placed in a -devel package [-] require package providing a file instead of the file itself no files outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin are required ===Issues to be fixed=== * There is a file radiotap.h which license is not GPLv2. According to the Packaging Guidelines [1] you will have to handle that in the License: tag field and add a comment above: # The entire source code is GPLv2+ except radiotap.h which is BSD License: GPLv2 and BSD * The package does not build with koji. There are some issues with the Makefile which prevent the build from working properly with the smp flags. I suggest to remove the smp flags temporarily to work around the issue: make CFLAGS="%{optflags} -DOPENSSL" Ideally this should be fixed by upstream. I will have another look on this issue these days. Until it is finally resolved the above mentioned workaround is appropriate I think. Anything else looks good so far, so the package is APPROVED. Remember to fix the mentioned issues first before checking in the specfile into CVS. [1] https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios
Oh, and I forgot to mention: Write a comment above the make command line which explains that the build fails with smp flags. :)
New Package CVS Request ======================= Package Name: cowpatty Short Description: Audit WPA pre-shared keys Owners: sagarun Branches: F13
CVS Done
cowpatty-4.6-3.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/cowpatty-4.6-3.fc13
cowpatty-4.6-3.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.