From rickard at opendnssec.org Mon Aug 1 08:19:34 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 1 Aug 2011 10:19:34 +0200 Subject: [Opendnssec-develop] Test results Open DNSSEC 1.2.2 - SIDN In-Reply-To: <60E0FAC48923D348BF7B1861488E606E06FFD42D@kambx3.SIDN.local> References: <60E0FAC48923D348BF7B1861488E606E06FFD42D@kambx3.SIDN.local> Message-ID: Thanks Then the only issue was #246, clarifying the text about the XML validation check. // Rickard On Thu, Jul 21, 2011 at 4:35 PM, Nick van den Heuvel wrote: > Hi Guys, > > > > I hereby send the test results of the regression test for OpenDNSSEC 1.2.2 > which I downloaded last week from the repository (branch (version 1.2). > > > > Regards, > > Nick > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > > From owner-dnssec-trac at kirei.se Mon Aug 1 09:32:56 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Aug 2011 09:32:56 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #254: Configure fails on RHEL6 In-Reply-To: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> References: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> Message-ID: <060.1d40865b0b487fa9216d76cc2fa9e37b@kirei.se> #254: Configure fails on RHEL6 ------------------------------------+--------------------------------------- Reporter: vanrein | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: configure libldns rhel6 | ------------------------------------+--------------------------------------- Comment (by rb): Where is this line located? The only similar line I can find is: http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/m4/acx_ldns.m4#L29 The variable $LDNS_LIBS is only used temporarily in the check. It will not be saved in the $LIBS variable. $LDNS_LIBS is added in the Makefiles that need to compile something with LDNS. E.g: http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/signer/src/Makefile.am#L64 -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Mon Aug 1 11:25:58 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 01 Aug 2011 13:25:58 +0200 Subject: [Opendnssec-develop] make dist Message-ID: <4E368D46.7080609@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is this me or does make dist not work? (I have enabled the epp client) (cd plugins/eppclient && make top_distdir=../../opendnssec-1.3.0 distdir=../../opendnssec-1.3.0/plugins/eppclient \ am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir) /bin/bash: line 10: cd: plugins/eppclient: No such file or directory make: *** [distdir] Error 1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJONo1GAAoJEA8yVCPsQCW5Mp8IAI9XdHhWux09ETGovFut+MkS J8AEOsPV0HLP0q1LqKIWhR8nyOvGPN45j9B/rb0cuMoihKQzmcNFxuCUGtGP6ynP Vft6J+YSA0SvOYM0Mw0ZguKdsH35DyEB/QEyfGHoaQFwp9y0IgkfSaIfka4pRmu1 O9seC30OZi56AngHkWDf+n3rTRie2fEpD+7Olm2HiMzC1GB6Qp+rT0WH0wCxZmVQ xhMuQ4mbhqdhQYD8OAOq09i+8ICaydMgy9R5/1qOEi94u+cVCQlXv9jUl/aCwODf pfvdE6ROoLqibvHgkjX9vmXeWdCdeI9TI0P9/HAWapncGXDefypM9QsRrJJne6s= =K5w+ -----END PGP SIGNATURE----- From rickard at opendnssec.org Mon Aug 1 12:02:14 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 1 Aug 2011 14:02:14 +0200 Subject: [Opendnssec-develop] make dist In-Reply-To: <4E368D46.7080609@nlnetlabs.nl> References: <4E368D46.7080609@nlnetlabs.nl> Message-ID: It works for me, but Ondrej is having a similar problem. http://trac.opendnssec.org/ticket/241 // Rickard On Mon, Aug 1, 2011 at 1:25 PM, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Is this me or does make dist not work? (I have enabled the epp client) > > ?(cd plugins/eppclient && make ?top_distdir=../../opendnssec-1.3.0 > distdir=../../opendnssec-1.3.0/plugins/eppclient \ > ? ? am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: > distdir) > /bin/bash: line 10: cd: plugins/eppclient: No such file or directory > make: *** [distdir] Error 1 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJONo1GAAoJEA8yVCPsQCW5Mp8IAI9XdHhWux09ETGovFut+MkS > J8AEOsPV0HLP0q1LqKIWhR8nyOvGPN45j9B/rb0cuMoihKQzmcNFxuCUGtGP6ynP > Vft6J+YSA0SvOYM0Mw0ZguKdsH35DyEB/QEyfGHoaQFwp9y0IgkfSaIfka4pRmu1 > O9seC30OZi56AngHkWDf+n3rTRie2fEpD+7Olm2HiMzC1GB6Qp+rT0WH0wCxZmVQ > xhMuQ4mbhqdhQYD8OAOq09i+8ICaydMgy9R5/1qOEi94u+cVCQlXv9jUl/aCwODf > pfvdE6ROoLqibvHgkjX9vmXeWdCdeI9TI0P9/HAWapncGXDefypM9QsRrJJne6s= > =K5w+ > -----END PGP SIGNATURE----- > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > From owner-dnssec-trac at kirei.se Mon Aug 1 12:12:32 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Aug 2011 12:12:32 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #137: text is not adequatly quoted for insertion in the database In-Reply-To: <053.670cfe1e78d519363e2d580bab9f19a1@kirei.se> References: <053.670cfe1e78d519363e2d580bab9f19a1@kirei.se> Message-ID: <068.2756df303afd1874569ed12f1a1af394@kirei.se> #137: text is not adequatly quoted for insertion in the database ----------------------------+----------------------------------------------- Reporter: Kim Minh Kaplan | Owner: sion Type: defect | Status: closed Priority: minor | Component: Enforcer Version: trunk | Resolution: fixed Keywords: | ----------------------------+----------------------------------------------- Changes (by rb): * status: accepted => closed * resolution: => fixed Comment: Fixed in r5336 -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Mon Aug 1 12:16:16 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 1 Aug 2011 14:16:16 +0200 Subject: [Opendnssec-develop] make dist In-Reply-To: References: <4E368D46.7080609@nlnetlabs.nl> Message-ID: <219FB6E4-71A8-433F-93C8-0A5C890BFD81@kirei.se> On 1 aug 2011, at 14.02, Rickard Bellgrim wrote: > It works for me, but Ondrej is having a similar problem. > http://trac.opendnssec.org/ticket/241 it seems to depend on whether you --enable-auditor or not, yes? jakob From roland.vanrijswijk at surfnet.nl Mon Aug 1 12:20:21 2011 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Mon, 1 Aug 2011 14:20:21 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting? Message-ID: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> Hi guys, Now that Ren? and Yuri are back from holiday, shall we plan another Enforcer NG meeting? I suggest one of the following dates/times: Thursday August 11th, 10:30h CEST Friday August 12th, 10:30h CEST Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From matthijs at NLnetLabs.nl Mon Aug 1 12:36:05 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 01 Aug 2011 14:36:05 +0200 Subject: [Opendnssec-develop] make dist In-Reply-To: <219FB6E4-71A8-433F-93C8-0A5C890BFD81@kirei.se> References: <4E368D46.7080609@nlnetlabs.nl> <219FB6E4-71A8-433F-93C8-0A5C890BFD81@kirei.se> Message-ID: <4E369DB5.6030604@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 auditor is enabled by default, but any case: adding --enable-auditor does not help. For now, I will just remove the eppclient from the subdirs On 08/01/2011 02:16 PM, Jakob Schlyter wrote: > On 1 aug 2011, at 14.02, Rickard Bellgrim wrote: > >> It works for me, but Ondrej is having a similar problem. >> http://trac.opendnssec.org/ticket/241 > > it seems to depend on whether you --enable-auditor or not, yes? > > jakob > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJONp21AAoJEA8yVCPsQCW57fMH/0skcuy0pEtC2KL13fl9IhFn adnVJBloOV98qIFCyFVyVNl750UMY9Cq+rpcOmbyEWnBWCvXLbd7I61LQqjcQQpH /PTmxlkY3d0Q5V26UNSU1Zox/7V7NOXMsdJUE0YmpI3cSG4CevpHGxkN4LqnY0cE wYCGgR0FtESgO4TuoJoLUbyxs0i+G7qy2bg0AVQIM0PYOQR0H1oN1H8b2z7rdw7o 8NJN5bCGixYXxyRbZqRN6y+LrfkUoNBVXTJp7KQZv+Y5f0xuIkZwjJ287JDsXzZx sNIVT4mlQACHg8YP6yhwLK02qkkzptKMZZ9VVMPjhzFlaBFQnHZ1T56LtPvve2Q= =kbJI -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Mon Aug 1 12:44:55 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Aug 2011 12:44:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #255: Patch to contrib/opendnssec.spec In-Reply-To: <045.68dfad79e267652e97eb413eccae295e@kirei.se> References: <045.68dfad79e267652e97eb413eccae295e@kirei.se> Message-ID: <060.d969f1b99517b03088f34ab5608a1abe@kirei.se> #255: Patch to contrib/opendnssec.spec ------------------------+--------------------------------------------------- Reporter: vanrein | Owner: rb Type: enhancement | Status: closed Priority: minor | Component: Unknown Version: 1.3.0 | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thanks, fixed in r5344. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 1 13:09:39 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Aug 2011 13:09:39 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #257: Error in ods-signerd In-Reply-To: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> References: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> Message-ID: <072.e775cbd0560689ecfa48b77d3384ab7a@kirei.se> #257: Error in ods-signerd ----------------------------------------------+----------------------------- Reporter: staffordp1@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.3.0 | Resolution: Keywords: nsec3params zone.c nsec3params_rr | ----------------------------------------------+----------------------------- Comment (by rb): Thanks for finding the issue. We will have a look at it. The code that you mention is used to read the internal backup file. You do not need to create the backup file if you migrate to OpenDNSSEC. You just need to: 1. Configure the system 2. ods-ksmutil setup 3. ods-ksmutil key import ... 4. ods-control start http://trac.opendnssec.org/wiki/Signer/Using/Migrating -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 1 14:07:18 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 01 Aug 2011 14:07:18 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #257: Error in ods-signerd In-Reply-To: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> References: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> Message-ID: <072.18482c42a87e57d5fdde1bc3f7f03ee6@kirei.se> #257: Error in ods-signerd ----------------------------------------------+----------------------------- Reporter: staffordp1@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.3.0 | Resolution: Keywords: nsec3params zone.c nsec3params_rr | ----------------------------------------------+----------------------------- Comment (by rb): If there is a parsing error, then the function will go to "recover_error". It will clean up and return an error code. If the parsing error occurs before the ldns_rr_new_frm_fp function call, then nsec3params_rr will have the NULL value. The ldns_rr_free is called using this variable during the clean up. But the ldns_rr_free will ignore any value which is NULL. No crash should happen in this part of the code. It then does not matter if the ldns_rr_new_frm_fp is separated from the big if-statement. Where did you have "Algorithm: 7 (?)"? Just so that I can recreate the issue. Was the question mark transferred from the Enforcer to the Signer Engine? Or did you enter it somewhere in the signer configuration or backup file? -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard at opendnssec.org Mon Aug 1 14:16:46 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 1 Aug 2011 16:16:46 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting? In-Reply-To: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> References: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> Message-ID: > Thursday August 11th, 10:30h CEST Ok > Friday August 12th, 10:30h CEST Maybe From AlexD at nominet.org.uk Tue Aug 2 14:54:51 2011 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Tue, 2 Aug 2011 14:54:51 +0000 Subject: [Opendnssec-develop] Minutes Thu Jun 16 2011 In-Reply-To: <1FE9786D-5FF3-45F3-86DE-667CEBE44F6D@kirei.se> References: <4DFA00EA.5030906@nlnetlabs.nl> <1FE9786D-5FF3-45F3-86DE-667CEBE44F6D@kirei.se> Message-ID: <4D3ECB4C-204C-464F-BA7A-A3EC5B72DA37@nominet.org.uk> On 17 Jun 2011, at 14:08, Jakob Schlyter wrote: > On 16 jun 2011, at 15.11, Matthijs Mekking wrote: > >> About the auditor. I really thought it was going to be disabled in >> feature releases, when the code has become more mature. I thought we >> decided that in Stockholm, Feb 2011. Eventually we already wanted to do >> that already in 1.3, but I said it might be better to do it later, as I >> was just introducing the drudgers. I wanted to look it up in the >> minutes, but I couldn't find them (are there any?) > > Yes, we've said we will disable it by default, but not remove it. This sounds sensible to me. Alex. From rickard at opendnssec.org Wed Aug 3 08:01:28 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 3 Aug 2011 10:01:28 +0200 Subject: [Opendnssec-develop] PIN daemon Message-ID: Hi We have been talking about a PIN daemon for some time now, and I was thinking if shared memory would be sufficient? E.g. 1. The process creates/opens a named semaphore. 2. Lock the semaphore. 3. Create the shared memory if it does not exist. 4. If PIN exist, unlock and return PIN. 5. If PIN does not exist, get PIN from config or PIN callback. 6. Save PIN, unlock, return PIN. // Rickard From AlexD at nominet.org.uk Wed Aug 3 09:09:51 2011 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Wed, 3 Aug 2011 09:09:51 +0000 Subject: [Opendnssec-develop] Testing ODS 1.2.2 branch In-Reply-To: References: <60E0FAC48923D348BF7B1861488E606E06FE8BBA@kambx3.SIDN.local> <4E1AF57E.2000206@nlnetlabs.nl> Message-ID: On 12 Jul 2011, at 13:17, Rickard Bellgrim wrote: > On Mon, Jul 11, 2011 at 3:07 PM, Matthijs Mekking wrote: >> The developers (including me) should check and report if there are >> pending patches before you can start testing. > > * No bug reports in Trac. > * NSEC3 problem reported by Bryton on the user list. Does this still need to be looked at? Thanks, Alex. From rickard at opendnssec.org Wed Aug 3 09:18:02 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 3 Aug 2011 11:18:02 +0200 Subject: [Opendnssec-develop] Testing ODS 1.2.2 branch In-Reply-To: References: <60E0FAC48923D348BF7B1861488E606E06FE8BBA@kambx3.SIDN.local> <4E1AF57E.2000206@nlnetlabs.nl> Message-ID: >> * NSEC3 problem reported by Bryton on the user list. > > Does this still need to be looked at? Yes See message from Bryton, Jul 8. // Rickard From yuri at NLnetLabs.nl Wed Aug 3 10:25:28 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Wed, 03 Aug 2011 12:25:28 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting? In-Reply-To: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> References: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> Message-ID: <4E392218.20304@nlnetlabs.nl> > Thursday August 11th, 10:30h CEST > Friday August 12th, 10:30h CEST Both fine. -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From jakob at kirei.se Wed Aug 3 10:50:48 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 3 Aug 2011 12:50:48 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting? In-Reply-To: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> References: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> Message-ID: On 1 aug 2011, at 14.20, Roland van Rijswijk wrote: > Thursday August 11th, 10:30h CEST works. > Friday August 12th, 10:30h CEST works not. j From matthijs at NLnetLabs.nl Wed Aug 3 11:12:11 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 03 Aug 2011 13:12:11 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting? In-Reply-To: <4E392218.20304@nlnetlabs.nl> References: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> <4E392218.20304@nlnetlabs.nl> Message-ID: <4E392D0B.1010107@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/2011 12:25 PM, Yuri Schaeffer wrote: >> Thursday August 11th, 10:30h CEST >> Friday August 12th, 10:30h CEST > > Both fine. > Ack. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOOS0KAAoJEA8yVCPsQCW52y8H/R5wIk86/x76jFUPyQB7zYxv +aQ9dKI98AxJd5e3dzv4bRP6MmjdyKK/p8mmTlbiArAljJgrcnvZkQiB9nBqMZqt 0NIuatB/4KSifKBp5MJesejzmygu3sP5dpt0ob38aOhSN8HBFW1u6TtNIrRjHSZL VI6KABhAfwF3mkhg3AiUNisBR2SrokDL22ZswSFdl6hAptQMQ1pqzs6PVvR64Mzd CAnD4uQlpbDfPLLRtqJ5Fai1pv4tsVMCd/veAtMdK1PZo3jDN9E0XMNXGG/DDZ6B QPh1d6q8Sf5WUHL5hPJ7ZlCAyd01zITPbuHGEtYVMRrb3jdTXc7tPu9OhLWUCz8= =xfEz -----END PGP SIGNATURE----- From nick.vandenheuvel at sidn.nl Wed Aug 3 11:59:53 2011 From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel) Date: Wed, 3 Aug 2011 11:59:53 +0000 Subject: [Opendnssec-develop] Enforcer NG meeting? In-Reply-To: <4E392218.20304@nlnetlabs.nl> References: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> <4E392218.20304@nlnetlabs.nl> Message-ID: <60E0FAC48923D348BF7B1861488E606E074D4A3D@kambx3.SIDN.local> Same here -----Original Message----- From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Yuri Schaeffer Sent: woensdag 3 augustus 2011 12:25 To: opendnssec-develop at lists.opendnssec.org Subject: Re: [Opendnssec-develop] Enforcer NG meeting? > Thursday August 11th, 10:30h CEST > Friday August 12th, 10:30h CEST Both fine. -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From Roland.vanRijswijk at surfnet.nl Wed Aug 3 19:52:47 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Wed, 3 Aug 2011 15:52:47 -0400 Subject: [Opendnssec-develop] Enforcer NG meeting? In-Reply-To: <60E0FAC48923D348BF7B1861488E606E074D4A3D@kambx3.SIDN.local> References: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> <4E392218.20304@nlnetlabs.nl> <60E0FAC48923D348BF7B1861488E606E074D4A3D@kambx3.SIDN.local> Message-ID: Thursday 11/8 it is then! On 3 aug 2011, at 07:59, Nick van den Heuvel wrote: > Same here > > -----Original Message----- > From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Yuri Schaeffer > Sent: woensdag 3 augustus 2011 12:25 > To: opendnssec-develop at lists.opendnssec.org > Subject: Re: [Opendnssec-develop] Enforcer NG meeting? > >> Thursday August 11th, 10:30h CEST >> Friday August 12th, 10:30h CEST > > Both fine. > > -- > Yuri Schaeffer > NLnet Labs > http://www.nlnetlabs.nl > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From staffordp1 at ornl.gov Mon Aug 1 13:54:05 2011 From: staffordp1 at ornl.gov (Stafford, Paige L.) Date: Mon, 01 Aug 2011 09:54:05 -0400 Subject: [Opendnssec-develop] RE: [OpenDNSSEC] #257: Error in ods-signerd In-Reply-To: <072.e775cbd0560689ecfa48b77d3384ab7a@kirei.se> References: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> <072.e775cbd0560689ecfa48b77d3384ab7a@kirei.se> Message-ID: Hmmm... I'm a bit confused. I'm not sure how I'm "creating a backup file." I do have the "" option in the conf.xml enabled. Is that the problem? Other than that, since the error occurred when executing "ods-control start," I don't believe I'm purposely requesting backup files... BTW, I'm migrating from Xelerance DNSx. Some of the KSK's do not have the key algorithm defined properly (it shows the algorithm="?"), and when importing, "softhsm-keyconf --topkcs8" doesn't complain about the it. -----Original Message----- From: OpenDNSSEC [mailto:owner-dnssec-trac at kirei.se] Sent: Monday, August 01, 2011 9:10 AM Cc: opendnssec-develop at lists.opendnssec.org Subject: Re: [OpenDNSSEC] #257: Error in ods-signerd #257: Error in ods-signerd ----------------------------------------------+----------------------------- Reporter: staffordp1@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.3.0 | Resolution: Keywords: nsec3params zone.c nsec3params_rr | ----------------------------------------------+----------------------------- Comment (by rb): Thanks for finding the issue. We will have a look at it. The code that you mention is used to read the internal backup file. You do not need to create the backup file if you migrate to OpenDNSSEC. You just need to: 1. Configure the system 2. ods-ksmutil setup 3. ods-ksmutil key import ... 4. ods-control start hxxp://trac.opendnssec.org/wiki/Signer/Using/Migrating -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 4 09:22:03 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Aug 2011 09:22:03 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #257: Error in ods-signerd In-Reply-To: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> References: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> Message-ID: <072.1557005b8ece770737e970040c67fdf5@kirei.se> #257: Error in ods-signerd ----------------------------------------------+----------------------------- Reporter: staffordp1@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.3.0 | Resolution: Keywords: nsec3params zone.c nsec3params_rr | ----------------------------------------------+----------------------------- Comment (by rb): Stafford replied on the automatic email, but the message did not end up here. So I am posting it here: ------- Hmmm... I'm a bit confused. I'm not sure how I'm "creating a backup file." I do have the "" option in the conf.xml enabled. Is that the problem? Other than that, since the error occurred when executing "ods-control start," I don't believe I'm purposely requesting backup files... BTW, I'm migrating from Xelerance DNSx. Some of the KSK's do not have the key algorithm defined properly (it shows the algorithm="?"), and when importing, "softhsm-keyconf --topkcs8" doesn't complain about the it. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 4 09:33:24 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Aug 2011 09:33:24 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #257: Error in ods-signerd In-Reply-To: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> References: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> Message-ID: <072.6a3cfc07c337bd87050a0e24c711d621@kirei.se> #257: Error in ods-signerd ----------------------------------------------+----------------------------- Reporter: staffordp1@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.3.0 | Resolution: Keywords: nsec3params zone.c nsec3params_rr | ----------------------------------------------+----------------------------- Comment (by rb): Maybe the backup file is a side effect. Will ignore it for now and focus on your first steps. So some of the BIND private key files from Xelerence DNSx will have "Algorithm: ?" in them? SoftHSM is doing strtol() and will get 0 on the question mark. Thus returning this error message: {{{ softhsm-keyconv --topkcs8 --in Kexample.com.+007+62955.private --out key.pem Error: The algorithm 0 is not supported. }}} What more steps did you take? Because I cannot reproduce this. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 4 10:04:39 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Aug 2011 10:04:39 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #257: Error in ods-signerd In-Reply-To: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> References: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> Message-ID: <072.cd37d1333bd4c9636b9ae975e5fdc7bb@kirei.se> #257: Error in ods-signerd ----------------------------------------------+----------------------------- Reporter: staffordp1@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.3.0 | Resolution: Keywords: nsec3params zone.c nsec3params_rr | ----------------------------------------------+----------------------------- Comment (by matthijs): Replying to [comment:3 rb]: > Stafford replied on the automatic email, but the message did not end up here. So I am posting it here: > > ------- > > Hmmm... I'm a bit confused. I'm not sure how I'm "creating a backup file." I do have the "" option in the conf.xml enabled. Is that the problem? Other than that, since the error occurred when executing "ods-control start," I don't believe I'm purposely requesting backup files... > > BTW, I'm migrating from Xelerance DNSx. Some of the KSK's do not have the key algorithm defined properly (it shows the algorithm="?"), and when importing, "softhsm-keyconf --topkcs8" doesn't complain about the it. You are mixing things. has nothing to do with the signer backup files. The report and change refer to code that reads the signer backup files from the tmp/ directory. I have yet to try out your patch. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 4 10:40:36 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Aug 2011 10:40:36 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #246: Kaspcheck validates kasp.xml when NSEC3 algorithm is 0 In-Reply-To: <057.ef3068d0c172b6bf23251027cbef494f@kirei.se> References: <057.ef3068d0c172b6bf23251027cbef494f@kirei.se> Message-ID: <072.9d4fad046c9af19dd10525e33edb7572@kirei.se> #246: Kaspcheck validates kasp.xml when NSEC3 algorithm is 0 --------------------------------+------------------------------------------- Reporter: Nick van den Heuvel | Owner: alex Type: defect | Status: closed Priority: minor | Component: Unknown Version: 1.3.0 | Resolution: fixed Keywords: 1.3.0rc3 | --------------------------------+------------------------------------------- Changes (by alex): * status: assigned => closed * resolution: => fixed Comment: svn r5351 -- Ticket URL: OpenDNSSEC OpenDNSSEC From AlexD at nominet.org.uk Thu Aug 4 13:11:01 2011 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Thu, 4 Aug 2011 13:11:01 +0000 Subject: [Opendnssec-develop] Testing ODS 1.2.2 branch In-Reply-To: References: <60E0FAC48923D348BF7B1861488E606E06FE8BBA@kambx3.SIDN.local> <4E1AF57E.2000206@nlnetlabs.nl> Message-ID: >>> * NSEC3 problem reported by Bryton on the user list. >> >> Does this still need to be looked at? > > Yes > > See message from Bryton, Jul 8. AFAICT, Bryton is running 1.2.1, released in March 2011. I believe that the bug he refers to was fixed in the 1.2 branch in svn r5144. HTH, Alex. From owner-dnssec-trac at kirei.se Thu Aug 4 13:29:59 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Aug 2011 13:29:59 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #257: Error in ods-signerd In-Reply-To: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> References: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> Message-ID: <072.9135de04295ac1e3eba1455785fc83f0@kirei.se> #257: Error in ods-signerd ----------------------------------------------+----------------------------- Reporter: staffordp1@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.3.0 | Resolution: Keywords: nsec3params zone.c nsec3params_rr | ----------------------------------------------+----------------------------- Comment (by anonymous): Because I'm not getting an error when I do the conversion, I'd like to make sure that it's not something to do with the key i'm using. Here is how it's executed to translate it: # /usr/local/softHSM/bin/softhsm-keyconv --topkcs8 --in ksk.6561.private --out ksk.6561.key[[BR]] The key has been written to ksk.6561.key Here is the contents of ksk.6561.private: {{{ Private-key-format: v1.2 Algorithm: 7 (?) Modulus: tzitzGUaFd5Z21Tz3R/Q2DYAJl7/92IWJFr5wnjPoVRwVMjWP73I0Ju9YAdTIEpj47bRS5NnkaRuc78GfqWt6zdfSSiQKPZ9plXYAiWmj36r8RYc6Acin10nwEf5X+WuZpUaQXz8nNcZ4XImU2Ha30e29X8iJM5SYVBoWv0oIdC2r/8EUb7I2/aT4eIIKETQbw5bnOu7o8czJbx8ORQC8hxZNL9tByCPv5FK90zOGRNInIJ4Doh20ZY+b02KWvuVSiTO459w6pCTFJm49FCpehEen2XilA742nysMayzTArCSJXIizZ0CXyeA5dvyJz1QaUNX9p9WpFKutNCP/Rk4w== PublicExponent: AQAB PrivateExponent: o2k+wSSO3mBAvjkHgvmEV8HZ4l8qZiYqX2Rwi70aWeYohcXWKGWI/F1aypHd1tfiPU9pXcFrRt9jz4HZNg1oj3gEWQh/grlNGZRIoqmX4zVz/wLc5yit/XqlIH5Q8PG12TI0h6IE35GNOKCJhCargibBDDXGaxNFMBv55uUQ7Q5pwt/v7aYYAcgAOG5pXer/i9bVbJGCLX1X9Jn7O8Kt4SfftJmCqGIyeDEMrHoXtuoOehwedlNMG8jH/GQ/R5DnjLAp5yyjppvXwQUkV7TOq3VE/mnZtiVfNSbjiqVt/x7Ze9e9I3Qwja2PNCqitHtFim8ojAh/8lIOqaGMvGAzQQ== Prime1: 4EIuE3d3VqF5QPQTgLTe77LIhIlVIveEAIj6Dt4KROoCUWH9mbv0kD7dC0uoKz/faPijEf3kTECDYYb4NAUtoEA0aEdPqcbVsjcIUIIkXsl9mqbZlTmOxhWNveCM66Dud2kSZa2vdMH2DSAj5vbgVNeWPYizdHA80fXnYOJoLUM= Prime2: 0SeNqiBHw1d83TMgX8cVmYIsh0sgxPlUl5HkxPgQrVCeOYo7bFpPElaakibZuxg6YVLK15Kca8a3mVYSLgd+eAVhijvgT1pJRVL53zQGHcddQMLGOl8rUUWXkLX3u7NXOTudHgK6NZxRHb31A19gq2ihokXXY6+p0vrjOXAYn+E= Exponent1: hPB2Y+/T/LToLksCLLAL4Eg5eef3Yi0cQTzyD1ItAEFAcoIGVdYH2mKJoqKM5GaOx6ls8cNyTImJ2IysIhpXu8GTz6VGYjyOfYEGGsOrT81d+gmivkVKj75DMiYlI6FY+8x7rW7SrgI1G/7LiaUbwu+yDnQ0/XdzdnuxV8ufOgU= Exponent2: RqUNfIEavCg4zJ4QOUmNSiRl1ezSTLXKlMd6de0z9NZeGyFNoPN/8bm+y87DjCZK0cSdLuMeYmjkaq5fxZxSY0euAnrm8OaWCQxVycZQqo5EOTOQsPakMvdGkmJkIsoYlARGtXRGYQVDgMBAmbsFc+ALeDwO3GTg/5ouVaA/MQE= Coefficient: FYAwTyzhqfg4JZ9cEqJLedAK2AbCKOkKL1P6VDzlaREI9eKN3jwFJ/5bpdq0RVXgq5QVQn5efu/JTpWqSzY/qAKgLBWGHMpnd92B4E5xzhqq6hX2bHttEmuf+MnBmaJrVZjlXyXiCRmnMMy8okE/WrOfHYORqU+awY/oBpquEms= }}} Replying to [comment:4 rb]: > Maybe the backup file is a side effect. Will ignore it for now and focus on your first steps. > [] > So some of the BIND private key files from Xelerence DNSx will have "Algorithm: ?" in them? > > SoftHSM is doing strtol() and will get 0 on the question mark. Thus returning this error message: > {{{ > softhsm-keyconv --topkcs8 --in Kexample.com.+007+62955.private --out key.pem > Error: The algorithm 0 is not supported. > }}} > > What more steps did you take? Because I cannot reproduce this. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 4 14:15:50 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Aug 2011 14:15:50 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #257: Error in ods-signerd In-Reply-To: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> References: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> Message-ID: <072.eea428966e7d4b0338d5c684e4399b26@kirei.se> #257: Error in ods-signerd ----------------------------------------------+----------------------------- Reporter: staffordp1@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.3.0 | Resolution: Keywords: nsec3params zone.c nsec3params_rr | ----------------------------------------------+----------------------------- Comment (by rb): The extra question mark should not be a problem. strtol() will stop parsing when it comes to it. It will get algorithm 7 as expected. The core dump is probably caused by something else. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard at opendnssec.org Fri Aug 5 08:48:14 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 5 Aug 2011 10:48:14 +0200 Subject: [Opendnssec-develop] libhsm with DSA and GOST Message-ID: Hi I added support for DSA and GOST to libhsm yesterday. I am having some problem with DSA key generation. SCA6000 is missing the CKM_DSA_PARAMETER_GEN mechanism. It is needed in order to generate the DSA parameters for a given key length. The SafeNet Luna SA will give CKR_ATTRIBUTE_TYPE_INVALID for a template only containing the CKA_PRIME_BITS attribute. 1. C_GenerateKey with CKA_PRIME_BITS. 2. Extract CKA_PRIME, CKA_SUBPRIME, and CKA_BASE from domain parameter object. 3. Delete domain parameter object. 4. C_GenerateKeyPair with CKA_PRIME, CKA_SUBPRIME, and CKA_BASE. Any ideas? It would be good to use the CKM_DSA_PARAMETER_GEN so that we do not have to generate the domain parameters ourselves. And GOST, I have no HSM that support it. I thus do not know if that code is working. // Rickard From rickard at opendnssec.org Fri Aug 5 14:40:42 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 5 Aug 2011 16:40:42 +0200 Subject: [Opendnssec-develop] Refactoring of libhsm Message-ID: Hi We had one task where we wanted to refactor libhsm. The main issues where lost connections and listing keys. Lost connections ------------------------- Some HSMs will close down a session if it has not been used for some time. The idea was to redesign libhsm to handle this. Most of the actions in libhsm has something to do with a session, so it would be a lot of work to be able to restore the session. I think it would more suitable for the application to handle this. Like the Enforcer does it, to reload libhsm or make sure to close down the connections if they are not going to be used. Listing keys ----------------- The problem was that it takes long time to list keys when using both private and public keys. Public and private keys are stored as separate objects in PKCS#11, but we bundle them with the same ID. There are however no way of searching for key pairs in PKCS#11, so we have to first find all private keys. Extract the ID and then find the corresponding public key using that ID. This is also the way it is done in libhsm. There are thus nothing we can change in libhsm to make it faster. Private vs. Public keys --------------------------------- RSA keys also have the public key material in the private key. We can thus save space by not storing the public key and save some performance because we do not need to search for the public key. PKCS#11 does not guarantee that the public key material is available in the private key, but all HSMs we have been in contact with does so. OpenDNSSEC utilize this by adding an option to the repository list. This does not however work for DSA and GOST. If you want to extract the public key material, then you need the public key object. Public value Y from DSA and the curve point P(X, Y) for GOST. There are two options here. 1. Detect what algorithm the key object belongs to. Will probably degrade the performance somewhat. 2. Recommend that user to disable the option if they plan to run DAS or GOST. What do you think? // Rickard From rickard at opendnssec.org Mon Aug 8 06:39:06 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 8 Aug 2011 08:39:06 +0200 Subject: [Opendnssec-develop] Auditor and adaptors In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 2:37 PM, Alex Dalitz wrote: > Hi ?- > > I have an outstanding action to kick off a discussion on the mailing list about how the auditor should interact with the new adaptors. > > Perhaps we could start by defining the functionality of the new adaptors? Do we have any thoughts on this topic? // Rickard From rickard at opendnssec.org Mon Aug 8 06:40:49 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 8 Aug 2011 08:40:49 +0200 Subject: [Opendnssec-develop] Meeting 20110810 Message-ID: Hi Next meeting is on Wednesday. Date: Wednesday 10 August Time: 14:00-15:00 CEST, 13:00-14:00 BST http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-08-10 // Rickard From owner-dnssec-trac at kirei.se Mon Aug 8 09:02:55 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 08 Aug 2011 09:02:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #257: Error in ods-signerd In-Reply-To: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> References: <057.4059ff51c872b25ae5022961c80d96b4@kirei.se> Message-ID: <072.6d12e59fc575397e3fb37217f634072c@kirei.se> #257: Error in ods-signerd ----------------------------------------------+----------------------------- Reporter: staffordp1@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.3.0 | Resolution: Keywords: nsec3params zone.c nsec3params_rr | ----------------------------------------------+----------------------------- Comment (by matthijs): The proposed change has the effect that all backup files will be corrupted, since it changes the expectations of how the backup file should look like. Is it possible to get the backup file for the zone that created this problem? It is stored at /var/opendnssec/tmp/.backup. (You may send it to me in private, and I think all I need is the NSEC3 parameters part). Thanks. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 8 12:57:10 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 08 Aug 2011 12:57:10 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #258: ods-control not robust in ensuring process running Message-ID: <047.4ce958334fd95f9427363b1ad33c0fe0@kirei.se> #258: ods-control not robust in ensuring process running ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: sion Type: defect | Status: new Priority: trivial | Component: Enforcer Version: 1.3.0 | Keywords: ods-control pid_file ----------------------+----------------------------------------------------- Instead of checking a pid file, which seemed to exist despite the ods- enforcerd not running, i changed the script for ods-control to have this instead: {{{ if [ $? -eq 0 ]; then #if [ -r "$enforcer_pid_file" ]; then echo "Enforcer is already running" RETVAL=-1 }}} running Linux 2.6.32-71.el6.x86_64 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 8 13:12:40 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 08 Aug 2011 13:12:40 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #258: ods-control not robust in ensuring process running In-Reply-To: <047.4ce958334fd95f9427363b1ad33c0fe0@kirei.se> References: <047.4ce958334fd95f9427363b1ad33c0fe0@kirei.se> Message-ID: <062.1fd7944fcaedd0095e38be2967c2a7bc@kirei.se> #258: ods-control not robust in ensuring process running ---------------------------------+------------------------------------------ Reporter: anonymous | Owner: sion Type: defect | Status: new Priority: trivial | Component: Enforcer Version: 1.3.0 | Resolution: Keywords: ods-control pid_file | ---------------------------------+------------------------------------------ Comment (by anonymous): When the ods-enforcerd process is killed w/o using ods-control, the ods- enforcerd pid file does not get deleted. Using the kill command is necessary when ods-control is unresponsive. To avoid ods-control not bringing the enforcer back up b/c of the existence of the pid file, i changed the script for ods-control to have this instead: {{{ /bin/ps -C ods-enforcerd -o pid= if [ $? -eq 0 ]; then #if [ -r "$enforcer_pid_file" ]; then echo "Enforcer is already running" RETVAL=-1 fi }}} running Linux 2.6.32-71.el6.x86_64 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Aug 8 13:34:44 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 08 Aug 2011 13:34:44 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #259: KSM interprets passwords Message-ID: <045.bd05356bfcbf398c7bf143f362afb045@kirei.se> #259: KSM interprets passwords --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: 1.3.0 | Keywords: --------------------+------------------------------------------------------- A surprise, and possibly a security concern: When trying to setup a KASP database in MySQL with a difficult password, I ran into the problem that it contained a shell-special character. I received an attempted mysql cmdline, including a -p with the password. The shell had gotten confused over it. This is an unwise constraint on the possible passwords -- and it makes them being interpreted, shown in process listings, and so on. A much better solution is to provide the password on the input stream. A workaround for some of the problems would be to quote the password. I just picked another password, but felt estanged enough to report this as a point of attention on OpenDNSSEC security. -Rick -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick at openfortress.nl Mon Aug 8 13:42:49 2011 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 8 Aug 2011 13:42:49 +0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #259: KSM interprets passwords In-Reply-To: <045.bd05356bfcbf398c7bf143f362afb045@kirei.se> References: <045.bd05356bfcbf398c7bf143f362afb045@kirei.se> Message-ID: <20110808134249.GA8447@phantom.vanrein.org> What was missing: > When trying to setup a KASP database in MySQL with a difficult password, I > ran into the problem that it contained a shell-special character. This was during "ods-ksmutil setup" which apparently invokes "mysql -u root -pXYZ" to get the work done. -Rick From rickard at opendnssec.org Tue Aug 9 14:37:18 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 9 Aug 2011 16:37:18 +0200 Subject: [Opendnssec-develop] Re: [Opendnssec-commits] [keihatsu.kirei.se/svn/dnssec] r5372 - in trunk/OpenDNSSEC/signer/src: shared signer In-Reply-To: <20110808080258.2C59F1EF01C@lists.nominet.org.uk> References: <20110808080258.2C59F1EF01C@lists.nominet.org.uk> Message-ID: On Mon, Aug 8, 2011 at 10:02 AM, Matthijs Mekking wrote: > Author: matthijs > Date: 2011-08-08 10:02:54 +0200 (Mon, 08 Aug 2011) > New Revision: 5372 > > Modified: > ? trunk/OpenDNSSEC/signer/src/shared/hsm.c > ? trunk/OpenDNSSEC/signer/src/signer/keys.c > ? trunk/OpenDNSSEC/signer/src/signer/keys.h > Log: > Pivotal Story #16517425: Signature lifetime too long/short > https://www.pivotaltracker.com/story/show/16517425 > > port from branch 1.3 I am getting errors from this one. Aug 9 14:19:20 fou ods-signerd: ../../../signer/src/shared/hsm.c at 58 could not pthread_mutex_lock(&key_id->key_lock): Invalid argument Aug 9 14:19:20 fou ods-signerd: ../../../signer/src/shared/hsm.c at 78 could not pthread_mutex_unlock(&key_id->key_lock): Invalid argument Aug 9 14:19:20 fou ods-signerd: ../../../signer/src/shared/hsm.c at 112 could not pthread_mutex_lock(&key_id->key_lock): Invalid argument Aug 9 14:19:20 fou ods-signerd: ../../../signer/src/shared/hsm.c at 114 could not pthread_mutex_unlock(&key_id->key_lock): Invalid argument Another problem is that you now only get a single threaded signer since there is a lock for the key. Would it be a solution to have a local params in the lhsm_sign and get the non-volatile information (owner, algorithm, flags) from the key_id? // Rickard From rickard at opendnssec.org Tue Aug 9 15:06:13 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 9 Aug 2011 17:06:13 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: References: Message-ID: On Wed, Aug 3, 2011 at 10:01 AM, Rickard Bellgrim wrote: > We have been talking about a PIN daemon for some time now, and I was > thinking if shared memory would be sufficient? The problem I am seeing now is that getpass() does not work so good when we are working with daemons. How should the user enter a PIN to a background process? The PIN request is part of hsm_open(). // Rickard From matthijs at NLnetLabs.nl Tue Aug 9 20:58:23 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 09 Aug 2011 22:58:23 +0200 Subject: [Opendnssec-develop] Re: [Opendnssec-commits] [keihatsu.kirei.se/svn/dnssec] r5372 - in trunk/OpenDNSSEC/signer/src: shared signer In-Reply-To: References: <20110808080258.2C59F1EF01C@lists.nominet.org.uk> Message-ID: <4E419F6F.6080504@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/09/2011 04:37 PM, Rickard Bellgrim wrote: > On Mon, Aug 8, 2011 at 10:02 AM, Matthijs Mekking wrote: >> Author: matthijs >> Date: 2011-08-08 10:02:54 +0200 (Mon, 08 Aug 2011) >> New Revision: 5372 >> >> Modified: >> trunk/OpenDNSSEC/signer/src/shared/hsm.c >> trunk/OpenDNSSEC/signer/src/signer/keys.c >> trunk/OpenDNSSEC/signer/src/signer/keys.h >> Log: >> Pivotal Story #16517425: Signature lifetime too long/short >> https://www.pivotaltracker.com/story/show/16517425 >> >> port from branch 1.3 > > I am getting errors from this one. > > Aug 9 14:19:20 fou ods-signerd: ../../../signer/src/shared/hsm.c at > 58 could not pthread_mutex_lock(&key_id->key_lock): Invalid argument > Aug 9 14:19:20 fou ods-signerd: ../../../signer/src/shared/hsm.c at > 78 could not pthread_mutex_unlock(&key_id->key_lock): Invalid argument > Aug 9 14:19:20 fou ods-signerd: ../../../signer/src/shared/hsm.c at > 112 could not pthread_mutex_lock(&key_id->key_lock): Invalid argument > Aug 9 14:19:20 fou ods-signerd: ../../../signer/src/shared/hsm.c at > 114 could not pthread_mutex_unlock(&key_id->key_lock): Invalid > argument Strange. > > Another problem is that you now only get a single threaded signer > since there is a lock for the key. Would it be a solution to have a > local params in the lhsm_sign and get the non-volatile information > (owner, algorithm, flags) from the key_id? Yes, I was afraid for that. I have already changed that locally, will commit tomorrow. Best regards, > > // Rickard > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOQZ9vAAoJEA8yVCPsQCW5TosH/2UaABtu8/P9LHe6uKM6ERDJ RGH/Fu7m9Kq1beORVj0Bj+/BkvYxOiCVF3iChJoJEG34rzrEP7DIJDaTKJ9n5KCG 5VdZ9I4uR8J8HDURRWqwQX32qICpb/Xl0fS3Oaop8UHKzrRoydifjyQlD/kKTbY3 8K4NoEVUsfNlC3Cj43BJLv0hJFrwrzTPWsFZj7Vi4X5E2waFBvkPRmpRWeJcG+57 tdE8hTz+XsEYAFpUJpdk4mBQX9tZ9Wi3zH5M5VTgcChhWe/EP6M1X5nP59rgbsdf +kVs7KQ8MUSJfdC2muLpiLqnCf+Q0tLCjDkJaPeuAiBDsc86haBlrBB1SwWMky4= =bUvh -----END PGP SIGNATURE----- From rickard at opendnssec.org Wed Aug 10 09:09:00 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 10 Aug 2011 11:09:00 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: References: Message-ID: On Tue, Aug 9, 2011 at 5:06 PM, Rickard Bellgrim wrote: > On Wed, Aug 3, 2011 at 10:01 AM, Rickard Bellgrim > wrote: >> We have been talking about a PIN daemon for some time now, and I was >> thinking if shared memory would be sufficient? > > The problem I am seeing now is that getpass() does not work so good > when we are working with daemons. How should the user enter a PIN to a > background process? > > The PIN request is part of hsm_open(). Perhaps the daemons should block (within libhsm) until the user has entered the PIN using ods-hsmutil? // Rickard From rickard at opendnssec.org Wed Aug 10 09:23:41 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 10 Aug 2011 11:23:41 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: References: Message-ID: On Wed, Aug 10, 2011 at 11:09 AM, Rickard Bellgrim wrote: > On Tue, Aug 9, 2011 at 5:06 PM, Rickard Bellgrim wrote: >> On Wed, Aug 3, 2011 at 10:01 AM, Rickard Bellgrim >> wrote: >>> We have been talking about a PIN daemon for some time now, and I was >>> thinking if shared memory would be sufficient? >> >> The problem I am seeing now is that getpass() does not work so good >> when we are working with daemons. How should the user enter a PIN to a >> background process? >> >> The PIN request is part of hsm_open(). > > Perhaps the daemons should block (within libhsm) until the user has > entered the PIN using ods-hsmutil? No, that would not be so good. Because ods-hsmutil also relies on libhsm. From rick at openfortress.nl Wed Aug 10 13:26:22 2011 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 10 Aug 2011 13:26:22 +0000 Subject: [Opendnssec-develop] Minutes made Message-ID: <20110810132622.GA23260@phantom.vanrein.org> Hi, I placed the minutes of the past meeting online, at http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-08-10 -Rick From matthijs at NLnetLabs.nl Wed Aug 10 13:42:46 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 10 Aug 2011 15:42:46 +0200 Subject: [Opendnssec-develop] Minutes made In-Reply-To: <20110810132622.GA23260@phantom.vanrein.org> References: <20110810132622.GA23260@phantom.vanrein.org> Message-ID: <4E428AD6.2070907@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I made a couple of editorial changes: - - Added pivotal story link to the signer threading bugfix - - Corrected "Joeri's" name :) - - typo http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-08-10?action=diff&version=2&old_version=1 Best regards, Matthijs On 08/10/2011 03:26 PM, Rick van Rein wrote: > Hi, > > I placed the minutes of the past meeting online, at > > http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-08-10 > > -Rick > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOQorWAAoJEA8yVCPsQCW5QfYH/jfEwSW38jbpt5ff22r8Ajy9 +U64z+jKzc+0eoOiCkzfLecLLpkrrNSet7GYvH1FVj0nwWE/wfxuxHJjPyFvmdC2 LdURA6X77lRN2uDtsp0O+3SK3dzXP2LRv3u1PdFKG9Cgn115b6RYS/xwlqMsfh2X FiNiLd+sZyAjlxGPxHMbh6JfmcnV2S1lrTkdgNnwgxNhn4aaZVtOKUL8sgUnBn0z QXd+ZVtmAmHRGdlTkbhNYEU0xK5vPAa5ZVF3TLcEIKix9Uoyy4z/kXX14BqNhzWU WZg8noxFKaNj5IubnhqsF4a1PfEYuyjaz9HC4hmMbEJS9AjsvQ9RoTczTkzXA5c= =GnS5 -----END PGP SIGNATURE----- From rickard at opendnssec.org Wed Aug 10 14:06:33 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 10 Aug 2011 16:06:33 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.2.2 Message-ID: Hi OpenDNSSEC 1.2.2 is ready for release. TODO: - Set correct release date in NEWS // Rickard From rickard at opendnssec.org Wed Aug 10 14:31:15 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 10 Aug 2011 16:31:15 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.3.1 Message-ID: Hi The threading issue which mixed up the validity periods is sufficient for us to make a new release. We do however have some other bug reports: * #254: Configure fails on RHEL6 - Need comment from Rick * #257: Error in ods-signerd - A malformed BIND private key file could not be the cause of the problem * #258: ods-control not robust in ensuring process running * #259: KSM interprets passwords Should we backport r5364, Alex? (Fix 'ZSK in use too long' message to handle new signer behaviour) Any comments? // Rickard From matthijs at NLnetLabs.nl Wed Aug 10 14:41:27 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 10 Aug 2011 16:41:27 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: <4E429897.8060105@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/10/2011 04:31 PM, Rickard Bellgrim wrote: > Hi > > The threading issue which mixed up the validity periods is sufficient > for us to make a new release. > > We do however have some other bug reports: > * #254: Configure fails on RHEL6 - Need comment from Rick > * #257: Error in ods-signerd - A malformed BIND private key file could > not be the cause of the problem - From the initial report, it looks to me like the cause is in the signer backup file. However, I don't think the proposed patch works. I am waiting on the backup file that caused this. > * #258: ods-control not robust in ensuring process running > * #259: KSM interprets passwords > > Should we backport r5364, Alex? (Fix 'ZSK in use too long' message to > handle new signer behaviour) > > Any comments? > > // Rickard > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOQpiXAAoJEA8yVCPsQCW5Em4H/0fOhEDHmCPf0sUCtgZVCxz8 9WkyeqojIk9ZP5HhnFkPAqcvKiwXslZOFurRG5TtIdX8J+7ob8R3Gi+1XKA7aQNS g7dlFX5IFKrkQbHD+fsbH5/DnkgujltMTaAQCeukjxWsR+5VNvprWiybdN1DSIeD eDFVFb/OvuKVIWtqviePQpAqFlF5o08pPvemLfmS9k3/2GFd3e2nMYRd9eB+76AQ NHEJPHQuWsv+sNLqcJmWqt1UzagqsFArWthUQpNnGyZbBWBIf8fseLuDA2oRLosV q3ik9TVSY+czT1z4gYYapBrqIWESlVLnxyNW+vAO2TIE+OpTf9wZ74ah8RY7KF0= =R/4M -----END PGP SIGNATURE----- From AlexD at nominet.org.uk Wed Aug 10 14:49:16 2011 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Wed, 10 Aug 2011 14:49:16 +0000 Subject: [Opendnssec-develop] OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: > Should we backport r5364, Alex? (Fix 'ZSK in use too long' message to > handle new signer behaviour) Might make sense. Alex. From owner-dnssec-trac at kirei.se Wed Aug 10 17:49:51 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 10 Aug 2011 17:49:51 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #254: Configure fails on RHEL6 In-Reply-To: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> References: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> Message-ID: <060.6ceb9fa83f62855e1e7ab249cca118e6@kirei.se> #254: Configure fails on RHEL6 ------------------------------------+--------------------------------------- Reporter: vanrein | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: configure libldns rhel6 | ------------------------------------+--------------------------------------- Comment (by vanrein): > Where is this line located? Line 14637 in OpenDNSSEC 1.3.0's ./configure script. Note that this is an estimate, based on my *limited* insight in configuration scripts. -Rick -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick at openfortress.nl Wed Aug 10 17:57:08 2011 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 10 Aug 2011 17:57:08 +0000 Subject: [Opendnssec-develop] OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: <20110810175708.GG23260@phantom.vanrein.org> Hello, In addition to those that are still open, a few closed tickets have also been applied to 1.3.0 as well AFAIK; these are mine: #256: Lost argument in "ods-control signer" #255: Patch to contrib/opendnssec.spec Cheers, -Rick From rick at openfortress.nl Wed Aug 10 18:31:07 2011 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 10 Aug 2011 18:31:07 +0000 Subject: [Opendnssec-develop] Again: Sharing PIN through POSIX message queues Message-ID: <20110810183107.GH23260@phantom.vanrein.org> Hello Rickard, I was pretty accurate with my "two years ago" estimate -- here is the PIN daemon that I proposed in August 2009. It is based on message queues, the principle of which is documented in most UNIX manuals, but it is not widely used by programmers: http://linux.die.net/man/7/mq_overview http://www.users.pjwstk.edu.pl/~jms/qnx/help/watcom/clibref/mq_overview.html Note that the attached code uses the older SysV API, which caught critisism back then. The POSIX references above are a little different, but capture the same idea. The SysV API is documented here: http://linux.die.net/man/2/msgget http://linux.die.net/man/2/msgctl http://linux.die.net/man/2/msgsnd http://linux.die.net/man/2/msgrcv The driving reason for preferring this mechanism for security reasons are: 1. The announcement is not as public as a filesystem reference; that is, it is not only protected by user/access settings like a file, but it actually is under full control of the PIN serving daemon; 2. The ability to lookup the sender's PID makes it possible to limit service to very specific processes, such as those whose PID is stored in a certain file in a certain location. I've been looking through the POSIX mq_ documentation, and cannot find the process identifier back. That means that the mileage of this approach may vary with the platform. (But now that OpenDNSSEC is ported to Windows, I suppose that is a basic issue underpinning OpenDNSSEC security anyway!) Let me know if you need more information! Cheers, -Rick -------------- next part -------------- An embedded message was scrubbed... From: Rick van Rein Subject: Sharing PIN through POSIX message queues Date: Wed, 19 Aug 2009 07:25:30 +0000 Size: 4312 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: msgqueue-pin.tgz Type: application/x-gtar Size: 1810 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Digital signature URL: From rick at openfortress.nl Wed Aug 10 19:17:44 2011 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 10 Aug 2011 19:17:44 +0000 Subject: [Opendnssec-develop] Again: Sharing PIN through POSIX message queues In-Reply-To: <20110810183107.GH23260@phantom.vanrein.org> References: <20110810183107.GH23260@phantom.vanrein.org> Message-ID: <20110810191744.GD25381@phantom.vanrein.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > I've been looking through the POSIX mq_ documentation, and cannot find the > process identifier back. That means that the mileage of this approach may > vary with the platform. (But now that OpenDNSSEC is ported to Windows, I > suppose that is a basic issue underpinning OpenDNSSEC security anyway!) Apparently, there are two API function sets to access queues. That's the nice thing about standards -- if you don't like today's version you can always wait for next year's to come 'rond. POSIX appears to be a closed spec[*] (way to go, IEEE) but online docs do give me the impression that the process-id based authentication mechanism would work in general on POSIX systems: http://pubs.opengroup.org/onlinepubs/9699919799/ I must say I've yet to find a system that doesn't implement IPC. Didn't try Windows though... but since this is an option for security-conscious users that hardly matters? So, mileage does not seem to vary at all. What I sent is indeed an approach that should port wonderfully to all POSIX systems. Cheers, -Rick [*] Interesting side-note: The formal spec for electric installations in the Netherlands, namely NEN 1010, is also a closed spec. Its status as an enforced spec (part of laws, etc.) is currently under attack as invalid because it is not open. Since we are all supposed to know the Dutch laws, they should be freely available to all. Love it :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: New to PGP? http://openfortress.nl/doc/essay/OpenPGP/index.nl.html iD8DBQFOQtlYFBGpwol1RgYRAgwcAJ0V/P/UH0iSO6h5Xv87mpAwzQZr8QCeL4CL tBFIhNasMGuMtGRM2LvMhc0= =36X1 -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Thu Aug 11 07:02:23 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Aug 2011 07:02:23 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #254: Configure fails on RHEL6 In-Reply-To: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> References: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> Message-ID: <060.78da0c3ad7cd5f9d33d669fca7cc766a@kirei.se> #254: Configure fails on RHEL6 ------------------------------------+--------------------------------------- Reporter: vanrein | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: configure libldns rhel6 | ------------------------------------+--------------------------------------- Comment (by rb): The configure script is automatically create from configure.ac together with the m4 files. http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/m4/acx_ldns.m4#L37 is converted to line 14629 in ./configure Line 14637 comes from http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/m4/acx_ldns.m4#L39 So to me it looks like the library path is included in the test. {{{ 14629: LIBS="$LIBS $LDNS_LIBS" ... 14637: LIBS="-lldns $LIBS" }}} Is the problem that you get double "-lldns" in $LIBS? What does config.log say about the failed test? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 11 07:38:53 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Aug 2011 07:38:53 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #254: Configure fails on RHEL6 In-Reply-To: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> References: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> Message-ID: <060.839bed749d80da194f3e7f3c275b63b0@kirei.se> #254: Configure fails on RHEL6 ------------------------------------+--------------------------------------- Reporter: vanrein | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: configure libldns rhel6 | ------------------------------------+--------------------------------------- Comment (by vanrein): Rickard, > Is the problem that you get double "-lldns" in $LIBS? No, it does not include the -L/usr/lib64 that it did mention as containing the library. > What does config.log say about the failed test? The fragment that seems to cover the problem is... configure:14606: checking what are the ldns libs configure:14609: result: -L/usr/lib64/python2.6 -L/usr/lib64 -lpython2.6 -L/usr/lib64 -lcrypto -lldns configure:14631: checking for ldns_rr_new in -lldns configure:14656: gcc -o conftest -g -O2 -pedantic -Wall -Wextra -I/usr/include conftest.c -lldns -L/usr/lib64/python2.6 -L/usr/lib64 -lpython2.6 -L/usr/lib64 -lcrypto -lldns >&5 /usr/bin/ld: cannot find -lpython2.6 collect2: ld returned 1 exit status configure:14656: $? = 1 configure: failed program was: | /* confdefs.h */ I'd looked at it before, but this time found a notice I hadn't seen before -- the missing python-devel package. After installing that, ./configure --with-data-base-backend=mysql --disable-auditor succeeded on RHEL6. I can only assume that this has been the problem all along. Sorry -- I seem to have read too much in the message from ./configure -- it seems a check for python before running this test is all that is needed to help configure-impaired people like me to make sense out of it all? -Rick -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Thu Aug 11 07:43:26 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Thu, 11 Aug 2011 08:43:26 +0100 Subject: [Opendnssec-develop] OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: <4E43881E.2010301@nominet.org.uk> On 10/08/11 15:31, Rickard Bellgrim wrote: > * #258: ods-control not robust in ensuring process running We appear to get a report around this sort of thing every couple of months or so... I seem to remember that we used to use "ps" in a (very) early version, possibly before the enforcer was a single process. I'll see if I can find out what issues we had with that to make us change. > * #259: KSM interprets passwords > I'll look at this today; it shouldn't take long to add quotes. Sion From rickard at opendnssec.org Thu Aug 11 07:44:28 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 11 Aug 2011 09:44:28 +0200 Subject: [Opendnssec-develop] Again: Sharing PIN through POSIX message queues In-Reply-To: <20110810183107.GH23260@phantom.vanrein.org> References: <20110810183107.GH23260@phantom.vanrein.org> Message-ID: Hi Rick On Wed, Aug 10, 2011 at 8:31 PM, Rick van Rein wrote: > Hello Rickard, > > I was pretty accurate with my "two years ago" estimate -- here is the PIN daemon > that I proposed in August 2009. ?It is based on message queues, the principle > of which is documented in most UNIX manuals, but it is not widely used by > programmers: Nice example! You can get the PID of sending process. But how do you send the message back to that PID? So that no one else can steal the message from the queue? // Rickard From owner-dnssec-trac at kirei.se Thu Aug 11 08:03:53 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Aug 2011 08:03:53 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #254: Configure fails on RHEL6 In-Reply-To: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> References: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> Message-ID: <060.cf59f6f7880cd33274a5dd232408cb17@kirei.se> #254: Configure fails on RHEL6 ------------------------------------+--------------------------------------- Reporter: vanrein | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: configure libldns rhel6 | ------------------------------------+--------------------------------------- Comment (by rb): > > Is the problem that you get double "-lldns" in $LIBS? > > No, it does not include the -L/usr/lib64 that it did mention > as containing the library. [[BR]]But it does according to your config.log below: [[BR]][[BR]] > {{{ > configure:14606: checking what are the ldns libs > configure:14609: result: -L/usr/lib64/python2.6 -L/usr/lib64 -lpython2.6 > -L/usr/lib64 -lcrypto -lldns > configure:14631: checking for ldns_rr_new in -lldns > configure:14656: gcc -o conftest -g -O2 -pedantic -Wall -Wextra -I/usr/include > conftest.c -lldns -L/usr/lib64/python2.6 -L/usr/lib64 -lpython2.6 > -L/usr/lib64 -lcrypto -lldns >&5 > /usr/bin/ld: cannot find -lpython2.6 > collect2: ld returned 1 exit status > configure:14656: $? = 1 > configure: failed program was: > | /* confdefs.h */ > }}} > > > I'd looked at it before, but this time found a notice I hadn't seen > before -- the missing python-devel package. After installing that, [[BR]]That is strange, python should not be a dependency of OpenDNSSEC. The question is where the python part comes from? What do you get from ldns-config? I get: {{{ rickard at fou:~$ ldns-config --cflags -I/usr/local/include rickard at fou:~$ ldns-config --libs -L/usr/local/lib -lcrypto -lldns }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 11 08:03:53 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Aug 2011 08:03:53 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #254: Configure fails on RHEL6 In-Reply-To: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> References: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> Message-ID: <060.2f64defdf8b5797b43688815f02ef0d6@kirei.se> #254: Configure fails on RHEL6 ------------------------------------+--------------------------------------- Reporter: vanrein | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: configure libldns rhel6 | ------------------------------------+--------------------------------------- Comment (by rb): > > Is the problem that you get double "-lldns" in $LIBS? > > No, it does not include the -L/usr/lib64 that it did mention > as containing the library. [[BR]]But it does according to your config.log below: [[BR]][[BR]] > {{{ > configure:14606: checking what are the ldns libs > configure:14609: result: -L/usr/lib64/python2.6 -L/usr/lib64 -lpython2.6 > -L/usr/lib64 -lcrypto -lldns > configure:14631: checking for ldns_rr_new in -lldns > configure:14656: gcc -o conftest -g -O2 -pedantic -Wall -Wextra -I/usr/include > conftest.c -lldns -L/usr/lib64/python2.6 -L/usr/lib64 -lpython2.6 > -L/usr/lib64 -lcrypto -lldns >&5 > /usr/bin/ld: cannot find -lpython2.6 > collect2: ld returned 1 exit status > configure:14656: $? = 1 > configure: failed program was: > | /* confdefs.h */ > }}} > > > I'd looked at it before, but this time found a notice I hadn't seen > before -- the missing python-devel package. After installing that, [[BR]]That is strange, python should not be a dependency of OpenDNSSEC. The question is where the python part comes from? What do you get from ldns-config? I get: {{{ rickard at fou:~$ ldns-config --cflags -I/usr/local/include rickard at fou:~$ ldns-config --libs -L/usr/local/lib -lcrypto -lldns }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From Roland.vanRijswijk at surfnet.nl Thu Aug 11 08:15:11 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 11 Aug 2011 10:15:11 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting? In-Reply-To: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> References: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> Message-ID: <445D30EC-D5F8-455E-899C-4B8DB6115687@surfnet.nl> Hi guys, The dial-in number for today is the same as for the last couple of meetings. We start at 10:30h CEST. Dial-in to +31-30-2040323 Conference PIN: 030003 Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jakob at kirei.se Thu Aug 11 08:20:39 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 11 Aug 2011 10:20:39 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting? In-Reply-To: <445D30EC-D5F8-455E-899C-4B8DB6115687@surfnet.nl> References: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> <445D30EC-D5F8-455E-899C-4B8DB6115687@surfnet.nl> Message-ID: <55F78D27-709A-4408-95C0-E0AB75E17CA4@kirei.se> Any change you can bridge this number via Skype and/or some other VoIP technology? jakob From Roland.vanRijswijk at surfnet.nl Thu Aug 11 08:21:28 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 11 Aug 2011 10:21:28 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting? In-Reply-To: <55F78D27-709A-4408-95C0-E0AB75E17CA4@kirei.se> References: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> <445D30EC-D5F8-455E-899C-4B8DB6115687@surfnet.nl> <55F78D27-709A-4408-95C0-E0AB75E17CA4@kirei.se> Message-ID: <6C1FB7CE-0D8B-4BDC-9227-A1286FF6B3E7@surfnet.nl> Hi Jakob, On 11 aug 2011, at 10:20, Jakob Schlyter wrote: > Any change you can bridge this number via Skype and/or some other VoIP technology? Unfortunately not, our VoIP deployment seems to be quite primitive in that respect :( Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jakob at kirei.se Thu Aug 11 08:22:26 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 11 Aug 2011 10:22:26 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting? In-Reply-To: <6C1FB7CE-0D8B-4BDC-9227-A1286FF6B3E7@surfnet.nl> References: <3C6C3507-351B-4C7F-B374-D71A7F845711@surfnet.nl> <445D30EC-D5F8-455E-899C-4B8DB6115687@surfnet.nl> <55F78D27-709A-4408-95C0-E0AB75E17CA4@kirei.se> <6C1FB7CE-0D8B-4BDC-9227-A1286FF6B3E7@surfnet.nl> Message-ID: I'll bridge to Skype then. Anyone interested in joining via Skype can contact me (jschlyter) and I'll connect you. jakob From rick at openfortress.nl Thu Aug 11 08:53:04 2011 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 11 Aug 2011 08:53:04 +0000 Subject: [Opendnssec-develop] Again: Sharing PIN through POSIX message queues In-Reply-To: References: <20110810183107.GH23260@phantom.vanrein.org> Message-ID: <20110811085304.GA565@phantom.vanrein.org> Hey Rickard, > Nice example! Thanks :) > You can get the PID of sending process. But how do you send the > message back to that PID? So that no one else can steal the message > from the queue? Good find :-D but this was a quick prototype to sketch the idea and to show that it works; I don't know if I was considering that back then. The obvious solution would be to use a separate getmsg() on the receiving end, and pass the global ID for that response mailbox over to the PIN daemon. It would then simply send the PIN to the mailbox owned by an approved process. Let me know if you'd like code to go with that; I believe this is a serious contender for a PIN daemon, better secure practice than what SSH and GPG2 do. Cheers, -Rick From owner-dnssec-trac at kirei.se Thu Aug 11 09:12:16 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Aug 2011 09:12:16 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #259: KSM interprets passwords In-Reply-To: <045.bd05356bfcbf398c7bf143f362afb045@kirei.se> References: <045.bd05356bfcbf398c7bf143f362afb045@kirei.se> Message-ID: <060.cffad000cde682a92f5736ebd499d22b@kirei.se> #259: KSM interprets passwords --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: 1.3.0 | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by sion): I've committed a small change in trunk; r5391... It should help unless the character "'" is in the username or password. If that is useful I'll patch it to the 1.3 branch. -- Ticket URL: OpenDNSSEC OpenDNSSEC From Roland.vanRijswijk at surfnet.nl Thu Aug 11 09:12:58 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 11 Aug 2011 11:12:58 +0200 Subject: [Opendnssec-develop] Meeting minutes Enforcer TNG 2011-08-11 online Message-ID: Hi guys, The meeting minutes for today's Enforcer TNG telecon are online: http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-08-11 Please check if any changes are needed and feel free to make them in Trac. Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jakob at kirei.se Thu Aug 11 09:29:27 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 11 Aug 2011 11:29:27 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.2.2 In-Reply-To: References: Message-ID: <277A4582-7434-437E-B13F-D84ED5D751F2@kirei.se> On 10 aug 2011, at 16:06, Rickard Bellgrim wrote: > OpenDNSSEC 1.2.2 is ready for release. tagged and bagged! will you make the announcement? jakob From rickard at opendnssec.org Thu Aug 11 09:41:23 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 11 Aug 2011 11:41:23 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.2.2 In-Reply-To: <277A4582-7434-437E-B13F-D84ED5D751F2@kirei.se> References: <277A4582-7434-437E-B13F-D84ED5D751F2@kirei.se> Message-ID: On Thu, Aug 11, 2011 at 11:29 AM, Jakob Schlyter wrote: > On 10 aug 2011, at 16:06, Rickard Bellgrim wrote: > >> OpenDNSSEC 1.2.2 is ready for release. > > tagged and bagged! will you make the announcement? ACK From rick at openfortress.nl Thu Aug 11 10:10:03 2011 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 11 Aug 2011 10:10:03 +0000 Subject: [Opendnssec-develop] Again: Sharing PIN through POSIX message queues In-Reply-To: References: <20110810183107.GH23260@phantom.vanrein.org> <20110811085304.GA565@phantom.vanrein.org> Message-ID: <20110811101003.GB565@phantom.vanrein.org> Hello Rickard, > Yes that would work if the processes behave. But I think it is > possible for another bad process to attach to the same mailbox and > then steal the message. You can "authenticate" the sender, but not > "authenticate" the recipient. Sorry if this comes in bits and pieces, but it's been two years... The PIN requesting party would create a new queue for the response with msgid = msgget (IPC_PRIVATE, S_IRUSR | S_IWUSR | S_IWGRP /*| S_IWOTH*/); This creates a unique, internal message queue (see below) with access privileges that permit owner+group (+others?) to send and only the owner to read from the queue. Note that this is done by a "good guy" process; a rogue one would want to access the msgqueue through other means. You could send msgid as a data field to the PIN daemon's message queu, to request sending the PIN to that message queue if the sender's PID is acceptable. Background: | Syntax | | #include | #include | | int msgget(key_t key, int msgflg); ... | Parameters | | key | (Input) Key associated with the message queue. A key of IPC_PRIVATE | (0x00000000) guarantees that a unique message queue is created. [...] Ref: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=%2Fapis%2Fipcmsggt.htm Then, from the Linux man page which is clear about privileges, it is quite clear that other processes cannot receive from a properly initialised message queue (see above) if they happened to find the queue-id and tried to msgrcv() the PIN sent to it: | When msgrcv() fails, errno will be set to one among the following values: ... | EACCES | The calling process does not have read permission on the message queue, | and does not have the CAP_IPC_OWNER capability. What this means is that a rogue process could not share this channel, as it would have to replicate the key; but given that the key is IPC_PRIVATE the rogue process would simply be creating its own channel. Of course, it is a good idea to restrict the queue over which the PIN daemon receives messages so that only the PIN daemon can read from it. It just shouldn't be IPC_PRIVATE because it _does_ have the intention to be easy to find for others. It would also be possible to protect the PIN requester against DoS attacks by verifying that the last received message was sent by the PIN daemon, based on the incoming pid_t. > Does this mean that we get the same > level of security as shared memory? Certainly not -- we're now discussing the security of the response channel, which should use the same mech for reasons of simplicity only, but this approach definately raises an extra bar on which PIN requests are acceptable. Cheers, -Rick From owner-dnssec-trac at kirei.se Thu Aug 11 11:30:55 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Aug 2011 11:30:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #259: KSM interprets passwords In-Reply-To: <045.bd05356bfcbf398c7bf143f362afb045@kirei.se> References: <045.bd05356bfcbf398c7bf143f362afb045@kirei.se> Message-ID: <060.e008070706a359ae143b5a5a250c2040@kirei.se> #259: KSM interprets passwords --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: 1.3.0 | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by vanrein): Quotes can be escaped just as you are doing it in your message: -p'hello'"'"'s world' would be the quoted version of hello's world In rising levels of comfort/security: 1. current solution with some passwords impossible (with or without r5391) 2. a solution that accepts all passwords but uses them in the process call 3. a solution that avoids mentioning passwords on any cmdline going from 1 to 2 would be useful, so yeah, please patch it; but to make the solution complete, please also quote the quote? -Rick -- Ticket URL: OpenDNSSEC OpenDNSSEC From yuri at nlnetlabs.nl Thu Aug 11 11:39:37 2011 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Thu, 11 Aug 2011 13:39:37 +0200 Subject: [Opendnssec-develop] TTL for signatures Message-ID: <1313062777.1716.19.camel@thorin> Hi, In Yesterday's call we discussed the kasp.xml must include some parameter for the worst case TTL of the zonedata. I see two options for including this in the XML: .. .... ......**** .... ......**** KASP.Policy.Signatures.TTL con: The RRSIG record does *not* actually get published this TTL (but rather the TTL of the it signs). Thus confusing. Pro: It *is* the TTL the enforcer will use in any case. Thus the effective TTL for signatures, even if published otherwise. KASP.Policy.Zone.TTL pro: More accurate. It is the (max) TTL of data in the zone. con: User might think has RRs will be published with this TTL. I think we should go for the second option. Apart from that, MaxZoneTTL might be a better name than just TTL. //yuri From rick at openfortress.nl Thu Aug 11 11:53:43 2011 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 11 Aug 2011 11:53:43 +0000 Subject: [Opendnssec-develop] TTL for signatures In-Reply-To: <1313062777.1716.19.camel@thorin> References: <1313062777.1716.19.camel@thorin> Message-ID: <20110811115343.GA3430@phantom.vanrein.org> Hey, > I think we should go for the second option. +1 > Apart from that, MaxZoneTTL > might be a better name than just TTL. +1 I am still confused about making the option mandatory though. We're changing a hardcoded default into a configurable option, and all of a sudden all users who upgrade OpenDNSSEC are then "punished" by being forced into studying documentation while new users will have a smooth ride because the configfiles contain the default. Rather than causing people to read docs, I'm pretty sure that they'll just copy the mandatory new attribute from the default configs, so they end up (as do the new users) with a setup that works due to reasonable defaults, even if they don't fully understand it. Since it's been working for them all along with a hardcoded setting, it seems strange to bother them now that we decided to make it more flexible. IMHO, making the attribute mandatory conflicts with the pushbutton ideal, and it doesn't add any direct usefulness as far as I can tell. Still, we discussed it yesterday, so I'm merely sharing my confusion over what we concluded. I'll leave it to others to pickup on this if they agree with me. Cheers, -Rick From owner-dnssec-trac at kirei.se Thu Aug 11 11:57:00 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Aug 2011 11:57:00 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #254: Configure fails on RHEL6 In-Reply-To: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> References: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> Message-ID: <060.e07c962edd835ebe51abaa058ab29763@kirei.se> #254: Configure fails on RHEL6 ------------------------------------+--------------------------------------- Reporter: vanrein | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: configure libldns rhel6 | ------------------------------------+--------------------------------------- Comment (by vanrein): Ah?! I got: bash$ ldns-config --cflags -I/usr/include bash$ ldns-config --libs -L/usr/lib64/python2.6 -L/usr/lib64 -lpython2.6 -L/usr/lib64 -lcrypto -lldns bash$ rpm -qa | grep ldns ldns-1.6.10-1.el6.x86_64 ldns-devel-1.6.10-1.el6.x86_64 Matthijs? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 11 12:09:02 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Aug 2011 12:09:02 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #254: Configure fails on RHEL6 In-Reply-To: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> References: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> Message-ID: <060.19667da41daa82de2e392f7c9141a621@kirei.se> #254: Configure fails on RHEL6 ------------------------------------+--------------------------------------- Reporter: vanrein | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: 1.3.0 | Resolution: Keywords: configure libldns rhel6 | ------------------------------------+--------------------------------------- Comment (by vanrein): Rickard, Matthijs says that ldns has a --with-python configuration option, which is probably on for EPEL/Fedora's version of LDNS 1.6.10 (which is what we use on RHEL6, as you cannot build OpenDNSSEC without EPEL attached, if you are not inclined to build quite a few RPMs). In short, this would be a platform issue, and not an OpenDNSSEC issue. Thanks for helping to clear that up. Thanks, -Rick -- Ticket URL: OpenDNSSEC OpenDNSSEC From nick.vandenheuvel at sidn.nl Thu Aug 11 12:25:56 2011 From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel) Date: Thu, 11 Aug 2011 12:25:56 +0000 Subject: [Opendnssec-develop] TTL for signatures In-Reply-To: <20110811115343.GA3430@phantom.vanrein.org> References: <1313062777.1716.19.camel@thorin> <20110811115343.GA3430@phantom.vanrein.org> Message-ID: <60E0FAC48923D348BF7B1861488E606E074ECD0B@kambx3.SIDN.local> I agree with Rick, the field should not be mandatory but optional. If this option is described clearly in the release notes/documentation on our website more advanced users can benefit of the new functionality. -----Original Message----- From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Rick van Rein Sent: donderdag 11 augustus 2011 13:54 To: Yuri Schaeffer Subject: Re: [Opendnssec-develop] TTL for signatures Hey, > I think we should go for the second option. +1 > Apart from that, MaxZoneTTL > might be a better name than just TTL. +1 I am still confused about making the option mandatory though. We're changing a hardcoded default into a configurable option, and all of a sudden all users who upgrade OpenDNSSEC are then "punished" by being forced into studying documentation while new users will have a smooth ride because the configfiles contain the default. Rather than causing people to read docs, I'm pretty sure that they'll just copy the mandatory new attribute from the default configs, so they end up (as do the new users) with a setup that works due to reasonable defaults, even if they don't fully understand it. Since it's been working for them all along with a hardcoded setting, it seems strange to bother them now that we decided to make it more flexible. IMHO, making the attribute mandatory conflicts with the pushbutton ideal, and it doesn't add any direct usefulness as far as I can tell. Still, we discussed it yesterday, so I'm merely sharing my confusion over what we concluded. I'll leave it to others to pickup on this if they agree with me. Cheers, -Rick _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From matthijs at NLnetLabs.nl Thu Aug 11 12:38:29 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 11 Aug 2011 14:38:29 +0200 Subject: [Opendnssec-develop] Re: [Opendnssec-announce] OpenDNSSEC 1.2.2 In-Reply-To: References: Message-ID: <4E43CD45.20604@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The following bugfixes are not covered by 1.3.0. They should be fixed for 1.3.1: * ods-ksmutil: manual keyroll on zones which have moved policies fixed. * Zonefetcher: Check inbound serial in transferred file, to prevent redundant zone transfers. [done] I think an additional requirement in the release process is needed: When a new version of an older release of OpenDNSSEC is brought out, we should make sure that newer released versions are not affected by the bugs that were fixed. Otherwise, a release in the newer series is required. Best regards, Matthijs On 08/11/2011 11:40 AM, Rickard Bellgrim wrote: > Hi > > Version 1.2.2 of OpenDNSSEC has now been released. > > Bugfixes: > * signconf.rnc now allows NSEC3 Iterations of 0 > * Auditor: Fix delegation checks. > * Bugfix #242: Race condition when receiving multiple NOTIFIES for a zone. > * Enforcer: Change message about KSK retirement to make it less confusing. > * ods-ksmutil: manual keyroll on zones which have moved policies fixed. > * Signer Engine: Handle stdout console output throttling that would > truncate daemon output intermittently. > * Signer Engine: When removing records, also remove NSEC3 records that > belong to the empty-non terminal. > * Signer Engine: Ifdef the zone fetcher header file. > * Zonefetcher: Sometimes invalid ?Address already in use? occurred. > * Zonefetcher: Check inbound serial in transferred file, to prevent > redundant zone transfers. > > Download the tarball from: > http://www.opendnssec.org/files/source/opendnssec-1.2.2.tar.gz > > // OpenDNSSEC team > _______________________________________________ > Opendnssec-announce mailing list > Opendnssec-announce at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-announce > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOQ81FAAoJEA8yVCPsQCW5nK0H/0vJBb//UKtUZLWw2kWZkjtU IsL9olgDpAxDktw7eblFVN4yBHxgjUtTAj1OCt2smlsy/l+K+lmcS5ZbsPdkKEnm oJkzU5KVOk2ypWoXBNbaF5pxmvoukQ7LlP3Jg9mEUUgG0BAEqpN/Ak8j+Gj9jlye ECGyTtoY38Ym/P7w5HTwsupdxDz599tptN9XS+d4iMlLlIqVPdVDzoXzMM+Glzyt tq93KVusFCmaNEhBYgSgIbrHiVbtUNuSsAJF88Vl5HvtZ05+T2jEVbtcT5SejMOv rCGA8MHlOQ4QOogo3yqwolYm8TKZ5bo4JKp4aav5AwC5YhoXJzNTl4zcuae4gog= =gvUe -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Thu Aug 11 12:46:23 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 11 Aug 2011 14:46:23 +0200 Subject: [Opendnssec-develop] TTL for signatures In-Reply-To: <20110811115343.GA3430@phantom.vanrein.org> References: <1313062777.1716.19.camel@thorin> <20110811115343.GA3430@phantom.vanrein.org> Message-ID: <4E43CF1F.6020801@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/11/2011 01:53 PM, Rick van Rein wrote: > Hey, > >> I think we should go for the second option. > > +1 ACK >> Apart from that, MaxZoneTTL >> might be a better name than just TTL. > > +1 ACK > I am still confused about making the option mandatory though. > > We're changing a hardcoded default into a configurable option, > and all of a sudden all users who upgrade OpenDNSSEC are then > "punished" by being forced into studying documentation while > new users will have a smooth ride because the configfiles contain > the default. Rather than causing people to read docs, I'm pretty > sure that they'll just copy the mandatory new attribute from the > default configs, so they end up (as do the new users) with a setup > that works due to reasonable defaults, even if they don't fully > understand it. Since it's been working for them all along with > a hardcoded setting, it seems strange to bother them now that we > decided to make it more flexible. > > IMHO, making the attribute mandatory conflicts with the pushbutton > ideal, and it doesn't add any direct usefulness as far as I can tell. > > Still, we discussed it yesterday, so I'm merely sharing my > confusion over what we concluded. I'll leave it to others to > pickup on this if they agree with me. The risk I tried to point out yesterday is that when you make a change in the policy that changes the behavior of the software, you might end up in unpredicted situations. For example, when we moved Stand-by Keys to deprecated. The old policy was still accepted by the software that deprecated Stand-by Keys but did not behave as it did before. This gave issues. However, when adding a feature it is probably less troublesome to make it optional and default to some defined standard behavior. Best regards, Matthijs > > > Cheers, > -Rick > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOQ88fAAoJEA8yVCPsQCW5uTQH/i6H5oiZ8EzKGaGGcIdO99Vr iWedZdkNRtVZGNIAa2oetKrQiyBXNGQDBpj+xAps3Rwa5vr2FotPOcFzF31DCglX 5OvclykrVh9QJKmlznQOm05rNupp7tkcWkd9CumIZQ9EWe5jbqMHnKPyrN3VreHR bn+BdI78/UHTY/CfTMt2I6ZpwGg2Fctz5P4MjAG8NiNWs8jyTGPCNMGG0ixMB3lt hyrVSC4mW9DR1+CpVYvjWNSRFBkShv0Q/1H+3hTYfe+tbMXUok0abF4AHxtOjPFr doMjifDST3umKWPKndIPx6swqiAdXrQKRLG698xhYLIkP6ZeFJLdmSBrjJA2QSw= =1VRA -----END PGP SIGNATURE----- From jakob at kirei.se Thu Aug 11 13:37:14 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 11 Aug 2011 15:37:14 +0200 Subject: [Opendnssec-develop] TTL for signatures In-Reply-To: <1313062777.1716.19.camel@thorin> References: <1313062777.1716.19.camel@thorin> Message-ID: <84465C68-F888-4B17-AFC5-849F36A7DC45@kirei.se> On 11 aug 2011, at 13:39, Yuri Schaeffer wrote: > I think we should go for the second option. Apart from that, MaxZoneTTL > might be a better name than just TTL. +1 jakob From rickard at opendnssec.org Fri Aug 12 06:43:58 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 12 Aug 2011 08:43:58 +0200 Subject: [Opendnssec-develop] TTL for signatures In-Reply-To: <84465C68-F888-4B17-AFC5-849F36A7DC45@kirei.se> References: <1313062777.1716.19.camel@thorin> <84465C68-F888-4B17-AFC5-849F36A7DC45@kirei.se> Message-ID: On Thu, Aug 11, 2011 at 3:37 PM, Jakob Schlyter wrote: > On 11 aug 2011, at 13:39, Yuri Schaeffer wrote: > >> I think we should go for the second option. Apart from that, MaxZoneTTL >> might be a better name than just TTL. > > +1 +1 From sion at nominet.org.uk Fri Aug 12 08:19:39 2011 From: sion at nominet.org.uk (=?UTF-8?B?U2nDtG4gTGxveWQ=?=) Date: Fri, 12 Aug 2011 09:19:39 +0100 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #259: KSM interprets passwords In-Reply-To: <060.e008070706a359ae143b5a5a250c2040@kirei.se> References: <045.bd05356bfcbf398c7bf143f362afb045@kirei.se> <060.e008070706a359ae143b5a5a250c2040@kirei.se> Message-ID: <4E44E21B.6020604@nominet.org.uk> On 11/08/11 12:30, OpenDNSSEC wrote: > Comment (by vanrein): > > Quotes can be escaped just as you are doing it in your message: > > -p'hello'"'"'s world' > > would be the quoted version of > > hello's world > So I have added (r5396) shell quoting to the username and password. I _believe_ that the quoting should look like: 'hello'\''s world' Can anyone confirm if that is correct on a mac? It seemed to work when I tried it. Once that is confirmed I'll patch the lot into the 1.3 branch. Sion From sion at nominet.org.uk Fri Aug 12 08:35:59 2011 From: sion at nominet.org.uk (=?windows-1252?Q?Si=F4n_Lloyd?=) Date: Fri, 12 Aug 2011 09:35:59 +0100 Subject: [Opendnssec-develop] Re: [Opendnssec-announce] OpenDNSSEC 1.2.2 In-Reply-To: <4E43CD45.20604@nlnetlabs.nl> References: <4E43CD45.20604@nlnetlabs.nl> Message-ID: <4E44E5EF.4070202@nominet.org.uk> On 11/08/11 13:38, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > The following bugfixes are not covered by 1.3.0. They should be fixed > for 1.3.1: > > * ods-ksmutil: manual keyroll on zones which have moved policies fixed. This should already work in 1.3 and trunk. From matthijs at NLnetLabs.nl Fri Aug 12 08:46:11 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 12 Aug 2011 10:46:11 +0200 Subject: [Opendnssec-develop] Re: [Opendnssec-announce] OpenDNSSEC 1.2.2 In-Reply-To: <4E44E5EF.4070202@nominet.org.uk> References: <4E43CD45.20604@nlnetlabs.nl> <4E44E5EF.4070202@nominet.org.uk> Message-ID: <4E44E853.6050500@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, it was not in the release notes though. On 08/12/2011 10:35 AM, Si?n Lloyd wrote: > On 11/08/11 13:38, Matthijs Mekking wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> The following bugfixes are not covered by 1.3.0. They should be fixed >> for 1.3.1: >> >> * ods-ksmutil: manual keyroll on zones which have moved policies fixed. > > This should already work in 1.3 and trunk. > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOROhSAAoJEA8yVCPsQCW5ZSQH/3ZX3v773vQkKlsbI73TpUT+ lMLwCFOB04yEMGo/gnkc6sPopL3ZsGN8VKcxBj6Y0dncAJo8wBW8RiY6DJenuZYi HDV1kzBr+cBcA3M+alrboA+g0/6OMXTEsLnGO60ZD7VMSr7OyCaWDaiJqoohqqH/ 8T8bJZ8MvQLsho/dLv+bVUweNsj1vTC/2mKK/oeJ+P0d1ho3rYcdkvX+76K3MM1C BFuM4pRQmsFCt9/f4jMaSvEszSpvVfcpZaUY2B5oVaNxIpjCf7JXO6MLkt+QVNed gVKxrNlKWjW6asZpIZSEUU+Y28OQW+NqJIgoBUx2AHYFy3oYOc/wPxKxMONHmJc= =QMbJ -----END PGP SIGNATURE----- From sion at nominet.org.uk Fri Aug 12 09:15:28 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Fri, 12 Aug 2011 10:15:28 +0100 Subject: [Opendnssec-develop] Refactoring of libhsm In-Reply-To: References: Message-ID: <4E44EF30.1000301@nominet.org.uk> On 05/08/11 15:40, Rickard Bellgrim wrote: > Hi > > We had one task where we wanted to refactor libhsm. The main issues > where lost connections and listing keys. > Sorry I missed the phone call on Wednesday. I'm not sure how this discussion went. > Lost connections > ------------------------- > Some HSMs will close down a session if it has not been used for some > time. The idea was to redesign libhsm to handle this. Most of the > actions in libhsm has something to do with a session, so it would be a > lot of work to be able to restore the session. I think it would more > suitable for the application to handle this. Like the Enforcer does > it, to reload libhsm or make sure to close down the connections if > they are not going to be used. > This works with the enforcer as it is now because the passphrase is available to it. If we move to a situation where user input is required then I think that keepalives would be desirable. > Private vs. Public keys > --------------------------------- > > There are two options here. > 1. Detect what algorithm the key object belongs to. Will probably > degrade the performance somewhat. > 2. Recommend that user to disable the option if they > plan to run DAS or GOST. > > What do you think? I think option 1 unless the performance hit is really significant... Option 2 sounds like requiring users to know in advance how the system might be used in the future. Sion From sion at nominet.org.uk Fri Aug 12 09:20:17 2011 From: sion at nominet.org.uk (=?windows-1252?Q?Si=F4n_Lloyd?=) Date: Fri, 12 Aug 2011 10:20:17 +0100 Subject: [Opendnssec-develop] Re: [Opendnssec-announce] OpenDNSSEC 1.2.2 In-Reply-To: <4E44E853.6050500@nlnetlabs.nl> References: <4E43CD45.20604@nlnetlabs.nl> <4E44E5EF.4070202@nominet.org.uk> <4E44E853.6050500@nlnetlabs.nl> Message-ID: <4E44F051.7030501@nominet.org.uk> On 12/08/11 09:46, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ok, it was not in the release notes though. > No, that is my fault. The fix sneaked in during another commit, and then I thought that adding the change to the news file might be more confusing as it would imply that it was broken in the previous release... Sorry. Sion From rickard at opendnssec.org Fri Aug 12 10:51:55 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 12 Aug 2011 12:51:55 +0200 Subject: [Opendnssec-develop] Release SoftHSM 1.3.0 Message-ID: Hi SoftHSM 1.3.0 is ready for release. TODO: * Set release date in NEWS. Jakob? // Rickard From Roland.vanRijswijk at surfnet.nl Fri Aug 12 12:47:35 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Fri, 12 Aug 2011 14:47:35 +0200 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #259: KSM interprets passwords In-Reply-To: <4E44E21B.6020604@nominet.org.uk> References: <045.bd05356bfcbf398c7bf143f362afb045@kirei.se> <060.e008070706a359ae143b5a5a250c2040@kirei.se> <4E44E21B.6020604@nominet.org.uk> Message-ID: <7FE292BF-24C2-431B-81EB-E13E94C77DBF@surfnet.nl> Hi Sion, On 12 aug 2011, at 10:19, Si?n Lloyd wrote: > On 11/08/11 12:30, OpenDNSSEC wrote: >> Comment (by vanrein): >> >> Quotes can be escaped just as you are doing it in your message: >> >> -p'hello'"'"'s world' >> >> would be the quoted version of >> >> hello's world >> > > So I have added (r5396) shell quoting to the username and password. > > I _believe_ that the quoting should look like: > > 'hello'\''s world' > > Can anyone confirm if that is correct on a mac? It seemed to work when I tried it. My Mac says: rijswijk at dhcp-193:~$ echo -p'hello'"'"'s world' -phello's world So this seems to work ;-) Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From owner-dnssec-trac at kirei.se Fri Aug 12 13:33:52 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 12 Aug 2011 13:33:52 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #259: KSM interprets passwords In-Reply-To: <045.bd05356bfcbf398c7bf143f362afb045@kirei.se> References: <045.bd05356bfcbf398c7bf143f362afb045@kirei.se> Message-ID: <060.23f07ab9652d29477d87d5fda20de85c@kirei.se> #259: KSM interprets passwords --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: closed Priority: minor | Component: Enforcer Version: 1.3.0 | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by sion): * status: new => closed * resolution: => fixed Comment: Fixed in trunk (r5391 and r5396) and the 1.3 branch (r5400) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Aug 12 13:35:31 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 12 Aug 2011 13:35:31 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #254: Configure fails on RHEL6 In-Reply-To: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> References: <045.8d44cd6f4983171c76ec3e68339efcde@kirei.se> Message-ID: <060.92e450a9e271653c43ff6b33185a8310@kirei.se> #254: Configure fails on RHEL6 ------------------------------------+--------------------------------------- Reporter: vanrein | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: 1.3.0 | Resolution: fixed Keywords: configure libldns rhel6 | ------------------------------------+--------------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard at opendnssec.org Fri Aug 12 13:53:13 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 12 Aug 2011 15:53:13 +0200 Subject: [Opendnssec-develop] Re: OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: > * #254: Configure fails on RHEL6 - Need comment from Rick Fixed and closed > * #257: Error in ods-signerd - A malformed BIND private key file could > not be the cause of the problem Waiting on backup file from user. Is this blocking 1.3.1 release? > * #258: ods-control not robust in ensuring process running A report coming now and then. May need to re-think the process handling. Is this blocking 1.3.1 release? > * #259: KSM interprets passwords Fixed and closed > Should we backport r5364, Alex? (Fix 'ZSK in use too long' message to > handle new signer behaviour) Waiting for commit // Rickard From rickard at opendnssec.org Fri Aug 12 14:03:41 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 12 Aug 2011 16:03:41 +0200 Subject: [Opendnssec-develop] Refactoring of libhsm In-Reply-To: <4E44EF30.1000301@nominet.org.uk> References: <4E44EF30.1000301@nominet.org.uk> Message-ID: >> Lost connections >> ------------------------- >> Some HSMs will close down a session if it has not been used for some >> time. The idea was to redesign libhsm to handle this. Most of the >> actions in libhsm has something to do with a session, so it would be a >> lot of work to be able to restore the session. I think it would more >> suitable for the application to handle this. Like the Enforcer does >> it, to reload libhsm or make sure to close down the connections if >> they are not going to be used. >> > > This works with the enforcer as it is now because the passphrase is > available to it. If we move to a situation where user input is required then > I think that keepalives would be desirable. The conclusion from the meeting was to return the error and let the application handle it. Like the Enforcer does it. Then also create a suggestion on a keepalive functionality. Either running automatically in libhsm or a no-op that the application forks off a thread for. >> Private vs. Public keys >> --------------------------------- >> >> There are two options here. >> 1. Detect what algorithm the key object belongs to. Will probably >> degrade the performance somewhat. >> 2. Recommend that user to disable the option ?if they >> plan to run DAS or GOST. >> >> What do you think? > > I think option 1 unless the performance hit is really significant... Option > 2 sounds like requiring users to know in advance how the system might be > used in the future. I can see if there is a simple solution. // Rickard From jakob at kirei.se Fri Aug 12 14:04:40 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 12 Aug 2011 16:04:40 +0200 Subject: [Opendnssec-develop] Release SoftHSM 1.3.0 In-Reply-To: References: Message-ID: <4DB31F4E-F2E1-43AF-9F07-217733A4C7D7@kirei.se> On 12 aug 2011, at 12:51, Rickard Bellgrim wrote: > Hi > > SoftHSM 1.3.0 is ready for release. > > TODO: > * Set release date in NEWS. > > Jakob? DONE, tar-ball ready for download. j From rickard at opendnssec.org Mon Aug 15 08:04:05 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 15 Aug 2011 10:04:05 +0200 Subject: [Opendnssec-develop] Refactoring of libhsm In-Reply-To: References: <4E44EF30.1000301@nominet.org.uk> Message-ID: >>> Private vs. Public keys >>> --------------------------------- >>> >>> There are two options here. >>> 1. Detect what algorithm the key object belongs to. Will probably >>> degrade the performance somewhat. >>> 2. Recommend that user to disable the option ?if they >>> plan to run DAS or GOST. >>> >>> What do you think? >> >> I think option 1 unless the performance hit is really significant... Option >> 2 sounds like requiring users to know in advance how the system might be >> used in the future. > > I can see if there is a simple solution. The key algorithm is not known in the libhsm key structure. It is looked up by calling hsm_get_key_algorithm(). Should we add a call to it hsm_key_new_privkey_object_handle() and store it in the key structure? The only downside is that it is called for each key pair when listing keys in the HSM, but that is an operation that the user does and not OpenDNSSEC. Thus not affecting the signing performance. The RSA public key was removed to save space and that we did not need to search for public key with a matching CKA_ID. This would however introduce a call where we fetch an attribute. The search for CKA_ID is however more expensive than getting an attribute. // Rickard From jakob at kirei.se Mon Aug 15 08:30:57 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 15 Aug 2011 10:30:57 +0200 Subject: [Opendnssec-develop] Refactoring of libhsm In-Reply-To: References: <4E44EF30.1000301@nominet.org.uk> Message-ID: <24B4EEC8-5E41-4970-9DEF-6B57FBEF6AC0@kirei.se> On 15 aug 2011, at 10:04, Rickard Bellgrim wrote: > The key algorithm is not known in the libhsm key structure. It is > looked up by calling hsm_get_key_algorithm(). Should we add a call to > it hsm_key_new_privkey_object_handle() and store it in the key > structure? The only downside is that it is called for each key pair > when listing keys in the HSM, but that is an operation that the user > does and not OpenDNSSEC. Thus not affecting the signing performance. yes, it makes sense to know what algorithm the key is. but hsm_key_info_t contains this, no? would it make sense to have such a struct in hsm_key_t ? jakob From rickard at opendnssec.org Mon Aug 15 08:45:33 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 15 Aug 2011 10:45:33 +0200 Subject: [Opendnssec-develop] Refactoring of libhsm In-Reply-To: <24B4EEC8-5E41-4970-9DEF-6B57FBEF6AC0@kirei.se> References: <4E44EF30.1000301@nominet.org.uk> <24B4EEC8-5E41-4970-9DEF-6B57FBEF6AC0@kirei.se> Message-ID: > yes, it makes sense to know what algorithm the key is. > > but hsm_key_info_t contains this, no? would it make sense to have such a struct in hsm_key_t ? Yes, it could be merged into hsm_key_t. hsm_get_key_info() would not be needed and then some minor adjustments in hsmutil.c. // Rickard From rickard at opendnssec.org Mon Aug 15 12:52:09 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 15 Aug 2011 14:52:09 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: References: Message-ID: Hi The different PIN sharing techniques (shared memory, domain sockets (ssh-agent et. al), message queues, etc.) all boils down to basic unix permissions. So it is more a choice of how we would like to implement it. The advantage of shared memory is that we do not need any special daemon to handle the PINs. It can be part of libhsm. If there is a PIN in config then us it, if not then try the shared memory. If it is not there, then wait for a signal to check again. "ods-hsmutil login" could be used by the user. This command would tell hsm_open() to also output the PIN prompt, thus not getting blocked as the other applications. // Rickard From AlexD at nominet.org.uk Tue Aug 16 08:44:37 2011 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Tue, 16 Aug 2011 08:44:37 +0000 Subject: [Opendnssec-develop] Re: OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: <03B71305-DB81-4DD2-B8F8-975F045D27F7@nominet.org.uk> >> Should we backport r5364, Alex? (Fix 'ZSK in use too long' message to >> handle new signer behaviour) > > Waiting for commit svn r5411 From rickard at opendnssec.org Tue Aug 16 10:16:16 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 16 Aug 2011 12:16:16 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: References: Message-ID: > The different PIN sharing techniques (shared memory, domain sockets > (ssh-agent et. al), message queues, etc.) all boils down to basic unix > permissions. So it is more a choice of how we would like to implement > it. > > The advantage of shared memory is that we do not need any special > daemon to handle the PINs. It can be part of libhsm. If there is a PIN > in config then us it, if not then try the shared memory. If it is not > there, then wait for a signal to check again. "ods-hsmutil login" > could be used by the user. This command would tell hsm_open() to also > output the PIN prompt, thus not getting blocked as the other > applications. I have code for this. Should I commit? // Rickard From jakob at kirei.se Tue Aug 16 10:39:30 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 16 Aug 2011 12:39:30 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: References: Message-ID: <361F165B-1EB8-4B2A-90D9-071676201D19@kirei.se> Can you show us s diff? Or commit to a private branch? -- Sent from my iPhone, hence this mail might be briefer than normal. 16 aug 2011 kl. 12:16 skrev Rickard Bellgrim : >> The different PIN sharing techniques (shared memory, domain sockets >> (ssh-agent et. al), message queues, etc.) all boils down to basic unix >> permissions. So it is more a choice of how we would like to implement >> it. >> >> The advantage of shared memory is that we do not need any special >> daemon to handle the PINs. It can be part of libhsm. If there is a PIN >> in config then us it, if not then try the shared memory. If it is not >> there, then wait for a signal to check again. "ods-hsmutil login" >> could be used by the user. This command would tell hsm_open() to also >> output the PIN prompt, thus not getting blocked as the other >> applications. > > I have code for this. Should I commit? > > // Rickard > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > From rickard at opendnssec.org Tue Aug 16 11:07:11 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 16 Aug 2011 13:07:11 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: <361F165B-1EB8-4B2A-90D9-071676201D19@kirei.se> References: <361F165B-1EB8-4B2A-90D9-071676201D19@kirei.se> Message-ID: See attached file. On Tue, Aug 16, 2011 at 12:39 PM, Jakob Schlyter wrote: > Can you show us s diff? Or commit to a private branch? > > -- > Sent from my iPhone, hence this mail might be briefer than normal. > > 16 aug 2011 kl. 12:16 skrev Rickard Bellgrim : > >>> The different PIN sharing techniques (shared memory, domain sockets >>> (ssh-agent et. al), message queues, etc.) all boils down to basic unix >>> permissions. So it is more a choice of how we would like to implement >>> it. >>> >>> The advantage of shared memory is that we do not need any special >>> daemon to handle the PINs. It can be part of libhsm. If there is a PIN >>> in config then us it, if not then try the shared memory. If it is not >>> there, then wait for a signal to check again. "ods-hsmutil login" >>> could be used by the user. This command would tell hsm_open() to also >>> output the PIN prompt, thus not getting blocked as the other >>> applications. >> >> I have code for this. Should I commit? >> >> // Rickard >> _______________________________________________ >> Opendnssec-develop mailing list >> Opendnssec-develop at lists.opendnssec.org >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: pin.patch Type: application/octet-stream Size: 23586 bytes Desc: not available URL: From owner-dnssec-trac at kirei.se Tue Aug 16 12:55:18 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 16 Aug 2011 12:55:18 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #260: Enforcer cannot handle empty zone lists Message-ID: <045.d0440a29fbc21ec60f8dca23d67c4773@kirei.se> #260: Enforcer cannot handle empty zone lists --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: new Priority: trivial | Component: Enforcer Version: 1.3.0 | Keywords: --------------------+------------------------------------------------------- Hello, After removing all zones from the Enforcer, it still reacts strangely. This is minor, and AFAIK it is a cosmetic issue, but nonetheless worth documenting. {{{ bashful# ods-ksmutil zone delete --all *WARNING* This will remove all zones from OpenDNSSEC; are you sure? [y/N] y MySQL database schema set to: KASP MySQL database user set to: ods MySQL database password set zonelist filename set to /var/opendnssec/surfdomeinen/zonelist.xml. bashful# ods-ksmutil zone list zonelist filename set to /var/opendnssec/surfdomeinen/zonelist.xml. MySQL database schema set to: KASP MySQL database user set to: ods MySQL database password set ERROR: error executing SQL - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard at opendnssec.org Tue Aug 16 13:08:40 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 16 Aug 2011 15:08:40 +0200 Subject: [Opendnssec-develop] Refactoring of libhsm In-Reply-To: <4E44EF30.1000301@nominet.org.uk> References: <4E44EF30.1000301@nominet.org.uk> Message-ID: >> Lost connections >> ------------------------- >> Some HSMs will close down a session if it has not been used for some >> time. The idea was to redesign libhsm to handle this. Most of the >> actions in libhsm has something to do with a session, so it would be a >> lot of work to be able to restore the session. I think it would more >> suitable for the application to handle this. Like the Enforcer does >> it, to reload libhsm or make sure to close down the connections if >> they are not going to be used. >> > > This works with the enforcer as it is now because the passphrase is > available to it. If we move to a situation where user input is required then > I think that keepalives would be desirable. I remember that we did a solution like that in the Enforcer, but I could not find that in the code when looking at it. hsm_open: http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/enforcer/enforcerd/enforcer.c#L121 hsm_close when closing the daemon: http://trac.opendnssec.org/browser/trunk/OpenDNSSEC/enforcer/enforcerd/enforcer.c#L298 I have also contacted the SafeNet support regarding the best way of doing a heartbeat mechanism. They do however state that there is no limitation on how long a session can be open. And that it is probably a problem with a firewall closing down the connection. I have asked SIDN for more feedback on this one. // Rickard From owner-dnssec-trac at kirei.se Tue Aug 16 14:42:46 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 16 Aug 2011 14:42:46 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #260: Enforcer cannot handle empty zone lists In-Reply-To: <045.d0440a29fbc21ec60f8dca23d67c4773@kirei.se> References: <045.d0440a29fbc21ec60f8dca23d67c4773@kirei.se> Message-ID: <060.b47f6bcda941a8304c22e2b4dc3a7df6@kirei.se> #260: Enforcer cannot handle empty zone lists --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: accepted Priority: trivial | Component: Enforcer Version: 1.3.0 | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by sion): * status: new => accepted Comment: Fixed in trunk (r5420) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 16 14:58:12 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 16 Aug 2011 14:58:12 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #260: Enforcer cannot handle empty zone lists In-Reply-To: <045.d0440a29fbc21ec60f8dca23d67c4773@kirei.se> References: <045.d0440a29fbc21ec60f8dca23d67c4773@kirei.se> Message-ID: <060.5099eb6308c1606d7a443c6d83d2f8cb@kirei.se> #260: Enforcer cannot handle empty zone lists --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: closed Priority: trivial | Component: Enforcer Version: 1.3.0 | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by sion): * status: accepted => closed * resolution: => fixed Comment: fixed in 1.3 branch (r5421) -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard at opendnssec.org Tue Aug 16 15:07:39 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 16 Aug 2011 17:07:39 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: References: <361F165B-1EB8-4B2A-90D9-071676201D19@kirei.se> Message-ID: > See attached file. Thank you Rick for the review. I have attached a new version. We now check the permissions and egid to avoid an attack where someone have created a shared memory with too open permissions. // Rickard -------------- next part -------------- A non-text attachment was scrubbed... Name: pin.patch Type: application/octet-stream Size: 24086 bytes Desc: not available URL: From jakob at kirei.se Tue Aug 16 19:32:05 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 16 Aug 2011 21:32:05 +0200 Subject: [Opendnssec-develop] PIN daemon In-Reply-To: References: <361F165B-1EB8-4B2A-90D9-071676201D19@kirei.se> Message-ID: Would it be possible to implement this as a single PIN callback function using the current infrastructure? I.e., move everything you wrote into a single function? jakob From rickard at opendnssec.org Wed Aug 17 06:54:17 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 17 Aug 2011 08:54:17 +0200 Subject: [Opendnssec-develop] PIN daemon In-Reply-To: References: <361F165B-1EB8-4B2A-90D9-071676201D19@kirei.se> Message-ID: On Tue, Aug 16, 2011 at 9:32 PM, Jakob Schlyter wrote: > Would it be possible to implement this as a single PIN callback function using the current infrastructure? I.e., move everything you wrote into a single function? The PIN module is a layer between libhsm and the user provided PIN callback. You could move the PIN module into two callback functions. One callback function which only waits for the PIN in the shared memory. Another which can prompt the user for the PIN. The only issue here is how the second callback would know whether to get the PIN from the cache or to prompt the user again. Perhaps extending the callback API to be able to indicate that it is a retry? The current PIN module only save the PIN if we could login with it. The PIN callback does not know if the login was successful or not. The bad PIN would then propagate to the daemons which would get a failed login and quit. What would be the benefit of not having the caching functionality within libhsm? // Rickard From rickard at opendnssec.org Wed Aug 17 08:59:22 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 17 Aug 2011 10:59:22 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: References: <361F165B-1EB8-4B2A-90D9-071676201D19@kirei.se> Message-ID: > Thank you Rick for the review. I have attached a new version. Some more comments from Rick got me thinking on how invalid PINs are handled. Changes: * Do not save the PIN from the configuration in the shared memory. * Try to use the configured PIN before looking in the shared memory. * Fail if the configured PIN is incorrect. Do not try the PIN callback. A PIN will only be saved in the shared memory if it was correct and was entered using the PIN callback. The scenario with an unvalid PIN in memory happens when the user has changed the PIN for the HSM. So if there is no PIN in configuration and the PIN in the shared memory is invalid, then the daemons will fail to start. This can be fixed by the user by calling "ods-hsmutil login". // Rickard -------------- next part -------------- A non-text attachment was scrubbed... Name: pin.patch Type: application/octet-stream Size: 23193 bytes Desc: not available URL: From rickard at opendnssec.org Wed Aug 17 09:46:02 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 17 Aug 2011 11:46:02 +0200 Subject: [Opendnssec-develop] Re: PIN daemon In-Reply-To: References: <361F165B-1EB8-4B2A-90D9-071676201D19@kirei.se> Message-ID: >> Thank you Rick for the review. I have attached a new version. And now there is a branch for the code: branches/OpenDNSSEC-pin/ // Rickard From rickard at opendnssec.org Wed Aug 17 11:22:14 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 17 Aug 2011 13:22:14 +0200 Subject: [Opendnssec-develop] Re: OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: We only have these left: >> * #257: Error in ods-signerd - A malformed BIND private key file could >> not be the cause of the problem > > Waiting on backup file from user. Is this blocking 1.3.1 release? > >> * #258: ods-control not robust in ensuring process running > > A report coming now and then. May need to re-think the process > handling. Is this blocking 1.3.1 release? I think we can proceed with the 1.3.1 without fixing #257 and #258. There are some important updates that we need to get out. // Rickard From matthijs at NLnetLabs.nl Wed Aug 17 12:19:16 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 17 Aug 2011 14:19:16 +0200 Subject: [Opendnssec-develop] Re: OpenDNSSEC 1.3.1 In-Reply-To: References: Message-ID: <4E4BB1C4.3080800@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Did a code review... - - Shouldn't we update the version numbers for dnsruby and ldns in contrib/opendnssec.spec.in? - - Removed news item, because it was only in branch (not in 1.3.0): * Signer Engine: Entered a deadlock if it was stopped while signing. I am ok with doing a release. Matthijs On 08/17/2011 01:22 PM, Rickard Bellgrim wrote: > We only have these left: > >>> * #257: Error in ods-signerd - A malformed BIND private key file could >>> not be the cause of the problem >> >> Waiting on backup file from user. Is this blocking 1.3.1 release? >> >>> * #258: ods-control not robust in ensuring process running >> >> A report coming now and then. May need to re-think the process >> handling. Is this blocking 1.3.1 release? > > I think we can proceed with the 1.3.1 without fixing #257 and #258. > There are some important updates that we need to get out. > > // Rickard > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOS7HEAAoJEA8yVCPsQCW5vHQIANkKGdmMK33mzwbVrIqdcRC8 P2sgb7ORlaijY6v03dNVVAaCtDjeq1wI9MQqoyhFNtzsH/a8uC1YHDZLITRceYut j8ekns8pREA57IYuOaQLR7BIXeg1QcfW14Xaq/hLEanwNhtSpcTJ78MJjLJZrsU1 RWUXiMpF3Nhq/sW4AkKvP/SPRP96w0scgE1gHOjaI0V/vaYEliZmHN2tA2Xo0IS4 HLV3DZeoAx+lrDtTQV4eusTwboc+s/Rf4/p1pdXRTc5RsnRybZQ5yp7cV4jwWmKL S1Mk2CKAK6e4mcIMGhs/JQ37q9M3Q1nT9CiWdrceUvZInd41c45Uvq9+V3NgybA= =cssX -----END PGP SIGNATURE----- From rickard at opendnssec.org Wed Aug 17 12:40:14 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 17 Aug 2011 14:40:14 +0200 Subject: [Opendnssec-develop] Re: OpenDNSSEC 1.3.1 In-Reply-To: <4E4BB1C4.3080800@nlnetlabs.nl> References: <4E4BB1C4.3080800@nlnetlabs.nl> Message-ID: > Shouldn't we update the version numbers for dnsruby and ldns in > contrib/opendnssec.spec.in? Fixed From AlexD at nominet.org.uk Wed Aug 17 12:58:55 2011 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Wed, 17 Aug 2011 12:58:55 +0000 Subject: [Opendnssec-develop] Re: OpenDNSSEC 1.3.1 In-Reply-To: <4E4BB1C4.3080800@nlnetlabs.nl> References: <4E4BB1C4.3080800@nlnetlabs.nl> Message-ID: <65751268-C937-4771-8365-AB9DC8DEDD46@nominet.org.uk> > - - Shouldn't we update the version numbers for dnsruby and ldns in > contrib/opendnssec.spec.in? I don't think there are any changes in dnsruby which impact on OpenDNSSEC. Probably no point hassling users to do an upgrade if nothing in it affects their usage... Alex. From matthijs at NLnetLabs.nl Wed Aug 17 13:34:27 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 17 Aug 2011 15:34:27 +0200 Subject: [Opendnssec-develop] Re: OpenDNSSEC 1.3.1 In-Reply-To: <65751268-C937-4771-8365-AB9DC8DEDD46@nominet.org.uk> References: <4E4BB1C4.3080800@nlnetlabs.nl> <65751268-C937-4771-8365-AB9DC8DEDD46@nominet.org.uk> Message-ID: <4E4BC363.4030609@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 True, but the spec still had 1.4 dependency, while configure expected at least 1.52 Matthijs On 08/17/2011 02:58 PM, Alex Dalitz wrote: >> - - Shouldn't we update the version numbers for dnsruby and ldns in >> contrib/opendnssec.spec.in? > > I don't think there are any changes in dnsruby which impact on OpenDNSSEC. Probably no point hassling users to do an upgrade if nothing in it affects their usage... > > > Alex. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOS8NjAAoJEA8yVCPsQCW5/18H/jUqloi6Vxrgu+H7u4zPJY/A 8e1EWk54G4/VEBKegGuDfY6YxMlJhPQxdSE7K2G+sXy3DFp5VFhbLlljsOfp9zDG ag/HCc2B088rKnuWdjw6LQd3yP+niOAq/Ccl9XtlFaBgyYEuxTRtUAgr0ouOrN8l 7xmjwkTXZuvm1w1uaH6DqiHg9MP3ZtvHrylsYZxhzdR1fhLoz2+0ylc9Vcn6logy nsBKnzvDok2rsdS+C2ZGxhSvjfqjSRaPsrx60YiFf169n1EWfr3NZi7+A9e4qC9a SPnqMOnMln/JQnJMSKDsAGOzPvaj8KWHv/lWSGHQZc+sxMXCmcCBo6Pc+YgYzNQ= =KJLc -----END PGP SIGNATURE----- From rickard at opendnssec.org Mon Aug 22 11:49:19 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 22 Aug 2011 13:49:19 +0200 Subject: [Opendnssec-develop] Meeting 20110824 Message-ID: Hi We have a telephone meeting on Wednesday. See agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-08-24 // Rickard From Roland.vanRijswijk at surfnet.nl Mon Aug 22 12:18:12 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Mon, 22 Aug 2011 14:18:12 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting 20110823 Message-ID: <52C2F80A-49EF-48DE-993C-7F50AE63A761@surfnet.nl> Hi guys, In follow-up to Rickard's e-mail: we also have an Enforcer NG meeting scheduled for tomorrow, August 23rd at 15:00h CEST. As before, please use the following dial-in instructions: Dial-in to +31-30-2040323 Conference PIN: 030003 I've put a draft agenda online here: http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-08-23 Please have a look at the action points before the meeting, thanks in advance! Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From owner-dnssec-trac at kirei.se Tue Aug 23 11:30:30 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 23 Aug 2011 11:30:30 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #240: Remove $Id tags from configuration files In-Reply-To: <065.d999458c6817b10e81d4259aa2c1fbec@kirei.se> References: <065.d999458c6817b10e81d4259aa2c1fbec@kirei.se> Message-ID: <080.3b9fda850dd1c078e65f17d842ffc019@kirei.se> #240: Remove $Id tags from configuration files ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: enhancement | Status: closed Priority: trivial | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: assigned => closed * resolution: => fixed Comment: Fixed in the latest release (1.2.2) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 23 12:49:20 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 23 Aug 2011 12:49:20 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #241: make dist in trunk fails In-Reply-To: <065.3ccbc0219f38890e28afbd0cb0ebf517@kirei.se> References: <065.3ccbc0219f38890e28afbd0cb0ebf517@kirei.se> Message-ID: <080.75b116427d83e2a09a00fbc1475a2774@kirei.se> #241: make dist in trunk fails ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Resolution: Keywords: | ------------------------------------------+--------------------------------- Comment (by rb): r5460 in trunk should make it better for you. -- Ticket URL: OpenDNSSEC OpenDNSSEC From roland.vanrijswijk at surfnet.nl Tue Aug 23 14:52:46 2011 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 23 Aug 2011 16:52:46 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting minutes 20110823 Message-ID: Hi guys, The meeting minutes for today's Enforcer NG telecon have been posted on Trac. Please review them and make any changes where you feel they're needed. http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-08-23 The next Enforcer NG call is on September 6th at 14:00h CEST. Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From rickard at opendnssec.org Wed Aug 24 09:52:38 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 24 Aug 2011 11:52:38 +0200 Subject: [Opendnssec-develop] Licence for Enforcer NG Message-ID: Hi What should we put in the licence headers for the Enforcer NG? Would this be ok? * Copyright (c) 2011 NLnet Labs * Copyright (c) 2011 SURFnet bv * Copyright (c) 2011 .SE (The Internet Infrastructure Foundation) * All rights reserved. Or should we try to split it depending on if the file was written by Ren? or Yuri? // Rickard From jakob at kirei.se Wed Aug 24 09:54:25 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 24 Aug 2011 11:54:25 +0200 Subject: [Opendnssec-develop] Licence for Enforcer NG In-Reply-To: References: Message-ID: On 24 aug 2011, at 11:52, Rickard Bellgrim wrote: > What should we put in the licence headers for the Enforcer NG? > > Would this be ok? > > * Copyright (c) 2011 NLnet Labs > * Copyright (c) 2011 SURFnet bv > * Copyright (c) 2011 .SE (The Internet Infrastructure Foundation) > * All rights reserved. Sure. > Or should we try to split it depending on if the file was written by > Ren? or Yuri? That works as well. Or we might consider setting copyright to "OpenDNSSEC AB (svb)" only. jakob -- Jakob Schlyter Kirei AB - http://www.kirei.se/ From rick at openfortress.nl Wed Aug 24 10:08:04 2011 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 24 Aug 2011 10:08:04 +0000 Subject: [Opendnssec-develop] Licence for Enforcer NG In-Reply-To: References: Message-ID: <20110824100804.GA14397@phantom.vanrein.org> Hi, Some options may be confusing: > > * Copyright (c) 2011 NLnet Labs > > * Copyright (c) 2011 SURFnet bv > > * Copyright (c) 2011 .SE (The Internet Infrastructure Foundation) > > * All rights reserved. This is rather confusing -- if I want to ask a question to the copyright holders, who should I contact? What N-out-of-M decision scheme would apply? > > Or should we try to split it depending on if the file was written by > > Ren? or Yuri? Also a bit confusing perhaps. > That works as well. Or we might consider setting copyright to "OpenDNSSEC AB (svb)" only. This is very, very clear. -Rick From rickard at opendnssec.org Wed Aug 24 10:35:55 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 24 Aug 2011 12:35:55 +0200 Subject: [Opendnssec-develop] Licence for Enforcer NG In-Reply-To: References: Message-ID: > That works as well. Or we might consider setting copyright to "OpenDNSSEC AB (svb)" only. This would be ok for .SE. // Rickard From sion at nominet.org.uk Wed Aug 24 14:21:25 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Wed, 24 Aug 2011 15:21:25 +0100 Subject: [Opendnssec-develop] Meeting 20110824 In-Reply-To: References: Message-ID: <4E5508E5.3070502@nominet.org.uk> On 22/08/11 12:49, Rickard Bellgrim wrote: > Hi > > We have a telephone meeting on Wednesday. > > See agenda: > http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-08-24 > Sorry for the delay. The minutes are up: http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-08-24 Hopefully I managed to capture everything; I got distracted by our SAs asking for help troubleshooting some machines, so please check. Sion From sion at nominet.org.uk Thu Aug 25 09:55:26 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Thu, 25 Aug 2011 10:55:26 +0100 Subject: [Opendnssec-develop] HSM reopen Message-ID: <4E561C0E.2010508@nominet.org.uk> From the meeting yesterday I was going to find the patch for HSM connection fun. This is code that I added in December last year, the patch is for the 1.1 branch. For my tests Rickard suggested adding the following: for (int i = 0; i < ctx->session_count; i++) { ctx->session[i]->session = 0; } which invalidates any HSM connections... It worked, but as I am not sure that this looks the same as a timed out connection I did not commit the code. It validates a connection by counting the keys, which seems like a neutral operation. As the enforcer doesn't run so often this should be okay; I'm not sure that the overhead of this is acceptable for the signer though. Sion sion at sion:~/work/opendnssec/OpenDNSSEC-1.1$ svn diff Index: enforcer/enforcerd/enforcer.c =================================================================== --- enforcer/enforcerd/enforcer.c (revision 4267) +++ enforcer/enforcerd/enforcer.c (working copy) @@ -286,6 +286,10 @@ log_msg(config, LOG_INFO, "Received SIGINT, exiting..."); break; } + + /* Make sure that we can still talk to the HSM; this call exits if + we can not */ + check_hsm_connection(&ctx, config); } /* @@ -1771,3 +1775,71 @@ return status; } + +void check_hsm_connection(hsm_ctx_t **ctx, DAEMONCONFIG *config) +{ + int result = 0; + char *hsm_error_message = NULL; + int i; + + for (i = 0; i < (*ctx)->session_count; i++) { + result = hsm_count_keys_session(*ctx, (*ctx)->session[i]); + if (result == 0) { + /* Either that HSM is empty or we could not talk to it, + assume that we need to reconnect */ + break; + } + } + + /* If we got zero then it probably means that we could not talk to an HSM */ + if (result == 0) { + + if (*ctx) { + hsm_destroy_context(*ctx); + } + + result = hsm_close(); + + if (config->configfile != NULL) { + result = hsm_open(config->configfile, hsm_prompt_pin, NULL); + } else { + result = hsm_open(CONFIG_FILE, hsm_prompt_pin, NULL); + } + if (result) { + hsm_error_message = hsm_get_error(*ctx); + if (hsm_error_message) { + log_msg(config, LOG_ERR, hsm_error_message); + free(hsm_error_message); + } else { + /* decode the error code ourselves + TODO find if there is a better way to do this (and can all of these be returned? are there others?) */ + switch (result) { + case HSM_ERROR: + log_msg(config, LOG_ERR, "hsm_open() result: HSM error"); + break; + case HSM_PIN_INCORRECT: + log_msg(config, LOG_ERR, "hsm_open() result: incorrect PIN"); + break; + case HSM_CONFIG_FILE_ERROR: + log_msg(config, LOG_ERR, "hsm_open() result: config file error"); + break; + case HSM_REPOSITORY_NOT_FOUND: + log_msg(config, LOG_ERR, "hsm_open() result: repository not found"); + break; + case HSM_NO_REPOSITORIES: + log_msg(config, LOG_ERR, "hsm_open() result: no repositories"); + break; + default: + log_msg(config, LOG_ERR, "hsm_open() result: %d", result); + } + } + unlink(config->pidfile); + exit(1); + } + log_msg(config, LOG_INFO, "HSM reopened successfully."); + *ctx = hsm_create_context(); + } else { + log_msg(config, LOG_INFO, "HSM connection open."); + } + +} Index: enforcer/enforcerd/enforcer.h =================================================================== --- enforcer/enforcerd/enforcer.h (revision 4267) +++ enforcer/enforcerd/enforcer.h (working copy) @@ -51,5 +51,6 @@ int read_zonelist_filename(const char* filename, char** zone_list_filename); int do_purge(int interval, int policy_id); int NewDSSet(int zone_id, const char* zone_name, const char* DSSubmitCmd); +void check_hsm_connection(hsm_ctx_t **ctx, DAEMONCONFIG *config); #endif /* ENFORCER_H */ From jakob at kirei.se Fri Aug 26 11:06:35 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 26 Aug 2011 13:06:35 +0200 Subject: [Opendnssec-develop] moving old rc dist files? Message-ID: <9A9B139E-B9C8-44AE-AD74-7411981CBFAF@kirei.se> Greetings, Does anyone (of you) have a problem with me moving the old rc dist files from http://www.opendnssec.org/files/source/ to http://www.opendnssec.org/files/source/archive/ or the like? jakob From rickard at opendnssec.org Fri Aug 26 12:44:04 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 26 Aug 2011 14:44:04 +0200 Subject: [Opendnssec-develop] moving old rc dist files? In-Reply-To: <9A9B139E-B9C8-44AE-AD74-7411981CBFAF@kirei.se> References: <9A9B139E-B9C8-44AE-AD74-7411981CBFAF@kirei.se> Message-ID: No problem, just need to remember to change the links on the download page. // Rickard On Fri, Aug 26, 2011 at 1:06 PM, Jakob Schlyter wrote: > Greetings, > > Does anyone (of you) have a problem with me moving the old rc dist files from http://www.opendnssec.org/files/source/ to http://www.opendnssec.org/files/source/archive/ or the like? > > ? ? ? ?jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > From jakob at kirei.se Fri Aug 26 13:38:02 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 26 Aug 2011 15:38:02 +0200 Subject: [Opendnssec-develop] moving old rc dist files? In-Reply-To: References: <9A9B139E-B9C8-44AE-AD74-7411981CBFAF@kirei.se> Message-ID: <473CF1FA-B490-4B5C-94D7-592F8985EE4A@kirei.se> On 26 aug 2011, at 14:44, Rickard Bellgrim wrote: > No problem, just need to remember to change the links on the download page. Done, now at http://www.opendnssec.org/files/source/testing/. jakob From rickard at opendnssec.org Fri Aug 26 13:44:13 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 26 Aug 2011 15:44:13 +0200 Subject: [Opendnssec-develop] HSM reopen In-Reply-To: <4E561C0E.2010508@nominet.org.uk> References: <4E561C0E.2010508@nominet.org.uk> Message-ID: I think we could implement a more simpler NO-OP in libhsm so that we do not need to count keys. Just to see that the sessions still work. // Rickard On Thu, Aug 25, 2011 at 11:55 AM, Si?n Lloyd wrote: > From the meeting yesterday I was going to find the patch for HSM connection > fun. > > This is code that I added in December last year, the patch is for the 1.1 > branch. > > For my tests Rickard suggested adding the following: > > for (int i = 0; i < ctx->session_count; i++) > { > ? ?ctx->session[i]->session = 0; > } > > which invalidates any HSM connections... It worked, but as I am not sure > that this looks the same as a timed out connection I did not commit the > code. > > It validates a connection by counting the keys, which seems like a neutral > operation. As the enforcer doesn't run so often this should be okay; I'm not > sure that the overhead of this is acceptable for the signer though. > > Sion > > > > sion at sion:~/work/opendnssec/OpenDNSSEC-1.1$ svn diff > Index: enforcer/enforcerd/enforcer.c > =================================================================== > --- enforcer/enforcerd/enforcer.c ? ? ? (revision 4267) > +++ enforcer/enforcerd/enforcer.c ? ? ? (working copy) > @@ -286,6 +286,10 @@ > ? ? ? ? ? ? log_msg(config, LOG_INFO, "Received SIGINT, exiting..."); > ? ? ? ? ? ? break; > ? ? ? ? } > + > + ? ? ? ?/* Make sure that we can still talk to the HSM; this call exits if > + ? ? ? ? ? we can not */ > + ? ? ? ?check_hsm_connection(&ctx, config); > ? ? } > > ? ? /* > @@ -1771,3 +1775,71 @@ > > ? ? return status; > ?} > + > +void check_hsm_connection(hsm_ctx_t **ctx, DAEMONCONFIG *config) > +{ > + ? ?int result = 0; > + ? ?char *hsm_error_message = NULL; > + ? ?int i; > + > + ? ?for (i = 0; i < (*ctx)->session_count; i++) { > + ? ? ? ?result = hsm_count_keys_session(*ctx, (*ctx)->session[i]); > + ? ? ? ?if (result == 0) { > + ? ? ? ? ? ?/* Either that HSM is empty or we could not talk to it, > + ? ? ? ? ? ? ? assume that we need to reconnect */ > + ? ? ? ? ? ?break; > + ? ? ? ?} > + ? ?} > + > + ? ?/* If we got zero then it probably means that we could not talk to an > HSM > */ > + ? ?if (result == 0) { > + > + ? ? ? ?if (*ctx) { > + ? ? ? ? ? ?hsm_destroy_context(*ctx); > + ? ? ? ?} > + > + ? ? ? ?result = hsm_close(); > + > + ? ? ? ?if (config->configfile != NULL) { > + ? ? ? ? ? ?result = hsm_open(config->configfile, hsm_prompt_pin, NULL); > + ? ? ? ?} else { > + ? ? ? ? ? ?result = hsm_open(CONFIG_FILE, hsm_prompt_pin, NULL); > + ? ? ? ?} > + ? ? ? ?if (result) { > + ? ? ? ? ? ?hsm_error_message = hsm_get_error(*ctx); > + ? ? ? ? ? ?if (hsm_error_message) { > + ? ? ? ? ? ? ? ?log_msg(config, LOG_ERR, hsm_error_message); > + ? ? ? ? ? ? ? ?free(hsm_error_message); > + ? ? ? ? ? ?} else { > + ? ? ? ? ? ? ? ?/* decode the error code ourselves > + ? ? ? ? ? ? ? ? ? TODO find if there is a better way to do this (and can > all > of these be returned? are there others?) */ > + ? ? ? ? ? ? ? ?switch (result) { > + ? ? ? ? ? ? ? ? ? ?case HSM_ERROR: > + ? ? ? ? ? ? ? ? ? ? ? ?log_msg(config, LOG_ERR, "hsm_open() result: HSM > error"); > + ? ? ? ? ? ? ? ? ? ? ? ?break; > + ? ? ? ? ? ? ? ? ? ?case HSM_PIN_INCORRECT: > + ? ? ? ? ? ? ? ? ? ? ? ?log_msg(config, LOG_ERR, "hsm_open() result: > incorrect > PIN"); > + ? ? ? ? ? ? ? ? ? ? ? ?break; > + ? ? ? ? ? ? ? ? ? ?case HSM_CONFIG_FILE_ERROR: > + ? ? ? ? ? ? ? ? ? ? ? ?log_msg(config, LOG_ERR, "hsm_open() result: config > file > error"); > + ? ? ? ? ? ? ? ? ? ? ? ?break; > + ? ? ? ? ? ? ? ? ? ?case HSM_REPOSITORY_NOT_FOUND: > + ? ? ? ? ? ? ? ? ? ? ? ?log_msg(config, LOG_ERR, "hsm_open() result: > repository not found"); > + ? ? ? ? ? ? ? ? ? ? ? ?break; > + ? ? ? ? ? ? ? ? ? ?case HSM_NO_REPOSITORIES: > + ? ? ? ? ? ? ? ? ? ? ? ?log_msg(config, LOG_ERR, "hsm_open() result: no > repositories"); > + ? ? ? ? ? ? ? ? ? ? ? ?break; > + ? ? ? ? ? ? ? ? ? ?default: > + ? ? ? ? ? ? ? ? ? ? ? ?log_msg(config, LOG_ERR, "hsm_open() result: %d", > result); > + ? ? ? ? ? ? ? ?} > + ? ? ? ? ? ?} > + ? ? ? ? ? ?unlink(config->pidfile); > + ? ? ? ? ? ?exit(1); > + ? ? ? ?} > + ? ? ? ?log_msg(config, LOG_INFO, "HSM reopened successfully."); > + ? ? ? ?*ctx = hsm_create_context(); > + ? ?} else { > + ? ? ? ?log_msg(config, LOG_INFO, "HSM connection open."); > + ? ?} > + > +} > Index: enforcer/enforcerd/enforcer.h > =================================================================== > --- enforcer/enforcerd/enforcer.h ? ? ? (revision 4267) > +++ enforcer/enforcerd/enforcer.h ? ? ? (working copy) > @@ -51,5 +51,6 @@ > ?int read_zonelist_filename(const char* filename, char** > zone_list_filename); > ?int do_purge(int interval, int policy_id); > ?int NewDSSet(int zone_id, const char* zone_name, const char* DSSubmitCmd); > +void check_hsm_connection(hsm_ctx_t **ctx, DAEMONCONFIG *config); > > ?#endif /* ENFORCER_H */ > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > From sion at nominet.org.uk Fri Aug 26 14:18:54 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Fri, 26 Aug 2011 15:18:54 +0100 Subject: [Opendnssec-develop] HSM reopen In-Reply-To: References: <4E561C0E.2010508@nominet.org.uk> Message-ID: <4E57AB4E.5060809@nominet.org.uk> On 26/08/11 14:44, Rickard Bellgrim wrote: > I think we could implement a more simpler NO-OP in libhsm so that we > do not need to count keys. Just to see that the sessions still work. > That would be good. Shall I add this code to trunk now, or wait until libhsm has this call? Sion From rickard at opendnssec.org Tue Aug 30 07:58:41 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 30 Aug 2011 09:58:41 +0200 Subject: [Opendnssec-develop] Enforcer NG testing Message-ID: Hi I have been sending Ren? and Yuri my test results. This is a summery of the findings. Things that needs to be automated: - Key generation - Enforcing - Signconf - Setting the ds-submit flag - NSEC3-resalting ds-submit - Only show the KSK and CSK, not ZSK - Remove the command arguments. The user should only be able to list the flags. - Perhaps only show keys that have the ds-submit set and not having the ds-seen set. Thus minimizing the number of keys shown. hsm key gen: - Should be able to set a time period of which we generate keys for Signer configuration: - I previously said that the KSK was marked as active, but the key list said not. Ignore this, I think it is the correct behaviour. The KSK tag is set when the RRSIGDNSKEY is rumoured or omnipresent, right? key list: - A KSK with DS, DNSKEY, and RRSIGDNSKEY marked as omnipresent does not get marked as active Error messages when starting fresh: - will give error messages when start on a fresh system. Fresh == no pb-files. key export: - Export keys as DNSKEY and DS. - Should send the keys of which there should be a DS in the parent zone. - ods-ksmutil key export --zone --ds - ods-ksmutil key export --zone - The tag is implemented but never run by the Enforcer. - src/keystate/keystate_ds_submit_task.cpp:280:keystate_ds_submit_task_perform(task_type *task) // Rickard From sion at nominet.org.uk Tue Aug 30 11:41:38 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Tue, 30 Aug 2011 12:41:38 +0100 Subject: [Opendnssec-develop] Re: [Opendnssec-user] Error returned from ds-seen command In-Reply-To: <20110830113052.GB23492@phantom.vanrein.org> References: <20110830071052.GB24311@phantom.vanrein.org> <4E5C9E94.1010309@nominet.org.uk> <20110830092635.GA14466@phantom.vanrein.org> <4E5CC6F9.7040400@nominet.org.uk> <20110830113052.GB23492@phantom.vanrein.org> Message-ID: <4E5CCC72.2060000@nominet.org.uk> >> I see now, it is only when there is no existing key to retire (i.e. the >> zone is new), I have a fix for trunk (revision 5493). >> >> It changes the behaviour slightly too, as in this situation the >> enforcerd would not get a HUP; which I think was wrong. > Glad to have squeezed that one out before people really need it :-) > > The missing HUP may have been the cause of the delayed 2nd key logged. > Should this be patched into the 1.3 branch? I'm not sure if the lack of a HUP to the enforcerd if this was the first KSK in a zone was deliberate. I doubt it was, but I'd rather not break 1.3 just before we release it. I could patch a fix in which only changes the return code? Or leave it as it is. Sion From matthijs at NLnetLabs.nl Tue Aug 30 13:05:59 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 30 Aug 2011 15:05:59 +0200 Subject: [Opendnssec-develop] Enforcer NG testing In-Reply-To: References: Message-ID: <4E5CE037.1090104@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/30/2011 09:58 AM, Rickard Bellgrim wrote: > Hi > Signer configuration: > - I previously said that the KSK was marked as active, but the key > list said not. Ignore this, I think it is the correct behaviour. The > KSK tag is set when the RRSIGDNSKEY is rumoured or omnipresent, right? This sounds correct, as in these two stages the KSK is being used for signing. > key list: > - A KSK with DS, DNSKEY, and RRSIGDNSKEY marked as omnipresent does > not get marked as active What do you mean here with 'get marked as active'? Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOXOA3AAoJEA8yVCPsQCW59BoH/RTtTKXIkGU+J+3DFVKU/Osj z9HjU3ieIvrV1bgRhdbBC8Cqtd5H21lTpA/VyHEEkucnBJjwTZF1B48t2pST0ly0 EW1CX8MDdb6AxWWwpceVGpcXVxDYBmqZcEaeX7JiHrPZjrwKv4LMq6ANJ6KLoyps 2lJOOv8vah0Ofb66OUemO12XGUrXmKy+R2b2ew47IefdUN7dZofCsPsVkDc5ZaFO vhv9KEXIuWPpz0OEuAitYlCXPlCHFWmkm6Pbx2Yn5xboTG2ovdXcNWBY9p+JxcBt ABa7bZZvRFdnhzMShrZPwlsYMCgMKWbTJZo9SN5/EuDSO8tEAjGC7s0yfft7HU0= =OANy -----END PGP SIGNATURE----- From rickard at opendnssec.org Tue Aug 30 13:07:02 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 30 Aug 2011 15:07:02 +0200 Subject: [Opendnssec-develop] PIN daemon In-Reply-To: References: <361F165B-1EB8-4B2A-90D9-071676201D19@kirei.se> Message-ID: >> Would it be possible to implement this as a single PIN callback function using the current infrastructure? I.e., move everything you wrote into a single function? > > Perhaps extending the callback API to be able to indicate that it is a > retry? The current PIN module only save the PIN if we could login with > it. The PIN callback does not know if the login was successful or not. > The bad PIN would then propagate to the daemons which would get a > failed login and quit. You could have two functions: hsm_prompt_pin(unsigned int id, const char *repository, void *data, int mode); hsm_block_pin(unsigned int id, const char *repository, void *data, int mode); - "id" will have a value between zero and HSM_MAX_SESSIONS. Used for identifying the repository. - "repository" is the repository name. - "data" optional data to send to the callback function. - "mode" is the type of mode the function should run in. There are three different modes: HSM_PIN_FIRST - Used when getting the PIN for the first time. HSM_PIN_RETRY - Used when we failed to login the first time. HSM_PIN_SAVE - The latest PIN can be saved for future use. Called after a successful login. hsm_prompt_pin() + HSM_PIN_FIRST = Return the PIN from the shared memory if there is one. If not, then prompt for one. hsm_prompt_pin() + HSM_PIN_RETRY = Prompt and return a PIN. hsm_prompt_pin() + HSM_PIN_SAVE = If we have prompted for a PIN, then save it in the shared memory. hsm_block_pin() + HSM_PIN_FIRST = Wait until there is a PIN in the shared memory and then return it. hsm_block_pin() + HSM_PIN_RETRY = Return the PIN from the shared memory. hsm_block_pin() + HSM_PIN_SAVE = Nothing to save. The daemons would initialize libhsm with the hsm_block_pin() and the other applications would use hsm_prompt_pin(). A PIN will only be saved in memory if we could successfully login. hsm_block_pin() would in that case never get HSM_PIN_RETRY. It will only get it if there is an invalid PIN there from a previous run. This will happen e.g. if the user has changed the PIN in the HSM. The daemons would in that case always quit. To resolve the situation, the user should call a program which uses the hsm_prompt_pin(), e.g. "ods-hsmutil login". // Rickard From rickard at opendnssec.org Tue Aug 30 13:12:06 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 30 Aug 2011 15:12:06 +0200 Subject: [Opendnssec-develop] Enforcer NG testing In-Reply-To: <4E5CE037.1090104@nlnetlabs.nl> References: <4E5CE037.1090104@nlnetlabs.nl> Message-ID: >> key list: >> - A KSK with DS, DNSKEY, and RRSIGDNSKEY marked as omnipresent does >> not get marked as active This is my output from the key list command: Zone: Key role: DS: DNSKEY: RRSIGDNSKEY: RRSIG: Pub: Act: Id: blipp.com KSK omnipresent omnipresent omnipresent NA 1 0 27d98675ec791fd63905d430df510007 Omnipresent in all fields, but the Act column is not set to 1. Shouldn't it be considered as active? // Rickard From rick at openfortress.nl Tue Aug 30 13:15:48 2011 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 30 Aug 2011 13:15:48 +0000 Subject: [Opendnssec-develop] Re: [Opendnssec-user] Error returned from ds-seen command In-Reply-To: <4E5CCC72.2060000@nominet.org.uk> References: <20110830071052.GB24311@phantom.vanrein.org> <4E5C9E94.1010309@nominet.org.uk> <20110830092635.GA14466@phantom.vanrein.org> <4E5CC6F9.7040400@nominet.org.uk> <20110830113052.GB23492@phantom.vanrein.org> <4E5CCC72.2060000@nominet.org.uk> Message-ID: <20110830131548.GD14466@phantom.vanrein.org> Hello Sion and others, I didn't really create an issue for this -- is it useful to do that? Then I can, of course. > Should this be patched into the 1.3 branch? Perhaps that is good to do, so future users won't be confused as we were. By the time people are going to automate ds-seen it would then be fixed. If it's just us, we could patch locally. Eventually it should end up in mainstream, of course. > I'm not sure if the lack of > a HUP to the enforcerd if this was the first KSK in a zone was > deliberate. I doubt it was, but I'd rather not break 1.3 just before we > release it. > I could patch a fix in which only changes the return code? Or leave it > as it is. Others should decide on this, we will manage either way. Although it's easier if the patch is incorporated of course ;-) Cheers, -Rick From matthijs at NLnetLabs.nl Tue Aug 30 13:18:17 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 30 Aug 2011 15:18:17 +0200 Subject: [Opendnssec-develop] Enforcer NG testing In-Reply-To: References: <4E5CE037.1090104@nlnetlabs.nl> Message-ID: <4E5CE319.4030001@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/30/2011 03:12 PM, Rickard Bellgrim wrote: >>> key list: >>> - A KSK with DS, DNSKEY, and RRSIGDNSKEY marked as omnipresent does >>> not get marked as active > > This is my output from the key list command: > > Zone: Key role: DS: DNSKEY: > RRSIGDNSKEY: RRSIG: Pub: Act: Id: > blipp.com KSK omnipresent omnipresent > omnipresent NA 1 0 27d98675ec791fd63905d430df510007 > > Omnipresent in all fields, but the Act column is not set to 1. > Shouldn't it be considered as active? > > // Rickard Thanks for clarifying. To answer your question: Yes, it should. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOXOMZAAoJEA8yVCPsQCW5eZQH/3laILT4z4i/6Kc6YrfTMTz4 v8BF2gerpejbVmnwxjEe+/ctlXVU6ranB5WoxdAbP5uc84W3bqIkFgngFF+FIwp8 Wz+IHcW3pDz4py4TPmfm/93eug41u7VTUQMApgJDxBDqOF3NTRCDSxqBxf+f7MC3 b/YwcG60QY9Fftw5H7VGBMCNLf6XN4zMhRT7Rqo3dmr7k2xlTUfp8WTyuIhu1gkl yVASHa6FHl5PCM5iBn821NMS1OvNKOOUrNpeYNvlSWoWDXsBUChREfyk6udGgfM/ u8D1Sc2CqAoDu81+uFB0qspWLzS7Pqb4LKKFFmyqm8iXdslpgxInrBd5+0Kzo0Q= =ZVwi -----END PGP SIGNATURE----- From yuri at NLnetLabs.nl Tue Aug 30 13:33:49 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Tue, 30 Aug 2011 15:33:49 +0200 Subject: [Opendnssec-develop] Enforcer NG testing In-Reply-To: References: <4E5CE037.1090104@nlnetlabs.nl> Message-ID: <4E5CE6BD.2070007@nlnetlabs.nl> > Zone: Key role: DS: DNSKEY: > RRSIGDNSKEY: RRSIG: Pub: Act: Id: > blipp.com KSK omnipresent omnipresent > omnipresent NA 1 0 27d98675ec791fd63905d430df510007 > > Omnipresent in all fields, but the Act column is not set to 1. > Shouldn't it be considered as active? I think we have a lack of granularity here (and an error), due to how the signconf _used_ to work. Formerly a published KSK implied signing the DNSKEY set. We should have three flags here: published - publish dnskey record (as is now) active_ksk - sign dnskeyset active_zsk - sign zone data Currently the active flag has a different meaning depending on the role of the key, this gets extra confusing when it is a single key signing scheme. The Signer configuration does not have this ambiguity (anymore), so it is an internal Enforcer problem. I will fix this. I propose to add the extra flag to the user interface as well. But an alternative is keep the interface and have active = active_ksk|active_zsk //yuri From rick at openfortress.nl Tue Aug 30 13:41:15 2011 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 30 Aug 2011 13:41:15 +0000 Subject: [Opendnssec-develop] PIN daemon In-Reply-To: References: <361F165B-1EB8-4B2A-90D9-071676201D19@kirei.se> Message-ID: <20110830134115.GE14466@phantom.vanrein.org> Hello Rickard, The API looks like it'll work. It was not immediately clear as a result of naming, so perhaps I may suggest a few changes? Also, the overview/introduction was at the end of your explanation :) > You could have two functions: > hsm_prompt_pin(unsigned int id, const char *repository, void *data, int mode); > hsm_block_pin(unsigned int id, const char *repository, void *data, int mode); The second name confuses me. Blocking a PIN sounds like making it unusable on the token. May I suggest a name like hsm_await_pin() instead? Should there not be a function hsm_forget_pin() as well? I can imagine an operator wanting to do this without having to resort to SYSV cmdline tools that forget to clear the shared memory before setting it free! The matching control operation would be called "logout" I suppose. > - "mode" is the type of mode the function should run in. It is an enumerated value, right, not a set of OR-ed flags? > hsm_prompt_pin() + HSM_PIN_FIRST = Return the PIN from the shared > memory if there is one. If not, then prompt for one. > hsm_prompt_pin() + HSM_PIN_RETRY = Prompt and return a PIN. > hsm_prompt_pin() + HSM_PIN_SAVE = If we have prompted for a PIN, then > save it in the shared memory. Shouldn't you speak in terms of the PIN daemon with these flags? That is, _MAY_PROMPT for _FIRST and _MUST_PROMPT for _RETRY? Instead of hsm_prompt_pin() I would use a name hsm_retrieve_pin(). In the _SAVE's explanation, "we" would best be the same process, in order to avoid DoS risks by other processes running it to confuse our process. Is it not clearer to have a separate hsm_save_pin() function instead of a "mode" in a function called hsm_prompt_pin()? > The daemons would initialize libhsm with the hsm_block_pin() and the > other applications would use hsm_prompt_pin(). What happens if multiple calls from "other applications" try to get the PIN entered at the same time? I suspect it'll work, but it is worth some explicit attention. Hope this helps, Cheers, -Rick From rickard at opendnssec.org Tue Aug 30 13:48:12 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 30 Aug 2011 15:48:12 +0200 Subject: [Opendnssec-develop] Enforcer NG testing In-Reply-To: <4E5CE6BD.2070007@nlnetlabs.nl> References: <4E5CE037.1090104@nlnetlabs.nl> <4E5CE6BD.2070007@nlnetlabs.nl> Message-ID: > I think we have a lack of granularity here (and an error), due to how > the signconf _used_ to work. Formerly a published KSK implied signing > the DNSKEY set. > > We should have three flags here: > > published ?- publish dnskey record (as is now) > active_ksk - sign dnskeyset > active_zsk - sign zone data The current Enforcer does not consider the KSK active until you also have the DS-seen. Right Sion? // Rickard From sion at nominet.org.uk Tue Aug 30 13:52:05 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Tue, 30 Aug 2011 14:52:05 +0100 Subject: [Opendnssec-develop] Enforcer NG testing In-Reply-To: References: <4E5CE037.1090104@nlnetlabs.nl> <4E5CE6BD.2070007@nlnetlabs.nl> Message-ID: <4E5CEB05.8010102@nominet.org.uk> On 30/08/11 14:48, Rickard Bellgrim wrote: >> I think we have a lack of granularity here (and an error), due to how >> the signconf _used_ to work. Formerly a published KSK implied signing >> the DNSKEY set. >> >> We should have three flags here: >> >> published - publish dnskey record (as is now) >> active_ksk - sign dnskeyset >> active_zsk - sign zone data > The current Enforcer does not consider the KSK active until you also > have the DS-seen. Right Sion? > That is correct. At the point of issuing the ds-seen command the key is made active. From rickard at opendnssec.org Tue Aug 30 14:21:36 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 30 Aug 2011 16:21:36 +0200 Subject: [Opendnssec-develop] PIN daemon In-Reply-To: <20110830134115.GE14466@phantom.vanrein.org> References: <361F165B-1EB8-4B2A-90D9-071676201D19@kirei.se> <20110830134115.GE14466@phantom.vanrein.org> Message-ID: > The second name confuses me. > Blocking a PIN sounds like making it unusable on the token. > May I suggest a name like hsm_await_pin() instead? Yes > Should there not be a function hsm_forget_pin() as well? > I can imagine an operator wanting to do this without having > to resort to SYSV cmdline tools that forget to clear the > shared memory before setting it free! ?The matching control > operation would be called "logout" I suppose. That would be good. I would suggest a forth mode HSM_PIN_FORGET. >> - "mode" is the type of mode the function should run in. > > It is an enumerated value, right, not a set of OR-ed flags? Yes, enumerated value. >> hsm_prompt_pin() + HSM_PIN_FIRST = Return the PIN from the shared >> memory if there is one. If not, then prompt for one. >> hsm_prompt_pin() + HSM_PIN_RETRY = Prompt and return a PIN. >> hsm_prompt_pin() + HSM_PIN_SAVE = If we have prompted for a PIN, then >> save it in the shared memory. > > Shouldn't you speak in terms of the PIN daemon with these flags? > That is, _MAY_PROMPT for _FIRST and _MUST_PROMPT for _RETRY? > Instead of hsm_prompt_pin() I would use a name hsm_retrieve_pin(). hsm_prompt_pin() is the current PIN callback function provided by libhsm. Jakob wanted to know if the PIN daemon could be implemented as PIN callback function. To use getpass/getpassphrase, you need to run in the foreground. But we also have processes running in the background. Two simplify it, we provide two functions. One who can prompt for the PIN and the other who will wait for it to appear in the memory. And as I said, HSM_PIN_FIRST will first see if the PIN is cached before prompting for it. > In the _SAVE's explanation, "we" would best be the same process, > in order to avoid DoS risks by other processes running it to > confuse our process. Yes, that would only be local. > Is it not clearer to have a separate hsm_save_pin() function > instead of a "mode" in a function called hsm_prompt_pin()? The application initiate libhsm by proving a PIN callback function, so we only have one function to call. >> The daemons would initialize libhsm with the hsm_block_pin() and the >> other applications would use hsm_prompt_pin(). > > What happens if multiple calls from "other applications" try to get > the PIN entered at the same time? ?I suspect it'll work, but it is > worth some explicit attention. If you run hsm_prompt_pin() from two different shells (remember that we need a foreground process) at the same time, then both will ask for the PIN if there is none in the shared memory. Both will login with the PIN. And both will save the PIN in the shared memory if the login was successful. (Still using the named semaphore) // Rickard From yuri at NLnetLabs.nl Tue Aug 30 14:21:56 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Tue, 30 Aug 2011 16:21:56 +0200 Subject: [Opendnssec-develop] Enforcer NG testing In-Reply-To: <4E5CEB05.8010102@nominet.org.uk> References: <4E5CE037.1090104@nlnetlabs.nl> <4E5CE6BD.2070007@nlnetlabs.nl> <4E5CEB05.8010102@nominet.org.uk> Message-ID: <4E5CF204.6080809@nlnetlabs.nl> >>> published - publish dnskey record (as is now) >>> active_ksk - sign dnskeyset >>> active_zsk - sign zone data >> The current Enforcer does not consider the KSK active until you also >> have the DS-seen. Right Sion? > That is correct. At the point of issuing the ds-seen command the key is > made active. Could either you or Rickard elaborate on this? I assume you are talking strictly about the user interface. Tell the user the KSK is not ready as long as the DS in not fully propagated? Depending on your strategy it would be possible to introduce the RRSIG DNSKEY (active_zsk flag) without any DS activity. (I'm not arguing about the sanity of such policy). or are you implying I should never try to have the DNSKEY set signed with a key without a DS? -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From sion at nominet.org.uk Tue Aug 30 14:38:00 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Tue, 30 Aug 2011 15:38:00 +0100 Subject: [Opendnssec-develop] Enforcer NG testing In-Reply-To: <4E5CF204.6080809@nlnetlabs.nl> References: <4E5CE037.1090104@nlnetlabs.nl> <4E5CE6BD.2070007@nlnetlabs.nl> <4E5CEB05.8010102@nominet.org.uk> <4E5CF204.6080809@nlnetlabs.nl> Message-ID: <4E5CF5C8.40301@nominet.org.uk> On 30/08/11 15:21, Yuri Schaeffer wrote: > >> That is correct. At the point of issuing the ds-seen command the key is >> made active. > Could either you or Rickard elaborate on this? > > I assume you are talking strictly about the user interface. Tell the > user the KSK is not ready as long as the DS in not fully propagated? > Yes, as soon as the key is included in a zone it is used, but "key list" will not indicate that. The transition to active is triggered by the user, which starts the key retirement clock. > Depending on your strategy it would be possible to introduce the RRSIG > DNSKEY (active_zsk flag) without any DS activity. (I'm not arguing about > the sanity of such policy). > > or are you implying I should never try to have the DNSKEY set signed > with a key without a DS? > From sion at nominet.org.uk Wed Aug 31 07:52:00 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Wed, 31 Aug 2011 08:52:00 +0100 Subject: [Opendnssec-develop] Re: [Opendnssec-user] Error returned from ds-seen command In-Reply-To: <20110830131548.GD14466@phantom.vanrein.org> References: <20110830071052.GB24311@phantom.vanrein.org> <4E5C9E94.1010309@nominet.org.uk> <20110830092635.GA14466@phantom.vanrein.org> <4E5CC6F9.7040400@nominet.org.uk> <20110830113052.GB23492@phantom.vanrein.org> <4E5CCC72.2060000@nominet.org.uk> <20110830131548.GD14466@phantom.vanrein.org> Message-ID: <4E5DE820.4080508@nominet.org.uk> On 30/08/11 14:15, Rick van Rein wrote: > Hello Sion and others, > > I didn't really create an issue for this -- is it useful to do that? > Then I can, of course. > I think it is fine as it is, the svn commit message should have enough information to find the reason for the change. >> Should this be patched into the 1.3 branch? > Perhaps that is good to do, so future users won't be confused > as we were. By the time people are going to automate ds-seen > it would then be fixed. > > If it's just us, we could patch locally. Eventually it should > end up in mainstream, of course. > >> I'm not sure if the lack of >> a HUP to the enforcerd if this was the first KSK in a zone was >> deliberate. I doubt it was, but I'd rather not break 1.3 just before we >> release it. >> I could patch a fix in which only changes the return code? Or leave it >> as it is. > Others should decide on this, we will manage either way. Although > it's easier if the patch is incorporated of course ;-) > > > Cheers, > -Rick Okay. I'll commit the same patch to the 1.3 branch at 9:30 BST (that's 10:30 for you folks ;) ) unless anyone objects before then. Sion From rickard at opendnssec.org Wed Aug 31 08:20:10 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 31 Aug 2011 10:20:10 +0200 Subject: [Opendnssec-develop] HSM reopen In-Reply-To: <4E57AB4E.5060809@nominet.org.uk> References: <4E561C0E.2010508@nominet.org.uk> <4E57AB4E.5060809@nominet.org.uk> Message-ID: >> I think we could implement a more simpler NO-OP in libhsm so that we >> do not need to count keys. Just to see that the sessions still work. >> > > That would be good. Shall I add this code to trunk now, or wait until libhsm > has this call? I have added hsm_check_context() in r5499. It will perform checks on all open sessions in the context: * Get session info and check if we still are logged in. * Try open and close a session with the same slotID. // Rickard From owner-dnssec-trac at kirei.se Wed Aug 31 12:02:24 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 31 Aug 2011 12:02:24 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #261: Add a command to force a key from publish-state to ready-state Message-ID: <047.b037f9bb429da3778c489b0a012e1a66@kirei.se> #261: Add a command to force a key from publish-state to ready-state ------------------------+--------------------------------------------------- Reporter: anonymous | Owner: sion Type: enhancement | Status: new Priority: trivial | Component: Enforcer Version: trunk | Keywords: ------------------------+--------------------------------------------------- Waiting for this is a pain it the A** when doing labs. /Guess who! -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Wed Aug 31 13:29:27 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Wed, 31 Aug 2011 14:29:27 +0100 Subject: [Opendnssec-develop] HSM reopen In-Reply-To: References: <4E561C0E.2010508@nominet.org.uk> <4E57AB4E.5060809@nominet.org.uk> Message-ID: <4E5E3737.70303@nominet.org.uk> On 31/08/11 09:20, Rickard Bellgrim wrote: > I have added hsm_check_context() in r5499. It will perform checks on > all open sessions in the context: > * Get session info and check if we still are logged in. > * Try open and close a session with the same slotID. The call to that code is now in trunk... I have tested it by deliberately invalidating my hsm_ctx_t; I have to assume that this is what a connection timeout will look like. Sion