[Bug 492609] Review Request: hmaccalc - Tools for computing and checking HMAC values for files

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=492609





--- Comment #2 from Nalin Dahyabhai <nalin at redhat.com>  2009-04-01 20:26:33 EDT ---
(In reply to comment #1)
> Builds fine; rpmlint says:
>   hmaccalc.x86_64: W: only-non-binary-in-usr-lib
> which is true as there's only a directory and some small text files.  However,
> it touches on my ignorance: I understand what this package does, but I don't
> understand the conventions behind the .hmac files.  What specifically would
> care whether the .hmac files were in a subdirectory of %{_libdir}, whether
> they're off in /usr/share or even stuck in %{_bindir} with the executables? 
> Other packages that have .hmac files seem to put them directly in with the
> libraries. openssl, for instance, has them for the four libraries (two
> symlinked) but not for the executable in /usr/bin.

Nothing else is checking the contents of the files, but since the same source
is used to build the various binaries, they need to be able to figure out where
the files are based on their own names.  I'd been told that non-binary files in
/usr/bin were icky, and they're dependent on the binary, so /usr/share is out,
and that leaves /etc and /usr/lib/<package>.  At that point it was a toss-up.

> Also, I understand the trick with __spec_install_post to get the hmac files
> generated after everything's been processed and debuginfo has been stripped. 
> However, the comment before that bit confuses me:
>   # We need to regenerate the HMAC values after the buildroot policies have
>   # mucked around with them.  This overrides the default which was in place
>   # at least from Red Hat Linux 9 through Fedora 11's development cycle.
> I'm reading into that implication there that something will generate .hmac
> files as a normal part of building things and that needs overriding in this
> case, but I don't think I've ever seen one that wasn't generated manually by a
> package using exactly that __spec_install_post manipulation.  Am I
> misunderstanding things?

Just a bit.  The reason we can't just generate the files during %install is
that the buildroot policy hasn't stripped the binaries yet, and we need to
compute the value for the binary as it's going to look once it's been
installed.
Changing the ambiguous "them" to "binaries".

> Is it possible to run the included test suite?  I tried the naive approach, but
> I just get:
> + ./run-tests.sh
>   /usr/lib64/hmaccalc/sha1hmac.hmac: No such file or directory
> which, I think, might be a clue to my first question above.

You'd have to recompile without a --enable-sum-directory so that the in-tree
copy of the binary would use an in-tree .hmac file rather than attempt to read
the one for the system copy, which would probably have a different value.  I
haven't quite sorted out how to get it to run properly when built with
--enable-sum-directory, but in such a way that it can't be faked out after the
package is built.

> * source files match upstream.  sha256sum:
>    c3f490fb6cbd8d11ba072f9278fc32bac76aa6de51c51167e213add52f5ff153  
>    hmaccalc-0.9.5.tar.gz
> * 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.
> * BuildRequires are proper.
> * compiler flags are appropriate.
> * %clean is present.
> * package builds in mock (rawhide, x86_64).
> * package installs properly.
> * debuginfo package looks complete.
> ? rpmlint has a complaint; I'm not sure how valid it is.
> * final provides and requires are sane:
>    hmaccalc = 0.9.5-1.fc11
>    hmaccalc(x86-64) = 0.9.5-1.fc11
>   =
>    libnspr4.so()(64bit)
>    libnss3.so()(64bit)
>    libnss3.so(NSS_3.2)(64bit)
>    libnss3.so(NSS_3.3)(64bit)
>    libnssutil3.so()(64bit)
>    libplc4.so()(64bit)
>    libplds4.so()(64bit)
>    libsmime3.so()(64bit)
>    libssl3.so()(64bit)
> 
> ? There's a test suite but I don't know if it can be run at build time.
> * 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.
> * no generically named files
> * 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.  

Thanks!

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.