Bug 521983

Since there's nothing to actually review here, I'm marking this and the other tickets without specs or srpms or, well, anything as not being ready to review.  Please clear the whiteboard if you actually have something you'd like for someone to look at.

Spec URL: http://people.redhat.com/kwright/osutil/osutil.spec
SRPM URL: http://people.redhat.com/kwright/osutil/osutil-1.3.0-1.fc11.src.rpm
Description: 

The Operating System Utilities Java Native Interface (JNI) package
supplies various native operating system operations to Java programs.

rpmlint /home/mharmsen/PKI/DOGTAG/release/pki/base/symkey/dist/rpmpkg/RPMS/i586/symkey-1.3.0-1.fc11.i586.rpm
symkey.i586: E: invalid-soname /usr/lib/libsymkey.so libsymkey.so
1 packages and 0 specfiles checked; 1 errors, 0 warnings.

readelf -d /home/mharmsen/PKI/DOGTAG/release/pki/base/symkey/dist/rpmpkg/RPMS/i586/usr/lib/libsymkey.so | grep SONAME
0x0000000e (SONAME) Library soname:                                       [libsymkey.so]

We are requesting a waiver for this since 'libsymkey.so' is the native
portion of a JNI library, and won't be used directly by any 'C' program.

correction to comment #3: should have used the osutil information here:

rpmlint /home/mharmsen/PKI/DOGTAG/release/pki/base/osutil/dist/rpmpkg/RPMS/i586/osutil-1.3.0-1.fc11.i586.rpm 
 osutil.i586: E: invalid-soname /usr/lib/libosutil.so libosutil.so
1 packages and 0 specfiles checked; 1 errors, 0 warnings.
        
readelf -d /home/mharmsen/PKI/DOGTAG/release/pki/base/osutil/dist/rpmpkg/RPMS/i586/usr/lib/libosutil.so  | grep SONAME
0x0000000e (SONAME) Library soname:
[libosutil.so]
        
We request a waiver for this since 'libosutil.so' is the native portion of a JNI library, and won't be used directly by any 'C' program.

