On Oct 20, 2015 7:46 AM, "Stephen Smalley" <s...@tycho.nsa.gov> wrote: > > On 10/20/2015 08:27 AM, Richard Haines wrote: >> >> >> >> >> >>> On Monday, 19 October 2015, 19:10, Stephen Smalley <s...@tycho.nsa.gov> wrote: >>>> >>>> On 10/18/2015 11:00 AM, Richard Haines wrote: >>>> >>>> >>>>> On Sunday, 18 October 2015, 15:07, Dominick Grift >>> >>> <dac.overr...@gmail.com> 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. > >
Will CryptLib work: http://unlicense.org/ > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to selinux-le...@tycho.nsa.gov. > To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
_______________________________________________ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
