This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 492609 - Review Request: hmaccalc - Tools for computing and checking HMAC values for files
Review Request: hmaccalc - Tools for computing and checking HMAC values for f...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-27 13:22 EDT by Nalin Dahyabhai
Modified: 2009-11-09 13:55 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-09 13:55:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Nalin Dahyabhai 2009-03-27 13:22:49 EDT
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 18:03:28 EDT
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-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!
Comment 3 Jason Tibbitts 2009-04-06 15:16:48 EDT
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 18:00:43 EDT
(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 16:52:40 EDT
New Package CVS Request
=======================
Package Name: hmaccalc
Short Description: Tools for computing and checking HMAC values for files
Owners: nalin@redhat.com
Branches: F-9 F-10 F-11
InitialCC:
Comment 6 Kevin Fenzi 2009-04-09 19:31:35 EDT
cvs done.
Comment 7 Jason Tibbitts 2009-07-29 17:34:15 EDT
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 17:46:26 EST
Is there any reason for this ticket to remain open?
Comment 9 Nalin Dahyabhai 2009-11-06 12:07:20 EST
(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 09:55:47 EST
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 13:55:10 EST
Good enough for me.  Closing.

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