Bug#294995: java-package: please support unlimited crypto policy files

[Sergio Gelato]

I second this wishlist item wholeheartedly.

Note that the issue is not limited to Sun Java: IBM also ships an 
unlimited crypto enabler separately.


I'm not keen on the auto-detection aspect of Steve Ihde's proposal #1, 
since I happen to be keeping the JCE .zips in a separate directory. It 
would seem better to at least allow the JCE file to be explicitly named 
on the command line.


Other than this, I like proposal #1 better than #2 since it leads to 
fewer packages and avoids having to divert the old files, which seems 
ugly. The only situation in which #2 may be better is if one plans to 
redistribute the generated .deb's to both eligible and non-eligible 
countries. (More generally, if one is going to redistribute the 
generated .deb's it would be nice if the package name could include an 
indication of which JCE policy it was built with; but this can also be 
done with approach #1.)


Another solution might be to treat the two files in question as 
conffiles. Incidentally, there is a third file which one may want to 
either turn into a conffile or replace at make-jpkg time (or maybe 
both): jre/lib/security/cacerts.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#294995: java-package: please support unlimited crypto policy files jce_policy*.zip

[Steven Ihde]

Package: java-package
Version: 0.20
Severity: wishlist

On Sun's download pages, there is a section at the end called Other
Downloads.  There, one can download jce_policy-x_y_z.zip (where x_y_z
is the java version number).  This zip contains a US_export_policy.jar
and a local_policy.jar that are meant to replace the jars by the same
name in jre/lib/security.

The new jars allow unlimited strength crypto; for example, AES with
256-bit key will not work without these jars.

It would be nice if java-package supported this.  I see several
possibilities:

1. Just build it in to the scripts; if the user is building a Sun
package and the script detects an appropriately named jce_policy-* in
the same directory as the .bin file, prompt the user and ask if he'd
like to use it.  If so, replace the jars in jre/lib/security with the
new ones before building the .deb.

2. Enhance make-jpkg to build tiny sun-j2{sdk,re}1.{4,5}-jce-policy
.debs from the jce_policy-*.zip files that contain only the two jars,
and dpkg-divert the old jars appropriately.

3. Supply a shell script that will assist the admin in setting up a
local diversion.

I think I like #2 the best.  #1 has the problem that it's difficult to
tell whether a given sun-j2sdk* package has the crypto jars or not.
#3 will certainly work but doesn't seem entirely satisfactory.

Thoughts?  I can contribute something if that will help.

Thanks,

Steve

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (900, 'unstable'), (890, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-hamachi
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages java-package depends on:
ii  coreutils 5.2.1-2The GNU core utilities
ii  debhelper 4.2.30 helper programs for debian/rules
ii  fakeroot  1.2.4  Gives a fake root environment

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]