The only exception, that I know of, to the "no GPL code is available on production image" is the kernel. On Fri, Dec 6, 2013 at 5:15 PM, Catalin Ionita <io.catalin@xxxxxxxxx> wrote: >> No they didn't... External/check policy is GPL...the kernel..etc > > external/checkpolicy is getting build only for host system and is used > with the Android build system. No GPL code is available on a > production image. Busybox and other GPL tools available in the Androd > tree are built only for debugging images, not production ones. This is > one of the main reason why Google has reimplemented GPL projects like > libc (bionic). > > --Catalin > > On Fri, Dec 6, 2013 at 4:28 PM, William Roberts > <bill.c.roberts@xxxxxxxxx> wrote: >> >> On Dec 6, 2013 12:02 AM, "Catalin Ionita" <io.catalin@xxxxxxxxx> wrote: >>> >>> Hi Tyler, >>> >>> > efs-tools, like ecryptfs-utils, is building against the LGPL-ed >>> > ibkeyutils. >>> >>> I'm using a minimal API from libkeyutils to add, search and remove a >>> key from kernel keyring. If the LGPL of keyutils will become a problem >>> I can switch to calling the syscalls directly inside efs-tools. >>> >>> > It would obviously take some more thought, but it is possible for >>> > ecryptfs-utils to provide an LGPL'ed library that all eCryptfs user >>> > space utilities could use. >>> > libecryptfs was supposed to be exactly that, but it was unfortunately >>> > licensed as GPL long ago... >>> >>> As far as I know, you have to rewrite the GPL branded components from >>> scratch. If there is a way to provide an LGPL ecryptfs-utils I will be >>> more than happy to integrate it with Android. I don't like >>> fragmentation, and, at this point, ecryptfs-utils is a mature product. >> >> No they didn't... External/check policy is GPL...the kernel..etc. >> >>> >>> >> >>> >> On the code side, are their dependencies to other libraries that the >>> >> userspace tools >>> >> require that perhaps Android does not have or has incompatible >>> >> versions? >>> > >>> > Possibly, but that could be worked around at build time. >>> >>> Google striped all GPL components from Android. You can't find easily >>> code that you can reuse, so I had to rewrite some features from >>> scratch: >>> - Android keystore implementation is different from any Linux >>> distro. libnss is not present on Android distributions. I've made a >>> minimal software keystore integration in efs-tools. The ultimate goal >>> is to have ecryptfs keys backed with hardware (on my todo list for >>> Intel mobile platforms). >>> - File utils like cp, mv, rm are scarce (only some BSD code) and I >>> had to rewrite those as well >>> - Android does things differently at boot than other Linux distros. >>> I had to write a small library that I can statically link with >>> initramfs components. >>> >>> Overall, the only thing that Android has in common with other Linux >>> distros is the Linux kernel. We can store efs-tools and ecryptfs-utils >>> in the same package and compile according to the OS, but other than >>> that, the two libraries can't share code or functionality. >>> >>> >>> --Catalin >>> >>> On Thu, Dec 5, 2013 at 9:11 PM, Tyler Hicks <tyhicks@xxxxxxxxxxxxx> wrote: >>> > On 2013-12-05 10:57:27, William Roberts wrote: >>> >> On Thu, Dec 5, 2013 at 10:38 AM, Tyler Hicks <tyhicks@xxxxxxxxxxxxx> >>> >> wrote: >>> >> > On 2013-12-05 19:32:11, Catalin Ionita wrote: >>> >> >> Hi, >>> >> > >>> >> > Hello! >>> >> > >>> >> >> >>> >> >> I've been working for some time on a solution to integrate ecryptfs >>> >> >> in Android. Due to some Android specifics and license problems I had >>> >> >> to rewrite the userspace tools. >>> >> > >>> >> > I really wish these problems would have been brought up on this list. >>> >> > Fragmentation of the utilities is a bad thing. There's already enough >>> >> > of >>> >> > it in ecryptfs-utils (mount.ecryptfs vs mount.ecryptfs_private) but >>> >> > now >>> >> > there's an entirely new package, too. >>> >> > >>> >> >> Also, for a nice finish touch, I have >>> >> >> implemented Android user data encryption from top (including a >>> >> >> minimal >>> >> >> GUI) to bottom on a Nexus 4 running latest AOSP kitkat. >>> >> > >>> >> > Very cool. Looking forward to checking it out. >>> >> > >>> >> >> >>> >> >> I'm looking for volunteers to test, review or contribute to Android >>> >> >> userspace tools that I've built. The project is stored at >>> >> >> https://github.com/catalinionita/Ecryptfs-Tools-for-Android >>> >> > >>> >> > First, I'd like to explore merging the two code bases. Can you lay >>> >> > out >>> >> > the reasons for writing from scratch? >>> >> >>> >> If he is looking to upstream it, Google prefers things under Apache >>> >> 2.0. However, >>> >> this doesn't mean that other licenses are instantly a no either. For >>> >> example, checkpolicy. >>> > >>> > efs-tools, like ecryptfs-utils, is building against the LGPL-ed >>> > libkeyutils. >>> > >>> > It would obviously take some more thought, but it is possible for >>> > ecryptfs-utils to provide an LGPL'ed library that all eCryptfs user >>> > space utilities could use. >>> > >>> > libecryptfs was supposed to be exactly that, but it was unfortunately >>> > licensed as GPL long ago... >>> > >>> >> >>> >> On the code side, are their dependencies to other libraries that the >>> >> userspace tools >>> >> require that perhaps Android does not have or has incompatible >>> >> versions? >>> > >>> > Possibly, but that could be worked around at build time. >>> > >>> >> >>> >> Another reason would perhaps be size, lets see what the author says. >>> >> Also, I could swear >>> >> I remember reading something about him asking about Android ecryptfs >>> >> before. >>> > >>> > There have been a couple people ask about building ecryptfs-utils on >>> > Android. I think the libnss dependency is the problem. We've discussed >>> > how to solve that problem with at least one of those people, but I'm >>> > pretty sure that it wasn't Catalin. >>> > >>> > Tyler -- To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
