Summary: | Ebuild / patch to add encryption support for various tasks (inc. loopback FS) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Preston A. Elder <prez> |
Component: | New packages | Assignee: | Ryan Phillips (RETIRED) <rphillips> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | ||
Priority: | High | ||
Version: | 1.0 RC6 r14 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Preston A. Elder
2002-04-08 18:29:19 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. 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 |