Bug 492609

Summary: Review Request: hmaccalc - Tools for computing and checking HMAC values for files
Product: [Fedora] Fedora Reporter: Nalin Dahyabhai <nalin>
Component: Package ReviewAssignee: Jason Tibbitts <j>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review, notting
Target Milestone: ---Flags: j: fedora-review+
kevin: fedora-cvs+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-09 18:55:10 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:

Description Nalin Dahyabhai 2009-03-27 17:22:49 UTC
Spec URL: http://git.fedorahosted.org/git/?p=hmaccalc.git;a=blob;f=hmaccalc.spec
SRPM URL: http://nalin.fedorapeople.org/hmaccalc-0.9.5-1.src.rpm
Description:
The hmaccalc package contains tools which can calculate HMAC (hash-based
message authentication code) values for files.  The names and interfaces are
meant to mimic the sha*sum tools provided by the coreutils package.

Comment 1 Jason Tibbitts 2009-04-01 22:03:28 UTC
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.

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?

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.


* 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.

Comment 2 Nalin Dahyabhai 2009-04-02 00:26:33 UTC
(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!

Comment 3 Jason Tibbitts 2009-04-06 19:16:48 UTC
I understand why you need to generate the checksums after rpm is done poling at the binaries; I was just confused by the language in use:

  This overrides the default which was in place at least from Red Hat Linux 9 
  through Fedora 11's development cycle.

which (to me, at least) sort of sounds like it's overriding some sort of default checksum generation.  Not that's it's in any way material, but perhaps it will explain my confusion.

Anyway, I guess it's not reasonable to run the test suite unless you somehow compile a specal version that doesn't check its checksums.  I guess it would be nice if the executables had some way to skip the verification, but absent that the test suite isn't useful.

Finally, the issue of where to put the checksums.  Given the problems with the alternatives, %{_libdir} seems fine, rpmlint's complaint about it nonwithstanding.

I guess that covers everything.  APPROVED

Comment 4 Nalin Dahyabhai 2009-04-06 22:00:43 UTC
(In reply to comment #3)
> I understand why you need to generate the checksums after rpm is done poling at
> the binaries; I was just confused by the language in use:
> 
>   This overrides the default which was in place at least from Red Hat Linux 9 
>   through Fedora 11's development cycle.
> 
> which (to me, at least) sort of sounds like it's overriding some sort of
> default checksum generation.  Not that's it's in any way material, but perhaps
> it will explain my confusion.

Oh, I see what you mean.  It's overriding the macro to wire in the generation of the HMAC values after the default buildroot policies are run.  I don't have better text ready, but I'd appreciate any suggestions.

> Anyway, I guess it's not reasonable to run the test suite unless you somehow
> compile a specal version that doesn't check its checksums.  I guess it would be
> nice if the executables had some way to skip the verification, but absent that
> the test suite isn't useful.

Yeah, still trying to come up with a good fix for that.

> Finally, the issue of where to put the checksums.  Given the problems with the
> alternatives, %{_libdir} seems fine, rpmlint's complaint about it
> nonwithstanding.
> 
> I guess that covers everything.  APPROVED  

Thanks!

Comment 5 Nalin Dahyabhai 2009-04-08 20:52:40 UTC
New Package CVS Request
=======================
Package Name: hmaccalc
Short Description: Tools for computing and checking HMAC values for files
Owners: nalin
Branches: F-9 F-10 F-11
InitialCC:

Comment 6 Kevin Fenzi 2009-04-09 23:31:35 UTC
cvs done.

Comment 7 Jason Tibbitts 2009-07-29 21:34:15 UTC
Did you intend to push this package to F-10 and F-11?  (Obviously it's too late to push to F-9.)

Comment 8 Jason Tibbitts 2009-11-05 22:46:26 UTC
Is there any reason for this ticket to remain open?

Comment 9 Nalin Dahyabhai 2009-11-06 17:07:20 UTC
(In reply to comment #7)
> Did you intend to push this package to F-10 and F-11?  (Obviously it's too late
> to push to F-9.)  

Yes.  Things keep distracting me from it, though.

(In reply to comment #8)
> Is there any reason for this ticket to remain open?  

Not that I'm aware of...?

Comment 10 Jason Tibbitts 2009-11-07 14:55:47 UTC
Well, it's up to you; close the ticket out when you no longer want it around to remind you of anything.  My job has long since been done.

Comment 11 Nalin Dahyabhai 2009-11-09 18:55:10 UTC
Good enough for me.  Closing.