Loopback filesystems, etc support encryption. However, to do this you need the encryption kernel modules. Theres 2 ways to do this, either use the international kernel patch, or use a package called cryptoapi, which just adds the encryption modules. You also need to patch the util-linux package to support it. I've included the ebuild for cryptoapi. The patch is too big to be pasted here, so has been emailed to gentoo-dev@gentoo.org, and is also available at http://www.goth.net/~prez/util-linux-2.11o-crypto.patch for download. cryptoapi-2.4.7.0.ebuild: # Copyright 1999-2001 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License, v2 or later # Author Preston A. Elder <prez@goth.net> S=${WORKDIR}/${P} DESCRIPTION="Modules that add encryption ability at the kernel level." SRC_URI="http://prdownloads.sourceforge.net/cryptoapi/${P}.tar.gz" HOMEPAGE="http://www.sourceforge.net/projects/cryptoapi" DEPEND="sys-kernel/linux-sources" src_compile() { econf || die cd ${S}/api cp Makefile Makefile.orig sed -e "s:-DMODVERSIONS:-DMODVERSIONS -DEXPORT_SYMTAB:g" \ Makefile.orig >Makefile cd .. cp config.status config.status.orig sed -e "s:-DMODVERSIONS:-DMODVERSIONS -DEXPORT_SYMTAB:g" \ config.status.orig >config.status emake || die } src_install() { dodir /lib/modules/misc make MODLIB=${D}/lib/modules/misc \ install || die dodoc AUTHORS COPYING ChangeLog INSTALL LICENSE.crypto dodoc NEWS README* TODO doc/* doc/utils/* }
Preston, does this ebuild build against the kernel sources in /usr/src/linux? If not, can you fix it to do so? /usr/src/linux always points to the kernel source tree that modules should be compiled against.
Yes, it uses /usr/src/linux (actually, I takes /usr/src/linux and resolves that to the real directory -- but the end result is the same).
are there licensing issues we need to be concerned about with this?
Wonderfully, no. Since every user is individually downloading cryptoapi themselves, its legal, we're not actually distributing encryption, just making a file to grab it from a place that is. If there are legal issues, they are sourceforge's, not ours -- they are distributing the encryption software. One would assume they have already thought about all this, and have gotten permission (exporting crypto is not illegal if its below a certain strength, or you get permission from the government). But, as far as gentoo is concerned, we're not legally liable for the ebuild, because we dont have any encryption technology in it itself. Its the same reason that having a libcss ebuild is legal -- we're not distributing libcss, just pointing at somewhere that does to download it, and the user themselves does the downloading -- not the gentoo team -- and even then, the user isnt liable for it -- if it shouldnt be distributed, the responsibility lays on the distributor, not the client.
Ryan, Can you confirm this? Sorry, Preston, I just want to be ultra careful with this, and make sure we are on the level with both this and libcss.
Preston is correct to an extent. If we assume the third party has gotten permission, then we should be ok. If we knowingly link to something that isn't kosher, then we could get into trouble. This could be 100% fixed and place the liability on the user, by adding a USE var. See gentoo-dev [Encryption Export] There should also be a RESTRICT variable for ebuilds to not merge with ibiblio. I just tried this, but libdvdcss, is located on ibiblio. It should be removed immediately and permanently; not the ebuild, but the source. The same goes for kernel patch. -ryan
I forgot to mention, we can mirror this as long as the changes to portage take place.
committed to app-crypt/cryptoapi