Plans for IcedTea6 1.11

DJ Lucas dj at lucasit.com
Tue Mar 8 23:37:50 PST 2011


On 03/08/2011 10:41 AM, Dr Andrew John Hughes wrote:

>  On 23:28 Mon 07 Mar     , DJ Lucas wrote:
>>  On 03/07/2011 09:58 AM, Dr Andrew John Hughes wrote:
>>>  Posting the patch to the list will allow it to be reviewed.
>>>
>>>  Is there really any value to having this optional?  I don't see why anyone
>>>  would want the existing broken cacerts file that prevents HTTPS from working.
>>>  I see this as something being depended on by make install, which isn't yet present.
>>  Reply off list, I wasn't sure if you had intended for this to go to list
>>  (I originally replied incorrectly). Feel free to reply on list with quoting.
>>
>  Yeah, it ended up off-list because I replied to your off-list response.
>  I'll cc this back on to the list.
>
>>  The effort was to not be heavy handed here...see my reply to Pavel. The
>>  possibility exists to simply include a populated cacerts file and and
>>  alternate --with-cacerts switch. I'd personally rather trust the
>>  sysadmin WRT CA trusts and use the system's certs as opposed to defining
>>  a default policy (regardless if it is mozzila.org or whomever), however,
>>  the script that I slapped together requires OpenSSL. Debian and friends
>>  might not like that requirement in favor of gnutls given their
>>  preference to GPL software over other free licenses. I had intended to
>>  get around that by adding the --with-cacerts switch for distributions'
>>  use.  While I'm personally against it, the --with-cacerts and a supplied
>>  cacerts file would work nicely to solve all previously voiced concerns
>>  except my own WRT security policy, but I can easily add cacerts
>>  generation to my own system certificates package if that is the
>>  direction deemed appropriate by the group.
>>
>  Most distros already have a solution.  The main aim of this is to get this
>  stuff into the main distribution instead of them hoarding their own personal
>  implementations.  They are of course welcome to ignore this and use their
>  own, but https should work on IcedTea for normal users building it with
>  minimal intervention.
>
>>  Alternately, I'm not sure if RedHat's Perl variant has any external
>>  dependencies besides Perl as distributed with default CPAN modules. The
>>  parts I've ripped out for use in LFS's internal use work fine for
>>  sanitizing the mozzila.org certs, but I always install OpenSSL and the
>>  CPAN::Bundle immediately (and this is how I create the system
>>  certificates package for BLFS). Also, it just occurred to me that if the
>>  script I wrote is to be utilized, then a conditional check for openssl
>>  would need to be added to configure. I didn't realize there wasn't
>>  one...just looked. I'll slap together a 3rd revision and add a switch to
>>  the mkcacerts.sh script to account for that in case it is needed, but I
>>  won't have time until Wed. Perhaps somebody else will chime in on list
>>  regarding the option of shipping of a populated cacerts file before then.
>>
>  I guess we have to do some dependency checking.

Okay, had a few extra minutes tonight so I reworked the patch for above
considerations, along with stream lining it a bit (all conditional on
the previous tests as the additional checks are not needed if a cacerts
file is supplied). I haven't completed a build yet (ran the configure
script and mkcacerts.sh script though various quick tests), but wondered
if the conditional ac tests are alright, or should they be run
unconditionally (unnecessarily)?

-- DJ Lucas




-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: icedtea6-1.10-cacerts-4.patch
Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110309/9c75b679/icedtea6-1.10-cacerts-4.patch 


More information about the distro-pkg-dev mailing list