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 611328 - Review Request: hydra - Fast login cracker
Summary: Review Request: hydra - Fast login cracker
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-04 21:46 UTC by Marcus Haebler
Modified: 2010-11-23 14:39 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-11-23 14:39:55 UTC

Attachments (Terms of Use)

Description Marcus Haebler 2010-07-04 21:46:28 UTC
Spec URL:
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:
 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.

- This is my first package. I am looking for a sponsor. - TIA
- I currently don't have hosting space on
- 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 Jérôme Glisse 2010-07-15 19:24:46 UTC
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 13:53:39 UTC
> Summary: A very fast network logon cracker which supports many different service

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

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

> %build
> %configure  

The two exports are superfluous. See:  rpm --eval %configure

Comment 3 Mohammed Safwat 2010-08-07 14:04:28 UTC
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

- 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 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 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 14:34:52 UTC
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 22:02:15 UTC
@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 The above link was wrongfully copied from another remark.

Comment 6 Jason Tibbitts 2010-11-17 03:13:37 UTC
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 14:39:55 UTC
No response; closing.

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