Bug 469553

Summary:	Review Request: asleap - Recovering tool for weak LEAP and PPTP passwords
Product:	[Fedora] Fedora	Reporter:	Fabian Affolter <mail>
Component:	Package Review	Assignee:	Nobody's working on this, feel free to take it <nobody>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	fedora-package-review, notting, tcallawa
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-07-09 15:49:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	201449

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.