Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 1607 - Ebuild / patch to add encryption support for various tasks (inc. loopback FS)
Summary: Ebuild / patch to add encryption support for various tasks (inc. loopback FS)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: x86 Linux
: High enhancement (vote)
Assignee: Ryan Phillips (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-08 18:29 UTC by Preston A. Elder
Modified: 2003-02-04 19:42 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Preston A. Elder 2002-04-08 18:29:19 UTC
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/*
}
Comment 1 Daniel Robbins (RETIRED) gentoo-dev 2002-04-09 20:46:42 UTC
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.
Comment 2 Preston A. Elder 2002-04-09 21:35:27 UTC
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).
Comment 3 Seemant Kulleen (RETIRED) gentoo-dev 2002-04-16 21:43:42 UTC
are there licensing issues we need to be concerned about with this?
Comment 4 Preston A. Elder 2002-04-16 22:00:03 UTC
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.
Comment 5 Seemant Kulleen (RETIRED) gentoo-dev 2002-04-17 19:16:26 UTC
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.

Comment 6 Ryan Phillips (RETIRED) gentoo-dev 2002-04-17 21:07:13 UTC
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
Comment 7 Ryan Phillips (RETIRED) gentoo-dev 2002-04-17 21:14:13 UTC
I forgot to mention, we can mirror this as long as the changes to portage take
place.
Comment 8 Ryan Phillips (RETIRED) gentoo-dev 2002-04-26 01:14:13 UTC
committed to app-crypt/cryptoapi