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 469553 - Review Request: asleap - Recovering tool for weak LEAP and PPTP passwords
Summary: Review Request: asleap - Recovering tool for weak LEAP and PPTP passwords
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: FE-DEADREVIEW
TreeView+ depends on / blocked
 
Reported: 2008-11-02 12:06 UTC by Fabian Affolter
Modified: 2009-07-09 17:27 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-09 15:49:45 UTC


Attachments (Terms of Use)

Description Fabian Affolter 2008-11-02 12:06:25 UTC
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 20:36:15 UTC
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 09:37:21 UTC
(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 21:16:38 UTC
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 11:27:32 UTC
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 22:26:56 UTC
Just noticed this was still open.  Did anything ever happen with upstream?

Comment 6 Jason Tibbitts 2009-06-28 17:42:29 UTC
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 15:49:45 UTC
Still no response, so I'm revoking my approval and closing.

Comment 8 Fabian Affolter 2009-07-09 17:27:58 UTC
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.