From jad at sinodun.com  Wed Apr 10 12:16:52 2013
From: jad at sinodun.com (John Dickinson)
Date: Wed, 10 Apr 2013 12:16:52 +0000
Subject: [Opendnssec-maintainers] supported sqlite3 version
Message-ID: <FADB61E3-7A40-438F-8D96-7CD139ABB08A@sinodun.com>

Hi,

The OpenDNSSEC developers would like your input on the impact of changing the required version of sqlite3 in future releases of OpenDNSSEC (v1.3, v1.4 and v2). Currently the enforcer checks for at least sqlite3 >= 3.3.9 which is very old.

We would like to raise this requirement to sqlite3 >= 3.7.0 as this would allow us to:
1. Enforce foreign key constraints. http://www.sqlite.org/foreignkeys.html
2. Make use of the WAL to better handle locking issues. http://www.sqlite.org/wal.html

Impact of this change:

RHEL and derivatives ship with 3.6.20
Ubuntu 10.04 LTS ships with 3.6.22

Users of these OS's would need to install/upgrade sqlite3. Users on recent *BSD or Solaris 11 should be OK.

(BTW SoftHSM will be tested against sqlite3 >= 3.7.0 before any change is made to the OpenDNSSEC requirements.)

regards
John

From pwouters at redhat.com  Wed Apr 10 18:17:40 2013
From: pwouters at redhat.com (Paul Wouters)
Date: Wed, 10 Apr 2013 14:17:40 -0400
Subject: [Opendnssec-maintainers] supported sqlite3 version
In-Reply-To: <FADB61E3-7A40-438F-8D96-7CD139ABB08A@sinodun.com>
References: <FADB61E3-7A40-438F-8D96-7CD139ABB08A@sinodun.com>
Message-ID: <5165ACC4.3030800@redhat.com>

On 04/10/2013 08:16 AM, John Dickinson wrote:

> The OpenDNSSEC developers would like your input on the impact of changing the required version of sqlite3 in future releases of OpenDNSSEC (v1.3, v1.4 and v2). Currently the enforcer checks for at least sqlite3 >= 3.3.9 which is very old.
>
> We would like to raise this requirement to sqlite3 >= 3.7.0 as this would allow us to:
> 1. Enforce foreign key constraints. http://www.sqlite.org/foreignkeys.html
> 2. Make use of the WAL to better handle locking issues. http://www.sqlite.org/wal.html
>
> Impact of this change:
>
> RHEL and derivatives ship with 3.6.20
> Ubuntu 10.04 LTS ships with 3.6.22
>
> Users of these OS's would need to install/upgrade sqlite3. Users on recent *BSD or Solaris 11 should be OK.

That is a nightmare because you'd have to create an sqlite36 package or 
an sqlite37 package that installs in a non-default location to avoid 
affecting other software that cannot use 3.7 due to possible API 
changes. It will not be possible to ship such a version of opendnssec in 
EPEL-6 as we currently do.

I would recommend waiting for RHEL and ubuntu LTS to be upgraded before 
demanding this switch. RHEL-7 will have sqlite 3.7.x.

Related, opendnssec won't be able to get into RHEL-6 properly (as 
opposed to being in EPEL-6) as long as it uses a 
non-approved/non-certified crypto library (botan). The only allowed 
crypto libraries are nss, openssl and libgcrypt.

Paul



From jad at sinodun.com  Fri Apr 12 11:08:03 2013
From: jad at sinodun.com (John Dickinson)
Date: Fri, 12 Apr 2013 11:08:03 +0000
Subject: [Opendnssec-maintainers] supported sqlite3 version
In-Reply-To: <5165ACC4.3030800@redhat.com>
References: <FADB61E3-7A40-438F-8D96-7CD139ABB08A@sinodun.com>
	<5165ACC4.3030800@redhat.com>
Message-ID: <7D2C5A1B-D27D-49EA-99CC-4909BE5A545D@sinodun.com>


On 10 Apr 2013, at 18:17, Paul Wouters <pwouters at redhat.com> wrote:

> On 04/10/2013 08:16 AM, John Dickinson wrote:
> 
>> The OpenDNSSEC developers would like your input on the impact of changing the required version of sqlite3 in future releases of OpenDNSSEC (v1.3, v1.4 and v2). Currently the enforcer checks for at least sqlite3 >= 3.3.9 which is very old.
>> 
>> We would like to raise this requirement to sqlite3 >= 3.7.0 as this would allow us to:
>> 1. Enforce foreign key constraints. http://www.sqlite.org/foreignkeys.html
>> 2. Make use of the WAL to better handle locking issues. http://www.sqlite.org/wal.html
>> 
>> Impact of this change:
>> 
>> RHEL and derivatives ship with 3.6.20
>> Ubuntu 10.04 LTS ships with 3.6.22
>> 
>> Users of these OS's would need to install/upgrade sqlite3. Users on recent *BSD or Solaris 11 should be OK.

Thanks for the feedback Paul,

> That is a nightmare because you'd have to create an sqlite36 package or an sqlite37 package that installs in a non-default location to avoid affecting other software that cannot use 3.7 due to possible API changes. It will not be possible to ship such a version of opendnssec in EPEL-6 as we currently do.

OK - that is what I thought - I just wondered what the pain level would be.

> I would recommend waiting for RHEL and ubuntu LTS to be upgraded before demanding this switch. RHEL-7 will have sqlite 3.7.x.

You would be happy even though RHEL-6 extended support goes until 2023?

Another option is for us to have configure detect the sqlite version and only compile new features if it detects 3.7.x.

> Related, opendnssec won't be able to get into RHEL-6 properly (as opposed to being in EPEL-6) as long as it uses a non-approved/non-certified crypto library (botan). The only allowed crypto libraries are nss, openssl and libgcrypt.

Out of interest, what are the requirements needed to become approved and certified?

Thanks,
John

From ondrej at sury.org  Fri Apr 12 11:22:03 2013
From: ondrej at sury.org (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Fri, 12 Apr 2013 13:22:03 +0200
Subject: [Opendnssec-maintainers] supported sqlite3 version
In-Reply-To: <7D2C5A1B-D27D-49EA-99CC-4909BE5A545D@sinodun.com>
References: <FADB61E3-7A40-438F-8D96-7CD139ABB08A@sinodun.com>
	<5165ACC4.3030800@redhat.com>
	<7D2C5A1B-D27D-49EA-99CC-4909BE5A545D@sinodun.com>
Message-ID: <CALjhHG-R_XEunLbTMVA2cXxaYSKH=GjurA9gj9co9U93WK_hVA@mail.gmail.com>

I think what Paul is trying to say is to switch to sqlite 3.7 only
after RHEL-7 is out.

And I would add that only for new branches (1.4 and 2.0) and keep the
library requirements same for the whole lifetime of branch. E.g. no
change in 1.3.x.

It's ok for Ubuntu and Debian. Debian has 3.7 in stable and stable+1.
And we don't have to support Ubuntu 10.04 for new releases, because
there's already Ubuntu 12.04 LTS, which already have sqlite >= 3.7.

Ondrej

On Fri, Apr 12, 2013 at 1:08 PM, John Dickinson <jad at sinodun.com> wrote:
>
> On 10 Apr 2013, at 18:17, Paul Wouters <pwouters at redhat.com> wrote:
>
>> On 04/10/2013 08:16 AM, John Dickinson wrote:
>>
>>> The OpenDNSSEC developers would like your input on the impact of changing the required version of sqlite3 in future releases of OpenDNSSEC (v1.3, v1.4 and v2). Currently the enforcer checks for at least sqlite3 >= 3.3.9 which is very old.
>>>
>>> We would like to raise this requirement to sqlite3 >= 3.7.0 as this would allow us to:
>>> 1. Enforce foreign key constraints. http://www.sqlite.org/foreignkeys.html
>>> 2. Make use of the WAL to better handle locking issues. http://www.sqlite.org/wal.html
>>>
>>> Impact of this change:
>>>
>>> RHEL and derivatives ship with 3.6.20
>>> Ubuntu 10.04 LTS ships with 3.6.22
>>>
>>> Users of these OS's would need to install/upgrade sqlite3. Users on recent *BSD or Solaris 11 should be OK.
>
> Thanks for the feedback Paul,
>
>> That is a nightmare because you'd have to create an sqlite36 package or an sqlite37 package that installs in a non-default location to avoid affecting other software that cannot use 3.7 due to possible API changes. It will not be possible to ship such a version of opendnssec in EPEL-6 as we currently do.
>
> OK - that is what I thought - I just wondered what the pain level would be.
>
>> I would recommend waiting for RHEL and ubuntu LTS to be upgraded before demanding this switch. RHEL-7 will have sqlite 3.7.x.
>
> You would be happy even though RHEL-6 extended support goes until 2023?
>
> Another option is for us to have configure detect the sqlite version and only compile new features if it detects 3.7.x.
>
>> Related, opendnssec won't be able to get into RHEL-6 properly (as opposed to being in EPEL-6) as long as it uses a non-approved/non-certified crypto library (botan). The only allowed crypto libraries are nss, openssl and libgcrypt.
>
> Out of interest, what are the requirements needed to become approved and certified?
>
> Thanks,
> John_______________________________________________
> Opendnssec-maintainers mailing list
> Opendnssec-maintainers at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-maintainers



-- 
?Ond?ej Sur? <ondrej at sury.org>


From pwouters at redhat.com  Fri Apr 12 13:42:39 2013
From: pwouters at redhat.com (Paul Wouters)
Date: Fri, 12 Apr 2013 09:42:39 -0400
Subject: [Opendnssec-maintainers] supported sqlite3 version
In-Reply-To: <7D2C5A1B-D27D-49EA-99CC-4909BE5A545D@sinodun.com>
References: <FADB61E3-7A40-438F-8D96-7CD139ABB08A@sinodun.com>
	<5165ACC4.3030800@redhat.com>
	<7D2C5A1B-D27D-49EA-99CC-4909BE5A545D@sinodun.com>
Message-ID: <51680F4F.1030502@redhat.com>

On 04/12/2013 07:08 AM, John Dickinson wrote:

>> I would recommend waiting for RHEL and ubuntu LTS to be upgraded before demanding this switch. RHEL-7 will have sqlite 3.7.x.
>
> You would be happy even though RHEL-6 extended support goes until 2023?

But you can tell people to use RHEL7 instead. Supported does not mean "dont use anything newer/better" :)

> Another option is for us to have configure detect the sqlite version and only compile new features if it detects 3.7.x.
>
>> Related, opendnssec won't be able to get into RHEL-6 properly (as opposed to being in EPEL-6) as long as it uses a non-approved/non-certified crypto library (botan). The only allowed crypto libraries are nss, openssl and libgcrypt.
>
> Out of interest, what are the requirements needed to become approved and certified?

A ship of money, and lots of time. And on a continued basis because every time there is a change in the crypto software, it has to get re-certified. And we are 
talking a lot more then just a few thousand dollars. So it is extremely unlikely to change in the next couple of years.

Paul



From jad at sinodun.com  Fri Apr 12 14:08:33 2013
From: jad at sinodun.com (John Dickinson)
Date: Fri, 12 Apr 2013 14:08:33 +0000
Subject: [Opendnssec-maintainers] supported sqlite3 version
In-Reply-To: <51680F4F.1030502@redhat.com>
References: <FADB61E3-7A40-438F-8D96-7CD139ABB08A@sinodun.com>
	<5165ACC4.3030800@redhat.com>
	<7D2C5A1B-D27D-49EA-99CC-4909BE5A545D@sinodun.com>
	<51680F4F.1030502@redhat.com>
Message-ID: <5A8EE36E-965E-49C5-857A-8E93B5227CB3@sinodun.com>


On 12 Apr 2013, at 13:42, Paul Wouters <pwouters at redhat.com> wrote:

> On 04/12/2013 07:08 AM, John Dickinson wrote:
> 
>>> I would recommend waiting for RHEL and ubuntu LTS to be upgraded before demanding this switch. RHEL-7 will have sqlite 3.7.x.
>> 
>> You would be happy even though RHEL-6 extended support goes until 2023?
> 
> But you can tell people to use RHEL7 instead. Supported does not mean "dont use anything newer/better" :)
> 
>> Another option is for us to have configure detect the sqlite version and only compile new features if it detects 3.7.x.
>> 
>>> Related, opendnssec won't be able to get into RHEL-6 properly (as opposed to being in EPEL-6) as long as it uses a non-approved/non-certified crypto library (botan). The only allowed crypto libraries are nss, openssl and libgcrypt.
>> 
>> Out of interest, what are the requirements needed to become approved and certified?
> 
> A ship of money, and lots of time. And on a continued basis because every time there is a change in the crypto software, it has to get re-certified. And we are talking a lot more then just a few thousand dollars. So it is extremely unlikely to change in the next couple of years.


Do you mean fips-140 compliant or some kind of redhat compliant?

Thanks
John

From pwouters at redhat.com  Fri Apr 12 14:48:40 2013
From: pwouters at redhat.com (Paul Wouters)
Date: Fri, 12 Apr 2013 10:48:40 -0400
Subject: [Opendnssec-maintainers] supported sqlite3 version
In-Reply-To: <5A8EE36E-965E-49C5-857A-8E93B5227CB3@sinodun.com>
References: <FADB61E3-7A40-438F-8D96-7CD139ABB08A@sinodun.com>
	<5165ACC4.3030800@redhat.com>
	<7D2C5A1B-D27D-49EA-99CC-4909BE5A545D@sinodun.com>
	<51680F4F.1030502@redhat.com>
	<5A8EE36E-965E-49C5-857A-8E93B5227CB3@sinodun.com>
Message-ID: <51681EC8.4070401@redhat.com>

On 04/12/2013 10:08 AM, John Dickinson wrote:

>>>> Related, opendnssec won't be able to get into RHEL-6 properly (as opposed to being in EPEL-6) as long as it uses a non-approved/non-certified crypto library (botan). The only allowed crypto libraries are nss, openssl and libgcrypt.
>>>
>>> Out of interest, what are the requirements needed to become approved and certified?
>>
>> A ship of money, and lots of time. And on a continued basis because every time there is a change in the crypto software, it has to get re-certified. And we are talking a lot more then just a few thousand dollars. So it is extremely unlikely to change in the next couple of years.
>
>
> Do you mean fips-140 compliant or some kind of redhat compliant?

FIPS-140 compliance is just one of many certifications that Red Hat complies with.

http://www.redhat.com/solutions/industry/government/certifications.html

Paul



From sara at sinodun.com  Wed Apr 17 10:14:12 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 17 Apr 2013 11:14:12 +0100
Subject: [Opendnssec-maintainers] RE: Changes to the versioning scheme and
	support policy
Message-ID: <240A7518-6BD2-4EF1-8E8D-7A6E6EFE4638@sinodun.com>

Hi All, 

The OpenDNSSEC team has been through a review of our release process and as a result we have agreed to make two changes:


Versioning scheme 
----------------------------
The current versioning scheme is component based and we plan to switch to an API compatibility based approach. The plan is to adopt the new scheme from 1.3.14 and 1.4.0 onwards. 


Maintenance of old releases
-----------------------------------------
We plan to adopt a split between Long Term Support (LTS) releases and Standard Releases somewhat along the lines of the Ubuntu model. 1.3 will be the first LTS release, 1.4. will be a Standard Release. 


The full details of the changes can be found on the OpenDNSSEC wiki:

https://wiki.opendnssec.org/display/OpenDNSSEC/Release+Management+Policy

Feedback and comments on this are welcomed. 


Sara.




From sara at sinodun.com  Mon Apr 22 10:34:28 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 22 Apr 2013 11:34:28 +0100
Subject: [Opendnssec-maintainers] OpenDNSSEC 1.4.0 release
Message-ID: <5D7F6051-2A73-4939-AEE8-6B1BBA74BF42@sinodun.com>

All, 

Version 1.4.0 of OpenDNSSEC has now been released. This is the latest stable release.

Updates since 1.4.0rc3:

* Production release of 1.4
* Versioning scheme and release support policies updated
* Summary of changes in 1.4  vs 1.3 can be found on the wiki:
   http://wiki.opendnssec.org/display/DOCS/New+in+OpenDNSSEC+1.4

Documentation:

* http://wiki.opendnssec.org/display/DOCS

Download:

* http://dist.opendnssec.org/source/opendnssec-1.4.0.tar.gz
* http://dist.opendnssec.org/source/opendnssec-1.4.0.tar.gz.sig
* Checksum sha1: 111a6de4bb8f13bcedc31880c87588ce07eecc31
* Checksum sha256: 36d4926dcdf351a527ad7600b151ab6cc56d0a472a7eb8871eecd70afef9e101

//OpenDNSSEC team