[opensuse-packaging] Packaging sqlmap
Dear all! I have packaged a pre-release of sqlmap[1], an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers. This tool produces the following failures: E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/32/8.2/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/64/9.0/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/32/8.3/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/mysql/linux/64/lib_mysqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/64/8.4/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/32/9.0/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/32/8.4/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/64/8.2/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/64/8.3/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/mysql/linux/32/lib_mysqludf_sys.so All those shared objects are required to be used on remote systems[2]. It's quite simple to suppress the error messages using a sqlmap-rpmlintrc file, but my question is: Is it ok, to simply package the files with the package or must all of them be built on OBS, which is a quite big job? Best regards, Johannes [1] http://sqlmap.org/ [2] https://github.com/sqlmapproject/sqlmap/blob/master/udf/README.txt -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 11/01/13 13:18, Johannes Weberhofer escribió:
Dear all!
I have packaged a pre-release of sqlmap[1], an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers.
This tool produces the following failures:
E: arch-independent-package-contains-binary-or-object (Badness: 499) hare/sqlmap/udf/mysql/linux/32/lib_mysqludf_sys.so
All those shared objects are required to be used on remote systems[2]. It's quite simple to suppress the error messages using a sqlmap-rpmlintrc file, but my question is: Is it ok, to simply package the files with the package or must all of them be built on OBS, which is a quite big job?
No, what you have to do is remove "BuildArch: noarch" from the spec file. The package contains arch-specific binaries. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Cristian Rodr?guez wrote:
No, what you have to do is remove "BuildArch: noarch" from the spec file.
The package contains arch-specific binaries.
To which architecture it must be assigned? The package contains binaries for multiple architectures not coinciding with host arch. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 11/01/13 14:11, Matwey V. Kornilov escribió:
Cristian Rodr?guez wrote:
No, what you have to do is remove "BuildArch: noarch" from the spec file.
The package contains arch-specific binaries.
To which architecture it must be assigned?
To none, you have to let rpm decide that. The package contains binaries for
multiple architectures not coinciding with host arch.
Then it is broken, the binaries must be built for target the package is being created. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 10.01.13 18:42, schrieb Cristian Rodríguez:
El 11/01/13 14:11, Matwey V. Kornilov escribió:
Cristian Rodr?guez wrote:
No, what you have to do is remove "BuildArch: noarch" from the spec file.
The package contains arch-specific binaries.
To which architecture it must be assigned?
To none, you have to let rpm decide that.
The package contains binaries for
multiple architectures not coinciding with host arch.
Then it is broken, the binaries must be built for target the package is being created.
The package is a noarch package; the .so files are used on the penetrated system; when I understand documentation currect, all .so files must be available after instalation because sqlmap decides during the analysis process which library to inject on the target server. -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Jan 11, 2013 at 07:08:19PM +0100, Johannes Weberhofer wrote:
Am 10.01.13 18:42, schrieb Cristian Rodríguez:
El 11/01/13 14:11, Matwey V. Kornilov escribió:
Cristian Rodr?guez wrote:
No, what you have to do is remove "BuildArch: noarch" from the spec file.
The package contains arch-specific binaries.
To which architecture it must be assigned?
To none, you have to let rpm decide that.
The package contains binaries for
multiple architectures not coinciding with host arch.
Then it is broken, the binaries must be built for target the package is being created.
The package is a noarch package; the .so files are used on the penetrated system; when I understand documentation currect, all .so files must be available after instalation because sqlmap decides during the analysis process which library to inject on the target server.
Hi Johannes, this is a big missunderstanding. If package installs architecture dependent files (assuming all .so files are shared objects, and not something else), then it it not noarch package. As far I can see, all you did is that you have unpacked the binaries from a tarball, which is not how packages are normally done. The normal approach is build everything from source - if nothing it gives you an ability to change things (like where so files will be installed and from where will be loaded). So the reasonable approach is to 1.) remove all .so files from a tarball 2.) build them in %build phase - this implies BuildArch: noarch removal 3.) install them to %{_libdir}/... 4.) change the code to look for them in a %{_libdir} Regards Michal Vyskocil
Hello Michal! Thank you for your response. The think is, that sqlmap per se is a python based software which can simply be executed and is therefore packaged in a noarch file. The tools tries to inject some user defined functions into a target server ( see https://github.com/sqlmapproject/udfhack ). On the server which runs sqlmap, I need to have different libraries for different postgres and mysql versions and for different architectures which is used on the target server that does _not have a sqlmap installation. So for the sqlmap-installation the shared objects are not more than a data-file... Johannes Am 15.01.2013 15:16, schrieb Michal Vyskocil:
Hi Johannes,
this is a big missunderstanding. If package installs architecture dependent files (assuming all .so files are shared objects, and not something else), then it it not noarch package.
As far I can see, all you did is that you have unpacked the binaries from a tarball, which is not how packages are normally done. The normal approach is build everything from source - if nothing it gives you an ability to change things (like where so files will be installed and from where will be loaded).
So the reasonable approach is to
1.) remove all .so files from a tarball 2.) build them in %build phase - this implies BuildArch: noarch removal 3.) install them to %{_libdir}/... 4.) change the code to look for them in a %{_libdir}
Regards Michal Vyskocil
-- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Jan 11, 2013 at 11:18 AM, Johannes Weberhofer
Dear all!
I have packaged a pre-release of sqlmap[1], an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers.
This tool produces the following failures:
E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/32/8.2/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/64/9.0/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/32/8.3/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/mysql/linux/64/lib_mysqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/64/8.4/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/32/9.0/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/32/8.4/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/64/8.2/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/postgresql/linux/64/8.3/lib_postgresqludf_sys.so E: arch-independent-package-contains-binary-or-object (Badness: 499) /usr/share/sqlmap/udf/mysql/linux/32/lib_mysqludf_sys.so
All those shared objects are required to be used on remote systems[2]. It's quite simple to suppress the error messages using a sqlmap-rpmlintrc file, but my question is: Is it ok, to simply package the files with the package or must all of them be built on OBS, which is a quite big job?
Your question seems to have been ignored. It is an unusual question in that the source code for the binary blobs is apparently opensource, you just don't want to have to setup a build mechanism for them I assume. If you want to submit it to factory as "opensource", then those binary blobs I doubt will fly. At a minimum, if you want an exception the legal team will have to weigh-in. ie. In general, for OSS distribution for openSUSE no binary blobs are allowed, but I think that is because of licensing/legal issues. Since the sqlmap package is GPL (per the spec file), opensuse legally has to ensure the source is part of the distribution. That is technically accomplished by simply saying no binary blobs are allowed in the distribution. I doubt you can get an exception, but I'm not a decision maker. I'm not sure about the non-OSS repository or the security repository. If someone could talk to those, then you could make a decision about how to best submit / maintain sqlmap. Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (5)
-
Cristian Rodríguez -
Greg Freemyer -
Johannes Weberhofer -
Matwey V. Kornilov -
Michal Vyskocil