This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 611328 - Review Request: hydra - Fast login cracker
Review Request: hydra - Fast login cracker
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low 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: 2010-07-04 17:46 EDT by Marcus Haebler
Modified: 2010-11-23 09:39 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-23 09:39:55 EST
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 Marcus Haebler 2010-07-04 17:46:28 EDT
Spec URL: http://sites.google.com/site/haebler/home/fedora/hydra.spec?attredirects=0&d=1
SRPM URL: http://sites.google.com/site/haebler/home/fedora/hydra-5.7-0.fc12.src.rpm?attredirects=0&d=1
Description: Number one of the biggest security holes are passwords, as every password 
security study shows. Hydra is a parallelized login cracker which supports 
numerous protocols to attack. New modules are easy to add, beside that, 
it is flexible and very fast.

Currently this tool supports:
 TELNET, FTP, HTTP, HTTPS, HTTP-PROXY, SMB, SMBNT, MS-SQL, MYSQL, REXEC,
 RSH, RLOGIN, CVS, SNMP, SMTP-AUTH, SOCKS5, VNC, POP3, IMAP, NNTP, PCNFS,
 ICQ, SAP/R3, LDAP2, LDAP3, Postgres, Teamspeak, Cisco auth, Cisco enable,
 LDAP2, Cisco AAA (incorporated in telnet module).

This tool is a proof of concept code, to give researchers and security
consultants the possibility to show how easy it would be to gain unauthorized
access from remote to a system.

Hydra modules not available in this RPM:
  SVN: Module uses deprecated library calls; SVN also needs APR during build, 
       Hydra's configure script is broken for APR 1.x
  NCP: Required library is not available in the current Fedora repository
  SAP/R3: Required library is not available in the current Fedora repository.

IMPORTANT:
- This is my first package. I am looking for a sponsor. - TIA
- I currently don't have hosting space on fedorapeople.org.
- The license of Hydra has been changed to GPLv3 in the latest version 5.7!!! This should make Hydra compatible with Fedora licensing requirements.
Comment 1 Jerome Glisse 2010-07-15 15:24:46 EDT
I am not an approved reviewer but specs is mostly ok, point that needs improvement/fixing :

Requires on openssl shouldn't be needed as rpmbuild should automaticly add dependency (see fedora packaging guideline)

Split each BuildRequires to have one per line, use libssh2-devel instead of libssh-devel (i don't think this change a lot from hydra perspective and i have the feeling that libssh-devel will eventualy disapear).

Also correct version from 0:5.7-0 to 5.7-0 (or do i miss something about the 0: ?)

* Naming is ok
* spec file correctly named
! Meets packaging guidelines (beside the aforementioned issues)
* Meets Licensing Guidelines GPLv3
! Does not install a desktop file, but should for the frontend
* Does not install manual pages, but upstream does not provide any.

Nice description by the way.
Comment 2 Michael Schwendt 2010-07-23 09:53:39 EDT
> Summary: A very fast network logon cracker which supports many different service
s

Most packages try to be even more concise, e.g.:

  Summary: Very fast network logon cracker which supports many different services


> %build
> export CFLAGS="$RPM_OPT_FLAGS"
> export CXXFLAGS="$RPM_OPT_FLAGS"
> %configure  

The two exports are superfluous. See:  rpm --eval %configure
Comment 3 Mohammed Safwat 2010-08-07 10:04:28 EDT
I amn't a sponsor; this's just a casual review.

- You can substitute the project name directly in the Source0 field instead of the macro %{name} just to facilitate tracking the URL for reviewers, but it's a matter of personal prefernce anyway.

- Unless you really have a strong reason, you should refrain from using epochs in the package version/release scheme(as currently present in the changelog section). See http://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment.

- Consider using %{name} instead of the direct package name in the Patch1 tag and the %prep and %files sections.

- Just a small(optional) hint about the patch, you can do without the -p1 switch in %patch macro if you generate the patch from inside hydra-5.7-src directory. See http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo#.25prep_section:_.25patch_commands for different methods and tips about generating diffs for patches.

- It's OK to start your patch sequence at 1(as in Patch1), but patches typically start from 0 onwards(i.e. Patch0, Patch1, and so on).

- As the build instructions for the main package hydra and subpackage hydra-frontend, you should put the packages in the BuildRequires tag of the subpackage into the BuildRequires tags in the main package. This'll also make the BuildRequires tags specific to the subpackage redundant and unnecessary, and should be therefore removed.

- The comment above Patch1 should indicate its status with the upstream(or indicating it's fedora specific if it really is). See http://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment for details.

- The INSTALL file shouldn't be included in the files installed by the package as %doc, since it contains manual build instructions not relevant to the user. You can remove it under %install section with `rm INSTALL' just before the make install step.

- Under %install section, consider using make with INSTALL="install -p" to preserve timestamps.

- If the Makefile supports DESTDIR(which is most likely the case), consider using DESTDIR instead of PREFIX and DIR with make install.
Comment 4 Michael Schwendt 2010-08-07 10:34:52 EDT
Whether to use %{name} or the expanded "hydra" is completely irrelevant here. Using %{name} makes sense in places where you expect the package name to change and you'd like to reuse spec file fragments.

Nowadays, it's fine to use such macros in the "SourceX" tags, because tools like spectool (from package "rpmdevtools") can expand them when downloading remote files. See e.g.: spectool -g hydra.spec

It's also perfectly fine not to use macros in the "PatchX" tags. "Patch1: hydra-5.7-nosvnapr.patch" refers to a file with exactly that name. And while the package %{name} might change, there is no implicit/automatic renaming of the patch files. You don't win anything by over-using macros.

To apply patches with -p1 is very common, too.

Whether to start with Patch0 or Patch1 is no issue at all, provided that the numbers for the "Patch" tags match the "%patch" commands. That is, avoid using the unnumbered "Patch: foo.patch" tag.
It's widely common for heavily patched packages to remove obsolete patches, too, from time to time. And if you don't close the gaps in the resulting numbering, such spec files don't start with Patch0.
Comment 5 Mohammed Safwat 2010-08-07 18:02:15 EDT
@Michael Schwendt: The remarks I posted about using patches are mostly enhancement points, which might differ from one person to another, as long as there's no obliging consensus about it between fedora packagers. I didn't mean, by any means, that they might render the package strictly non-conformant to the packaging guidelines.

@Marcus Haebler: Correction for the remark about using epochs: The link for this remark should be http://fedoraproject.org/wiki/Packaging/Guidelines#Use_of_Epochs. The above link was wrongfully copied from another remark.
Comment 6 Jason Tibbitts 2010-11-16 22:13:37 EST
There's been plenty of commentary on this ticket but no response at all from the submitter.  Marcus, please respond or we'll have to close this ticket out.
Comment 7 Jason Tibbitts 2010-11-23 09:39:55 EST
No response; closing.

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