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.
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.
> 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
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.
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.
@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.
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.
No response; closing.