Spec URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps.spec SRPM URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps-20161229git-1.fc25.src.rpm Source : http://dev.leandrocosta.pro.br/fedora/pixiewps/master.zip Description: Pixiewps is a tool written in C used to bruteforce offline the WPS pin exploiting the low or non-existing entropy of some Access Points, the so-called "pixie dust attack" discovered by Dominique Bongard in summer 2014. It is meant for educational purposes only. As opposed to the traditional online bruteforce attack, implemented in tools like Reaver or Bully which aim to recover the pin in a few hours, this method can get the pin in only a matter of milliseconds to minutes, depending on the target, if vulnerable. Fedora Account System Username: lokidarkeden Hi there, I'm willing to pack some software for fedora, I this is my first attempt. I hope it's ok. Thaks for your help in advance.
Have you tested this package at all? A simple "rpmbuild --rebuild pixiewps-20161229git-1.fc25.src.rpm" fails early. So, here are some more comments: $ rpmls -p pixiewps-20161229git-1.fc25.src.rpm -rwxrwxrwx master.zip -rwxrwxrwx pixiewps.spec Executable and world-writable. Why? Consider pointing the fedora-review tool at this ticket: fedora-review -b 1409138 It will try to download the latest package files, perform a local test-build and add many helpful checks. What about the manual page? https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation > Version: 20161229git https://fedoraproject.org/wiki/Packaging:Versioning > License: GPLv3+ https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text Plus, subdirectory "crypto" and file random_r.c are not licensed under GPLv3+. > %clean > rm -rf %{buildroot} > > %prep The %clean section is executed _after_ the %install section, so placing it before %prep is senseless. Plus, it should not be defined anymore (unless you have good reason to override the default): https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections > %build > cd pixiewps-master/src > make https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags > – Initial Packaging Absolutely no need to use a non-ASCII character there instead of '-'. https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs
Hello Michael Schwendt, thanks for your observations. The permissions on the files are because my data partition is ntfs, I will move the folder and make the suggested adjustments.
Hello, I've fixed the problemns pointed by Michael Schwendt. Here the new links to the files: Spec URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps.spec SRPM URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps-1.2-2.fc25.src.rpm Source0: http://dev.leandrocosta.pro.br/fedora/pixiewps/master.zip Source1: http://dev.leandrocosta.pro.br/fedora/pixiewps/README.md Source2: http://dev.leandrocosta.pro.br/fedora/pixiewps/LICENSE.md Tested with rpmbuild --rebuild pixiewps-1.2-2.fc25.src.rpm, as sugested, OK. Tested with rpmbuild -ba pixiewps.spec, OK. Installed with dnf install pixiewps-1.2-2.fc25.x86_64.rpm, OK. Fixed Version Number. Fixed Non ASCII Characteres. Removed clean section as sugested. Fixed License section. Added README and LICENSE files. Added manpage. I hope I'm getting on the right path now. :) Thanks again.
> Source1: README.md > Source2: LICENSE.md ??? > rm -rf pixiewps-master README.md LICENSE.md > unzip -q %{_sourcedir}/master.zip > cp %{_sourcedir}/pixiewps-master/README.md . > cp %{_sourcedir}/pixiewps-master/LICENSE.md . What is going on here? Why do you remove the two files and add them back as separate sources? > Version: 1.2 What are the release habits of this project? The version has changed to 1.2.2 in January 2016. https://github.com/wiire/pixiewps/tags https://github.com/wiire/pixiewps/releases/tag/v1.2.2 https://github.com/wiire/pixiewps/archive/v1.2.2.tar.gz > install -p -m 755 pixiewps-master/pixiewps.1 %{buildroot}%{_mandir}/man1 0644 would be correct since a manual page doesn't need to be executable. > make %{?_smp_mflags} https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags
Things you may want to look into: | %prep | %setup -n pixiewps-master The %setup macro will extract the source archive automatically (also if you stick to the .zip file instead of a .tgz). The -n option will tell RPM the name of the top-level source directory. If not using -n, the default would be to enter directory %{name}-%{version}. rpmbuild is clever enough to enter this top-level source directory for every build section (such as %build, %install, %check and even the %files list). You can see that in the rpmbuild output. | %build | cd src | CFLAGS="%{optflags}" make %{?_smp_mflags} This would work already to build with Fedora's global C compiler flags, but the Makefile adds some flags such as -O3 and therefore more will be necessary (such as a trivial patch or some guarded "sed" magic) to adhere to the guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags | %install | cd src | %make_install This _would_ work. Examine output of "rpm -E %make_install" to see what that macro does. However, currently the Makefile is affected by a bug (a duplicated $DESTDIR prefix). There is a pull request at github to fix that. A trivial patch.
Hello again, I did some changes on the spec file, using the %setup macro on the prep section as suggested, and added the option -q for silent running because rpmlint was complaining. My previous use of Source1 and Source2 was to attempt to put the files on the src.rpm. But now I see it's unnecessary. It's fixed in the new spec file. The build section and the install are the same for now, I'm going to do some reading on creating diff files, so I can create the patch to fix the Makefile as suggested. About the versioning, I really don't know how is done on this project. It's a pretty old software and doesn't seems very active. It's used on pentesting, I have it on kali linux, but really like fedora, that's why I'm trying to pack it as rpm :), but I'm going to read more the documentation about versioning using git checkout and make the necessary adjustments. The new links: Spec URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps.spec SRPM URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps-1.2-3.fc25.src.rpm Source0: http://dev.leandrocosta.pro.br/fedora/pixiewps/master.zip Once again, thanks for your help, I'm learning a lot.
> added the option -q for silent running because rpmlint was complaining. Hmmm. Just don't only try to please rpmlint. Decide yourself whether what rpmlint suggests is helpful or not. The setup-not-quiet warning from rpmlint is just a warning, it's not an error not to use -q with %setup. For this tiny package, adding -q reduces the build output log by less than 30 lines. On the contrary, if it were a source archive with hundreds or thousands of files, using -q might make much more sense. And still, a package maintainer may prefer default output of %setup, because displaying the source archive files list in a build.log makes it searchable, for example. You never know what may be discovered thanks to that, such as a [new] bundled library or an incorrectly generated tarball (with the right source dir only in a subdir, or "unclean" and with prebuilt files) -- both cases have happened before. Even if the majority of packages add -q to %setup, there's nothing about it in the guidelines. And with %autosetup, quiet output is the default, but one can add -v for verbose output. ;-)
Hi again, I've updated the package with a patch I've made myself, fixing the double DSTDIR on the Makefile. I'm applying the patch using the macro %patch0 as suggested at https://fedoraproject.org/wiki/How_to_create_an_RPM_package.I removed the -q option of the %setup macro as Michael Schwendt suggested. Here the link to the new files: The new links: Spec URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps.spec SRPM URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps-1.2-4.fc25.src.rpm Source0: http://dev.leandrocosta.pro.br/fedora/pixiewps/master.zip Patch0: http://dev.leandrocosta.pro.br/fedora/pixiewps/Makefile.patch
Me again, this time I've changed the spec file to use the %make_install macro since I was doing it manually. And passed the src directory as parameter to %make and %make_install. Here the new Links, I believe it's fine now :). The new links: Spec URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps.spec SRPM URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps-1.2-5.fc25.src.rpm Source0: http://dev.leandrocosta.pro.br/fedora/pixiewps/master.zip Patch0: http://dev.leandrocosta.pro.br/fedora/pixiewps/Makefile.patch
Fixed the use of macros on the changelog. The new links: Spec URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps.spec SRPM URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps-1.2-6.fc25.src.rpm Source0: http://dev.leandrocosta.pro.br/fedora/pixiewps/master.zip Patch0: http://dev.leandrocosta.pro.br/fedora/pixiewps/Makefile.patch
Anything in reply to comment 4? v1.2.2 is from January 2016. This checkout from git master is also v1.2.2 not v1.2, $ grep _VER pixiewps-master/src/version.h #define SHORT_VERSION "1.2" #define LONG_VERSION "1.2.2" but with a few changes compared with the v1.2.2 release, which effectively makes it either a pre-release of the next version or a post-release of 1.2.2: https://fedoraproject.org/wiki/Packaging:Versioning
Hi, I was reading the wiki in order to understand the versioning... now I'm more confused, on the git repository the last release is 1.2.2 from 2016-01-04, but I'm packing the git version, so... Should I pack the 1.2.2 version or change the spec file to reflect the git checkout version as explained on the section Snapshot packages of https://fedoraproject.org/wiki/Packaging:Versioning ? Inside the version.h file it shows 1.2.3 as current version of the snapshot: PKG_VERSION:=1.2 PKG_RELEASE:=3 Assuming the use of snapshot version, should I change the specfile version tag to 1.2.3, reset the release to 1, and create the section %{checkout} ?
There is version.mk and src/version.h with different versions inside. The former says "1.2" release "3". The latter says "1.2" and "1.2.2". The latter is what is printed by the program itself. See src/pixiewps.c. Note that the code released as 1.2.2 also says "1.2" release "3" in version.mk. The release 1.2.1 said "1.2" release "2" in version.mk. D'oh! Further, the variables defined in there are not used anywhere. Perhaps debian buildpackage specific. However, Debian's pixiewps package is 1.2.2-1 and includes the 1.2.2 release tarball. > Assuming the use of snapshot version, should I change the specfile > version tag to 1.2.3, reset the release to 1, and create the section > %{checkout} ? Well, first of all, the git master you've packaged is not the 1.2.2 upstream release. It is newer than 1.2.2. Calling it 1.2 would be wrong, and the program itself would print "1.2.2", too. It's a small change to the code only, plus the manual page and Makefile fixes. Imagine you would have added such a change to a package as a patch. In that case you would have increased only the package "Release" tag. For such a small code base with such a small change since 1.2.2, applying the post-release snapshot versioning guidelines would be overhead, but nevertheless more correct, since what you've packaged is not the 1.2.2 upstream release. Second, calling the master checkout 1.2.3 already assumes that the next upstream release will be 1.2.3. That may be likely, but one doesn't know yet. Unless you ask upstream. It could also become v1.3. Github shows 1.0.0, 1.0.5, 1.1, 1.2.1 and 1.2.2 releases, no 1.2. Is it a big issue? Probably not in this case. Would adding the %{checkout} stuff from the guidelines to a "Version: 1.2.2" package make a big difference? Not likely. Hardly anyone would care whether it is 1.2.2-3%{?dist} or 1.2.2-3.20161229gitsomething%{?dist}. More important would be to review the small code changes, as it may change behavior compared with the released 1.2.2 and either work or not and come as a surprise to users, who know 1.2.2 already.
Ok, so I'm going to read the documentation on the post-release versioning as you said it's the correct to do, and change the package.
Done, I've changed the version to 1.2.2 to match the value printed by the program and the value in version.h, and add the timestamp of the git checkout to Release field. The new links: Spec URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps.spec SRPM URL: http://dev.leandrocosta.pro.br/fedora/pixiewps/pixiewps-1.2.2-7.20170105git.fc25.src Source0: http://dev.leandrocosta.pro.br/fedora/pixiewps/master.zip Patch0: http://dev.leandrocosta.pro.br/fedora/pixiewps/Makefile.patch
Hello, i can see that pixiewps has some bundled libraries in itself. Specifically TomCrypt in src/crypto/tc and TomsFastMath in src/crypto/tfm. This needs to be fixed before we can add it to Fedora. TomCrypt is already in fedora, but TomsFastMath isnt so it will be necessary to create its package first.
Created attachment 1425670 [details] Patch for unbundle libtomcrypt This patch will unbundle tomcrypt from pixiewps. The file left in tc folder is so changed that i think it is not a part of library anymore and can stay here.
Created attachment 1425672 [details] Patch for unbundle tomsfastmath This patch will unbundle tomsfastmath.
For speedup you can give +karma on https://bodhi.fedoraproject.org/updates/FEDORA-2018-f244a84f25
*** This bug has been marked as a duplicate of bug 1573778 ***