(In reply to comment #4)
> rpmlint
> /home/mharmsen/PKI/DOGTAG/release/pki/base/osutil/dist/rpmpkg/RPMS/i586/osutil-1.3.0-1.fc11.i586.rpm 
>  osutil.i586: E: invalid-soname /usr/lib/libosutil.so libosutil.so
> 1 packages and 0 specfiles checked; 1 errors, 0 warnings.
> 
> readelf -d
> /home/mharmsen/PKI/DOGTAG/release/pki/base/osutil/dist/rpmpkg/RPMS/i586/usr/lib/libosutil.so
>  | grep SONAME
> 0x0000000e (SONAME) Library soname:
> [libosutil.so]
> 
> We request a waiver for this since 'libosutil.so' is the native portion of a
> JNI library, and won't be used directly by any 'C' program.  

https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI
Quoted:
JAR files that require JNI shared objects MUST be installed in %{_libdir}/%{name}. The JNI shared objects themselves must also be installed in %{_libdir}/%{name}.

The referenced packaging guideline appears to mandate a source code change without any particular security or performance rationale.

As this cross-platform code must run on both 32-bit and 64-bit platforms on multiple architectures, and has been successfully utilized on a number of different JVM versions from multiple vendors over the course of the past decade, upstream does not accept this change without a more sound security or performance rationale.

Additionally, the packaging logic follows the example of a closely related existing Fedora JNI library package called JSS (e. g. - from a machine running 32-bit Fedora 11):

# rpm -qlv jss
-rw-r--r--    1 root    root                   681931 Aug 21 01:34 /usr/lib/java/jss4-4.2.6.jar
lrwxrwxrwx    1 root    root                       14 Aug 21 01:34 /usr/lib/java/jss4.jar -> jss4-4.2.6.jar
-rwxr-xr-x    1 root    root                   176840 Aug 21 01:34 /usr/lib/libjss4.so
drwxr-xr-x    2 root    root                        0 Aug 21 01:34 /usr/share/doc/jss-4.2.6
-rw-r--r--    1 root    root                    25755 Dec 14  2008 /usr/share/doc/jss-4.2.6/MPL-1.1.txt
-rw-r--r--    1 root    root                    17987 Dec 14  2008 /usr/share/doc/jss-4.2.6/gpl.txt
-rw-r--r--    1 root    root                     4680 Apr 25  2004 /usr/share/doc/jss-4.2.6/jss.html
-rw-r--r--    1 root    root                    26436 Dec 14  2008 /usr/share/doc/jss-4.2.6/lgpl.txt

However, in an effort to obtain more detailed information in this area, I am cc'ing Andrew Haley of the Open JDK community for any known security/performance issues regarding the use of "System.loadLibrary()" versus "System.load()".

Created attachment 364163 [details]
Suggested changes for osutil.spec

The following is from an email from 'dgilmore':

the best and cleanest way to fix the way that dogtag builds i think is
to do the specs like the attached osutil spec file.

the biggest change is passing in the variables to ant from the spec file
rather than using perl to grep through the tarballs spec file.  the main
issue is that the spec file in the tarball is irrelevant the canonical
specfile is what will be in fedora's cvs.  at times it will be modified
outside of the maintainers control. those modifications must be preserved.


the attached spec file cleans up the unnecessary macro proliferation. it
works very similar to how we handle configure for the ant use case. its
much easier to read and follow. it doesnt build as ants xml needs some
patching but gives you the idea.

we likely should setup the ant xml to have a sane default if the user
doesn't pass in values.

there is no need to run ldconfig as the .so files are not in %{_libdir}

http://www.javalobby.org/java/forums/t102482.html  gives a small amount
of insight into why we should be using
System.load("some-absolute-path") and not
System.loadLibrary("some-path") for the jni interface. basically it
ensures someone doesn't hijack your load call. with there own .so

updated spec file and src rpm:
Spec URL: http://people.redhat.com/kwright/osutil/osutil.spec
SRPM URL: http://people.redhat.com/kwright/osutil/osutil-1.3.0-1.fc11.src.rpm

per the changelog:

* Tue Oct 27 2009 Matthew Harmsen <mharmsen> 1.3.0-2
- Bugzilla Bug #521983 -  New package for Dogtag PKI: osutil
- Complied with Fedora JNI packaging logic

updated spec file and src rpm:
Spec URL: http://people.redhat.com/kwright/osutil/osutil.spec
SRPM URL: http://people.redhat.com/kwright/osutil/osutil-1.3.0-2.fc11.src.rpm

you must own directories that you create. drop the * off of %{_libdir}/%{name}/* in %files and you will own the directory and its contents.

no need to do the following making LICENSE as a %doc file in %files copies the LICENSE file from the tarball

mkdir -p %{buildroot}%{_datadir}/doc/%{name}-%{version}/
mv %{buildroot}/opt/doc/LICENSE %{buildroot}%{_datadir}/doc/%{name}-%{version}/

spec file updated by mharmsen:

* Fri Oct 30 2009 Matthew Harmsen <mharmsen> 1.3.0-3
- Bugzilla Bug #521983 -  New package for Dogtag PKI: osutil
- Removed LICENSE logic from installation section
- Take ownership of library directory

updated spec file and src rpm:
Spec URL: http://people.redhat.com/kwright/osutil/osutil.spec
SRPM URL: http://people.redhat.com/kwright/osutil/osutil-1.3.0-3.fc11.src.rpm

843573b28350f1ad93fb552c6dd3cb1e869fd39cc2d5e967e6da53c02d7e085a  osutil-1.3.0.tar.gz
843573b28350f1ad93fb552c6dd3cb1e869fd39cc2d5e967e6da53c02d7e085a  fedora/SOURCES/osutil-1.3.0.tar.gz

source matches upstream

rpmlint is quiet
all files and directories owned correctly.
spec file is clear, in english and meets the naming and packaging guidelines.

approved.

New Package CVS Request
=======================
Package Name: osutil
Short Description:  The osutil JNI package supplies various native OS operations to Java programs. 
Owners: kwright
Branches: F-10 F-11, F-12, F-13
InitialCC: ausil

cvs done.

osutil-1.3.1-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/osutil-1.3.1-1.fc11

osutil-1.3.1-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/osutil-1.3.1-1.fc12

osutil-1.3.1-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update osutil'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-13718

osutil-1.3.1-1.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update osutil'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13729

osutil-1.3.1-1.el5.1 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/osutil-1.3.1-1.el5.1

osutil-1.3.1-1.el5.1 has been pushed to the Fedora EPEL 5 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update osutil'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-5/FEDORA-EPEL-2010-0024

osutil-1.3.1-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

osutil-1.3.1-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

osutil-1.3.1-1.el5.1 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

osutil-1.3.1-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/osutil-1.3.1-3.fc11

osutil-1.3.1-3.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/osutil-1.3.1-3.fc12

osutil-1.3.1-3.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/osutil-1.3.1-3.el5

osutil-1.3.1-3.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

osutil-1.3.1-3.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

osutil-1.3.1-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.