Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/20/2015 08:27 AM, Richard Haines wrote:




On Monday, 19 October 2015, 19:10, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
On 10/18/2015 11:00 AM, Richard Haines wrote:


  On Sunday, 18 October 2015, 15:07, Dominick Grift
<dac.override@xxxxxxxxx> wrote:

  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA512

  On Sun, Oct 18, 2015 at 12:48:12PM +0000, Richard Haines wrote:
    I added openssl to libselinux to support the new
selabel_digest(3)
    function.

    I'm not aware of any issues between openssl and gnutls,
however as

    selabel_digest was only added last week I guess not much testing.
    Well apart from myself as I'm currently adding the
selinux_restorecon
    feature that makes use of it.


  Thanks for clarifying, I am not hitting any issues with it just
  wondering if instead of openssl, gnutls could be used for this and if

  so, if this should be somehow supported or not.

  I tried using gnutls after I read your initial email, however I
  could not find a way to generate the same digest as openssl
  (I changed the SHA1 function to gnutls_hmac_fast(3) with various
  algorithms and used the selabel_digest util to compare digests).
  It could be that I should use some other function but I could

  not find any useful info on this (including web searches).
  If anyone knows how to resolve this please let me know.

  I guess what is supported (openssl or gnutls) would be down to
  the maintainers.

Wondering if dependency on openssl might be a license issue for Debian
or others.  Apparently openssl license is considered GPL-incompatible
[1] [2], and obviously libselinux is linked by a variety of GPL-licensed
programs.  Fedora seems to view this as falling under the system library
exception [3] but not clear that other distributions would view it that
way.  On the other hand, using gnutls would be subject to the reverse
problem; it would make libselinux depend on a LGPL library, and that
could create issues for non-GPL programs that statically link
libselinux.  We might need to revert this change and revisit how to

solve this in a manner that avoids such issues.


Would building with the Android mincrypt SHA functions help regarding the
licensing issues ??? I've attached a quick patch that seems to work okay
using Android system/core/libmincrypt/sha.c

That looks BSD-licensed and thus broadly compatible. We would need to amend libselinux/LICENSE to add that license information and we would need to hide those functions from being exposed outside of the library. Other alternative would be to look for a public domain SHA implementation and use that.


_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux