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