This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 469553 - Review Request: asleap - Recovering tool for weak LEAP and PPTP passwords
Review Request: asleap - Recovering tool for weak LEAP and PPTP passwords
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2008-11-02 07:06 EST by Fabian Affolter
Modified: 2009-07-09 13:27 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-09 11:49:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Fabian Affolter 2008-11-02 07:06:25 EST
Spec URL: http://fab.fedorapeople.org/packages/SRPMS/asleap.spec
SRPM URL: http://fab.fedorapeople.org/packages/SRPMS/asleap-2.2-1.fc9.src.rpm

Project URL: http://www.willhackforsushi.com/Asleap.html

Description:
asleap is a tool to recover weak LEAP and PPTP passwords. asleap is the
product of the research of weaknesses in Cisco's proprietary LEAP protocol.

asleap can work directly from any wireless interface in RFMON mode and can
perform channel hopping.

Koji scratch builds:
http://koji.fedoraproject.org/koji/taskinfo?taskID=914677

rpmlint output:
[fab@laptop024 i386]$ rpmlint -i asl*
2 packages and 0 specfiles checked; 0 errors, 0 warnings.

[fab@laptop024 SRPMS]$ rpmlint asl*
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Comment 1 Jason Tibbitts 2008-12-20 15:36:15 EST
Indeed, builds fine and rpmlint is silent.

However, this package is GPLv2 (only) and it needs libpcap which is BSD with advertising.  I don't believe this is permitted, but then snort does it so I'm a bit confused.  Blocking the legal tracker so someone who knows can check.

The compiler flags are not correct.  They do include -g, though, so the debuginfo package comes out OK.

I'm concerned that /usr/bin/genkeys is a bit generic.  It conflicts with at least some installs of ntp, although not Fedora's. and liblogtrend has /usr/bin/genkeys.pl (although, again, not in Fedora).  dkim-milter has dkim-genkey and asterisk has astgenkey.

* source files match upstream.  sha256sum:
  92beb6495a856884ca343787ab2f7c9d4b9d3aba21526c2e1f6ba38736c67a23  
   asleap-2.2.tgz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
X compiler flags are not.correct
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint is silent.
* final provides and requires are sane:
   asleap = 2.2-1.fc11
   asleap(x86-64) = 2.2-1.fc11
  =
   libcrypto.so.7()(64bit)
   libpcap.so.0.9()(64bit)

* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
X generically named /usr/bin/genkeys.
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.
Comment 2 Fabian Affolter 2009-01-11 04:37:21 EST
(In reply to comment #1)
> The compiler flags are not correct.  They do include -g, though, so the
> debuginfo package comes out OK.

At the moment the package is not building with the compiler flags.

> I'm concerned that /usr/bin/genkeys is a bit generic.  It conflicts with at
> least some installs of ntp, although not Fedora's. and liblogtrend has
> /usr/bin/genkeys.pl (although, again, not in Fedora).  dkim-milter has
> dkim-genkey and asterisk has astgenkey.

I will get in touch with upstream perhaps they will change the name.
Comment 3 Tom "spot" Callaway 2009-01-12 16:16:38 EST
We're probably okay, since libpcap is 99% 3 clause BSD and the only parts which are BSD with advertising relate to the ATM layer. Lifting FE-Legal, because I'm not losing sleep here.
Comment 4 Fabian Affolter 2009-01-15 06:27:32 EST
Thanks Tom for the legal stuff.  So far there is no answer from upstream.  I will wait some more days and resend the message.
Comment 5 Jason Tibbitts 2009-05-27 18:26:56 EDT
Just noticed this was still open.  Did anything ever happen with upstream?
Comment 6 Jason Tibbitts 2009-06-28 13:42:29 EDT
It's been another month.  I'll go ahead and close this ticket if nothing happens in a week.
Comment 7 Jason Tibbitts 2009-07-09 11:49:45 EDT
Still no response, so I'm revoking my approval and closing.
Comment 8 Fabian Affolter 2009-07-09 13:27:58 EDT
There was no answer from upstream during the whole time this review was open.  Perhaps in the future I will reopen this request if upstream make a statement about the 'genkeys'.  Thanks Jason for your time and your patience.

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