#418 Bundling exception for reaver-wps
Closed: Fixed None Opened 10 years ago by jskarvad.

Hi,

reaver-wps (BZ #1070482) is under review. It is currently bundling significant part of the wpa_supplicant 0.7.3 code. The wpa_supplicant itself is standalone utility not library, and reaver modified the code such a way that will probably never get to upstream (i.e. reaver goal is to exploit weakness of the WPA/WPS, so it is e.g. trying to enforce small DH keys for fast computation, which is apparently against the goal of the wpa_supplicant). Thus it is probably not easy to unbundle the code / turn it into library that would satisfy both projects. Also reaver-wps is tool targeted to skilled admins to do "security audits", so the risk of using unpatched bundled code is probably low. For more details see BZ #1070482.


We discussed this at today's meeting and are inclined to think of this as a fork. However there's one standard question we'd like answered: Is upstream following wpa_supplicant upstream and rebasing on a regular basis or did they take a code drop at one point in time and are now diverging? This won't affect our feeling of whether this is a fork but will affect whether we want to create virtual bundled Provide to query for in case of security bugs in wpa_supplicant.

Replying to [comment:1 toshio]:

Is upstream following wpa_supplicant upstream and rebasing on a regular basis or did they take a code drop at one point in time and are now diverging?

It seems they took the code one time in the past and it seems they don't rebase, i.e. it seems they used wpa_supplicant-0.7.3 and the current version in Fedora is wpa_supplicant-2.0. I would use virtual provide there.

info reaver-wps usage of wpa-supplicant code is a fork: thus allowed and no need for virtual provides. APPROVED: (+1:5, 0:0, -1:0)

You are free to continue the package review now :-) Thanks!

Log in to comment on this ticket.

Metadata