Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1409138 - Review Request: pixiewps - An offline WPS bruteforce utility
Summary: Review Request: pixiewps - An offline WPS bruteforce utility
Status: CLOSED DUPLICATE of bug 1573778
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-12-29 19:10 UTC by Leandro Costa
Modified: 2018-05-02 09:05 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-05-01 07:55:36 UTC

Attachments (Terms of Use)
Patch for unbundle libtomcrypt (deleted)
2018-04-23 13:48 UTC, Tomáš Korbař
no flags Details | Diff
Patch for unbundle tomsfastmath (deleted)
2018-04-23 13:50 UTC, Tomáš Korbař
no flags Details | Diff

Description Leandro Costa 2016-12-29 19:10:42 UTC
Spec URL:
Source  :
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.

Comment 1 Michael Schwendt 2016-12-29 21:32:16 UTC
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  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?

> Version: 20161229git

> License: GPLv3+

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):

> %build
> cd pixiewps-master/src
> make

> – Initial Packaging

Absolutely no need to use a non-ASCII character there instead of '-'.

Comment 2 Leandro Costa 2016-12-29 22:11:20 UTC
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.

Comment 3 Leandro Costa 2016-12-30 03:54:13 UTC
Hello, I've fixed the problemns pointed by Michael Schwendt. Here the new links to the files:

Spec URL:

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.

Comment 4 Michael Schwendt 2016-12-30 10:59:03 UTC
> Source1:
> Source2:


> rm -rf pixiewps-master
> unzip -q %{_sourcedir}/
> cp %{_sourcedir}/pixiewps-master/ .
> cp %{_sourcedir}/pixiewps-master/ .

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.

> 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}

Comment 5 Michael Schwendt 2016-12-30 20:55:40 UTC
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:

  | %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.

Comment 6 Leandro Costa 2016-12-30 21:56:46 UTC
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:

Once again, thanks for your help, I'm learning a lot.

Comment 7 Michael Schwendt 2016-12-31 12:03:19 UTC
> 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. ;-)

Comment 8 Leandro Costa 2017-01-02 18:55:41 UTC
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 removed the -q option of the %setup macro as Michael Schwendt suggested. 

Here the link to the new files:

The new links:
Spec URL:

Comment 9 Leandro Costa 2017-01-03 13:54:33 UTC
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:

Comment 11 Michael Schwendt 2017-01-04 21:37:20 UTC
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:

Comment 12 Leandro Costa 2017-01-05 00:32:25 UTC
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 ?

Inside the version.h file it shows 1.2.3 as current version of the snapshot:

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} ?

Comment 13 Michael Schwendt 2017-01-05 13:47:40 UTC
There is



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 The release 1.2.1 said "1.2" release "2" in 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.

Comment 14 Leandro Costa 2017-01-05 19:14:51 UTC
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.

Comment 15 Leandro Costa 2017-01-05 19:40:20 UTC
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:

Comment 16 Tomáš Korbař 2018-04-10 12:24:56 UTC
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.

Comment 17 Tomáš Korbař 2018-04-23 13:48:40 UTC
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.

Comment 18 Tomáš Korbař 2018-04-23 13:50:12 UTC
Created attachment 1425672 [details]
Patch for unbundle tomsfastmath

This patch will unbundle tomsfastmath.

Comment 19 Tomáš Korbař 2018-04-23 14:07:12 UTC
For speedup you can give +karma on

Comment 20 Tomáš Korbař 2018-05-02 09:05:31 UTC

*** This bug has been marked as a duplicate of bug 1573778 ***

Note You need to log in before you can comment on or make changes to this bug.